BIND (Berkeley Internet Name Domain) to najpopularniejszy serwer DNS używany do tłumaczenia nazw domen na adresy IP. Jako krytyczny element infrastruktury internetowej, serwer BIND jest częstym celem ataków, jeśli nie jedną z najczęściej atakowanych usług. Dlatego ważne jest, aby zabezpieczyć go przed różnorodnymi zagrożeniami, szczególnie gdy jest publicznie dostępny. W tym artykule skupimy się na kompleksowym podejściu do hardeningu serwera BIND na systemie Debian 12, obejmującym najlepsze znane mi praktyki konfiguracyjne, zabezpieczenia sieciowe oraz monitorowanie i audyt. 

Firewall 

Nie będzie chyba zaskoczeniem, jak ważna jest odpowiednia konfiguracja firewalla. W tym przypadku pokuszę się o małe uproszczenie i skorzystam z już opisywanego firewalla ufw. Można oczywiście wykorzystać gołe iptables, ale co do zasady idea jest podobna. Wiemy już z moich poprzednich artykułów, jak skonfigurować poprawnie firewall na bazie ufw czy iptables. Zakładam, że macie włączone odpowiednie reguły i logowanie. Zajmijmy się więc odblokowaniem ruchu do binda. 

ufw allow 53/tcp 
ufw allow 53/udp 
ufw enable 

Ograniczenie dostępu do konfiguracji BIND

Od strony systemu operacyjnego upewnij się, że pliki konfiguracyjne BIND są dostępne tylko dla użytkownika `bind` i administratora: 

chown -R bind:bind /etc/bind 
chmod -R 750 /etc/bind

 Zabezpieczenie komunikacji DNS

Jednym z najważniejszych pojęć jest zabezpieczenie komunikacji. Można to zrobić poprzez włączenie mechanizmu DNSSEC, o czym nie wolno zapomnieć. Mechanizm DNSSEC (DNS Security Extensions) zapewnia integralność i autentyczność odpowiedzi DNS. Aby włączyć DNSSEC, dodaj do pliku `named.conf.options`: 

options { 
dnssec-enable yes; 
    dnssec-validation auto; 
dnssec-lookaside auto; 
}; 

Kontrola transferów stref 

Ogranicz transfery stref do zaufanych serwerów DNS w `named.conf.local. To kluczowe, aby nie można było czytać całej konfiguracji stref z Waszego DNSa. 

zone „strona.pl” {
type master; 
file „/etc/bind/zones/db.strona.pl”;
  allow-transfer { 192.168.0.1; };
}; 

Kontrola transferów stref 

Ogranicz transfery stref do zaufanych serwerów DNS w `named.conf.local. To kluczowe, aby nie można było czytać całej konfiguracji stref z Waszego DNSa. 

zone „strona.pl” { 
type master
file „/etc/bind/zones/db.strona.pl”;
allow-transfer { 192.168.0.1; };
}; 

Ochrona przed atakami DDoS

Wspomniałem już wyżej, że serwer DNS jest jednym z najchętniej atakowanych, a jednocześnie jedną z najbardziej chodliwych dla oszustów usług do testowania. Nie powinno to dziwić – łatwo przy jej pomocy stworzyć potężny atak DDOS na inne serwery. 

Zainstalujcie i skonfigurujcie fail2ban, aby chronić się przed atakami brute-force: 

apt-get install fail2ban 

Oraz dodajcie regułki dla serwera BIND: 

vi /etc/fail2ban/jail.local 

[bind] 
enabled = true 
port = domain,953
filter = bind 
logpath = /var/log/named/security.log 
maxretry = 5 

vi /etc/fail2ban/filter.d/bind.conf 

[Definition] 
failregex = security: .*: client <HOST>#\d+: query \(cache\) denied 
ignoreregex = 

Monitorowanie i logowanie 

Konfiguracja logowania: 
Równie ważnym jak odpieranie ataków jest ich przewidywanie i monitorowanie potencjalnie niepożądanych aktywności. Innymi słowy: aktywacja i monitorowanie logów. Skonfigurujmy więc BIND do logowania ważnych zdarzeń, takich jak błędy i próby naruszeń bezpieczeństwa.  

vi named.conf 

logging { 
    channel default_log { 
        file „/var/log/named/default.log” versions 3 size 5m;
        severity info; 
        print-time yes;
    }; 

    channel security_log { 
        file „/var/log/named/security.log” versions 3 size 5m; 
        severity dynamic; 
        print-time yes; 
    }; 

    category default { default_log; }; 
    category security { security_log; }; 
}; 

Analiza logów: 
Przeglądanie logów jest nudne, monotonne i niezwykle czasochłonne, ale istnieją sposoby na pewną automatyzację tego procesu. Jednym z nich jest logwatch, który na podstawie regexów może wyłapywać niepożądane akcje i odpowiednio nas alarmować. 

apt-get install logwatch 

Konfiguracja Logwatch’a do monitorowania logów z BIND’a: 

vi /usr/share/logwatch/default.conf/logfiles/named.conf 

LogFile = /var/log/named/security.log 
LogFile = /var/log/named/default.log 

Po więcej informacji o tym jak działa LogWatch, zapraszam do moich innych artykułów na stronie. Znajdziecie tam naprawdę sporą dawkę informacji o tym, jak działają tego typu narzędzia oraz przykłady konfiguracyjne. 

Chroot Jail

Uruchomienie BIND w środowisku chroot jail ogranicza skutki ewentualnego przełamania zabezpieczeń, izolując proces serwera od reszty systemu. Jest to nieco zapomniana już technika – rzadko kiedy spotykam ją u klientów, chyba że pracują tam jeszcze administratorzy pamiętający czasy transformacji cyfrowej. Mimo wszystko jest to wciąż jedna z najlepszych technik ochrony całego systemu. Chrootowanie aplikacji jest naprawdę pomocne i uratowało niejeden system. 

Szybka konfiguracja chroota dla BIND’a 

mkdir -p /var/named/chroot 

Skopiujcie pliki konfiguracyjne BIND do katalogu chroot: 

   sudo cp -r /etc/bind /var/named/chroot/etc 
   sudo cp -r /var/cache/bind /var/named/chroot/var/cache
   sudo cp -r /var/run/named /var/named/chroot/var/run 

Zmieńmy konfigurację BIND, aby używała katalogu chroot: 

vi/etc/default/bind9 

   OPTIONS=”-u bind -t /var/named/chroot” 

Restart aplikacji: 

 systemctl restart bind9 

Po więcej informacji o tym, jak chrootować i co to właściwie daje, zapraszam do moich poprzednich artykułów na Władcach Sieci. 

Ograniczenie uprawnień 

Zawsze upewnijmy się, że serwer BIND działa z minimalnymi uprawnieniami. 

vi etc/default/bind9 

OPTIONS=”-u bind” 

Audyt i przegląd bezpieczeństwa 

Podobnie jak w przypadku monitorowania logów, ciągłe siedzenie nad audytami czy przeglądem bezpieczeństwa może być na tyle żmudne i powtarzalne, że w końcu przestaniemy to robić. Warto więc wspomóc się różnymi aplikacjami. Możemy skorzystać z narzędzi takich jak Lynis (o którym już pisałem na Władcach sieci), służących do przeprowadzania audytów bezpieczeństwa na serwerze. 

apt-get install lynis 

lynis audit system 

Podsumowanie 

Hardening serwera nazw BIND na systemie Debian wymaga zastosowania wielu warstw zabezpieczeń, od odpowiedniej konfiguracji i monitorowania, przez kontrolę dostępu i regularne aktualizacje, po dodatkowe techniki zabezpieczające, takie jak chroot jail i ograniczenie uprawnień. Prawidłowe zabezpieczenie serwera DNS jest kluczowe dla zapewnienia integralności, dostępności i poufności danych. Implementacja opisanych przeze mnie praktyk pozwala na minimalizację ryzyka i zwiększenie odporności na ataki, co jest niezbędne w dzisiejszym skomplikowanym środowisku cyberbezpieczeństwa. Regularne przeglądy i audyty bezpieczeństwa, zarówno wewnętrzne, jak i zewnętrzne, pomagają w utrzymaniu wysokiego poziomu zabezpieczeń i adaptacji do nowych zagrożeń. Ostatecznie, świadome podejście do zabezpieczenia serwera DNS BIND jest kluczowe dla ochrony infrastruktury IT i danych organizacji. Zgodzimy się wszyscy, że temat nie jest całkowicie i do końca wyczerpany – przegląd, audyty, bezpieczeństwo jest dzisiaj tak szerokim tematem, że nie sposób wymienić wszystkich aspektów w jednym artykule. Wierzę jednak, że zawarte tu wskazówki pomogą w zachowaniu większego bezpieczeństwa. W kontekście aplikacji serwera DNS bind, który jest jednym z najchętniej atakowanych w sieci, szczególnie warto skorzystać ze wszystkich porad i sięgnąć do artykułów na Władcach sieci, aby jeszcze lepiej rozumieć sposoby na utrzymanie bezpieczeństwa.