Korzyści związane z bezpieczeństwem

Wprowadzenie: zagrożenia i zabezpieczenia przed atakiem DNS

Ze względu na otwarty, rozproszony system systemu nazw domenowych i użycie protokołu User Datagram Protocol (UDP) system DNS jest narażony na różne rodzaje ataków. Publiczne lub rekurencyjne resolvery DNS są szczególnie zagrożone, ponieważ nie ograniczają pakietów przychodzących do dozwolonych dozwolonych źródłowych adresów IP. Obawiamy się przede wszystkim na 2 typowe rodzaje ataków:

  • Podszywanie się pod inne osoby w celu zatrucia pamięci podręcznej DNS. Istnieje wiele rodzajów podszywania się pod innych DNS i wykorzystywania fałszywych informacji, które mają na celu przekierowywanie użytkowników z wiarygodnych witryn do złośliwych. Do takich ataków należą m.in. ataki Kaminsky, w których atakujący mają kontrolę nad całą strefą DNS.
  • ataki DoS. Osoby przeprowadzające atak mogą uruchamiać ataki DDoS przeciwko sobie, a innym osobom, które przeprowadzają ataki DoS, w innych systemach. Ataki przeprowadzane przez serwery DNS i przeprowadzające ataki DoS na innych systemach przez wykorzystanie dużego rozmiaru rekordu/odpowiedzi DNS są nazywane atakami wzmacniającymi.

Poniżej znajdziesz omówienie każdej klasy ataku.

Pamięć podręczna dotycząca zatruć

Jest kilka wariantów ataków polegających na podszywaniu się pod DNS, które mogą spowodować zatrucie pamięci podręcznej. Ogólny opis wygląda tak:

  1. Atakujący wysyłający docelowy resolver DNS wysyła wiele zapytań dotyczących nazwy domeny, której serwer nie jest potwierdzony i prawdopodobnie nie znajduje się w pamięci podręcznej serwera.
  2. resolver wysyła żądania do innych serwerów nazw (których adresy IP mogą też przewidzieć atakujący).
  3. Tymczasem atakujący zapełnia serwer ofiar fałszowanymi odpowiedziami, które wyglądają, jakby pochodziły z serwera z przekazanym dostępem. Odpowiedzi zawierają rekordy, które ostatecznie określają żądaną domenę dla adresów IP kontrolowanych przez atakującego. Mogą one zawierać rekordy odpowiedzi dotyczące zakończonej nazwy lub, co gorsza, mogą przekazać uprawnienia do serwera nazw należącego do atakującego, aby mieć kontrolę nad całą strefą.
  4. Jeśli jedna ze sfałszowanych odpowiedzi pasuje do żądania resolvera (np. według nazwy zapytania, typu, identyfikatora i portu źródłowego) i zostanie odebrana przed odpowiedzią z oryginalnego serwera nazw, resolver akceptuje sfałszowaną odpowiedź i zapisuje jej faktyczną odpowiedź.
  5. Przyszłe zapytania o przejętą domenę lub strefę odpowiadają na sfałszowane wyniki DNS z pamięci podręcznej. Jeśli atakujący określił długi czas życia w sfałszowanej odpowiedzi, sfałszowane rekordy są przechowywane w pamięci podręcznej tak długo, jak to możliwe, bez odświeżania.

Jeśli chcesz dowiedzieć się więcej o atakach Kaminskiego, przeczytaj artykuł Ilustrowany przewodnik pod kątem luki w zabezpieczeniach usługi Kaminski DNS.

DoS i ataki wzmacniające

Programy do rozpoznawania nazw DNS są podatne na typowe zagrożenia DoS, które mają wpływ na dowolny system sieciowy. Jednak ataki wzmacniania są szczególnie istotne, ponieważ resolvery DNS są celem ataków, które korzystają z resolverów przez współczynnik rozmiaru odpowiedzi na żądanie, aby uzyskać dodatkową wolną przepustowość. Rozdzielacze obsługujące EDNS0 (Mechanizmy rozszerzeń do DNS) są szczególnie narażone na ataki ze względu na znacznie większy rozmiar pakietów.

