Vakava tietoturva: kuinka vapautetut tYpOs voivat parantaa DNS-suojausta

Vuosien varrella olemme kirjallinen ja puhuttu Naked Securityssa monta kertaa DNS-ongelmasta kaappaus.

DNS, kuten luultavasti tiedät, on lyhenne sanoista verkkotunnuksen järjestelmä, ja kuulet sen usein kuvattavan Internetin "puhelinluetteloksi" tai "lehtikirjaksi".

Jos sana ei ole sinulle tuttu gazeteer, se viittaa kartaston takana olevaan hakemistoon, josta katsot esimerkiksi Monrovia, Liberia kätevässä aakkosluettelossa, ja se sanoo jotain sellaista 184 - C4. Tämä käskee sinua kääntymään suoraan sivulle 184 ja seuraamaan ruudukkoviivoja alaspäin C-kirjaimesta kartan yläosassa ja vasemmalla olevaa numeroa 4 vastapäätä. Siellä missä rivit kohtaavat, löydät Monrovian.

Useimmille käyttäjille useimmat DNS-haut sisältävät palvelimen nimen ja pyytävät vastausta, joka sisältää niin sanotun A-tietueen tai AAAA-tietueen.

(A-tietueita käytetään 32-bittisille IPv4-internet-numeroille, kuten 203.0.113.42; AAAA-tietueet ovat vastaavia vastauksia 128-bittisille IPv6-osoitteille, kuten esim. 2001:db8:15a:d0c::42 – Tässä artikkelissa käytämme vain A-tietueita ja IPv4-numeroita, mutta samat tietoturvaongelmat koskevat hakuprosessia molemmissa tapauksissa.)

Tässä on esimerkki, jossa etsimme kuvitteellista verkkotunnuksen nimeä naksec.test DNS-palvelimen kautta, joka on erityisesti luotu seuraamaan ja opettamaan sinulle DNS-liikennettä.

Olemme käyttäneet vanhan koulun Linux-työkalua dig, lyhenne jstk verkkotunnuksen Internet-groper, luodaksesi yksinkertaisen DNS-pyynnön (dig oletuksena etsii A-tietueita) haluamalta palvelimelta:

$ dig +noedns @127.42.42.254 naksec.test ;; KYSYMYSOSA: ;naksec.test. JONKIN SISÄLLÄ ;; VASTAUSOSA: NAKSEC.TESTI. 5 IN A 203.0.113.42 ;; Kyselyaika: 1 ms ;; PALVELIN: 127.42.42.254#53(127.42.42.254) (UDP) ;; MILLOIN: ma 23. tammikuuta 14:38:42 GMT 2023 ;; MSG-KOKO rcvd: 56

DNS-palvelimemme käsitteli pyynnön seuraavasti: saapuvasta pyynnöstä näkyy heksadesimaattinen vedos ja onnistunut vastaus, joka palasi:

---> Pyyntö 127.0.0.1:57708 - 127.42.42.254:53 ---> 00000000 62 4e 01 20 00 01 00 00 00 00 00 00 06 6b |b. .........nak| 61 6 00000010 73 65 63 04 74 65 73 74 00 00 01 |sek.testi..... | DNS-haku: A-tietue for naksec.test ==> A=00 <--- Vastaa 01:203.0.113.42 - 127.42.42.254:53 <--- 127.0.0.1 57708 00000000e 62 4 84 0 00 01 00 01 00e 00 00b |bN.........nak| 00 06 6 61 6 00000010 73 65 63 04 74 65 73 74 00 00e 01 |sek.testi......NA| 00 01b 06 4 41 00000020 4 53 45 43 04 54 45 53 54 00 00 |KSEC.TESTI.......| 01 00 01 00 00 cb 00000030 00 05a |......q* |

