Poważne bezpieczeństwo: w jaki sposób celowe literówki mogą poprawić bezpieczeństwo DNS

Przez lata, my napisany i mówiony na Naked Security wielokrotnie o drażliwym problemie DNS porwanie.

DNS, jak zapewne wiesz, jest skrótem od system nazw domeni często można go usłyszeć jako „książkę telefoniczną” lub „gazetteer” w Internecie.

Jeśli nie znasz tego słowa gazeter, odnosi się do indeksu na końcu atlasu, gdzie patrzysz w górę, powiedzmy, Monrowia, Liberia w wygodnej liście alfabetycznej i mówi coś w stylu 184 - C4. To mówi ci, abyś skręcił prosto na stronę 184 i podążał za liniami siatki w dół od litery C na górze mapy i naprzeciw cyfry 4 po lewej stronie. Tam, gdzie linie się spotykają, znajdziesz Monrowię.

W przypadku większości użytkowników większość wyszukiwań DNS zawiera nazwę serwera, prosząc o odpowiedź zwrotną zawierającą tak zwany rekord A lub rekord AAAA.

(Rekordy A są używane dla 32-bitowych numerów internetowych IPv4, takich jak 203.0.113.42; Rekordy AAAA to równoważne odpowiedzi dla 128-bitowych adresów IPv6, takich jak 2001:db8:15a:d0c::42 – w tym artykule będziemy używać tylko rekordów A i numerów IPv4, ale w obu przypadkach te same kwestie bezpieczeństwa dotyczą procesu wyszukiwania.)

Oto przykład, w którym szukamy wyimaginowanej nazwy domeny naksec.test za pośrednictwem serwera DNS, który został specjalnie stworzony do śledzenia ruchu DNS i uczenia go.

Użyliśmy oldschoolowego narzędzia Linux dig, skrót od wyszukiwarka internetowa domeny, aby wygenerować proste żądanie DNS (dig domyślnie szuka rekordów A) dla żądanego serwera:

$ dig +noedns @127.42.42.254 naksec.test ;; SEKCJA PYTANIA: ;naksec.test. W ;; SEKCJA ODPOWIEDZI: NAKSEC.TEST. 5 W 203.0.113.42 ;; Czas zapytania: 1 ms ;; SERWER: 127.42.42.254#53(127.42.42.254) (UDP);; KIEDY: Pon. 23 stycznia 14 r. 38:42:2023 GMT ;; ROZMIAR MSG rcvd: 56

Oto jak nasz serwer DNS poradził sobie z żądaniem, pokazując zrzut szesnastkowy przychodzącego żądania i pomyślną odpowiedź, która wróciła:

---> Żądanie od 127.0.0.1:57708 do 127.42.42.254:53 ---> 00000000 62 4e 01 20 00 01 00 00 00 00 00 00 06 6e 61 6b |bN. .........nak| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 |test.sek..... | Wyszukiwanie DNS: rekord A dla naksec.test ==> A=203.0.113.42 <--- Odpowiedź od 127.42.42.254:53 do 127.0.0.1:57708 <--- 00000000 62 4e 84 b0 00 01 00 01 00 00 00 00 06 6e 61 6b |bN...........nak| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 06 4e 41 |sec.test......ND| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |KSEC.TEST.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

Należy pamiętać, że ze względu na wydajność większość żądań DNS korzysta z protokołu UDP, tzw protokół datagramu użytkownika, który działa na zasadzie wysyłania i nadziei: odpalasz pakiet UDP na serwerze, z którym chcesz rozmawiać, a następnie czekasz, czy odpowiedź wróci.

To sprawia, że ​​protokół UDP jest znacznie prostszy i szybszy niż jego duży kuzyn TCP, tzw protokół kontroli transmisji, który, jak sama nazwa wskazuje, automatycznie zajmuje się wieloma szczegółami, których nie ma UDP.

Warto zauważyć, że TCP zajmuje się wykrywaniem utraty danych i ponownym żądaniem ich odzyskania; upewnienie się, że wszelkie porcje danych docierają we właściwej kolejności; oraz zapewnienie pojedynczego połączenia sieciowego, które po skonfigurowaniu może być używane do jednoczesnego wysyłania i odbierania.

