C

iasteczka DNS zostały przedstawione w RFC 7873. Są opcją rozszerzonego DNS (ang. EDNS – Extended DNS), która próbuje zaadresować wiele problemów, które próbował rozwiązać DNSSEC np. zatruwanie pamięci podręcznej (ang. Cache Poisoning), czy ataki polegające na wzmocnieniu odpowiedzi DNS (ang. DNS Amplification Attack) z sfałszowanymi adresami źródłowymi (ang. Spoofed Source Queries), którym DNSSEC nie zapobiegał, a nawet w niektórych przypadkach je pogarszał. Ciasteczka są znacznie łatwiejsze do wdrożenia niż DNSSEC, a bezpieczeństwo zapewniane przez nie można porównać do bezpieczeństwa uzyskiwanego dzięki użyciu TCP zamiast UDP.

Zasada działania:

W mechanizmie ciasteczek DNS zarówno serwer, jak i klient DNS przechowują ciasteczka. Każdy z nich utrzymuje inne ciasteczko, które można użyć podczas transakcji DNS, aby upewnić się, że żądanie DNS rzeczywiście pochodzi od autentycznego klienta DNS, a jego źródłowy adres IP nie jest sfałszowany. Ciasteczko klienta ma długość 8 bajtów i jest pseudolosową funkcją adresu IP klienta, adresu IP serwera i tajnego ciągu znanego tylko klientowi (powinien mieć co najmniej 64 bity). Ta pseudolosowa funkcja jest tajna dla klienta i może być okresowo zmieniana. Każdy klient DNS będzie miał inne ciasteczko DNS, którego może użyć wraz z żądaniem DNS do zweryfikowania jego autentyczności. Ponieważ ciasteczko DNS jest zwracane tylko do adresu IP, z którego wygenerowano żądanie, nie można go używać do śledzenia użytkowników internetu ***.

Podobnie sprawa się ma od strony serwera. Każdy serwer DNS o innym adresie IP będzie miał inne ciasteczko. Jest ono pseudolosową funkcją ciasteczka klienta, adresu IP serwera (adres IP klienta nie jest używany, ponieważ może się zmienić z powodu użycia NAT) i tajnego ciągu znanego tylko serwerowi (powinna mieć co najmniej 64 bity). Pseudolosowa funkcja jest tajna dla serwera i może być okresowo zmieniana. Serwer DNS musi wysyłać różne ciasteczka dla różnych klientów. Kiedy klient DNS wysyła żądanie DNS zawiera w nim ciasteczko. Jeśli zna ciasteczko serwera – jest ono wysyłane razem ze swoim. Serwer po otrzymaniu żądania DNS od klienta razem z ciasteczkiem sprawdza, czy zawiera ono tylko ciasteczko klienta (bez ciasteczka serwera) – jeśli tak to oblicza on swoje ciasteczko przy użyciu tajnej pseudolosowej funkcji używając do tego adresu IP klienta, jego ciasteczka i tajnego ciągu znanego tylko serwerowi. Po tym zabiegu serwer procesuje żądanie DNS klienta i odsyła mu swoje ciasteczko, aby klient mógł się na nie powoływać w przyszłej komunikacji.

Jeśli serwer otrzyma swoje ciasteczko razem z ciasteczkiem klienta – zweryfikuje ich poprawność, a następnie zacznie przetwarzać żądanie DNS. Wygenerowana odpowiedź zostanie wysłana z tym samym ciasteczkiem lub nowym, jeśli serwer zdecyduje się na jego przegenerowanie. Różni klienci np. znajdujący się za NATem mogą używać swoich lokalnych adresów IP, aby posiadać różne ciasteczka. Na podstawie różnych ciasteczek klientów mogą zostać wygenerowane różne ciasteczka po stronie serwera, aby bezpiecznie przeprowadzać transakcje DNS bez większej komplikacji. Klient obsługujący ciasteczka może je wysyłać przy każdym żądaniu. To “nie powinno” powodować żadnych problemów, ponieważ nieobsługiwane opcje po stronie serwera powinny zostać zignorowane. Jednak mogą istnieć serwery DNS lub ich warstwy ochronne, które będą odrzucać żądania jako źle sformułowane. W przypadku źle sformatowanego ciasteczka zwracany jest błąd FORMERR. Żądania zawierające niepoprawne ciasteczka serwera traktowane są jak żądania, które w ogóle nie zawierają ciasteczka serwera. Funkcja ta pozwala klientowi prowadzić komunikację, jeśli adres IP serwera uległ zmianie lub został zrestartowany i użył nowego tajnego klucza.

Plusy dodatnie:

Korzystanie z ciasteczek umożliwia klientowi wykonywanie mniej pracy podczas wysyłania zapytań DNS. Na przykład może zrezygnować z zarządzania wieloma gniazdami sieciowymi w celu uzyskania losowości portów źródłowych, aby zapobiec otrzymywaniu fałszywych odpowiedzi. Po drugie zasada działania pytania i odpowiedzi DNS z użyciem ciasteczek DNS adresuje ataki DoS i ich wzmocnione odmiany. Ograniczając szybkość odpowiedzi (ang. Response Rate Limiting) na “żądanie ciasteczek” serwera DNS per klient skutecznie można ograniczyć szybkość z jaką dany klient może wysyłać pakiety z podrobionym adresem źródłowym. Nie ma znaczenia, jak szybko atakujący wysyła żądania / pakiety DNS – otrzyma tylko ciasteczko w określonym czasie, które umożliwi mu wysyłanie prawidłowych żądań w określonej szybkości. W dodatku mechanizm ograniczający szybkość odpowiedzi może być bardziej skuteczny, gdy będzie w stanie skupić się tylko na zapytaniach klientów niezwiązanych jeszcze ciasteczkami. Biorąc również pod uwagę, że osoba atakująca nie będzie w stanie sfałszować ciasteczka dla celu wzmocnionego ataku DDoS – jedyną rzeczą, do której może zmusić serwer DNS to wysłanie do ofiary krótkiego komunikatu błędu (już bez dużych rekordów TXT i w dodatku zlimitowane prędkością).