Huomaa, että suorituskykysyistä useimmat DNS-pyynnöt käyttävät UDP:tä käyttäjän datagrammiprotokolla, joka toimii lähetä ja toivo -periaatteella: käynnistät UDP-paketin palvelimella, jolle haluat puhua, ja odotat sitten, tuleeko vastaus takaisin.

Tämä tekee UDP:stä paljon yksinkertaisempaa ja nopeampaa kuin sen iso-serkku TCP, the lähetyksen ohjausprotokolla, joka nimensä mukaisesti huolehtii automaattisesti monista yksityiskohdista, joita UDP ei.

Erityisesti TCP käsittelee tietojen katoamisen havaitsemista ja tietojen pyytämistä uudelleen; varmistaa, että kaikki datapalaset saapuvat oikeassa järjestyksessä; ja yhden verkkoyhteyden tarjoaminen, jota kun se on muodostettu, sitä voidaan käyttää lähettämiseen ja vastaanottamiseen samanaikaisesti.

UDP:llä ei ole "yhteyden" käsitettä, joten pyynnöt ja vastaukset kulkevat olennaisesti itsenäisesti:

• DNS-pyyntö saapuu DNS-palvelimelle omassa UDP-paketissaan.
• DNS-palvelin pitää kirjaa mistä tietokone lähetti kyseisen paketin.
• Palvelin alkaa etsiä vastausta lähetettäväksi takaisin, tai päättää, ettei sellaista ole.
• Palvelin lähettää vastauksen alkuperäiselle lähettäjälle käyttämällä toista UDP-pakettia.

Käyttöjärjestelmän tai verkon tasolla nämä kaksi yllä olevaa UDP-pakettia ovat itsenäisiä, itsenäisiä lähetyksiä – niitä ei ole sidottu yhteen osana samaa digitaalista yhteyttä.

Palvelimen on muistettava, mille asiakkaalle kukin vastaus lähetetään; ja asiakkaan tehtävänä on selvittää, mitkä vastaukset liittyvät sen alun perin lähettämiin pyyntöihin.

Kuinka voit olla varma?

Tässä vaiheessa, etenkin kun tarkastellaan yllä olevan DNS-pyynnön ja vastauksen pientä kokoa, ihmettelet todennäköisesti: "Kuinka asiakas voi olla varma, että se vastaa oikeaa vastausta eikä sellaista, jota on sekoitettu siirron aikana tai ohjattu väärin. vahingossa, joko vahingossa tai suunnittelemalla?"

Valitettavasti monet, elleivät useimmat, DNS-pyynnöt (etenkin palvelimelta palvelimelle, kun ensimmäinen kysymäsi palvelin ei tiedä vastausta ja sen on löydettävä vastaus, joka osaa muotoilla vastauksensa) ei ole salattu tai muuten merkitty millä tahansa salaustodennuskoodilla.

Itse asiassa DNS-pyynnöt sisältävät oletusarvoisesti yhden "tunnistetunnisteen", johon viitataan DNS-tietomuodon dokumentaatiossa yksinkertaisesti nimellä ID.

Hämmästyttävää kyllä, vaikka se on saanut lukuisia päivityksiä ja parannusehdotuksia vuosien varrella, virallinen Internet RFC (Pyydä kommentteja) -asiakirja, joka toimii DNS-määrityksenä, on edelleen RFC 1035 (harrastamme tällä hetkellä RFC:tä 9000-luvun puolivälissä), vuodelta 1987, hieman yli 35 vuotta sitten!

Tuolloin sekä kaistanleveydestä että prosessointitehosta oli pulaa: tyypilliset suorittimen nopeudet olivat noin 10 MHz; pöytätietokoneissa oli noin 1 megatavu RAM-muistia; Internet-yhteyden nopeudet organisaatioille, jotka pääsivät verkkoon ollenkaan, olivat usein 56 kbit/s tai 64 kbit/s, jaettuna kaikkien kesken; ja 1200 bittiä/s oli edullinen valinta henkilökohtaisiin yhteyksiin nykyaikaisten puhelinverkkoyhteyksien kautta.