UDP nie ma koncepcji „połączenia”, więc żądania i odpowiedzi zasadniczo są przesyłane niezależnie:

• Żądanie DNS dociera do serwera DNS we własnym pakiecie UDP.
• Serwer DNS prowadzi rejestr z którego komputera wysłał ten konkretny pakiet.
• Serwer zabiera się za znalezienie odpowiedzi do odesłania, lub zdecydować, że go nie ma.
• Serwer wysyła odpowiedź do pierwotnego nadawcy przy użyciu drugiego pakietu UDP.

Z poziomu systemu operacyjnego lub sieci te dwa powyższe pakiety UDP są niezależnymi, autonomicznymi transmisjami – nie są ze sobą powiązane w ramach tego samego łącza cyfrowego.

To do serwera należy zapamiętanie, do którego klienta wysłać każdą odpowiedź; i to do klienta należy ustalenie, które odpowiedzi odnoszą się do żądań, które pierwotnie wysłał.

Jak możesz być pewny?

W tym momencie, zwłaszcza patrząc na niewielki rozmiar żądania DNS i odpowiedzi powyżej, prawdopodobnie zastanawiasz się: „Skąd klient może mieć pewność, że jest dopasowana do właściwej odpowiedzi, a nie taka, która została zniekształcona podczas przesyłania lub nieprawidłowo skierowana przez pomyłkę, przez przypadek lub celowo?”

Niestety, wiele, jeśli nie większość, żądań DNS (zwłaszcza te wysyłane z serwera do serwera, gdy pierwszy serwer, o który pytasz, nie zna odpowiedzi i musi znaleźć taki, który ją zna, aby sformułować odpowiedź) nie są szyfrowane lub w inny sposób oznaczone jakimkolwiek kryptograficznym kodem uwierzytelniającym.

W rzeczywistości domyślnie żądania DNS zawierają pojedynczy „znacznik identyfikacyjny”, który jest określany w dokumentacji formatu danych DNS po prostu jako ID.

O dziwo, pomimo otrzymywania przez lata licznych aktualizacji i sugerowanych ulepszeń, oficjalne internetowe RFC (prośba o komentarze) dokument, który działa jako specyfikacja DNS, jest nadal RFC 1035 (jesteśmy obecnie w RFC w połowie lat 9000), sięgający aż do listopada 1987 roku, nieco ponad 35 lat temu!

W tamtych czasach brakowało zarówno przepustowości, jak i mocy obliczeniowej: typowa prędkość procesora wynosiła około 10 MHz; komputery stacjonarne miały około 1 MB pamięci RAM; prędkości dostępu do internetu dla organizacji, które w ogóle mogły uzyskać dostęp do Internetu, często wynosiły 56 kb/s lub 64 kb/s, dzielone między wszystkich; a 1200 bitów/s było niedrogim wyborem do osobistej łączności za pośrednictwem ówczesnych modemów telefonicznych.

Właśnie dlatego nagłówki żądań i odpowiedzi DNS były – i nadal są – ściśnięte do nędznych 12 bajtów, z których znacznik ID zajmuje pierwsze dwa, jak uroczy RFC 1035 Sztuka ASCII wyjaśnia:

 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+ --+--+--+--+--+--+--+ | identyfikator | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QR| Kod operacji |AA|TC|RD|RA| Z | RKOD | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDLICZ.| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RACHUNEK | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSLICZNIK | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARLICZNOŚĆ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Możesz zobaczyć identyfikator w akcji na pokazanych powyżej zrzutach szesnastkowych, gdzie zarówno żądanie, jak i pakiet odpowiedzi zaczynają się od tych samych dwóch znaków bN, które odpowiadają 16-bitowemu identyfikatorowi 62 4e w szesnastkach.

Mówiąc bardzo luźno, te 16 bitów to tyle, ile zapewnia oficjalny protokół DNS w ramach „uwierzytelniania” lub „wykrywania błędów”.

Wtrącanie się w domysły

