anonimowy blog

Ostatnio robiłem przegląd serwrów w pracy, analizujac które z publicznie dostępnych można “podkręcić” bądź dodać kolejny murek firewalla

Wybór padł na starego, dobrego BINDa w wersji 9. Poczytałem w internecie na grupach dyskusyjnych oraz stronie domowej projektu jakie to wady i dziury ten named posiada i zabrałem się do “shellowania” nad named.conf

Poświęciłem tematowi trochę czasu i dlatego postanowiłem, że popełnię ten oto wpis aby inne zinteresowane osoby miały punkt wyjścia

Na wstepie aby uniknąć nieporozumień i niedomówień przedstawię co rozumiem jako serwer DNS. Name server to proces daemona odwzorowania nazw domenowych na adres IP (i odwrotnie), zlokalizowany w DMZ, odcięty zarówno od Internetu jak i sieci wewnetrznej firewallami. Przez sieć wewnetrzną rozumiem zarówno inne serwery DMZ jaki i komputery sieci LAN oraz VPN. Natomiast sieć zewnętrzna to cały wielki, zły internet. Priorytetem dla mnie jest bezpieczeństwo, więc niektórym czytelnikom pewne opcje mogą wydawać się … kontrowersyjne.

1. Wersja BIND
   Im nowsza tym lepsza, ale oczywiscie nie sugeruje, a nawet nie zalecam “na produkcję” wersji z cvs z branchem devel Generalnie od 9.1 uznaje się (opinie z forum), że daemon jest “ustabilizowany” i bezpieczny.
2. Chroot
   Bind bardzo latwo i chętnie daje sie “chrootować”, co więcej we wielu dystybucjach,. min. PLD, instalacja w chroot jest domyślna.
   Jak wspomiałem wyżej bezpieczeństwo jest dla mnie priorytetem, dlatego dla serwera nazw oddelegowałem indywidualny adres IP i maszynę, nic innego tam nie działa tylko PLD z libSELinux oraz firewallem. Nie znalazło się miejsce na SSH, dostęp administracyjny tylko poprzez konsolę.
3. Kopie zapasowe
   Aby ułatwić sobie pracę posiadając wiele serwerów sugeruję użycie rsync lub innego systemu backupów celem archiwizowania nie tyle logów co plików stref.
4. Widoki
   Oczywistym jest, że każdy komputer łaczący się z internetu nie powinien i nie może znać adresów czy też IP niezbędnych do komunikacji w sieci LAN. Co więcej żaden komputer z intenetu nie ma prawa uzyskać odpowiedzi na zapytanie host www.onet.pl natomiast sieć lokalna musi posiadać takie uprawnienia.
5. Firewall
   Jedyny ruch przychodzący do oraz wychodzący z adresu IP do internetu to zapytania DNS na porcie 53 (polityka firewalla).
   Wszystkie aktualizacje czy też synchronizacje muszą odbywać się poprzez bramy aplikacyjne lub firmowe serwery (firmowe tzn takie którym ufam <także na etapie połączenia> lub nad którymi mam kontrolę)

Mająć jasno wyznaczoną liste celów do osiągnięcia można spokojnie i skutecznie przygotować serwer dns.

Oczywiście jeśli chodzi o dystybucję wybór padł na PLD. Instalując boćka zystałem na wstępie całkiem aktualną wersję bind od razu w chroot. Lokalizacją bind będzie /var/lib/named Przygotowanie plików stref oraz wpisy w bazie sprzedawcy domen pomijam.

Kwestią pierwszą są widoki i ich przygotowanie. Stworzyłem katalog include a w nim wszelkie niezbędne dodatki. Pierwsza linijka w named.conf

include "include/acls";

Plik acls powinien zawierać informację o adresach IP (bądź klasach) sieci wewnętrznej, serwerach uprawnionych do transferowania domen (zazwyczaj serwery określane mianem secondary bądź slave) U mnie wyglada to mniej, więcej tak:

// my LAN networks
acl lan {
127.0.0.0/8;
192.168.0.0/16;
10.0.0.0/8;
172.16.22.0/24;
194.204.159.1/32;
};

// whole NET
acl everyone {
0.0.0.0/0;
};

// who can transfer domains
acl transfer-ns {
194.145.96.21/32;
193.111.27.194/32;
127.0.0.0/8;
};

Oczwiście to tylko część pliku oraz fikcyjny “publiczny” adres IP, na którym nasłuchuje serwer. Teraz większość czasu należy poświęcić na dokończenie edycji named.conf

options {
//bind pracuje w chroot
directory "/";
pid-file "named.pid";
dump-file "named.db";
statistics-file "bind.stats";
//aby ukryć prawdziwą wersję daemona
version "4.92 alpha 2";
auth-nxdomain yes;
datasize default;
//daemon ma nasłuchiwać na wszystkich interfejsach
listen-on { any; };
interface-interval 0;
//zapytania binda "wychodzą" z portu 53 (łatwiejsza kontrola na firewallu)
query-source address * port 53;
// maksymalna liczba klientów
tcp-clients 300;
trasfers-out 20;
max-transfer-time-in 30;
max-transfer-time-out 60;
max-refresh-time 86400;
min-refresh-time 3600;
// zapytania rekurencyjne (o każda domene) dozwolone tylko z sieci określonej w acls jako lan
allow-recursion { lan; };
recursive-clients 1023;
};

Teraz należy dodać obsłużyć widoki i przygotować odpowiednie strefy

view "lan_networks" {
match-clients { lan; };
//
zone "localhost" IN {
type master;
file "Master/localhost.zone";
allow-update { none; };
allow-transfer { any; };
(̷
//
zone "eqax.pl" IN {
type master;
file "Master/db.eqax.pl.lan";
allow-query { lan; };
allow-update { none; };
allow-transfer { none; };
};
//
include "include/public-zones";
};

Tutaj słowo komentarza. Otóż domena eqax.pl jest także wykorzytywana do “nazywania” części hostów w LAN (także poprzez domenę Windows), i odpowiedź uzależniamy od adresu IP pytającego. Natomiast plik public-zones zawiera definicje stref, które serwowane są wszystkim niezależnie od adresu IP (domyślnie są to domeny “widoczne” w internecie czyli Top Level Domains).
Wiemy już co zostanie “zaserwowane” adresom z acl lan. Teraz pora cały internet.

view "whole_world" {
match-clients { everyone; };
//
zone "eqax.pl" IN {
type master;
file "Master/db.eqax.pl";
notify yes;
allow-query { any; };
allow-update { none; };
allow-transfer { transfer-ns; };
zone-statistics yes;
};
//
include "include/public-zones";
};


Pozostała jeszcze kwestia logowania

logging {
channel xfer-log {
file "named.log";
print-category yes;
print-severity yes;
print-time yes;
severity warning;
};
category statistics { xfer-log; };
category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; };
};


Mając tak skonfigurowany serwer Bind udostępniłem ruch do/z tylko na porcie 53 i już miałem publicznie dostępny serwer DNS, który także jest serwerem pośredniczącym dla całej mojej sieci.
Aktualnie serwuje okolo 50 Top Level Domains, oraz 30 lokalnych i przy dość dużym ruchu sprawuje się bez zarzutu.

Końcowe uwagi:

1. Logrotate
   Należy mieć na uwadze, że plik logowania (podobnie plik statystyk) może bardzo szybko rozrosnąć się i należy przeciwdziałać temu.
2. Root Servers
   Co jakiś czas (rozsądnie raz na tydzień) powinno się uaktualniać baze o serwerach nadrzędnych
   dig @a.root-servers.net . ns > root.hint

ZOLTAN