» »

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

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

Brane2 ::

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 ?
On the journey of life, I chose the psycho path.

x.sci ::

Brane2 je 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.

Brane2 je izjavil:

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

Tole resi listen-on.

Brane2 je izjavil:

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.

Seveda ne, glej zgoraj.

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

Brane2 ::

x.sci je izjavil:

Brane2 je 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...
On the journey of life, I chose the psycho path.

x.sci ::

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.

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.

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.

Zgodovina sprememb…

  • spremenil: x.sci ()

Brane2 ::

x.sci je 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...
On the journey of life, I chose the psycho path.

x.sci ::

transfers are made from port

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.

Kako je enostavno ločit, če gre za VEČINO primerov ? Kaj naj naredim z razliko ?

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.

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...

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.

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.

Edit: Bi bilo v tem primeru res lazje, ce bi mu lahko povedal na kater port naj gre.

Zgodovina sprememb…

  • spremenil: x.sci ()

Brane2 ::


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.
On the journey of life, I chose the psycho path.

x.sci ::

Ko si ravno omenil nat, na pamet mi je padel en zelo grd hack :P

Prek nata lahko posljes vse requeste na port 53, ki pridejo od ipjev slave-ov, na poljuben port. Ne vem, ce ti to kaj pomaga, samo ideja.

Brane2 ::

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.
On the journey of life, I chose the psycho path.

Brane2 ::

Še eno pravzaprav dve vprašanjci, ker vidim da se s tem ukvarjaš bolj kot iz čiste amaterske radovednosti:

1. SPF stvar naj bi bila namenjena v pomoč sesuvanju email spama, ker prejemnik emaila lahko preko DNS infrastrukture preveri, če pošiljatelj emaila odgovarja deklaracijam, vpisanim v njegovi domeni.
Vprašanja:

Obstajata dve "verziji", pri čemer gre v bistvu za dva ortogonalna standarda s ponesrečenim imenom.

SPFv1 govori o tem, katere mašine lahko pošiljajo email v imenu določene domene.

1a.Kako točno laufa SPFv2 (= EMail-Id) ?

1b. Kako sta v1 in v2 uporabljena v praksi ? Se predvsem uporablja v1, v2 ali sta predvsem v mešani varianti ?

1c. Je normalno, da so vsi SPF zapisi v "TXT" recordu in da nihče nima zraven še SPF recorda?
Vem, da je to zdruzžljivostni način, ampak Bind 9.6 že podpira SPF record in lahko bi imela dva sicer istovetna recorda, enega TXT in drugega SPF


2. DNNSSEC. Namenjen je torej oteževanju napadov na DNS omrežje in injektiranja lažnih preslikav v nek strežnik, saj lahko vsak klient preveri elektronski podpis domene in recorda. Rečeno je bilo, da se bo začel uvajati letos, oziroma raje da bo vrh DNS piramide imel podpisane domene in se pričakuje, da bo stvar začela napredovat navzdol po piramidi.

2a. kolk je to uporabno in preizkušeno ? Nekako vidim mnogo potanciala za DDOS napade na DNS omrežje, ki se bo sedaj moralo ukvarjati še s preverjanjem podpisov.

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 ?

Koliko se sploh splača ubadat z DNSSEC trenutno ?
On the journey of life, I chose the psycho path.

x.sci ::

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.

Brane2 ::

Raje ne.

Kako pa je z IPv6 BTW ? Baje da IPv4 poide čez kako leto (predvidoma), torej bo treba nekaj naredit.

Se kaj ve, kako to laufa sedaj s podelitvijo IP prostora- kdaj se bo to začelo dogajati itd ?
On the journey of life, I chose the psycho path.

x.sci ::

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.


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Problem z domenami na Apache

Oddelek: Omrežja in internet
261436 (1063) Ice-Heki
»

Vpis DNS strežnika v vrhnji DNS

Oddelek: Omrežja in internet
378339 (6830) kronik
»

Poštni strežnik na Fedori

Oddelek: Operacijski sistemi
71395 (1138) operater
»

Linux - konfiguracija domene

Oddelek: Omrežja in internet
221519 (1300) EagerWolf
»

Doma postavljen DNS server?

Oddelek: Omrežja in internet
132219 (1893) Bakunin

Več podobnih tem