Jak możesz sobie wyobrazić, biorąc pod uwagę kompleksową prostotę zwykłego ruchu DNS, każdy z tzw środkowy boks or skanowanie proxy kto może przechwytywać, badać i modyfikować ruch sieciowy, może w trywialny sposób ingerować w ruch DNS.

Obejmuje to odsyłanie odpowiedzi, które celowo podają niedokładne informacje, na przykład przekierowują cię z serwerów, o których wie, że są zaśmiecone złośliwym oprogramowaniem.

Może to również obejmować zgodność twojego dostawcy usług internetowych z przepisami obowiązującymi w twoim kraju, które wymagają zgłaszania niektórych serwerów jako nieistniejących, nawet jeśli działają i działają dobrze, ponieważ znajdują się na liście zablokowanych nielegalnych treści, takich jak materiały przedstawiające wykorzystywanie dzieci.

Ale na pierwszy rzut oka ten bardzo słaby rodzaj tagowania DNS ID również wydaje się banalny nawet dla atakujących, którzy w ogóle nie mają wglądu w ruch sieciowy do wysyłania fałszywych odpowiedzi DNS do użytkowników lub serwerów…

…z niebezpiecznie dużą szansą powodzenia.

W końcu, jeśli atakujący wiedzą, że ktoś w Twojej sieci regularnie lubi odwiedzać naksec.test, serwer ten może wydawać się doskonałym miejscem do umieszczania fałszywych wiadomości, podejrzanych aktualizacji lub fałszywego kodu JavaScript.

A jeśli atakujący nie są w stanie włamać się do naksec.test samego serwera, co by było, gdyby regularnie i często wysyłali pakiety UDP na twój serwer DNS, używając wymyślonego identyfikatora, który twierdził, że odpowiada na pytanie: „Co to jest rekord A dla naksec.test„?

W ten sposób mogą być w stanie przejąć żądanie DNS, udzielić fałszywej odpowiedzi, a tym samym źle skierować Twoją następną wizytę na stronie internetowej – zasadniczo przejmując samą witrynę bez konieczności atakowania naksec.test serwer w ogóle.

Wymagane trochę szczęścia

Oczywiście musieliby mieć trochę szczęścia, chociaż mogliby próbować w kółko, aby zwiększyć swoje ogólne szanse, biorąc pod uwagę, że muszą odnieść sukces tylko raz, podczas gdy za każdym razem musisz uzyskać prawdziwą odpowiedź DNS.

Aby odnieść sukces, musieliby wysłać nieuczciwą odpowiedź DNS:

• W okresie, w którym twój własny serwer nie znał jeszcze odpowiedzi na pytanie. Odpowiedzi DNS zawierają 32-bitowy numer o nazwie TTL, skrót od czas żyć, która mówi, jak długo drugi koniec może ponownie wykorzystywać odpowiedź. Jeśli Ty lub ktokolwiek inny w Twojej sieci o to poprosi naksec.test ostatnio Twój serwer DNS mógł mieć odpowiedź w swojej pamięci podręcznej. Dalsze wyszukiwanie nie byłoby potrzebne, a osoby atakujące nie wysyłałyby wychodzących żądań przejęcia kontroli.
• Pomiędzy wysłaniem prośby a oficjalną odpowiedzią nadeszła z zewnątrz. Nawet w dawnych czasach czas wyszukiwania DNS rzadko przekraczał kilka sekund. Obecnie najlepiej mierzyć je w milisekundach.
• Z właściwą liczbą w pierwszych 16 bitach. Możesz zmieścić 65536 (2¹⁶) różne wartości na 16 bitów, więc atakujący musieliby mieć trochę szczęścia. Ale przy dzisiejszej przepustowości sieci wysłanie 65536 różnych fałszywych odpowiedzi naraz, obejmujących wszystkie możliwe numery identyfikacyjne, zajmuje ułamek sekundy.

Na szczęście przyzwoite serwery DNS podejmują dodatkowy krok, aby domyślnie utrudnić przejęcie.

Przynajmniej tak robią od około 2008 roku, kiedy to nieżyjący już Dan Kamiński zwrócił uwagę, że wiele ówczesnych serwerów DNS było nie tylko skonfigurowanych do nasłuchiwania przychodzących żądań na stałym porcie UDP (prawie zawsze port 53, oficjalnie przypisany do DNS)…

… ale także odbieranie odpowiedzi przychodzących na stałym porcie, często także porcie 53, choćby po to, aby stworzyć przyjemną symetrię w ruchu.

Powodem używania stałego portu w obu kierunkach była prawdopodobnie pierwotnie prostota programowania. Dzięki temu, że zawsze nasłuchujesz odpowiedzi na tym samym numerze portu UDP, nie musisz śledzić, które porty powinny być otwarte dla jakich odpowiedzi. Oznacza to, że komponenty obsługi żądań i generatora odpowiedzi oprogramowania DNS mogą działać niezależnie. Odbiornik żądań nie musi mówić nadawcy odpowiedzi: „Ta konkretna odpowiedź musi wrócić na specjalny port, a nie zwykły”.

Użyj numerów portów jako dodatkowego identyfikatora

W dzisiejszych czasach prawie wszystkie serwery DNS oparte na protokole UDP nasłuchują jak zawsze na porcie 53, ale śledzą tak zwany „port źródłowy” używany przez requester DNS, który oczekuje, że zostanie wybrany losowo.

Porty źródłowe UDP, które są trochę jak „numer wewnętrzny” w starej szkolnej biurowej centrali telefonicznej, mają pomóc Tobie i sieci w odróżnianiu żądań od siebie.

Porty protokołów internetowych (TCP też ich używa) mogą działać od 1 do 65535, chociaż większość połączeń wychodzących używa tylko portów źródłowych 1024-65535, ponieważ numery portów 1023 i niższe są zwykle zarezerwowane dla procesów z uprawnieniami systemowymi.

Pomysł polega na tym, że nadawca każdego wyszukiwania DNS powinien nie tylko wstawić prawdziwie losowy 16-bitowy identyfikator na początku każdego żądania, ale także wybrać prawdziwie losowy numer portu źródłowego UDP, na którym będzie nasłuchiwał powiązanej odpowiedzi.

Dodaje to dodatkowy poziom zgadywania, który oszuści muszą dodać do swojej powyższej listy „przejęcia szczęścia”, a mianowicie, że muszą wysłać fałszywą odpowiedź, która zaznacza wszystkie te pola:

• Musi to być zapytanie, które zostało ostatnio zadane, zwykle w ciągu ostatnich kilku sekund.
• Musi to być wyszukiwanie, którego nie było w pamięci podręcznej serwera lokalnego, zazwyczaj oznacza to, że nikt inny o to nie pytał w ciągu ostatnich kilku minut.
• Musi mieć prawidłowy 16-bitowy numer identyfikacyjny na początku pakietu danych.
• Musi zostać wysłany do właściwego portu docelowego pod odpowiednim numerem IP serwera.

I jeszcze jedna rzecz

W rzeczywistości istnieje jeszcze jedna sztuczka, którą requestery DNS mogą wykonać bez zmiany bazowego protokołu DNS, a tym samym (w większości) bez psucia czegokolwiek.

Ta sztuczka, o dziwo, była pierwszy zaproponowany w 2008 roku w artykule o chwalebnym tytule Zwiększona odporność na fałszowanie DNS dzięki kodowaniu 0x20-bitowemu: BEZPIECZEŃSTWO PRZEZ ZAPYTANIA LEET.

Pomysł jest dziwnie prosty i opiera się na dwóch szczegółach protokołu DNS:

• Wszystkie odpowiedzi DNS muszą na początku zawierać oryginalną sekcję zapytania. Zapytania mają oczywiście pustą sekcję odpowiedzi, ale odpowiedzi muszą odzwierciedlać pierwotne pytanie, co pomaga zapewnić, że prośby i odpowiedzi nie zostaną przypadkowo pomieszane.
• We wszystkich pytaniach DNS nie jest rozróżniana wielkość liter. Czy o to poprosisz naksec.testlub NAKSEC.TESTlub nAksEc.tESt, powinieneś otrzymać tę samą odpowiedź.

Teraz w protokole nie ma nic, co mówi, że MUSISZ używać tej samej pisowni w części odpowiedzi, w której powtarzasz oryginalne zapytanie, ponieważ DNS nie dba o wielkość liter.