Siksi DNS-pyyntö- ja vastausotsikot puristettiin – ja ovat edelleen – 12 tavuksi, joista ID-tunniste vie kaksi ensimmäistä, RFC 1035:n söpönä. ASCII-taide tekee selväksi:

 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+ --+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Näet tunnuksen toiminnassa yllä näytetyissä heksadesimaatioissa, joissa sekä pyyntö- että vastauspaketit alkavat samoilla kahdella merkillä bN, jotka vastaavat 16-bittistä tunnistetta 62 4e hex.

Hyvin löyhästi sanottuna nämä 16 bittiä ovat yhtä paljon kuin virallinen DNS-protokolla tarjoaa "todennusta" tai "virheiden havaitsemista" varten.

Sekaantumista arvauksella

Kuten voit kuvitella, tavallisen DNS-liikenteen päästä päähän -yksinkertaisuuden vuoksi kuka tahansa, jolla on ns keskilaatikko or skannaus välityspalvelinta jotka voivat siepata, tutkia ja muokata verkkoliikennettäsi, voivat vähäpätöisesti sekaantua DNS-liikenteesi.

Tämä sisältää vastausten lähettämisen, jotka antavat sinulle tarkoituksella virheellisiä tietoja, kuten IT-tiimisi uudelleenohjauksen pois palvelimilta, joiden se tietää olevan täynnä haittaohjelmia.

Se voi myös sisältää Internet-palveluntarjoajasi noudattavan maasi lainsäädäntöä, joka edellyttää joidenkin palvelimien ilmoittamista olemattomiksi, vaikka ne olisivat elossa ja toimivat hyvin, koska ne ovat laittoman sisällön, kuten lasten hyväksikäyttömateriaalin, estolistalla.

Mutta ensi silmäyksellä tämä erittäin heikko DNS ID -koodaus näyttää myös tekevän siitä triviaalia jopa hyökkääjille, jotka eivät näe verkkoliikennettäsi ollenkaan lähettääksesi väärennettyjä DNS-vastauksia käyttäjillesi tai palvelimillesi…

…vaarallisen suurella menestyksellä.

Loppujen lopuksi, jos hyökkääjät tietävät, että joku verkossasi haluaa säännöllisesti vierailla naksec.test, tämä palvelin saattaa tuntua mehukkaalta paikalta valeuutisten, ovelien päivitysten tai väärennetyn JavaScript-koodin istuttamiseen.

Ja jos hyökkääjät eivät pysty murtautumaan sisään naksec.test palvelin itse, entä jos he käynnistäisivät säännöllisesti ja usein UDP-paketteja DNS-palvelimellasi käyttämällä keksittyä ID-tagia, joka väitti vastaavan kysymykseen "Mikä on A-tietue naksec.test"?

Tällä tavalla he saattavat pystyä kaappaamaan DNS-pyynnön, antamaan väärennetyn vastauksen ja siten ohjaamaan seuraavan vierailusi verkkosivustolle harhaan – käytännössä kaappaavat itse sivuston ilman, että heidän tarvitsee hyökätä naksec.test palvelin ollenkaan.

Vähän tuuria vaadittiin

Heillä pitäisi tietysti olla vähän onnea, vaikka he voisivat yrittää yhä uudelleen ja uudelleen parantaakseen yleisiä mahdollisuuksiaan, koska heidän tarvitsee menestyä vain kerran, kun taas sinun on saatava totuudenmukainen DNS-vastaus joka kerta.

Menestyäkseen heidän on lähetettävä petollinen DNS-vastaus:

