Harald Brombach (digi.no) Skrevet 6. august 2019 Del Skrevet 6. august 2019 Får hjelp fra Mnemonic til å ta MailRisk-tjenesten ut i verden [Ekstra] Lenke til kommentar
-Night- Skrevet 6. august 2019 Del Skrevet 6. august 2019 (endret) Spenstig at mnemonic lever en tjeneste som de kalle for "secure" DNS uten støtte for DNSSEC, som gjør denne langt i fra sikker og åpen for MITM angrep samt manipulering i stor grad. Edit: DNSSEC er noe Difi også anbefaler for tjenestetilbydere. Hvor er IPv6 støtte forresten? night@apps:~$ dig www.dnssec-failed.org @54.76.198.100 +dnssec +multi ; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> www.dnssec-failed.org @54.76.198.100 +dnssec +multi ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5230 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; ANSWER SECTION: www.dnssec-failed.org. 7200 IN A 68.87.109.242 www.dnssec-failed.org. 7200 IN A 69.252.193.191 www.dnssec-failed.org. 7200 IN RRSIG A 5 3 7200 ( 20190811174436 20190804143936 44973 dnssec-failed.org. DbBl0serI0KDtZE/gmhcu6opLU7RFlS6KNnuNm8WoVAq sEFWFM4UM+n8Hip8859V9zeH8H00zHhBYQx62QozyVNE GGe7kJ5LvynOnSeWiQdwd8RENHYZ4+k8FDRDUqUb7A7j sfZmM0A/SAnBG0gA7Sb3kRYrZrES8d2ufdJEZ1I= ) ;; Query time: 538 msec ;; SERVER: 54.76.198.100#53(54.76.198.100) ;; WHEN: ti. aug. 06 09:29:32 CEST 2019 ;; MSG SIZE rcvd: 259 night@apps:~$ dig www.dnssec-failed.org @52.28.79.14 +dnssec +multi ; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> www.dnssec-failed.org @52.28.79.14 +dnssec +multi ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4807 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; ANSWER SECTION: www.dnssec-failed.org. 7200 IN A 68.87.109.242 www.dnssec-failed.org. 7200 IN A 69.252.193.191 www.dnssec-failed.org. 7200 IN RRSIG A 5 3 7200 ( 20190811174436 20190804143936 44973 dnssec-failed.org. DbBl0serI0KDtZE/gmhcu6opLU7RFlS6KNnuNm8WoVAq sEFWFM4UM+n8Hip8859V9zeH8H00zHhBYQx62QozyVNE GGe7kJ5LvynOnSeWiQdwd8RENHYZ4+k8FDRDUqUb7A7j sfZmM0A/SAnBG0gA7Sb3kRYrZrES8d2ufdJEZ1I= ) ;; Query time: 122 msec ;; SERVER: 52.28.79.14#53(52.28.79.14) ;; WHEN: ti. aug. 06 09:31:24 CEST 2019 ;; MSG SIZE rcvd: 259 Forventet resultat night@apps:~$ dig www.dnssec-failed.org @1.1.1.1 +dnssec +multi ; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> www.dnssec-failed.org @1.1.1.1 +dnssec +multi ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16020 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 120 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: ti. aug. 06 09:31:39 CEST 2019 ;; MSG SIZE rcvd: 39 Endret 6. august 2019 av -Night- Lenke til kommentar
Lars Are @ mnemonic Skrevet 8. august 2019 Del Skrevet 8. august 2019 Hei @Night! Så bra at du tester vår gratis sikre DNS tjeneste. Du har helt rett i at våre DNS tjenere ikke benytter «STRICT» validering av DNSSEC, som du helt korrekt viser med ditt eksempel. Her er det to forskjellige dimensjoner av «Secure» og vi benytter én av dimensjonene i vår offentlig annonserte DNS tjeneste, men ikke den andre. Hvis du vil teste en DNSSEC STRICT tjener, kan du spørre en av våre andre DNS tjenere, som du finner her: 52.214.41.72 og her: 18.194.101.249. Disse benytter begge dimensjonene av Secure og skal gi deg SERVFAIL i tilfelle valideringsfeil på DNSSEC. Vi følger utviklingen av DNSSEC nøye og skulle gjerne sett at alle domener benyttet seg av denne sikkerhetsmekanismen. Da kunne vi benyttet det som i DNSSEC kalles STRICT validering av alle DNS forespørseler som kommer til oss og svart med SERVFAIL til brukerne, som du påpeker. Slik det er i dag, validerer vi alle forespørsler som kommer til oss på alle DNS tjenerne vi drifter. På grunn av mange falske positive, logger vi imidlertid kun dette hos oss, men viser det ikke til brukeren. Årsaken til at vi ikke har slått på DNSSEC STRICT validering på de DNS tjenerne vi har publisert på nettsidene våre er at, slik vi ser det, Internett i sin helhet ikke klar for Strict validering av DNSSEC på det nåværende tidspunkt. En litt for stor prosentandel av legitime nettsider støtter i dag ikke DNSSEC, eller har implementert støtte for det, men feiler på validering. For en vanlig bruker vil bruk av DNSSEC Strict serverne våre gi en del falske positive. Våre DNS tjenere er først og fremt benyttet av bedrifter som peker sine DNS tjenere mot våre, samt sluttbrukere som legger de inn i sine hjemmeroutere. Vi har derfor ikke full kontroll på hvordan disse igjen forteller brukerne sine at et domene ikke validerer. På grunn av hvordan DNSSEC fungerer, der det sendes SERVFAIL tilbake til bedriftens DNS tjener og dette ikke nødvendigvis presenteres på en god måte for brukeren, er det vanskelig for brukeren å forstå hvorfor han ikke kommer frem til domenet han prøver å nå. Dette er et felt som er i konstant utvikling og i fremtiden kommer nok DNSSEC støtte på plass i flere og flere produkter. Det er imidlertid derfor vi har valgt å ikke ha det som standard på våre åpent tilgjengelige DNS tjenere nå. Vi har relativt mange brukere på de IPene jeg nevner over. Forskjellen fra de publiserte IPene til disse med DNSSEC Strict validering er at vi har en dialog med de som bruker disse DNS serverne om hva dette innebærer av feilkilder. Så, hvorfor mener vi fortsatt at vi kan kalle vår DNS tjeneste «secure»? Det vi gjør i vår SecureDNS tjeneste, er å sjekke hvert eneste oppslag mot et dynamisk sett med IPer, domener og URLer vi kategoriserer som ondsinnet. Dette er lister vi samler inn gjennom vår trusseletterretning og som vårt operasjonssenter, vår «SOC» klassifiserer som ondsinnede. Dette mener vi gir oss et godt grunnlag for å si noe om hvilke nettsider du helst ikke bør besøke. Dette er den merverdien vi tilfører brukerne av våre DNS tjenere og årsaken til at vi kaller tjenesten for SecureDNS. I de tilfellene du gjør oppslag etter en av disse IPene, blir du i stedet for å få servert den ondsinnede IPen gitt IPen til en blokkside vi har satt opp. Eksempelvis slik som denne: http://52.17.197.206/ For å teste om du har satt opp vår SecureDNS riktig og blir sikret av oss, kan du prøve å gå til http://eicar.mnemonic.no/. Vi har sett at andre store tilbydere av DNS har begynt å tilby DNSSEC Strict validering og har sett litt på hvordan de kan gjøre det uten å få mange falske positive. Ved å ettergå kjente sider vi vet ikke validerer, men som vi ikke får SERVFAIL på hos disse tilbyderne, kan det se ut til at de vedlikeholder lister over godkjente domener som ikke validerer på DNSSEC, men som fortsatt brukerne får tilgang til. Dette har vi valgt å ikke gjøre og heller satse på våre egne blokklister. DNS tjenerne våre støtter i dag navneoppslag på IPv6, men selve DNS tjenerne er enda ikke tilgjengelige på v6. Årsaken til det er rett og slett hittil manglende etterspørsel. Har du flere spørsmål er det bare å ta kontakt! -Lars Are 2 Lenke til kommentar
-Night- Skrevet 8. august 2019 Del Skrevet 8. august 2019 (endret) Hei @Night! Så bra at du tester vår gratis sikre DNS tjeneste. Du har helt rett i at våre DNS tjenere ikke benytter «STRICT» validering av DNSSEC, som du helt korrekt viser med ditt eksempel. Her er det to forskjellige dimensjoner av «Secure» og vi benytter én av dimensjonene i vår offentlig annonserte DNS tjeneste, men ikke den andre. Hvis du vil teste en DNSSEC STRICT tjener, kan du spørre en av våre andre DNS tjenere, som du finner her: 52.214.41.72 og her: 18.194.101.249. Disse benytter begge dimensjonene av Secure og skal gi deg SERVFAIL i tilfelle valideringsfeil på DNSSEC. Vi følger utviklingen av DNSSEC nøye og skulle gjerne sett at alle domener benyttet seg av denne sikkerhetsmekanismen. Da kunne vi benyttet det som i DNSSEC kalles STRICT validering av alle DNS forespørseler som kommer til oss og svart med SERVFAIL til brukerne, som du påpeker. Slik det er i dag, validerer vi alle forespørsler som kommer til oss på alle DNS tjenerne vi drifter. På grunn av mange falske positive, logger vi imidlertid kun dette hos oss, men viser det ikke til brukeren. Årsaken til at vi ikke har slått på DNSSEC STRICT validering på de DNS tjenerne vi har publisert på nettsidene våre er at, slik vi ser det, Internett i sin helhet ikke klar for Strict validering av DNSSEC på det nåværende tidspunkt. En litt for stor prosentandel av legitime nettsider støtter i dag ikke DNSSEC, eller har implementert støtte for det, men feiler på validering. For en vanlig bruker vil bruk av DNSSEC Strict serverne våre gi en del falske positive. Våre DNS tjenere er først og fremt benyttet av bedrifter som peker sine DNS tjenere mot våre, samt sluttbrukere som legger de inn i sine hjemmeroutere. Vi har derfor ikke full kontroll på hvordan disse igjen forteller brukerne sine at et domene ikke validerer. På grunn av hvordan DNSSEC fungerer, der det sendes SERVFAIL tilbake til bedriftens DNS tjener og dette ikke nødvendigvis presenteres på en god måte for brukeren, er det vanskelig for brukeren å forstå hvorfor han ikke kommer frem til domenet han prøver å nå. Dette er et felt som er i konstant utvikling og i fremtiden kommer nok DNSSEC støtte på plass i flere og flere produkter. Det er imidlertid derfor vi har valgt å ikke ha det som standard på våre åpent tilgjengelige DNS tjenere nå. Vi har relativt mange brukere på de IPene jeg nevner over. Forskjellen fra de publiserte IPene til disse med DNSSEC Strict validering er at vi har en dialog med de som bruker disse DNS serverne om hva dette innebærer av feilkilder. Så, hvorfor mener vi fortsatt at vi kan kalle vår DNS tjeneste «secure»? Det vi gjør i vår SecureDNS tjeneste, er å sjekke hvert eneste oppslag mot et dynamisk sett med IPer, domener og URLer vi kategoriserer som ondsinnet. Dette er lister vi samler inn gjennom vår trusseletterretning og som vårt operasjonssenter, vår «SOC» klassifiserer som ondsinnede. Dette mener vi gir oss et godt grunnlag for å si noe om hvilke nettsider du helst ikke bør besøke. Dette er den merverdien vi tilfører brukerne av våre DNS tjenere og årsaken til at vi kaller tjenesten for SecureDNS. I de tilfellene du gjør oppslag etter en av disse IPene, blir du i stedet for å få servert den ondsinnede IPen gitt IPen til en blokkside vi har satt opp. Eksempelvis slik som denne: http://52.17.197.206/ For å teste om du har satt opp vår SecureDNS riktig og blir sikret av oss, kan du prøve å gå til http://eicar.mnemonic.no/. Vi har sett at andre store tilbydere av DNS har begynt å tilby DNSSEC Strict validering og har sett litt på hvordan de kan gjøre det uten å få mange falske positive. Ved å ettergå kjente sider vi vet ikke validerer, men som vi ikke får SERVFAIL på hos disse tilbyderne, kan det se ut til at de vedlikeholder lister over godkjente domener som ikke validerer på DNSSEC, men som fortsatt brukerne får tilgang til. Dette har vi valgt å ikke gjøre og heller satse på våre egne blokklister. DNS tjenerne våre støtter i dag navneoppslag på IPv6, men selve DNS tjenerne er enda ikke tilgjengelige på v6. Årsaken til det er rett og slett hittil manglende etterspørsel. Har du flere spørsmål er det bare å ta kontakt! -Lars Are Hei Lars, Takk for utfyllende svar de to andre serveren du oppga funker knall og gir svar som er forventet. Secure har mange elementer i seg og mange lag, hva man tar i bruk og til hvilket trusselbilde man befinner seg i vil sette kriteriene for hva man kan og ikke kan kalle sikkert nok eller om man setter smør på flesk Det er selvsagt forskjell på Ole Hansen som spiller CS på gutterommet, Blomsterbutikken til Ari Behn og en offentligetat, de to siste nevnte er uansett underlagt GDPR som setter krav på dem for personvern og kontroll på informasjonsflyt. DNSSEC vil hjelpe disse sammen med StartTLS, PKI.... osv være sikre på at de kobler seg til rettsted. DNS er uansett veiviseren på nettet og uten elementærsikring i mot mitm og annen omdirigering så er man ofte blind, og da har man ikke sikkerhet på første nivet selv om andre nivåer om satt opp riktig vil avdekke og hindre(client sertifikater og andre metoder for fingerpritinging) Jeg vedgår kan ha vert lit kjapp på avtrekkeren når det kommer til secure, det beklager jeg. Erfaringen som vi har her og som har innhentet via samarbeid med andre bedrifter er gode ved bruk av DNSSEC validering også der det er delt domene for intern / ekstern bruk, etter at det ble implementert var det ingen virksomhetkritisk utfall foruten avdekking av feil hos en stor leverandør i Norge sine rutiner som ble rettet samme dag av den leverandøren. DNSEC er som IPv6 burde ikke lenger være en nice to have men et krav for for tjenesteleverandøren at de både har det på tjeneste de lever til bedrifter og ikke minst sluttbruker. Hos hjemmebruker slik som Telenor, Get, CD osv har de alt innført DNSSEC validering på sine tjenester imot sluttbrukere uten at det er noe dramaskrik, de sidene som har implementert DNSSEC hvor det gir serverfeil utsalg er feil konfigurert og lett fiks. og det er bra at de store presser på med dette, det burde de forsette med på like linje som Google presser på med bruk av https. Domeneshop har forresten også innført DNSSEC, DMARC og DKIM for alle dem sine kunder. Jeg husker ikke i farte om de også tok DANE men det er en annen diskusjon, trenden er uansett av tjenesteleverandørene tar i bruk elementær funksjoner i DNS for sikkerhet. Når det kommer til bedriftnettverk med lokale domener og oppslag så er vell ikke mnemonic første server den går til heller den som nettverket slår opp på utgående trafikk? Uansett er der det metoder for og løse dette slik som, slette alle conditional forwarders og opprette AD intrigerte soner på DNS-serverne i x.bedrift.no eller hva du enn vill slik at oppslag til alle relevante servere i ressurs-domenene er opprettet og vedlikeholdt statisk, en kan også ta skrittet ved å implementert DNSSEC på ressurs domene. Det er selvsagt ingen sølvkule og en hvert miljø må tilpasses og til tider også moderniseres og integreres på tvers av miljøer, som mange andre sliter mye med tekniskgjeld og DNS er dessverre ikke høyt prioritet siden det funker (inntil det smeller). Så tjenesteutsetting av DNS er utelukkende positivt men krever at en er kjent med sit trusselbilde og riskoapetitt. Oppslag og verifisering i mot lister(både automatisk sjekk og manuelle tilføringen fra div cert miljøer rundt om i verden ) er veldig bra og er positivt for helheten i DNS og internet kodus for det og bra at det er flere som tilbyr enn kun en håndfull alltid bra med norsk utviklet (ref. buypass) . Hvordan tar dere her hensyn til nye skytjenester der IPer bytter med raske mellomrom er det er kun URL eller en kombinasjon av URL og automatiske tester i mot siden? IPv6 er forresten ikke lenger nice to have men et krav, eller slik som flere ansatte i Google sier. har du ikke IPv6 har du ikke internet, ikke minst nå som RIPE har opprettet ventelister på Iper viser det hvor viktig dette er. med utrulling av 5G blir vi nok og see utstrakt bruk av CGN for ipv4 og nativ IPv6 slik som telenor gjør idag på sine APN, (telia er en sinke her), Dette gjør at det vil bli treger response i fra dere og kall kan avlyttes/logges siden DNS er ukryptert med mindre man tar i bruk DoT/DoH eller DNSCrypt som alle skaper flere avhengigheter som tar meg tilbake til starten vurder din riskoapetitt og velg tjenester deretter. Edit: Sjekket lit etter ECS støtte, så ikke det ved en rask overblikk, dette kan blir problematisk for CDN og bedrifter som bruker mye sky eller streaming, ved at de blir sent til et datasenter som er nærme Norge og ikke det landet de faktisk befinner seg i. Sjekket ikke så alt for mye etter de så gjerne korriger men om jeg har feil. DNS har uansett blitt mye mer avansert og viktig de siste årene og det krever at man holder tungen rett i munnen og følger med mye nye standard og utvidelser av DNS. Domeneshop hadde vist også tatt seg av DANE, dette er veldig bra at det blir mer utbredt ikke minst at de som er tjenesteleverandør faktisk gjør tiltak på vegne av kundene som helhet så er det heller opt-out isteden for opt-inn når det kommer til sikkerhet. Det er en prinsipp som flere burde følge av de som levere tjenester både når de er gratis tjenester og de som er underlagt SLA krav. Edit 2: Kom gjerne med lit informasjon om falske positive som dere opplever med dnssec, da dette er av interesse, vi hadde selv noen utfordringer med DNSSEC når det først ble etablert på våre domener men dette ble løst i samarbeid med microsoft og aktuelle internet leverandør mv Endret 9. august 2019 av -Night- Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå