suns
system network data news bugtraq
sexy unix security project
network > DNS droshinaashana (4) 23.11.2005 16:00

Shajaa rakstaa koncentreejos uz deviito Bind versiju, bet praktiski visu, kas te rakstiits var attiecinaat arii uz astoto, ceturto vairs lieto tikai degjeneraati. Deviitais Bind ir pilniibaa paarrakstiits kopsh astotas versijas, skaitaas droshaaks, turklaat tajaa ir arii daudz noderiigu fiichu, kuras tu, mans daargais lasiitaaj, visticamaak nekad neizmantosi :)


Chroot.

Uz OpenBSD un FreeBSD 6.x Bind naak jau gatavs chrootoshnai, gan uz OpenBSD, gan FreeBSD chroot direktorija ir /var/named. Lai palaistu chroototu Bindu zem OpenBSD, ir nepiecieshama shaada rinda ieksh /etc/rc.conf.local:

named_flags="-t /var/named -u named"

Bet uz FreeBSD 6.x ieksh /etc/rc.conf:

named_enable="YES"
named_flags="-u bind"
named_pidfile="/var/run/named/pid"
named_chrootdir="/var/named"
named_chroot_autoupdate="YES"
named_symlink_enable="YES"

Skaidrot, ko katra rinda noziimee man nav ne mazaakaas veeleeshanaas, tas viss shkjiet pavisam pashsaprotami, bet ja tev kautkas liekaas neskaidrs, tad atbildi meklee manuaaljos. Manuaali palaist Bindu var ar komandu (bind lietotaajs uz FreeBSD):

# named -t /var/named -u named

named servera konfiguraacija.

Konfiguraacija atrodaas ieksh named.conf. Tagad mees Bindam noraadiisim defaultos uzstaadiijumus:

options {
    version "KKND";
    listen-on { any; };
    listen-on-v6 { none; };
    allow-transfer { none; };
    allow-recursion { none; };
    allow-query { any; };
};

Ar version "KKND" mees nomainam DNS servera versijas banneri, jo defaultajaa tam patiik raadiit paaraak daudz liekas informaacijas. No komandrindas DNS servera versiju var nochekot ar dig version.bind chaos txt +short @ns.domain.lv, kur ns.domain.lv ir DNS serveris, kura versiju veelies uzzinaat (to var dariit arii IP adresei). Ar listen-on noraadam, kuras adreses lokaali DNS serverim ir jaaklausaas. allow-transfer noraada, ka defaultajaa neviens nedriikst veikt zonas transferu (pameegjini dig axfr gov.lv +nostats +nocmd @sunic.sunet.se un iespeejams, ka sapratiisi, kaapeec). Ar 'allow-recursion' opciju, savukaart, mees noraadam, ka neviens nedriikst veikt rekursiivos pieprasiijumus. Tas paliidzees izsargaaties no cache-poisoning uzbrukumiem. Rekursiivos pieprasiijumus ir jaaljauj tikai saviem klientiem (un arii tikai gadiijumaa, ja tas ir forwarding dns serveris, t.i. atbild uz pieprasiijumiem, kas attiecas uz visaam zonaam, ne tikai taam, kas ir ierakstiitas shajaa DNS serverii).


rndc.

rndc aivieto to, kas ieksh astotaas bind versijas saucaas ndc. Ja nemaldos, tad paplashinaas tas kaa 'Remote NameD Control', pienjemu, ka nosaukums izsaka visu. Nekas daudz nebuus nepiecieshams, pietiek vieniigi palaist shaadu komandu (uz FreeBSD direktorija ir /etc/named):

# rndc-confgen > /etc/rndc.conf

Tagad atver izveidoto failu un to, kas tur ir aizkomenteets iekopee ieksh named.conf. Ieteicams arii palabot rndc.conf faila permissijas, jo, jebkursh, kuram buus piekljuve shim failam, varees kontroleet named servisu, tas attiecaas arii uz named.conf. Tagad jau varees visaadi izvirst, piemeeram, paarlaadeet named ar shaadu komandu:

$ rndc reload

Uz ko ir speejiigs rndc vari apskatiities vienkaarshi to palaizhot bez jebkaadaam opcijaam.


Zonas.