• Aikana, jolloin oma palvelimesi ei vielä tiennyt vastausta kysymykseen. DNS-vastaukset sisältävät 32-bittisen numeron nimeltä TTL, lyhenne sanoista aika elää, joka kertoo, kuinka kauan toinen pää voi käyttää vastausta uudelleen. Jos sinä tai joku muu ytour-verkostossa pyysi naksec.test äskettäin DNS-palvelimellasi saattaa olla vastaus välimuistissaan. Lisähakuja ei tarvittaisi, eikä hyökkääjillä olisi lähteviä kaappauspyyntöjä.
• Pyyntösi lähettämisen ja virallisen vastauksen välisenä aikana tuli takaisin ulkopuolelta. Jopa entisaikaan DNS-hakuajat kestivät harvoin muutamaa sekuntia pidempään. Nykyään ne mitataan parhaiten millisekunneissa.
• Oikealla numerolla sen ensimmäisissä 16 bitissä. Mukaan mahtuu 65536 (2¹⁶) eri arvot 16 bitiksi, joten hyökkääjillä olisi oltava jonkin verran onnea. Mutta nykypäivän verkon kaistanleveyksillä 65536 eri valevastauksen lähettäminen kerralla, mikä kattaa kaikki mahdolliset tunnusnumerot, kestää sekunnin murto-osan.

Onneksi kunnolliset DNS-palvelimet ottavat ylimääräisen askeleen tehdäkseen kaappauksen oletusarvoisesti vaikeaksi.

Ainakin sitä he ovat tehneet vuodesta 2008 lähtien, jolloin edesmennyt Dan Kaminsky huomautti, että monet DNS-palvelimet eivät tuolloin olleet vain konfiguroituja kuuntelemaan saapuvia pyyntöjä kiinteässä UDP-portissa (melkein aina portti 53, virallisesti osoitettu DNS:lle)…

…mutta myös vastaanottamaan saapuvia vastauksia kiinteästä portista, usein myös portista 53, jos vain luodaan miellyttävä symmetria liikenteessä.

Syy kiinteän portin käyttöön molempiin suuntiin oli luultavasti alun perin ohjelmoinnin yksinkertaisuus. Kuuntelemalla aina saman UDP-porttinumeron vastauksia, sinun ei tarvitse seurata, mitkä portit pitäisi avata millekin vastaukselle. Tämä tarkoittaa, että DNS-ohjelmistosi pyyntökäsittelijä ja vastausgeneraattorikomponentit voivat toimia itsenäisesti. Pyynnön kuuntelijan ei tarvitse kertoa vastauksen lähettäjälle: "Tämän tietyn vastauksen on palattava erityiseen porttiin, ei tavalliseen."

Käytä porttinumeroita lisätunnuksena

Nykyään lähes kaikki UDP-pohjaiset DNS-palvelimet kuuntelevat porttia 53, kuten aina, mutta ne seuraavat DNS-pyynnön lähettäjän käyttämää ns. "lähdeporttia", jonka se odottaa valitsevansa satunnaisesti.

UDP-lähdeportit, jotka ovat vähän kuin "alanumero" vanhan koulun toimistopuhelinkeskuksessa, on tarkoitettu auttamaan sinua ja verkkoa erottamaan pyynnöt toisistaan.

Internet-protokollaportit (myös TCP käyttää niitä) voivat toimia välillä 1 - 65535, vaikka useimmat lähtevät yhteydet käyttävät vain lähdeportteja 1024-65535, koska porttinumerot 1023 ja sitä alemmat on yleensä varattu prosesseille, joilla on järjestelmäoikeudet.

Ajatuksena on, että minkä tahansa DNS-haun lähettäjän ei pitäisi vain lisätä todella satunnaista 16-bittistä tunnusta jokaisen pyynnön alussa, vaan myös valita todella satunnainen UDP-lähdeporttinumero, jossa se kuuntelee siihen liittyvää vastausta.

Tämä lisää ylimääräistä arvailua, joka huijareiden on lisättävä yllä olevaan "kaappausonni" -luetteloonsa, nimittäin se, että heidän on lähetettävä väärennetty vastaus, joka rastittaa kaikki nämä ruudut:

• Täytyy olla kysely, jota kysyttiin äskettäin, tyypillisesti muutaman viime sekunnin aikana.
• Täytyy olla haku, joka ei ollut paikallisen palvelimen välimuistissa, tarkoittaa yleensä sitä, että kukaan muu ei kysynyt siitä muutaman viime minuutin aikana.
• Täytyy olla oikea 16-bittinen tunnusnumero datapaketin alussa.
• On lähetettävä oikeaan kohdeporttiin kyseisen palvelimen IP-numerossa.

Ja toinen asia

Itse asiassa on vielä yksi temppu, jonka DNS-pyynnön esittäjät voivat tehdä muuttamatta taustalla olevaa DNS-protokollaa ja siten (useimmiten) rikkomatta mitään.

Tämä temppu, hämmästyttävän, oli ensimmäinen ehdotus vuonna 2008 loistavalla otsikolla kirjoitetussa lehdessä Lisääntynyt DNS-väärennösten vastus 0x20-bittisellä koodauksella: TURVALLISUUS LEET-KYSELYJEN kautta.

Idea on oudon yksinkertainen ja perustuu kahteen DNS-protokollan yksityiskohtaan:

• Kaikkien DNS-vastausten alussa on oltava alkuperäinen kyselyosa. Kyselyissä on tietysti tyhjä vastausosio, mutta vastausten on vastattava alkuperäistä kysymystä, mikä auttaa varmistamaan, että pyynnöt ja vastaukset eivät vahingossa mene sekaisin.
• Kaikissa DNS-kysymyksissä kirjainkoolla ei ole merkitystä. Kysytpä sitten naksec.testtai NAKSEC.TESTtai nAksEc.tESt, sinun pitäisi saada sama vastaus.

Protokollassa ei ole mitään, mikä sanoisi, että sinun TÄYTYY käyttää samaa kirjoitusasua vastauksen siinä osassa, jossa toistat alkuperäisen kyselyn, koska DNS ei välitä kirjainkoosta.

Mutta vaikka RFC 1035 vaatiikin vertailemaan kirjainkokoa, se viittaa vahvasti siihen, että älä muuta tapausta kaikista tekstinimistä, jotka vastaanotat pyynnöissä tai noutat omista tietokannoistasi käytettäväksi vastauksissa.

Toisin sanoen, jos saat pyynnön nAKsEC.tEST, ja tietokantaasi on tallennettu muodossa NAKSEC.TEST, näiden kahden nimen katsotaan kuitenkin olevan identtisiä ja ne täsmäävät.

Mutta kun muotoilet vastauksesi, RFC 1035 ehdottaa sinulle älä muuta vastaukseesi lisäämiesi tietojen kirjainkokoa, vaikka luulisi sen näyttävän siistimmältä ja vaikka se silti vastaisi toisessa päässä DNS:n vaatiman vertailun ansiosta, jossa kirjainkoolla ei ole merkitystä.

Joten jos sekoitat satunnaisesti DNS-pyynnön kirjainten kirjaimia ennen sen lähettämistä, useimmat DNS-palvelimet heijastavat uskollisesti tuota outoa kirjainyhdistelmää, vaikka heidän oma tietokantansa tallentaisi palvelimen nimen eri tavalla, kuten näet tästä. :

$ dig +noedns @127.42.42.254 nAkSEc.TEST ;; KYSYMYSOSA: ;nAkSEc.TEST. JONKIN SISÄLLÄ ;; VASTAUSOSA: NAKSEC.TESTI. 5 IN A 203.0.113.42 ;; Kyselyaika: 1 ms ;; PALVELIN: 127.42.42.254#53(127.42.42.254) (UDP) ;; MILLOIN: ma 23. tammikuuta 14:40:34 GMT 2023 ;; MSG-KOKO rcvd: 56

DNS-palvelimemme tallentaa nimen naksec.test kaikki isoilla kirjaimilla, joten vastauksen vastausosio sisältää nimen muodossa NAKSEC.TEST, sekä sen IPv4-numero (A-tietue). 203.0.113.42.