Ale chociaż RFC 1035 wymaga porównywania bez rozróżniania wielkości liter, zdecydowanie sugeruje, że ty właściwie nie zmieniaj sprawy wszelkich nazw tekstowych, które otrzymujesz w żądaniach lub pobierasz z własnych baz danych do wykorzystania w odpowiedziach.

Innymi słowy, jeśli otrzymasz prośbę o nAKsEC.tEST, a twoja baza danych ma go zapisanego jako NAKSEC.TEST, to mimo wszystko te dwie nazwy są uważane za identyczne i będą pasować.

Ale kiedy formułujesz swoją odpowiedź, RFC 1035 sugeruje, że ty nie zmieniaj wielkości liter danych, które umieściłeś w swojej odpowiedzi, nawet jeśli mogłoby się wydawać, że wyglądałoby to schludniej i nawet gdyby nadal pasowało na drugim końcu, dzięki porównywaniu bez rozróżniania wielkości liter, którego wymaga DNS.

Tak więc, jeśli przypadkowo pomieszasz wielkość liter w żądaniu DNS przed jego wysłaniem, większość serwerów DNS wiernie odzwierciedli to dziwne połączenie liter, nawet jeśli ich własna baza danych przechowuje nazwę serwera inaczej, jak widać tutaj :

$ dig +noedns @127.42.42.254 nAkSEc.tEsT ;; SEKCJA PYTANIA: ;nAkSEc.tEsT. W ;; SEKCJA ODPOWIEDZI: NAKSEC.TEST. 5 W 203.0.113.42 ;; Czas zapytania: 1 ms ;; SERWER: 127.42.42.254#53(127.42.42.254) (UDP);; KIEDY: Pon. 23 stycznia 14 r. 40:34:2023 GMT ;; ROZMIAR MSG rcvd: 56

Nasz serwer DNS przechowuje nazwę naksec.test wszystko pisane dużymi literami, więc sekcja odpowiedzi w odpowiedzi zawiera imię i nazwisko w formularzu NAKSEC.TEST, wraz z jego numerem IPv4 (rekord A) z 203.0.113.42.

Jednak w części odpowiedzi odsyłanej przez nasz serwer DNS „oto dane zapytania zwrócone do sprawdzenia krzyżowego” zachowana jest kombinacja znaków i wielkości liter pierwotnie użyta w wyszukiwaniu DNS:

---> Żądanie od 127.0.0.1:55772 do 127.42.42.254:53 ---> 00000000 c0 55 01 20 00 01 00 00 00 00 00 00 06 6e 41 6b |.U. .........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 |SEC.TEST..... | Wyszukiwanie DNS: rekord A dla nAkSEc.tEsT ==> A=203.0.113.42 <--- Odpowiedź od 127.42.42.254:53 do 127.0.0.1:55772 <--- 00000000 c0 55 84 b0 00 01 00 01 00 00 00 00 06 6e 41 6b |.U...........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 06 4e 41 |SEC.TEST......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |KSEC.TEST.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

Dodatkowe oznakowanie zabezpieczające, bezpłatnie

Bingo!

Istnieje więcej „tagów identyfikacyjnych”, które może dodać wyszukiwanie DNS!

Wraz z około 15 bitami losowo wybranego portu źródłowego i 16 bitami losowo wybranego numeru identyfikacyjnego, żądający może wybrać wielkie i małe litery dla każdego znaku alfabetu w nazwie domeny.

oraz naksec.test zawiera 10 liter, z których każda może być zapisana małymi lub dużymi literami, co daje kolejne 10 bitów losowego „tagowania”.

Mając te dodatkowe szczegóły do ​​odgadnięcia, atakujący musieliby mieć szczęście z czasem, numerem portu UDP, wartością znacznika identyfikacyjnego i wielką literą nazwy domeny, aby wstrzyknąć fałszywą „odpowiedź przejęcia”, którą serwer żądający zaakceptowałby.

Swoją drogą nazwa kodowanie 0x20 powyżej to trochę żart: 0x20 w nagłówku jest 00100000 w systemie binarnym, a samotny bit w tym bajcie jest tym, co odróżnia wielkie i małe litery w systemie kodowania ASCII.

