DNS/Bind9.xx zone update- zna kdo uporabit non-standard port ?

Zdaj se nekaj zaj* z nastavitvami DNS na svojih dveh strežnikih.

Iz varnostne perspektive mi gre na živce to, da gre pri BINDu vse čez port 53- tako pozvsedbe klientov kot pogovor med master in slave DNS strežnikom.

Rad bi interni promet med vozlišči premaknil na nek drug port, ker bi ga tako lahko lepše objel s firewallom, pa mi ne gre.

Po parih dnevih zajebancije sem našel neko stran, kjer tip trdi, da to na Bind9xx ne gre.

Če je to res, so razvijalci prasci, saj so predvideli opcije za izbiro porta,vendar ne vseh potrebnih.

Lahko pri slaveu navedem kdo so mastri in na katerm portu naj jih povpraša, a ni podobne opcije za nastavitve mastrov.

Je pa tudi globalna port opcija, a ta mi ne pomaga, ker zajema vse promet- server pa mora pričakovati stranke na portu 53.

Sem probal nastavit eno instanco binda da služi samo updatanju drugih DNSov in ne sprejema klientov in jo nastavil preko globalne port direktive na port XY. Vse ostale strežnike sem nastavil kot slave strežnike, ki se pustijo obdatat z osnovnega na portu XY. Stvar ne dela, pa ne vem zakaj.

Je kdo že ustvaril kaj podobnega ?

x.sci je 22. apr 2010 ob 11:43 izjavil:

Brane2 je 21. apr 2010 ob 18:44 izjavil:

Lahko pri slaveu navedem kdo so mastri in na katerm portu naj jih povpraša

AFAIK se tega ne da. Ti verjetno nastavljas source port slavea.

Ne. Vsaj mislim da ne. Ti pri definiciji slave zone lahko uporabiš recimo:

masters port 7712 { tralala.com; 89.212.73.15; };

ali pa podaš port in če hočeš še key za vsak master:

masters { tralala.com port 7712 key key1; 89.212.73.15 port 5347 key key2; };

Ni pa videt podobne zadeve za master zono. Je "allow-transfer", ki pa dovoljuje samo noaslove, brez portov.

Tole resi listen-on.

Listen on je ravno tako globalen, le da ti omogoča definicijo porta za vsak interface posebej.

Ne vem, zakaj bi to sploh kdo hotel. Kaj tocno bi ti rad naredil?

Dodatno zavaroval strežnik. Sedaj se promet za zone transfer meša s prometom za client access. Tako ga ne moreš enostavno zagradit s firewallom, sploh pa ne umaknit na kak visok, neočiten, anonimen port.

Server ti dovoljuje nadzor dostopa preko ključa, a tu ni videt, kako lahko preprečiš DDOS napad, ker ti je za preverjanje pristnosti potrebno več CPU ciklov kot za to, da ti pač nekdo pošlje neko sekvenco...

Ja, ti lahko omejiš tudi IP, s/na katerega lahko poteka update, a packet injection je na UDP za napadalca na isti mreži trivialen, na TCP pa tudi dokaj izvedljiv...

x.sci je 22. apr 2010 ob 18:08 izjavil:

Masters list elements can also be names of other masters lists. By default, transfers are made from port 53 on the servers; this can be changed for all servers by specifying a port number before the list of IP addresses, or on a per-server basis after the IP address.

RTFM :) Sicer ti bo pa packet sniffer povedal, kaj je dejansko na stvari.

Pa saj natanko to sem probal. Ne dela. Ne znam pa pognat snifferja na oddaljeni mašini, kjer nimam Xov, da bi mi laufal zaslon na lokalni mašini.

Kar pa se tice ostalih stvari; v security through obscurity se ne bi spuscal. Ne vem, ce se gres kake dinamicne update-e ali kaj podobnega, ampak v vecini primerov gre navaden dns promet cez udp, zone transferi pa cez tcp. Kar pomeni, da je enostavno locit.

Kako je enostavno ločit, če gre za VEČINO primerov ? Kaj naj naredim z razliko ?
kar se "security through obscurity" tiče, dela čisto lepo kot ena od komponent. Je super zadeva kot dodaten haklc, za katerega veš samo ti, čeprav naj bi bila po defaultu tudi brez tega secure.

Se mi zdi, da ce bi tole res bil tak hud problem, bi se to dalo skonfigurirat. Kar pa ti preprecujes, se pa ponavadi dela na drug nacin.

1. Če bi bilo to res, potem ne bi prihajale ven vedno nove verzije z novimi opcijami.
2. Res je, to se dela s key-i, kar tudi uporabljam. Nisem pa komot samo s tem.

Bind ni ravno znan po neprebojnosti in če lahko izbiram, imam raje zraven obstoječe še plast firewall zaščite, čeprav ta sam zase ni secure...

Po domace, s slave-a:xxx -> master:53, ker transfer vedno dela slave. No, vsaj jaz tako razumem. Sicer pa poskusi kak tcpdump, ce imas nek *nix.

Verjetno res, ampak notify dela master, in ta je tudi na :53. In jaz imam "notify yes" opcijo v globalsih.
Kar se tcpdump tiče- ni slaba ideja. Bom probu.

To recimo ni res, ce se gres dnssec ipd. Torej, ce ne ves za kaj rabis tcp 53 port poleg transferjev, potem clienti do tega ne rabijo dostopa. Ne kompliciraj prevec, odpri tcp 53 samo za ipje tvojih slaveov in si resil problem.

Kot sem nekje zasledil, to tudi ni res pri vseh klientih. Pri UDP je bil problem, če gredo vse zahtevane info v en UDP paket in se je dogajalo, da je del informacij odrezan. Zato so baje eni klienti zahtevali raje stvari po TCP. Oziroma vsaj tako sem stvari razumel jaz.

Sedaj pa novi BINDi baje znajo uporabit IP fragmetnacijo tudi na UDP in tako to mejo lahko pomaknejo bistveno višje kot tistih ~1500 byteov...

Ah... tole je problem. No, da razjasnimo stvari. Ljudje izklaplajo zone xfer, ker je to information leak (imena in kateri hosti). To je cisto ok, samo zavedat se moras, da so informacije v dnsu javne (zato pa so tam) in ce se nekdo odloci, da to hoce, lahko dobi tudi na druge nacine. Koda v bindu za tole je tam noter ze dolgo casa in bi rekel, da je priblizno tako dobra kot ostala. Recimo, veliko bolj pametno je vloziti cas, da stvar tece v chrootu, kot pa da firewallas zone transfer.

Ni tak problem chroot. V gentooju je že praktično vse pripravljeno zanj. Pri zone xfer je problem varnost. So bili opisani napadi, kjer je napadalec preko zone xfer sesul slavea, nato pa z njim updatal master v določenih corner caseih.

Meni je fajn master-slave odnos ker je eden od serverjev pri meni lokalno ( je sicer preko port adress translationa viden tudi zunaj) in če je ta master, potem se vse vnešene spremembe enostavno prenesejo čez xfer zunaj na slave.
Če se mi mudi, lahko s simpl "rndc reload zone_name && rndc notify zone_name" dosežem praktično takojšen update slavea....

Pa kot sem rekel, tudi tole se da, samo ne tako kot ti hoces. Postavis ti. stealth primary na drug ip, do katerega imajo dostop le slave-i, na njih pa izklopis transfer.

Tudi to sem že naredu, pa na gentooju možnost da bi laufal več primerkov binda na isti mašini ( kar bi mi na moji strani pasalo iz drugih vzrokov- en permanenten slave in en začasen master za update ) iz več vzrokov.

Prvič, startup skripte je treba predelat, kar je nekoliko nerodno, ampak to sem opravil.
Drugič je precej bolj problematičen- iz nekega vzroka, če sta si oba binda delila isto mašino, stvar ni špilala: master ni nikoli notifyal lokalnega slavea...

Eden je imel listen na 127.0.0.1, drugi pa na IP eth0.
Ziher sem jaz kaj zašuštral, ampak nisem se pač imel več časa ukvarjat s tem in sem raje prekonfiguriral stvari v simpl lokalni master-oddaljeni slave varianto.

Clever. Nisem še zgruntal, če je v moji konfiguraciji to praktično, a kot ideja za naprej ni slabo.

Ampak zaenkrat bom pustu stvari takole- dokler pač delajo lepo.

Hvala za ideje.

Ubistvu se s tem ne ukvarjam vec toliko, s spfjem pa niti nimam resnih izkusenj. Ce s spfv2 mislis sender-id, vem samo, da je prakticno ista stvar kot spf, samo da so nekaj zakomplicirali s preverjanjem naslova return mailov, tako da mail liste ne delajo vec, zaradi cesar se mi je stvar zdela precej neuporabna. Kolikor vem, se pri nas skoraj ne uporablja, ga pa uporablja google, samo tudi ni problemov, ce ga ti nimas in so ostale stvari postimane, kot je treba.

dnssec je uporaben in slej ko prej bomo verjetno vsi tam. Preizkuseno je pa tudi dovolj, ce si upajo to postavit na root-e :) Itak preverjanje dela resolver in na serverju se ubistvu pozna samo to, da so (nekajkrat) vecji zapisi, ker pride zraven se hash.

2b. Neki je bila opisana problematika updata domene, kateri se zaradi tega spremeni podpis in s tem tudi poddomenam itd.
Se pravi v času tranzicije se lahko zgodi, da klient dobi vsebino domene, ki ne odgovraja podpisu, pridobljenem iz domene nad njo. So te težave rešene ?

Ce misliva isti problem, to ni problem tranzicije. Fora je, da moras biti pri dnssecu zelo pazljiv s kljuci in kako jih objavljas (namrec kljuce je "treba" menjat). Tule se ti lahko zgodi (ce se stvari lotis napacno), da ima client se vedno cachean star kljuc, dobi dns reply z novim hashem in ga zato vrze stran -> dos.

Kar pa se tice dnsseca na splosno; plan je letos julija podpisan root zone, .net konec 2010, .com konec 2011. Torej do 2012 se pomoje ne bo dogajalo kaj veliko, ker morajo dnssec zacet uporabljat resolverji in to se verjetno ne bo zgodilo, dokler ne bodo vsaj pomembnejsi tldji podpisani -- lahko dodas se par let, da zacnejo zone podpisovat lastniki domen. Je pa s postavitijo in vzdrzevanjem kar nekaj dela, tako da, ce imas zeljo in cas, se lahko igras s tem, ce ne, pa se nekaj let ne bos veliko zamujal.

To vse laufa. Samo zaenkrat imamo (pri nas) se cisto dovolj naslovnega prostora, da se nikomur ne mudi. Pomoje bos lahko dobil ipv4 naslov se vsaj kakih 5 let. Zaenkrat je bila pac taksna politika, da se ipje samo dodeljuje, vraca pa ne in jih bo najvisji instanci zmanjkalo. Seveda bo pa se nekaj casa, preden jih bo zmanjkalo lokalnim registrarjem, potem pa sele ispjem.