Mutta DNS-palvelimemme lähettämän vastauksen "tässä on ristiintarkistusta varten palautetut kyselytiedot" -osassa säilytetään DNS-haussa alun perin käytetty kirjainkoko:

---> Pyyntö 127.0.0.1:55772 - 127.42.42.254:53 ---> 00000000 c0 55 01 20 00 01 00 00 00 00 00 00 06 6e .41. .........nAk| 6 00000010 53 45 63 04 74 45 73 54 00 00 01 00 |SEK.TESTI..... | DNS-haku: A-tietue nAkSEc.tEST:lle ==> A=01 <--- Vastaus 203.0.113.42:127.42.42.254 - 53:127.0.0.1 <--- 55772 b00000000 0 55 84 0 00 01 00e 01 00b |.U.........nAk| 00 00 00 06 6 41 6 00000010 53 45 63 04 74 45 73 54e 00 |SEc.TESTI......NA| 00 01b 00 01 06 4 41 00000020 4 53 45 43 04 54 45 53 54 |KSEC.TESTI.......| 00 00 01 00 01 cb 00 00 00000030a |......q* |

Ylimääräinen turvamerkintä, ilmainen

Bingo!

DNS-haku voi lisätä muita "tunnistekoodauksia"!

Noin 15 bitin satunnaisesti valitun lähdeportin ja 16 bitin satunnaisesti valitun ID-numerodatan lisäksi pyynnön esittäjä saa valita isot ja pienet kirjaimet jokaiselle verkkotunnuksen aakkosmerkille.

Ja naksec.test sisältää 10 kirjainta, joista jokainen voidaan kirjoittaa isoilla tai pienillä kirjaimilla, mikä mahdollistaa vielä 10 bitin satunnaisen "tagauksen".

Kun tämä lisätieto on arvattava, hyökkääjien täytyy olla onnellisia ajoituksensa, UDP-portin numeron, ID-tunnisteen arvon ja verkkotunnuksen nimen isojen kirjainten kanssa, jotta pyynnön esittänyt palvelin saisi väärennetyn "kaappausvastauksen". hyväksyisi.

Nimi muuten 0x20-koodaus yllä on vähän vitsi: 0x20 otsikossa on 00100000 binäärimuodossa, ja tuon tavun yksittäinen bitti erottaa isot ja pienet kirjaimet ASCII-koodausjärjestelmässä.