Listy A do I, na przykład wyjdź jako 0x41 do 0x49, while a do i wyjdzie jako 0x61 do 0x69.

 Wykres kodowania ASCII jako tekst ASCII +------+------+------+------+------+------+- -----+------+ |00 ^@ |10 ^P |20 |30 0 |40 @ |50 P |60 ` |70 p | |01 ^A |11 ^P |21 ! |31 1 |41 ZA |51 Q |61 za |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 D |54 T |64 d |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 F |56 V |66 f |76 v | |07 ^G |17 ^W |27 ' |37 7 | 47 G |57 W |67 g |77 w ||08 ^H |18 ^X |28 ( |38 8 |48 H |58 X |68 godz. |78 x | |09 ^I |19 ^Y |29 ) |39 9 |49 I |59 Y |69 i |79 y | |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 | +------+------+------+--- ---+------+------+------+------+

Innymi słowy, jeśli dodasz 0x41+0x20, aby otrzymać 0x61, obracasz się A najnowszych a; jeśli odejmiesz 0x69-0x20, aby uzyskać 0x49, obracasz się i najnowszych I.

Dlaczego teraz?

Być może teraz zastanawiasz się, „Dlaczego teraz, skoro pomysł pojawił się 15 lat temu i czy rzeczywiście byłby dobry?”

Nasze nagłe zainteresowanie, tak się składa, pochodzi z ostatni publiczny e-mail od techników Google, przyznając, że ich eksperymenty z 2022 roku z tą staromodną sztuczką BEZPIECZEŃSTWA zostały wdrożone w prawdziwym życiu:

Jak już wcześniej ogłosiliśmy, Google Public DNS jest w trakcie włączania losowego losowania nazw zapytań DNS wysyłanych do autorytatywnych serwerów nazw. Z powodzeniem wdrożyliśmy go w niektórych regionach Ameryki Północnej, Europy i Azji, chroniąc większość (90%) zapytań DNS w regionach nieobjętych DNS przez TLS.

Co ciekawe, Google sugeruje, że główne problemy, jakie miał z tą prostą i pozornie niekontrowersyjną poprawką, polegają na tym, że podczas gdy większość serwerów DNS konsekwentnie rozróżnia wielkość liter (więc ta sztuczka może być z nimi używana) lub konsekwentnie nie (więc są na liście zablokowanych), Jak możesz się spodziewać…

… kilka serwerów głównego nurtu czasami przechodzi w tryb „rozróżniania wielkości liter” na krótkie okresy czasu, co brzmi jak rodzaj niespójności, której mielibyście nadzieję uniknąć główni usługodawcy.

Czy to naprawdę pomaga?

Odpowiedź na pytanie, "Czy warto?" nie jest jeszcze jasne.

Jeśli masz ładną, długą nazwę firmy, np nakedsecurity.sophos.com (22 znaki alfabetu), to jest mnóstwo dodatkowej mocy sygnalizacyjnej, ponieważ 2²² różne litery oznaczają 4 miliony kombinacji do wypróbowania przez oszustów, pomnożone przez 65536 różnych numerów identyfikacyjnych, pomnożone przez około 32000 do 64000 różnych portów źródłowych do odgadnięcia…

…ale jeśli zapłaciłeś małą fortunę za superkrótką nazwę domeny, taką jak Twitter t.co, twoi napastnicy mają tylko zadanie 2x2x2=8 razy trudniejsze niż wcześniej.

Niemniej jednak myślę, że możemy powiedzieć „Chapeau” Google za wypróbowanie tego.

Jak lubią mówić obserwatorzy cyberbezpieczeństwa, ataki stają się coraz szybsze, więc wszystko, co może wykorzystać istniejący protokół i dodać do niego dodatkowy czas na złamanie zabezpieczeń, prawie „za darmo”, jest użytecznym sposobem walki.

---

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• Platoblockchain. Web3 Inteligencja Metaverse. Wzmocniona wiedza. Dostęp tutaj.
• Źródło: https://nakedsecurity.sophos.com/2023/01/23/serious-security-how-deliberate-typos-might-improve-dns-security/