{"id":97349,"date":"2020-10-17T14:42:14","date_gmt":"2020-10-17T12:42:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh"},"modified":"2020-10-17T14:42:14","modified_gmt":"2020-10-17T12:42:14","slug":"minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","title":{"rendered":"Minimering av risikoene ved bruk av DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MinimeringMinimering av risikoene ved bruk av DoH og DoT<\/p>\n

Beskyttelse mot DoH og DoT<\/h2>\n

Kontrollerer du DNS-trafikken din? Organisasjoner investerer mye tid, penger og krefter i \u00e5 sikre nettopp sine nettverk. Imidlertid er det et omr\u00e5de som ofte f\u00e5r lite oppmerksomhet, nemlig DNS. <\/p>\n

En god oversikt over risikoene som DNS medf\u00f8rer er presentasjonen fra Verisign<\/a><\/noindex> p\u00e5 konferansen Infosecurity. <\/p>\n

\"Minimering31 % av de unders\u00f8kte ransomware-klassene brukte DNS for n\u00f8kkelutveksling. Konklusjonene fra studien<\/p>\n

31 % av de unders\u00f8kte ransomware-klassene brukte DNS for n\u00f8kkelutveksling.<\/p>\n

Problemet er alvorlig. If\u00f8lge forskningslaboratoriet Palo Alto Networks Unit 42, benytter omtrent 85 % av skadelig programvare DNS for \u00e5 etablere kommandokontrollkanaler, noe som gir angripere lett tilgang til \u00e5 infiltrere skadelig programvare i nettverket ditt, samt stjele data. Siden oppstarten har DNS-trafikken stort sett v\u00e6rt ukryptert og lett analysert av NGFW-beskyttelsesmekanismer. <\/p>\n

Det har dukket opp nye protokoller for DNS som har som m\u00e5l \u00e5 forbedre personvernet i DNS-tilkoblinger. Disse f\u00e5r aktiv st\u00f8tte fra ledende nettleserleverand\u00f8rer og andre programvareleverand\u00f8rer. Snart vil det skje en \u00f8kning i kryptert DNS-trafikk i bedriftsnettverk. Kryptert DNS-trafikk, som ikke analyseres p\u00e5 riktig m\u00e5te og deretter er tillatt, utgj\u00f8r en sikkerhetstrussel for selskapet. For eksempel er en slik trussel kryptolokere som bruker DNS til \u00e5 utveksle krypteringsn\u00f8kler. Angripere krever n\u00e5 l\u00f8sepenger i millionklassen for \u00e5 gjenopprette tilgang til dataene dine. I selskapet Garmin, for eksempel, betalte de 10 millioner dollar.<\/p>\n

Med riktig konfigurasjon kan NGFW-er forby eller beskytte bruken av DNS-over-TLS (DoT) og kan brukes til \u00e5 forby bruken av DNS-over-HTTPS (DoH), noe som gj\u00f8r det mulig \u00e5 analysere all DNS-trafikk i nettverket ditt.<\/p>\n

Hva er kryptert DNS?<\/h2>\n

Hva er DNS<\/p>\n

Domain Name System (DNS) konverterer lesbare domenenavn (for eksempel adressen www.paloaltonetworks.com<\/a><\/noindex> ) til IP-adresser (for eksempel 34.107.151.202). N\u00e5r en bruker skriver inn et domenenavn i nettleseren, sender nettleseren et DNS-foresp\u00f8rsel til DNS-serveren for \u00e5 be om IP-adressen knyttet til dette domenenavnet. Som svar returnerer DNS-serveren IP-adressen som nettleseren vil bruke.<\/p>\n

DNS-foresp\u00f8rselene og svarene sendes over nettverket som vanlig tekst i ukryptert form, noe som gj\u00f8r dem s\u00e5rbare for overv\u00e5kning eller endring av svaret, samt \u00e5 omdirigere nettleseren til ondsinnede servere. Kryptering av DNS gj\u00f8r det vanskeligere \u00e5 overv\u00e5ke DNS-foresp\u00f8rselene eller endre dem under overf\u00f8ringen. Kryptering av DNS-foresp\u00f8rslene og svarene beskytter deg mot Man-in-the-Middle-angrep, samtidig som det utf\u00f8rer de samme funksjonene som den tradisjonelle DNS-protokollen (domenenavnsystemet) i klartekst. <\/p>\n

I l\u00f8pet av de siste \u00e5rene har to protokoller for kryptering av DNS blitt implementert:<\/p>\n

    \n
  1. \n

    DNS-over-HTTPS (DoH)<\/p>\n<\/li>\n

  2. \n

    DNS-over-TLS (DoT) <\/p>\n<\/li>\n<\/ol>\n

    Disse protokollene har ett felles trekk: de skjuler bevisst DNS-foresp\u00f8rslene fra enhver overv\u00e5kning\u2026 inkludert fra selskapets sikkerhetsfolk. Protokollene bruker hovedsakelig TLS (Transport Layer Security) for \u00e5 etablere en kryptert tilkobling mellom klienten som sender foresp\u00f8rslene og serveren som l\u00f8ser DNS-foresp\u00f8rslene, gjennom en port som vanligvis ikke brukes for DNS-trafikk.<\/p>\n

    Personvernet til DNS-foresp\u00f8rslene er en stor fordel med disse protokollene. Imidlertid skaper de problemer for sikkerhetsfolk som m\u00e5 overv\u00e5ke nettverkstrafikken og oppdage og blokkere ondsinnede forbindelser. Siden protokollene varierer i implementeringen, vil analysmetodene v\u00e6re forskjellige for DoH og DoT.<\/p>\n

    DNS over HTTPS (DoH)<\/h2>\n

    \"MinimeringDNS inne i HTTPS<\/p>\n

    DoH bruker den velkjente porten 443 for HTTPS, for hvilken RFC spesifikt sier at oppgaven er \u00e5 'blande DoH-trafikk med annen HTTPS-trafikk i samme forbindelse', 'vanskeliggj\u00f8re analysen av DNS-trafikken', og dermed omg\u00e5 tiltak for bedriftskontroll ( RFC 8484 DoH, avsnitt 8.1<\/a><\/noindex> ). DoH-protokollen bruker TLS-kryptering og syntaks for foresp\u00f8rslene som tilbys av vanlige standarder for HTTPS og HTTP\/2, som legger DNS-foresp\u00f8rslene og svarene opp\u00e5 standard HTTP-foresp\u00f8rslene.<\/p>\n

    Risikoene forbundet med DoH<\/h2>\n

    Hvis du ikke kan skille almindelig HTTPS-trafik fra DoH-anmodninger, kan applikationer inden for din organisation (og vil) omg\u00e5 lokale DNS-indstillinger ved at omdirigere anmodninger til eksterne servere, der besvarer DoH-anmodninger, hvilket underminerer enhver overv\u00e5gning og dermed eliminerer muligheden for kontrol over DNS-trafik. Ideelt set b\u00f8r du kontrollere DoH ved at anvende HTTPS-dekrypteringsfunktioner. <\/p>\n

    Og b\u00e5de Google og Mozilla har implementeret DoH-funktionalitet<\/a><\/noindex> i den seneste version af deres browsere, og begge virksomheder arbejder p\u00e5 at g\u00f8re DoH til standard for alle DNS-anmodninger. Microsoft udvikler ogs\u00e5 planer<\/a><\/noindex> om at integrere DoH i sine operativsystemer. En ulempe er, at ikke kun anerkendte softwareudviklingsvirksomheder men ogs\u00e5 ondsindede akt\u00f8rer er begyndt at anvende DoH som et middel til at omg\u00e5 traditionelle foranstaltninger i virksomhedens firewall. (Se for eksempel f\u00f8lgende artikler: PsiXBot bruger nu Google DoH<\/a><\/noindex> , PsiXBot forts\u00e6tter med at udvikle sig med en opdateret DNS-infrastruktur<\/a><\/noindex> og analyse af Godlua-backdoor<\/a><\/noindex> .) Uanset hvad, vil b\u00e5de god og skadelig DoH-trafik forblive uset, hvilket efterlader organisationen blind over for den ondsindede brug af DoH som en kanal til styring af malware (C2) og tyveri af fortrolige data.<\/p>\n

    At sikre synlighed og kontrol over DoH-trafik<\/h2>\n

    Som den bedste l\u00f8sning til kontrol over DoH anbefaler vi at konfigurere HTTPS-dekryptering og blokering af DoH-trafik i NGFW (programnavn: dns-over-https). <\/p>\n

    F\u00f8rst, s\u00f8rg for at NGFW er konfigureret til at dekryptere HTTPS i henhold til retningslinjerne for bedste praksis for dekryptering<\/a><\/noindex>.<\/p>\n

    For det andet, opret en regel for applikationstrafik \"dns-over-https\", som vist nedenfor:<\/p>\n

    \"MinimeringPalo Alto Networks NGFW-regel til blokering af DNS-over-HTTPS<\/p>\n

    Som en midlertidig alternativ (hvis din organisation ikke har implementeret HTTPS-dekryptering fuldt ud) kan NGFW konfigureres til at anvende en \"forhindre\"-handling p\u00e5 applikations-id'et \"dns-over-https\", men effekten vil v\u00e6re begr\u00e6nset til at blokere bestemte velkendte DoH-servere ved deres dom\u00e6nenavn, da DoH-trafik ikke kan kontrolleres fuldt ud uden dekryptering af HTTPS (se.  Applipedia fra Palo Alto Networks<\/a><\/noindex>   og s\u00f8g efter udtrykket \"dns-over-https\").<\/p>\n

    DNS over TLS (DoT)<\/h2>\n

    \"MinimeringDNS inde i TLS<\/p>\n

    Mens protokoll DoH strever etter \u00e5 blande seg med annen trafikk p\u00e5 samme port, bruker DoT derimot som standard en spesialport, reservert for dette ene form\u00e5let, og forbyr spesifikt bruk av samme port for tradisjonell ukryptert DNS-trafikk ( RFC 7858, Seksjon 3.1<\/a><\/noindex> ).<\/p>\n

    Protokoll DoT bruker TLS-protokollen for \u00e5 sikre kryptering som innkapsler standard foresp\u00f8rselene til DNS-protokollen, med trafikk som bruker den velkjente porten 853 ( RFC 7858, seksjon 6<\/a><\/noindex> ). Protokollen DoT ble utviklet for \u00e5 forenkle for organisasjoner i \u00e5 blokkere trafikk p\u00e5 porten, eller \u00e5 tillate bruk av den, men inkludere dekryptering p\u00e5 denne porten.<\/p>\n

    Risikoer forbundet med DoT<\/h2>\n

    Google implementerte DoT i sin klient Android 9 Pie og senere versjoner<\/a><\/noindex> , med standardinnstillingen automatisk p\u00e5sl\u00e5tt for bruk av DoT n\u00e5r det er tilgjengelig. Hvis du har vurdert risikoene og er klar til \u00e5 bruke DoT p\u00e5 organisasjonsniv\u00e5, m\u00e5 nettverksadministratorer eksplisitt tillate utg\u00e5ende trafikk p\u00e5 port 853 gjennom sin perimeter for dette nye protokoll.<\/p>\n

    Sikre synlighet og kontroll over DoT-trafikk<\/h2>\n

    Som beste praksis for kontroll av DoT anbefaler vi noe av det ovennevnte, avhengig av kravene til organisasjonen din:<\/p>\n