B

IND jest serwerem DNS tworzonym przez ISC (ang. Internet Systems Consortium) powszechnie używanym do rozwiązywania nazw hostów na adresy IP i odwrotnie. Jako kluczowy element infrastruktury serwery DNS często stają się celem ataków. Podejmując jednak kilka prostych kroków można pomóc w ochronie swojej sieci oraz całego Internetu. Niniejszy artykuł zawiera minimum informacji potrzebnych do poprawny bezpieczeństwa BIND9 pozwalając administratorom systemów zminimalizować zagrożenie. Zdecydowanie najważniejszą rzeczą jest, aby odseparować działanie serwera DNS od innych usług typu serwery WWW, poczty, czy ftp, które są równie często atakowanymi usługami.

Ataki na serwery DNS można przypisać do kilku kategorii:

• Błędy programistyczne w samym oprogramowaniu, które są odkrywane i naprawiane na przestrzeni lat istnienia pakietu (żadne oprogramowanie nie jest idealne),
• Błędy systemowe – każde oprogramowanie jest na tyle bezpieczne na ile jest bezpieczny system operacyjny, na którym działa. Włączone jest w to ryzyko ataku na inne usługi, które są uruchomione na tej samej maszynie. Wraz z naruszeniem podstawowej ochrony hosta, serwer DNS może zostać wykorzystany do szkodliwych celów,
• Ataki Denial of Service – bardzo wiele usług zależy od poprawnego działania zapytań DNS. Wraz z sparaliżowaniem obsługi DNS sytuacja ta będzie miała istotny wpływ na działanie reszty usług. Jeśli zostanie zablokowana nasza domena przestaniemy świadczyć również usługi dla klientów.
• Ataki sieciowe – te opierają się na samej implementacji protokołu DNS. Przykładem są ataki typu cache poisoning (gdzie serwer jest przekonany do zapamiętania innego adresu IP i przekierowaniu użytkowników pod złowrogi adres), dostęp do wrażliwych informacji, które służą w ułatwianiu innych ataków, ataki na transfery stref DNS, dynamiczne aktualizacje, powiadomienia o zmianach w strefach itd.

1. Wsparcie firewall:

Zapora ogniowa powinna być pierwszym stykiem z Internetem serwera DNS. Poniższe reguły odnoszą się do ochrony dedykowanego serwera DNS. Zmienna $IPL odnośni się do zewnętrznego adresu IP, na którym serwer DNS nasłuchuje zapytań:

$IPT="iptables"
$IPL="192.168.1.1"

$IPT -A INPUT -i eth0 -p udp -d $IPL --dport 53 --sport 1024:65535 \
-m state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o eth0 -p udp -s $IPL --sport 53 -d 0/0 --dport 1024:65535 \
-m state ESTABLISHED -j ACCEPT

Jeśli posiadamy drugi lub więcej zapasowych serwerów DNS musimy umożliwić mu transfer stref, którymi zarządzamy:

$IPT="iptables"
$IPL="192.168.1.1"
$NS2="192.168.1.2"

$IPT -A INPUT -i eth0 -p tcp -d $IPL --dport 53 -s $NS2 --sport 1024:65535 \
-m state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o eth0 -p tcp -s $IPL --sport 53 -d $NS2 --dport 1024:65535 \
-m state ESTABLISHED -j ACCEPT

Większość osób ukrywających serwery DNS za zaporami uważa, że jedynym protokołem jaki jest wykorzystywany do komunikacji to UDP. Po części jest to prawda. Większość zapytań będzie wysyłanych za pomocą UDP jednak w przypadku wystąpienia błędu lub przekroczeniu rozmiaru pakietu UDP (w przypadku używania DNSSEC lub zapytań po IPv6) serwer BIND spróbuje wykorzystać mechanizm rozszerzeń DNS (EDNS0) lub przejdzie na komunikację TCP. Dlatego w przypadku pojawiających się trudnych do zdiagnozowania problemów do poprawnej analizy będzie wymagane udostępnienie komunikacji po TCP – przynajmniej dla hostów, które doświadczają trudności w komunikacji z naszym serwerem DNS.

2. Losowy port dla zapytań:

Jest jednym z mechanizmów hartowania serwera DNS przed atakiem podszywania oraz zatruwania pamięci cache. Kiedyś BIND oraz inne implementacje serwerów DNS używały portu 53 do zapytań, a odpowiedzi były zawsze zwracane na tym samym porcie. Aktualnie BIND powinien za każdym razem zwracać losowy port dla tego typu operacji:

query-source address * port *;

Jeśli zdecydujemy się ustawić na sztywno port (np. port 53) bardzo szybko możemy zostać ofiarą ataku zatruwania pamięci cache. W w/w ustawieniu atakujący musi odgadnąć id transakcji oraz numer portu (16 bitowe wartości). Jeśli port będzie statyczny do odgadnięcia pozostaje tylko identyfikator transakcji, czyli ułatwiamy pracę agresorowi. Jeśli chcemy przetestować nasz serwer na tego typu podatność możemy wykorzystać do tego celu Domain Name System Operations Analysis and Research Center. Przykład zapytania:

root@darkstar:~# dig +short @localhost porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"192.168.1.1 is GREAT: 26 queries in 3.7 seconds from 26 ports with std dev 19485"

W przypadku braku losowości portów wynik zostanie przedstawiony jako POOR:

root@darkstar:~# dig +short @localhost porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"192.168.1.1 is **POOR**: 26 queries in 2.0 seconds from 1 ports with std dev 19485"

3. Ograniczenie zapytań:

Serwer pozwalający każdemu na wykonywanie zapytań DNS oprócz własnych problemów z wydajnością oraz bycia łatwym celem dla ataku DoS – umożliwia przeprowadzanie za swoim pośrednictwem ataków typu DNS Amplification. Tego typu serwery DNS nazywane są Open Resolver. Należy unikać tego typu sytuacji i ograniczyć możliwość wykonywania nierekursywnych i rekursywnych zapytań tylko do zaufanych źródeł:

allow-query { localnets; };
allow-query-cache { localnets; };
allow-recursion { localnets; };

gdzie localnets odnosi się do sieci interfejsów, na których nasłuchuje serwer BIND. Dla serwerów wieloadresowych (ang. multi-homed) zostały również udostępnione opcje: allow-query-on, allow-query-cache-on oraz allow-recursion-on, które pozwalają dodatkowo zdefiniować, z których interfejsów będą akceptowane zapytania. Oprócz tych mechanizmów możemy również wykorzystać ograniczenia acl do określenia adresów lokalnych sieci, które będą mogły wykonywać odpowiednie rodzaje zapytań np.:

acl "dmz" { 192.168.1.0/24; };
allow-recursion { dmz; };

Jeśli posiadamy tylko autorytatywny serwer możemy całkowicie zrezygnować z możliwości wykonywania rekursywnych zapytań:

recursion no;

Warto wspomnieć, że w BIND od wersji 9.4 jeśli ustawimy tylko jedną opcję allow-* z trzech powyższych pozostałe dwie przyjmą te same wartości.

4. Ograniczenie transferu stref:

Serwery pozwalające na pobranie całego pliku strefy (AXFR) mogą ujawniać wrażliwe dane, jeśli chodzi o wewnętrzną adresację lub rozmieszczenie innych usług w naszej infrastrukturze. Jeśli nie przeraża nas publiczność strefy – to wyobraźmy sobie możliwość zmuszenia setek serwerów do jednoczesnego pobrania pliku z naszego serwera powodując atak DoS. Transfery stref powinny zostać ograniczone tylko do serwerów, które pełnią rolę zapasowych serwerów DNS lub zajmują się utrzymaniem strefy (zarządzanie, testy funkcjonalne itp.). W poniższym przykładzie globalnie blokujemy transfery stref, a zezwalamy tylko na transfer domeny “nfsec.pl” do serwera o adresie 192.168.1.2:

options {
   allow-transfer { none; };
}
zone "nfsec.pl" { 
   type master;
   file "/etc/bind/zones/nfsec.pl";
   allow-transfer { 192.168.1.2; };
   allow-query { any; };
}

który jest drugim serwerem DNS (slave) dla strefy nfsec.pl.

Więcej informacji: DNS for Rocket Scientists, Basic security options