W scenariuszu wzmocnienia atak przebiega w następujący sposób:

  1. Atak wysyła zapytanie do serwera DNS ofiary, używając sfałszowanego źródłowego adresu IP. Zapytania mogą być wysyłane z jednego systemu lub sieci systemów przy użyciu tego samego sfałszowanego adresu IP. Zapytania są związane z informacjami, których atakujący wie, że w rezultacie pojawi się kilkanaście odpowiedzi1, czyli rozmiar oryginalnych zapytań (czyli nazwa „&ampt;ampampify" ataku”).
  2. Serwer ofiary wysyła duże odpowiedzi na źródłowy adres IP przekazany w sfałszowanych żądaniach, powodując przeciążenie systemu i wywołanie stanu DoS.

Łagodzenie

Standardowe rozwiązanie systemowe do wykrywania luk w zabezpieczeniach DNS to DNSSEC. Dopóki jednak nie zostanie ono uniwersalnie wdrożone, otwarte programy do wykrywania DNS muszą podejmować działania w celu ograniczenia znanych zagrożeń. Wprowadziliśmy wiele technik opisanych w artykule IETF RFC 5452: pomiary odporności DNS na sfałszowane odpowiedzi w większości z nich. W publicznej wersji DNS Google wdrożyliśmy i zalecamy wykonanie tych czynności:

  • Zabezpieczenie kodu przed przepełnieniem bufora, szczególnie w przypadku kodu odpowiedzialnego za analizowanie i serializowanie wiadomości DNS.
  • Nadmierne zasoby maszynowe do ochrony przed bezpośrednimi atakami DoS na samym resolverze. Ponieważ adresy IP są łatwe do zaatakowania, blokowanie zapytań na podstawie adresu IP lub podsieci nie jest możliwe. Jedynym skutecznym sposobem obsługi takich ataków jest po prostu wchłonięcie obciążenia.
  • Wdróż podstawową kontrolę poprawności pakietów odpowiedzi oraz wiarygodności serwera nazw, aby chronić się przed prostym zatruciem pamięci podręcznej. Są to standardowe mechanizmy i kontrola sprawdzania, czy powinny działać wszystkie resolvery zgodne z normami.
  • Dodawanie entropii do żądań wiadomości, aby zmniejszyć prawdopodobieństwo wystąpienia bardziej zaawansowanych ataków podszywania się i zatruwania pamięci podręcznej, takich jak ataki Kaminsky. Istnieje wiele zalecanych technik dodawania entropii. Poniżej znajdziesz omówienie zalet, ograniczeń i wyzwań związanych z poszczególnymi metodami, a także o sposobie ich wdrożenia w publicznym systemie DNS Google.
  • Usuwanie duplikatów zapytań, aby chronić się przed prawdopodobieństwem ataków i urodzin.
  • Prośby o ograniczenie liczby żądań, aby zapobiec atakom typu DoS i wzmacniaczom.
  • Monitorowanie usługi pod adresami IP klienta z wykorzystaniem największej przepustowości i uzyskanie najwyższego współczynnika rozmiaru odpowiedzi.

DNSSEC

Standard zabezpieczeń domeny (DNSSEC) jest określony w kilku identyfikatorach IETF RFC: 4033, 4034, 4035 i 5155.

Sprawdzający autentyczność odpowiedzi otrzymanych z serwerów nazw stosujących ataki typu „licznik” pamięci podręcznej licznika DNSSEC. Każda strefa DNS zawiera zestaw par kluczy prywatnych/publicznych, a każdy rekord DNS generuje i szyfruje unikalny podpis cyfrowy za pomocą klucza prywatnego. Odpowiedni klucz publiczny jest następnie uwierzytelniony przy użyciu łańcucha zaufania przez klucze należące do stref nadrzędnych. resolvery zgodne z DNSSEC odrzucają odpowiedzi, które nie zawierają prawidłowych podpisów. DNSSEC skutecznie uniemożliwia manipulowanie odpowiedziami, ponieważ w praktyce podpisy są praktycznie niemożliwe do sfałszowania bez dostępu do kluczy prywatnych.

Od stycznia 2013 roku Google Public DNS w pełni obsługuje DNSSEC. Akceptujemy i przekazujemy wiadomości w formacie DNSSEC oraz weryfikujemy odpowiedzi w celu prawidłowego uwierzytelnienia. Gorąco zachęcamy do tego inne osoby.

Zapisujemy też odpowiedzi NSEC w pamięci podręcznej zgodnie z opisem w dokumencie IETF RFC 8198: Agressive Use of DNSSEC-Verified Cache Może to zmniejszyć liczbę zapytań NXDOMAIN na serwery nazw implementujące DNSSEC i używać NSEC do negatywnych odpowiedzi.

Transport szyfrowany po stronie klienta

Google Public DNS obsługuje zaszyfrowane protokoły transportowe, DNS przez HTTPS oraz DNS przez TLS. Te protokoły zapobiegają modyfikowaniu, przechwytywaniu i podszywaniu się, znacznie poprawiając prywatność i bezpieczeństwo między klientem a publicznym serwerem DNS Google. Uzupełniają one DNSSEC, aby umożliwić kompleksowe uwierzytelnianie wyszukiwań DNS.

Wdrażanie podstawowych kontroli poprawności

Niektóre uszkodzenia pamięci podręcznej DNS mogą być spowodowane niezamierzonymi i niekorzystnymi niezgodnościami między żądaniami a odpowiedziami (np.z powodu nieprawidłowo skonfigurowanego serwera nazw, błędu w systemie DNS itd.). Programy rozpoznawania nazw powinny przeprowadzać przynajmniej testy, aby zweryfikować wiarygodność i trafność serwerów nazw. Zalecamy zastosowanie (i wdrożenie) wszystkich tych środków ochrony:

  • Nie ustawiaj bitów rekurencyjnych w żądaniach wychodzących i zawsze stosuj łańcuchy przekazywania. Wyłączenie bitów rekurencyjnych zapewnia, że resolver działa w trybie &rytacyjnym i powoduje, że zapytania dotyczące każdego serwera nazw w łańcuchu przekazywania są przeprowadzane w sposób wyraźny, zamiast umożliwić innym serwerom nazw wykonywanie tych zapytań w Twoim imieniu.
  • Odrzucać podejrzane odpowiedzi. Poniżej znajdziesz szczegółowe informacje, które uznajemy za &podejrzane;
  • Nie zwracaj rekordów A do klientów na podstawie rekordów typu glue zapisanych w pamięci podręcznej z poprzednich żądań. Jeśli na przykład otrzymasz zapytanie klienta dotyczące domeny ns1.example.com, rozwiąż adres ponownie, zamiast wysyłać rekord A na podstawie rekordów glue zapisanych w pamięci podręcznej z serwera nazw domen .com.

Odrzucanie odpowiedzi, które nie spełniają wymaganych kryteriów

Publiczny serwer DNS Google odrzuca wszystkie następujące przyczyny:

  • Odpowiedzi nieczytelne lub zniekształcone.
  • Odpowiedzi, w których pola klucza nie zgadzają się z odpowiednimi polami w żądaniu. Obejmują one identyfikator zapytania, źródłowy adres IP, port źródłowy, docelowy adres IP lub nazwę zapytania. Pełny opis zachowania podszywania się pod DNS znajdziesz w sekcji RFC 5452, sekcja 3.
  • Rekordy, które nie mają związku z żądaniem.
  • Rekordy odpowiedzi, których nie możemy odtworzyć w łańcuchu CNAME.
  • Rekordy (w odpowiedzi, urzędzie lub dodatkowych sekcjach), dla których serwer nazw nadawcy nie jest wiarygodny. &Wiarygodność&serwera określamy na podstawie jego miejsca w łańcuchu przekazywania dostępu dla danej domeny. Google Public DNS przechowuje w pamięci podręcznej informacje o łańcuchu przekazywania. Sprawdzamy każdą odpowiedź na podstawie informacji z pamięci podręcznej, aby ustalić wiarygodność serwera odpowiedzi na konkretne żądanie.

Dodawanie entropii do żądań

Gdy resolver musi przeprowadzić podstawowe kontrole stanu, zaatakowany musi zapełnić resolver ofiarami odpowiedzi, aby dopasować identyfikator zapytania, port UDP (żądania), adres IP (odpowiedzi) i nazwę zapytania pierwotnego żądania, zanim będzie działać dozwolony serwer nazw.

Nie jest to jednak łatwe, ponieważ to jednoznacznie identyfikujące pole zapytania ma tylko 16 bitów (czyli 1/65 536 szans na prawidłowe działanie). Pozostałe pola są też ograniczone, dzięki czemu łączna liczba niepowtarzalnych kombinacji jest stosunkowo niska. Aby dowiedzieć się, jak obliczyć kombinatory, zapoznaj się z sekcją 7 (RFC-5452).

Wyzwaniem jest więc dodanie jak największej entropii do pakietu żądania w standardowym formacie wiadomości DNS, aby utrudniać osobom przeprowadzającym atak prawidłowe dopasowanie pól w okresie możliwości. Zalecamy zastosowanie i wdrożenie wszystkich technik opisanych w poniższych sekcjach.

W lipcu 38 lipca 2022 r. przedstawiliśmy zaktualizowaną opinię o wymienionych tutaj technikach podczas konferencji DNS OARC. Zawiera ona też zalecenia dla operatorów serwera nazw.

Losowe porty źródłowe

Domyślnie nigdy nie zezwalaj pakietom żądań wychodzących na używanie domyślnego portu UDP 53 ani używanie przewidywalnego algorytmu do przypisywania wielu portów (np. prostego przyrostu). Użyj jak największej liczby portów od 1024 do 65535 w Twoim systemie. Do przypisywania portów użyj niezawodnego generatora liczb losowych. Na przykład publiczny serwer DNS Google używa ok. 15 bitów, co umożliwia uzyskanie około 32 tys. różnych numerów portów.

Pamiętaj, że jeśli Twoje serwery są wdrożone za zaporą sieciową, systemem równoważenia obciążenia lub innymi urządzeniami wykonującymi translację adresów sieciowych (NAT), urządzenia te mogą usuwać losowe porty pakietów wychodzących. Pamiętaj, aby skonfigurować urządzenia NAT do wyłączania deranizacji portu.

losowy wybór serwerów nazw,

Niektóre resolvery podczas wysyłania żądań do serwera głównego, domeny najwyższego poziomu lub innych serwerów nazw powinny wybrać adres IP serwera nazw na podstawie najkrótszego czasu oczekiwania. Zalecamy randomizowanie docelowych adresów IP w celu dodania entropii do żądań wychodzących. W publicznym serwerze DNS Google losowo wybieramy serwer nazw spośród skonfigurowanych serwerów nazw dla każdej strefy, co nieco faworyzuje.

Jeśli martwisz się z opóźnieniem, możesz użyć pasmowania w czasie błądzenia (RTT), które składa się z losowych adresów w zakresie poniżej określonego progu opóźnienia (np. 30 ms, 300 ms itp.).

Pliki cookie DNS

RFC 7873 definiuje opcję EDNS0 umożliwiającą dodawanie 64-bitowych plików cookie do wiadomości DNS. Plik cookie DNS obsługujący klienta zawiera losowy 64-bitowy plik cookie i (opcjonalnie) plik cookie serwera (jeśli jest znany). Jeśli serwer odbierający uzna plik cookie za prawidłowy, w pliku cookie pojawi się prawidłowy plik cookie klienta i poprawny plik cookie serwera. Klient obsługujący tę funkcję może następnie zweryfikować odpowiedź z oczekiwanego serwera przez zweryfikowanie pliku cookie klienta w odpowiedzi.

Jeśli serwer nazw nie obsługuje plików cookie DNS, do dodania entropii można użyć poniższych dwóch opcji.

Wielkość liter w nazwach zapytań

Standardy DNS wymagają, aby serwery nazw rozróżniały wielkość liter. Na przykład nazwy example.com i EXAMPLE.COM powinny mieć ten sam adres IP2. Oprócz tego każda mniejszość serwerów nazw powtarza nazwę w odpowiedzi na żądanie, zachowując pierwotną wielkość liter.

Innym sposobem dodawania entropii do żądań jest losowe zmienianie wielkości liter w nazwach domen zapytań. Ta technika, znana też jako „"0x20"” oznacza, że w standardzie IETF Internet opiera się na literze 0x20. Dlatego zaproponowano ją w wersji roboczej IETF w internecie. Użycie bitu 0x20 w etykietach DNS do poprawy tożsamości transakcji. W przypadku tej metody odpowiedź serwera nazw musi pasować nie tylko do nazwy zapytania, ale także do każdej litery w ciągu znaków, np. wWw.eXaMpLe.CoM lub WwW.ExamPLe.COm. Może to spowodować niewielką energię w zapytaniach dotyczących domen najwyższego poziomu i głównych, ale nie będzie to skuteczne w przypadku większości nazw hostów.

Jednym z znaczących wyzwań, które znaleźliśmy podczas wdrażania tej metody, jest to, że niektóre serwery nazw nie działają w oczekiwany sposób:

  • W przypadku niektórych serwerów nazw odpowiedź jest rozróżniana (wielkość liter nie jest rozróżniana), ale wyniki są zwracane poprawnie bez względu na wielkość liter w żądaniu.
  • W przypadku innych serwerów nazw wielkość liter jest rozróżniana (z uwzględnieniem standardów DNS): obsługa nazw odpowiedników w żądaniu jest inna w zależności od przypadku (niezgodność odpowiedzi lub zwrócenie nieprawidłowych odpowiedzi NXDOMAIN zgodnych z nazwą nazwy w żądaniu).
  • Niektóre serwery nazw działają prawidłowo z wyjątkiem zapytań PTR w strefie arpa.

W przypadku obu typów serwerów nazw zmiana nazwy zapytania spowodowałaby niepożądane rezultaty: w przypadku pierwszej grupy odpowiedzi nie można było odróżnić od sfałszowanej. W przypadku drugiej grupy odpowiedź mogłaby być całkowicie nieprawidłowa.

Obecne rozwiązanie tego problemu polega na tym, że stosuje się randomizację tylko serwerów nazw, o których wiadomo, że standardy są stosowane prawidłowo. W przypadku każdej z nich wyświetlamy odpowiednie subdomeny wyjątków, korzystając z analizy naszych dzienników. Jeśli odpowiedź, która wydaje się pochodzić z tych serwerów, nie zawiera właściwego przypadku, odrzucimy ją. Włączone serwery nazw obsługują ponad 70% naszego ruchu wychodzącego.

Wcześniejsze etykiety jednorazowe do zapytań

Jeśli resolver nie może bezpośrednio rozpoznać nazwy z pamięci podręcznej lub nie może bezpośrednio wysłać zapytania do wiarygodnego serwera nazw, musi śledzić odesłania z poziomu serwera nazw domeny najwyższego poziomu lub TLD. W większości przypadków żądania wysyłane do serwerów nazw domeny najwyższego poziomu lub do domeny najwyższego poziomu powodują przekierowanie na inny serwer nazw, a nie na próbę rozpoznania nazwy do adresu IP. W takich żądaniach do nazwy zapytania można bezpiecznie dodawać losową etykietę, aby zwiększyć entropię żądania i nie narażać się na ryzyko rozwiązania nieistniejącej nazwy. Oznacza to, że wysłanie żądania do serwera nazw odsyłającego w przypadku nazwy z prefiksem, takim jak entriih-f10r3.www.google.com, powinno zwrócić ten sam wynik jak żądanie dotyczące www.google.com.

Chociaż w praktyce takie żądania stanowią mniej niż 3% żądań wychodzących, przy założeniu, że normalny ruch (ponieważ większość zapytań można znaleźć bezpośrednio w pamięci podręcznej lub według pojedynczego zapytania), są to właśnie typy żądań, których atakujący próbuje wymusić problem, aby rozwiązać problem. Dlatego ta metoda może być bardzo skuteczna w celu zapobiegania naruszeniom Kaminskiego.

Stosowanie tej metody wymaga, aby etykiety jednorazowe były używane tylko w przypadku żądań, które mogą zagwarantować odesłania. Oznacza to, że odpowiedzi niezawierające rekordów w sekcji odpowiedzi. Podczas próby zdefiniowania zestawu takich żądań napotkaliśmy jednak kilka wyzwań:

  • Niektóre serwery nazw TLD krajowego kodu domeny (TLD) są wiarygodnymi postaciami innych domen najwyższego poziomu (2LD 2LD). Mimo że są one oznaczone 2 etykietami, działają one tak samo jak domeny najwyższego poziomu. Z tego powodu często są obsługiwane przez serwery nazw ccTLD. Na przykład serwery nazw .uk są również wiarygodne w przypadku stref mod.uk i nic.uk, a tym samym – nazw hostów znajdujących się w tych strefach, takich jak www.nic.uk, www.mod.uk itd. Oznacza to, że żądania wysyłane do serwerów nazw ccTLD w celu rozwiązania problemu z takimi nazwami hostów nie będą kierować do witryn odsyłających, ale z wiarygodnymi odpowiedziami. Jeśli użyjesz takich nazw, nie uda się znaleźć nazw.
  • Czasami ogólne serwery nazw TLD (gTLD) zwracają nierzetelne odpowiedzi dla serwerów nazw. Niektóre nazwy hostów serwerów nazw znajdują się w strefie gTLD, a nie w strefie ich domeny. Domena gTLD zwraca nieautoryzowaną odpowiedź na te nazwy hostów, używając dowolnego rekordu typu glue, który znajduje się w bazie danych, zamiast zwracania odesłania. Na przykład serwer nazw ns3.indexonlineserver.com znajdował się wcześniej w strefie .COM gTLD, a nie w strefie indexonlineserver.com. W odpowiedzi na żądanie skierowane do serwera gTLD domeny n3.indexonlineserver.com zamiast tego odesłania otrzymaliśmy adres IP. Jeśli jednak dołączysz etykietę niejednoznaczną, otrzymaliśmy skierowanie do indexonlineserver.com, który nie mógł rozpoznać nazwy hosta. Dlatego w przypadku serwerów nazw nie można dodawać etykiet jednorazowych, które wymagają rozwiązania z serwera gTLD.
  • Dane dotyczące stref i nazw hostów zmieniają się z czasem. Może to spowodować, że niepołączonych nazw hosta, które wcześniej nie były możliwe do rozwiązania, staną się one nie do rozwiązania, jeśli łańcuch przekazania zostanie zmieniony.

Aby sprostać tym wyzwaniom, skonfigurowaliśmy wyjątki dla nazw hostów, dla których nie można dołączyć etykiet jednorazowych. Z naszych dzienników serwera wynika, że są to nazwy hostów, dla których serwery nazw domen najwyższego poziomu zwracają odpowiedzi bez odesłania. Nieustannie sprawdzamy listę wyjątków, aby mieć pewność, że z czasem zachowuje ona ważność.

Usuwanie duplikatów zapytań

Mechanizmy rozpoznawania nazw DNS są narażone na ataki dnia urodzenia, ponieważ wykorzystują paradoks matematyczny, w którym prawdopodobieństwo dopasowania nie wymaga dużej liczby wprowadzonych danych. Ataki urodzinowe polegają na zalaniu serwera ofiar nie tylko w formie sfałszowanych odpowiedzi, ale także w przypadku początkowych zapytań, co powoduje, że resolver wysyła wiele żądań dla pojedynczej nazwy użytkownika. Im większa liczba wysłanych żądań wychodzących, tym większe prawdopodobieństwo, że osoba przeprowadzająca atak spełni jedno z tych żądań ze sfałszowaną odpowiedzią. atakujący potrzebuje tylko 300 żądań lotniczych, aby zapewnić 50-procentowe szanse na dopasowanie, i 700 żądań niemal w 100%.

Aby zabezpieczyć się przed tą strategią ataku, pamiętaj, by odrzucić wszystkie zduplikowane zapytania z kolejki poczty wychodzącej. Na przykład publiczny publiczny DNS Google nigdy nie zezwala na więcej niż jedno żądanie typu twoja nazwa zapytania, typ zapytania i docelowy adres IP.

Zapytania ograniczające liczbę wyświetleń

Zapobieganie atakom typu „odmowa usługi” wiąże się z kilkoma określonymi wyzwaniami dla otwartych rekurencyjnych resolverów DNS:

  • Otwarte rozwiązania rekurencyjne to atrakcyjne cele uruchamiania ataków wzmacniających. Są to wydajne serwery o dużych mocach i mogą generować większe odpowiedzi niż przeciętny serwer nazw – zwłaszcza gdy haker może wstrzyknąć do pamięci podręcznej dużą odpowiedź. Żaden deweloper otwartej usługi DNS nie chce, aby jego serwery służyły do przeprowadzania ataków na inne systemy.
  • Ataki wzmacniania mogą być trudne do wykrycia w czasie ich występowania. Osoby przeprowadzające ataki mogą rozpocząć atak na tysiącach otwartych rozwiązań, tak aby każdy resolver widział tylko niewielką część ogólnej liczby zapytań i nie może wyodrębnić wyraźnego sygnału, że zostało ono przejęte.
  • Złośliwy ruch musi być blokowany bez zakłóceń i zakłóceń w działaniu usługi DNS dla zwykłych użytkowników. DNS jest podstawową usługą sieciową, więc wyłączenie serwera nie pozwala na atak, a także przez długi czas nie zezwala na dostęp do danego adresu IP klienta. Osoby podejmujące decyzje muszą mieć możliwość szybkiego zablokowania ataku zaraz po jego rozpoczęciu i przywrócenia w pełni funkcjonalnej usługi zaraz po zakończeniu.

Najlepszym sposobem na walkę z atakami DoS jest nałożenie ograniczeń na mechanizm lub ograniczanie mechanizmów ograniczania liczby żądań. Publiczny serwer DNS Google stosuje 2 rodzaje kontroli szybkości:

  • Kontrola nad liczbą wychodzących żądań do innych serwerów nazw. Aby chronić inne serwery nazw DNS przed atakami typu DoS, które mogą być uruchamiane z naszych serwerów resolverów, Google Public DNS egzekwuje limity zapytań na sekundę dla poszczególnych klastrów udostępniania dla każdego adresu IP serwera nazw.

  • Kontrola nad liczbą odpowiedzi wychodzących do klientów. Aby chronić inne systemy przed wzmacnianiem i tradycyjnymi atakami DoS (botnetami), które można uruchomić z naszych serwerów resolverów, Google Public DNS wykonuje 2 rodzaje ograniczeń liczby zapytań w zapytaniach klienta:

    • Aby chronić je przed tradycyjnymi atakami wykorzystującymi woluminy, każdy serwer stosuje limity zapytań na sekundę na dany adres IP klienta i średnią przepustowość.
    • Aby chronić się przed atakami typu wzmacnianie, które polegają na wykorzystywaniu dużych odpowiedzi na małe zapytania, każdy serwer wymusza maksymalny współczynnik wzmocnienia na podstawie adresu IP klienta. Średni współczynnik wzmocnienia to konfigurowalny stosunek rozmiaru do odpowiedzi na zapytanie, określony na podstawie historycznych wzorców ruchu zarejestrowanych w naszych logach serwera.

    Jeśli zapytania DNS z jednego źródłowego adresu IP przekraczają maksymalną szybkość zapytań na sekundę, nadmiarowe zapytania zostaną odrzucone. Jeśli zapytania DNS wysyłane przez UDP z jednego źródłowego adresu IP spójnie przekraczają limit średniej przepustowości lub wzmacniania (co czasami zdarza się duża odpowiedź), zapytania mogą zostać pominięte lub może zostać wysłana tylko niewielka odpowiedź. Małe odpowiedzi mogą być odpowiedzią na błąd lub pustą odpowiedzią z ustawionym bitem skracania (aby większość prawidłowych zapytań była powtarzana przez TCP i kończy się powodzeniem). Nie wszystkie systemy lub programy ponawiają próby przez TCP. System DNS może być blokowany przez zapory sieciowe po stronie klienta, więc niektóre aplikacje mogą nie działać prawidłowo po skróceniu odpowiedzi. Jednak skracanie czasu umożliwia w większości przypadków prawidłowe działanie klientów zgodnych ze standardem RFC.

  1. Przykłady znajdziesz w publikacji Ampamping ampampations (ataków wzmacniania DNS) oraz w ogóle omówiliśmy ten problem.↩

  2. RFC 1034, sekcja 3.5: ↩

    Pamiętaj, że chociaż w nazwach domen dozwolone są wielkie i małe litery, wielkość liter nie ma znaczenia. To znaczy, że dwie nazwy o tej samej nazwie, ale z innym przypadku, powinny być traktowane tak, jakby były identyczne.