Obsługa w Linuksie:

Funkcjonalność ciasteczek jest włączona fabrycznie w serwerze BIND od wersji 9.11.0 – dlatego jeśli posiadamy system Ubuntu w wersji 18.04 LTS możemy zaobserwować ich używanie odpytując swój lokalny serwer DNS:

root@darkstar:~# dig @localhost -t A host.tld

; DiG 9.11.3-1ubuntu1.8-Ubuntu @localhost -t A host.tld
; (1 server found)
;; global options: +cmd
;; Got answer:
;; HEADER opcode: QUERY, status: NOERROR, id: 40722
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 92253f92800adc2878b84ea45d698d3948f17a4fffe71525 (good) 
;; QUESTION SECTION:
;host.tld.                         IN      A

;; ANSWER SECTION:
host.tld.                  300     IN      A       222.77.99.9

;; AUTHORITY SECTION:
host.tld.                  86400   IN      NS      ns1.tld.

;; Query time: 523 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 30 22:55:21 CEST 2019
;; MSG SIZE  rcvd: 141

Jeśli posiadamy wiele serwerów DNS w konfiguracji anycast możemy ręcznie skonfigurować wspólny, tajny ciąg (128 bitów) dla każdego z serwerów, aby współdzieliły to samo ciasteczko:

root@darkstar:~# dd if=/dev/random bs=16 count=1 | od -x
1+0 records in
1+0 records out
16 bytes transferred in 0.000026 secs (615678 bytes/sec)
0000000      491c    b772    dfaf    cac4    4a4f    d6f2    0ab6    871b
0000020

Teraz możemy dodać opcję cookie-secret do pliku named.conf:

cookie-secret "491cb772dfafcac44a4fd6f20ab6871b";

Standardowym algorytmem jest AES (cookie-algorithm). Do wyboru mamy jeszcze SHA256 oraz SHA1. Z uwagi na fakt, że nasz serwer jest autorytatywny dla domeny nfsec.pl to jako dopełnienie do ciasteczek w ramach tego samego pliku dodajemy dyrektywę limitującą liczbę odpowiedzi na sekundę dla danego klienta:

rate-limit {
  responses-per-second 10;
};

W celu jej przetestowania generujemy ruch większy niż 10 żądań na sekundę do serwera DNS:

dig @ns1.nfsec.pl TXT -f <(printf 'nfsec.pl\n%.0s' {1..20})

Po stronie logów serwera powinniśmy zobaczyć wpisy:

Aug 31 14:18:01 stardust named[19131]: 
limit responses to 127.0.0.0/24 for nfsec.pl IN TXT  (5d4d8703)
Aug 31 14:18:01 stardust named[19131]: 
client @0x7f53a8010870 127.0.0.1#33754 (nfsec.pl): rate limit slip response 
to 127.0.0.0/24 for nfsec.pl IN TXT  (5d4d8703)
Aug 31 14:18:01 stardust named[19131]: 
client @0x7f53a8010870 127.0.0.1#48420 (nfsec.pl): rate limit drop response
to 127.0.0.0/24 for nfsec.pl IN TXT  (5d4d8703)

Kwestie wdrożenia:

Ponieważ ciasteczka DNS jako opcja EDNS będą lub już są wdrażane przez wielu dostawców od strony serwerów DNS, jak i klientów – nasze serwery będą coraz częściej napotykać tę opcję w otrzymywanych zapytaniach. Powinniśmy się upewnić, że nasze serwery i wszystkie urządzenia pośrednie (load balancery, zapory sieciowe, proxy) są w pełni zgodne z RFC6891. Ciasteczka podobnie jak wszystkie opcje EDNS teoretycznie można wdrażać stopniowo i niezależnie. Serwery, które nie są świadome EDNS, powinny ją ignorować (zgodnie z RFC). W praktyce nigdy tak nie jest; około 10% serwerów (stan na czerwiec 2016 r.) źle i na różne sposoby obsługuje zapytania z nieznanymi opcjami EDNS. Zwykle nie jest to fatalne w skutkach dla DNS Cookie powodując tylko nieco wolniejszą obsługę zapytań od tych serwerów. Niemniej jednak błędne obchodzenie się z opcją COOKIE powoduje błędy, które mogą mieć negatywne skutki dla rozpoznawania nazw, gdy resolver sprawdza poprawność odpowiedzi pochodzących z podpisanej strefy, a autorytatywny serwer zwraca kody FORMERR lub BADVERS lub nie odpowiada w ogóle na zapytanie. Błędne obchodzenie się z opcją COOKIE może również powodować niepoprawne odpowiedzi (takie jak NXDOMAIN lub NOERROR/NODATA, kiedy powinna nadejść pozytywna odpowiedź). Jest to zwykle spowodowane nieprawidłowo skonfigurowanym urządzeniem pośrednim.

Więcej informacji: DNS Cookies in BIND 9, Using the Response Rate Limiting Feature, DNS Cookies and DDoS Attacks, DNS is Changing. Are you Ready?