Korzystanie ze strefy DNS posiadającej skonfigurowanym DNSSEC zdecydowanie poprawia bezpieczeństwo. Wiąże się jednak także z dodatkowymi zadaniami administracyjnymi oraz potencjalnie negatywnym wpływem na wydajność sieci. Zanim więc uruchomi się DNSSEC, warto poznać potencjalne zalety i wady tego rozwiązania.
W środowisku, w którym nie stosuje się takich technologii, jak IPsec czy HTTPS, protokół DNS jest narażony na ataki. Nie ma bowiem wbudowanych mechanizmów uwierzytelniania. Ponadto zagrożona jest integralność danych przesyłanych między serwerami DNS lub do klientów DNS. Protokół DNS został pierwotnie zaprojektowany tak, że nie oferuje żadnych zabezpieczeń. Jest podatny m.in. na spoofing czy ataki man-in-the-middle. Jeśli napastnik włamie się do serwera DNS, może uzyskać dostęp do całej komunikacji, która przechodzi przez zaatakowane urządzenie.

Podmiana nazw DNS

Ponieważ serwery DNS są podatne na ataki, opracowano protokół DNSSEC, który uzupełnia braki w zabezpieczeniach. DNSSEC wprowadza zmiany zarówno po stronie serwera DNS, jak i komponentów klienta. Umożliwiają one szyfrowane podpisywanie danych DNS oraz stosowanie reguł do weryfikacji nazw w celu ochrony komunikacji DNS. Dzięki DNSSEC serwer DNS może weryfikować poprawność odpowiedzi. W efekcie obie strony komunikacji są zabezpieczone przed największym zagrożeniem dla komunikacji DNS – spoofingiem.

DNS spoofing jest to atak polegający na podmianie nazwy DNS jakiegoś systemu poprzez uszkodzenie pamięci cache usługi DNS lub poprzez włamanie się do serwera DNS. Kiedy klient DNS wysyła żądanie dotyczące tłumaczenia nazwy, oznacza je 16-bitowym identyfikatorem transakcji (XID) zapisanym w nagłówku pakietu DNS i oczekuje, że zdalny serwer DNS odeśle odpowiedź na tym samym porcie i zawierającą ten sam identyfikator. Żądanie jest z reguły wysyłane z użyciem protokołu UDP, który jest bardziej podatny na ataki niż TCP. Nie korzysta on bowiem z trzyetapowego procesu ustanowienia połączenia. TCP jest używany przez DNS dopiero po otrzymaniu odpowiedzi.

Kiedy tzw. DNS Resolver otrzyma odpowiedź na wysłane żądanie, może tylko powierzchownie sprawdzić autentyczność pakietów, porównując wartości następujących parametrów:
• Adres zdalnego serwera DNS – sprawdzanie tego adresu często jest domyślnie wyłączone, ponieważ poprawne odpowiedzi mogą przychodzić z innych adresów niż ten, na który zostało wysłane żądanie (ten fakt dodatkowo ułatwia przeprowadzanie spoofingu DNS).
• Numer portu, na którym pakiet został odebrany – DNS Resolver z reguły wysyła żądanie używając tymczasowego portu na port o numerze 53, a serwer DNS odpowiada, używając portu 53 niezależnie od tego, jaki był źródłowy adres żądania.
• Wartość identyfikatora XID pakietu – wartość XID jest ustawiana w żądaniu przez DNS Resolver i musi zgadzać się z wartością, która przyjdzie w odpowiedzi. XID powinien przyjmować losowe wartości (jest to rekomendowane), ale ma tylko 16 bitów długości. Ten identyfikator jest zapisywany w niezaszyfrowanej postaci w nagłówku pakietu DNS.

Wysyłanie sfabrykowanych pakietów z odpowiedziami

Jeśli atakujący ma dostęp do ruchu w sieci, z której korzysta serwer lub klient DNS, może próbować wysyłać sfabrykowane pakiety z odpowiedziami, próbując zastąpić nimi autentyczne odpowiedzi. Atakujący (np. botnet znajdujący się pod jego kontrolą) może atakować klientów i serwery DNS, wysyłać zdalne żądania. Atakujący kontroluje wartość parametru TTL (Time-To-Live) w wysyłanych przez siebie pakietach. Jeśli więc atak zakończy się sukcesem, może trwać nawet tygodniami.

Dzięki DNSSEC klient DNS może ignorować odpowiedzi, które nie przeszły walidacji w rekurencyjnym serwerze DNS. Ten serwer nie zweryfikuje jako poprawnych również nieautentycznych odpowiedzi DNS sprawdzając ich cyfrową sygnaturę. W ten sposób DNSSEC skutecznie zapobiega atakom wykorzysującym spoofing. Natomiast DNSSEC, jak każdy protokół kryptograficzny, może być celem ataku siłowego (brute force). Zaleca się więc regularne zmienianie haseł. Bezpieczeństwo zwiększa stosowanie dłuższych kluczy szyfrujących, ale trzeba pamiętać, że ma to negatywny wpływ na wydajność, trzeba więc znaleźć odpowiedni balans.

DNSSEC a publiczne strefy DNS

Publiczne strefy DNS, które są podłączone do Internetu i muszą być dostępne, np. dla klientów, są szczególnie podatne na ataki. W przypadku takich stref korzyści z wdrożenia DNSSEC są największe. Wewnętrzne strefy są mniej podatne na ataki, ponieważ nie są podłączone bezpośrednio do Internetu. Ponadto mogą być chronione innymi protokołami bezpieczeństwa. W ich przypadku korzyści z DNSSEC będą mniejsze, a jednocześnie wdrożenie tego protokołu przyniesie dodatkowe zadania administracyjne. W takim przypadku wiele komputerów klienckich będzie wymagało dostępu do takich usług domenowych, jak LDAP, Net Logon, Kerberos i innych. Jednakże w przypadku niektórych domen wymagane jest stosowanie DNSSEC, np. w agencjach rządowych. Ponieważ wewnętrzne domeny często oferują też dodatkowe usługi, których nie wdraża się w publicznych strefach DNS, tym bardziej trzeba bardzo uważnie zarządzać DNSSEC w domenach wewnętrznych.

Podziel się na:
  • Facebook
  • Google Bookmarks
  • LinkedIn