Tagad ir pienaacis laiks uztaisiit kaadu zonu. Principaa, ar to, kaadaam zonaam ir jaabuut, tu noteikti iepazinies sava distributiiva (lol) dokumentaacijaa, es veelos pieveersties tieshi tam, kaa taas labaak nokonfigureet. Saaksim ar piemeeriem (turpmaak rakstaa primaaraa DNS servera IP ir 192.168.1.10, bet sekondaaraa - 10.0.15.96):

zone "example.lv" {
    type master;
    file "master/example.lv";
    allow-transfer { 10.0.15.96; };
};

zone "example.lv" {
    type slave;
    file "slave/example.lv";
    masters { 192.168.1.10; };
};

Nekas iipashs jau te nav, vieniigais, kam svariigi pieveerst uzmaniibu, ir allow-transfer, kas noraada to, no kaadas IP adreses driikst transfereet zonu. Te ir jaanoraada tikai sekondaaro serveru IP adreses. No Latvijaa regjistreetajiem domeiniem aptuveni 50% no tiem ir iespeejams veikt zone tranferu. Pat LatNets reiz bija liiki nokonfigureejis savu DNS serveri, un no taa bija iespeejams novilkt visu .lv zonu.


TSIG (Transaction SIGnatures).

Limiteet DNS zonu transferus peec IP adreseem arii nav diez ko laba ideja, labaak ir izmantot atsleegas (liidziigi parolei). Taatad laizham shaadu komandu:

$ dnssec-keygen -a hmac-md5 -b 128 -n HOST ns-ns2.example.lv

Tiks izveidoti divi faili: Kns-ns2.example.lv.+157+30236.key un Kns-ns2.example.lv.+157+30236.private. Tagad veram valjaa named.conf un uz primaaraa servera liekam konfiguraacijas failaa shaadas rindas:

server 10.0.15.96 {
    keys { ns-ns2.example.lv; };
};

key "ns-ns2.example.lv" {
    algorithm hmac-md5;
    secret "Cxdk3sER56dUHidGezVhNg==";
};

Bet uz sekondaaraa servera shaadas:

server 192.168.1.10 {
    keys { ns-ns2.example.lv; };
};

key ns-ns2.example.lv {
    algorithm hmac-md5;
    secret "Cxdk3sER56dUHidGezVhNg==";
};

Jaapiebilst, ka ieksh secret sadaljas ir jaaliek taa atsleega, kura paraadiijaas ieksh pirmiit uzgjenereetaa faila, kursh beidzaas ar .private. Mees tikko noraadiijaam, ka serveriem komuniceejot savaa starpaa, ir jaaizmanto uzgjenereetaa atsleega, vieniigais, kas veel ir atlicis, ir noraadiit zonu failos, lai autentifikaacijai taas lieto nevis IP adresi, bet sho atsleegu. Diemzheel abus reizee lietot neizdosies, jo Bind izstraadaataajiem tas shkjiet lieki. Uz primaaraa servera tas izskatiisies shaadi:

zone "example.lv" {
    type master;
    file "master/example.lv";
    allow-transfer { key ns-ns2.example.lv.; };
};

Bet uz sekondaaraa shaadi (iisteniibaa te nekaadu izmainju nav):

zone "example.lv" {
    type slave;
    masters { 192.168.1.10; };
    file "slave/example.lv";
};

DNSSEC.

Labpraat uzrakstiitu arii par DNSSEC, bet kameer pie stuures ir LatNets, Latvijaa mums taada ekstra noteikti 'nedraud' :)

/ petruha - http://petruha.bsd.lv/ /
comments
valdiic:
Njaa... TSIG + IP adreses norādīšana sleiviem gan noderētu. :/
n3on <dev.random(at)gmail.com>:
un vispaar, ja nav slinkums uzliekam DJBDNSu, Bernsteins tomeer zin ko dara ;)
maita:
n3on, jā. sūds par hier(7), bet viņam riebjas dnssec. djbdns nekad nebūs dnssec implementācijas.
Edijs:
bet vai maita pats kaa pirmo neietesteeja djbdns? :) kopumaa tak bij varen labs, viegli un aatri apguustams - imho tu ta teici.
add comment*
author:
email:
piecpadsmit:
comment:


* ja iztiksi bez spama, offtopika un muljkjiibaam, iespeejams, ka tavs koments netiks izdzeests.
« back

valid xhtmlvalid css