Kirjeet A että I, esimerkiksi tulevat ulos muodossa 0x41 - 0x49, while a että i tulee ulos muodossa 0x61 - 0x69.

 ASCII-koodauskaavio ASCII-tekstina +------+------+------+------+------+-------+- -----+------+ |00 ^@ |10 ^P |20 |30 0 |40 @ |50 P |60` |70 p | |01 ^A |11 ^Q |21 ! |31 1 |41 A |51 Q |61 a |71 q | |02 ^B |12 ^R |22 " |32 2 |42 B |52 R |62 b |72 R | |03 ^C |13 ^S |23 # |33 3 |43 C |53 S |63 c |73 s | |04 ^D |14 ^T |24 $ |34 4 |44 P |54 T |64 p |74 t | |05 ^E |15 ^U |25 % |35 5 |45 E |55 U |65 e |75 u | |06 ^F |16 ^V |26 & |36 6 |46 P |56 V |66 f |76 v | |07 ^G |17 ^L |27 ' |37 7 | 47 K |57 L |67 g |77 L | |08 ^K |18 ^X |28 ( |38 8 |48 K |58 X |68 K |78 x | | |09 ^I |19 ^K |29 ) |39 9 |49 I |59 Y |69 i |79 v | |0A ^J |1A ^Z |2A * |3A : |4A J |5A Z |6A j |7A z | |0B ^K |1B ^ [ |2B + |3B ; |4B K |5B [ |6B k |7B { | |0C ^L |1C ^ |2C , |3C < |4C L |5C |6C l |7C | | |0D ^M | 1D ^] |2D - |3D = |4D M |5D ] |6D m |7D } | |0E ^N |1E ^^ |2E . |3E > |4E N |5E ^ |6E n |7E ~ | | 0F ^O |1F ^_ |2F / |3F ? |4F O |5F _ |6F o |7F | +-------+------+------+---- ---+------+-------+------+------+

Toisin sanoen, jos lisäät 0x41+0x20 saadaksesi 0x61, käännät A tulee a; jos vähennät 0x69-0x20 saadaksesi 0x49, käännät i tulee I.

Miksi nyt?

Saatat jo nyt ihmetellä, "Miksi nyt, jos idea syntyi 15 vuotta sitten, ja olisiko siitä oikeasti mitään hyötyä?"

Äkillinen kiinnostuksemme, kuten tapahtuu, tulee a viimeisin julkinen sähköposti Googlen teknikot myöntävät, että heidän vuoden 2022 kokeilunsa tällä vanhan koulun TURVALLISUUStemppulla on otettu käyttöön tosielämässä:

Kuten aiemmin ilmoitimme, Google Public DNS on parhaillaan mahdollistamassa arvovaltaisille nimipalvelimille lähetettyjen DNS-kyselynimien tapausten satunnaistamista. Olemme ottaneet sen käyttöön onnistuneesti joillakin alueilla Pohjois-Amerikassa, Euroopassa ja Aasiassa suojaten suurimman osan (90 %) DNS-kyselyistä niillä alueilla, joita DNS ei kata TLS:n kautta.

Mielenkiintoista on, että Google ehdottaa, että suurimmat ongelmat, joita sillä on ollut tämän yksinkertaisen ja näennäisesti kiistattoman säädön kanssa, ovat se, että vaikka useimmat DNS-palvelimet eivät joko jatkuvasti erota kirjainkoosta (joten tätä temppua voidaan käyttää niiden kanssa) tai eivät jatkuvasti (joten ne on estetty), kuten arvata saattaa…

…muutamat maintream-palvelimet putoavat ajoittain "kirjainkoolla huomioivaan" tilaan lyhyeksi ajaksi, mikä kuulostaa sellaiselta epäjohdonmukaisuudelta, jota suurten palveluntarjoajien toivoisi välttävän.

Auttaako se todella?

Vastaus kysymykseen, "Onko se sen arvoista?" ei ole vielä selvä.

Jos sinulla on mukava pitkä palvelunimi, esim nakedsecurity.sophos.com (22 aakkosmerkkiä), silloin on runsaasti ylimääräistä merkinantotehoa, koska 2²² eri isot kirjaimet tarkoittavat 4 miljoonaa yhdistelmää, joita roistot voivat kokeilla, kerrottuna 65536 32000 eri ID-numerolla, kerrottuna noin 64000 XNUMX - XNUMX XNUMX erilaisella lähdeportilla arvattavaksi...

…mutta jos olet maksanut pienen omaisuuden supershort-verkkotunnuksesta, kuten Twitterin t.co, hyökkääjilläsi on vain 2x2x2=8 kertaa vaikeampi työ kuin ennen.

Uskon kuitenkin, että voimme sanoa "Chapeau" Googlelle tämän kokeilemisesta.

Kuten kyberturvallisuuden tarkkailijat sanovat, hyökkäykset vain nopeutuvat, joten kaikki, mikä voi viedä olemassa olevan protokollan ja lisätä siihen ylimääräistä murtumisaikaa, melkein "ilmaiseksi", on hyödyllinen tapa torjua.

---

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• Platoblockchain. Web3 Metaverse Intelligence. Tietoa laajennettu. Pääsy tästä.
• Lähde: https://nakedsecurity.sophos.com/2023/01/23/serious-security-how-deliberate-typos-might-improve-dns-security/