DNS etc.

[Petr Novotny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6 Apr 00, at 16:59, Pavel Kankovsky wrote:

> > 2. Je bezpecne napsan. :-)
> 
> Vzhledem k tomu, jak moc ma DJB v oblibe nadratovane konstanty (mam na
> mysli veci jako "header[2] & 120"), globalni promenne a podobne chyby
> skryvajici konstrukce, tak bych toto tvrzeni povazoval ze ponekud
> diskutabilni (ale aspon uz opustil K&R styl).

Stejne tak vidi clovek spoustu chyb v tom, ze si takovehle veci da 
do maker, a po par letech s prekvapenim zjistuje, ze si prepisuje 
pamet; a ejhle, nahle byl porusen vztah mezi symbolickymi 
konstantami, a pole se adresuje minus trojkou.

Zadratovane konstanty nejsou primarne proti bezpecnosti. I kdyz 
samozrejme udrzbu znesnadnuji hodne silne.

Ovsem podivejte se na RFC, ktera jsou v djb programech 
implementovana. Tak se opravdu mluvi o presnych offsetech. Takze 
i ta RFC by mela kvuli tomu byt nebezpecna? :-)

> > 1. Musite vzit v potaz, ze cache a autoritativni zdroj jsou rozdilne
> > programy, a tedy kazdy poslouchaji na jinem interface. (Normalne
> > mate k dispozici interfejsu spoustu - udelate si loopback na
> > 127.0.0.2, 127.0.0.3 atd. :-))
> 
> Bohuzel zadny z nich neni videt zvenku. Pro ty, co z jakehokoli duvodu
> nechteji/nemohou aliasovat skutecny interfejs, to predstavuje veliky
> (a IMHO dost zbytecny) problem pri migraci z bindu, ktery umi delat na
> jednom interfejsu kes i autoritativni ns.

Ano. Za cenu toho, ze buffer oveflow v cache vam zrusi 
administrativni ns.

> > 3. Zonovy format vypada vyrazne jinak. (Je snadno parsovatelny
> > pocitacem, a clovek se uci snaze nez pocitac.)
> 
> Ovsem pocitac neni narozdil od cloveka liny a ma spoustu energie na
> vykonavani cinnosti, ktere nevyzaduji tvurci pristup. :)

Jenze clovek, ktery ho uci, aby tyto cinnosti delal, je ve svem 
konani omylny. V kritickych systemech (a DNS _je_ kriticky 
system) je treba co nejvice chyb v parsovani vyloucit - nejlepe tim, 
ze se neparsuje.

> > Pokud se s uvedenymi body smirite, dostanete se do sveta 
> > mnohych vyhod, kde treba split-DNS triky jsou uplne za babku, 
> 
> Pokud mate IP adresy za babku.

Pokud chci split DNS, mam aspon dve IP adresy. Nebo myslite 
"kazdemu odpovez jinak"? Na to mam ipfwadm a transparent proxy 
(ruzne prichozi rozhazuji na ruzne porty).

> > 2. Program neni navrzen bezpecne; je bezpecny ve smyslu "pokud jsme
> > to tentokrat napsali dobre, tak to uz je snad OK"; historie rika, ze
> > nelze bezpecnost zalozit na tom, ze v programu neni prehlednuti.
> 
> Mozna vyse napsanemu rozumim spatne, ale tomu, ze bezpecnost zavisi na
> tom, ze se nektere komponenty (treba TCB) musi v podstate
> bezpodminecne chovat spravne, se asi nevyhneme (aspon pomineme-li
> "byzantske" replikovane systemy, kde to lze nekdy preformulovat tak,
> ze se musi spravne chovat aspon urcity pocet zucastnenych).

To je mysleno jinak. Program lze matematicky dokazat. Lze tedy 
matematicky dokazat, ze pokud neni v programu _preklep_, je 
program spravny. To je fundamentalni rozdil od pocitu programatora 
"jo, dneska se mi to povedlo".

> > 3. Nema omezeni pouzite pameti.
> 
> Ale ma. Rozhodne nesezere vic, nez kolik ma ta masina k dispozici. :)

Pokud mate omezenou pamet a vite to, umite prizpusobit strategii. 
Pokud mate omezenou pamet pres ulimit a nikdo vam to nerekne, 
tak se akorat divite, az se nepovede malloc(); a pak budete dlouho 
vymyslet, co udelate, nebo zahodite nove RR a stare nechate v 
cachi hnit.

> > 5. Neni oddelena autoritativni cast od cache.
> 
> Pod slovem "oddelena" si lze predstavit ruzne veci. Pocinaje tim, ze
> obe casti se nachazeji v ruznych galaxiich, konce tim, ze se pocitac v
> jednom okamziku zabyva pouze jednou z techto uloh. :)

"Oddelena" = jiny proces, i jine uid, k nemuz se soubory vraceji.

> Navic zakladni funkcni vyhoda, ktera z toho rozdeleni IMHO plyne...
> totiz znesnadneni cache poisoningu

Ne. Hlavni vyhoda NENI znesnadneni poisoningu. Hlavni vyhoda je, 
ze i kdyby byla chyba v jedne casti, tak tu druhou cast neohrozi. 
"Nedavej si vsechna vejce do stejneho kosiku."

> tim, ze neumoznime kazdemu, aby se
> ptal na cokoli, neni az tak tak velka vyhra, protoze presvedcit nejaky
> stroj, ktery ma k dane kesi pristup, aby se na neco konkretniho
> zeptal, neni vetsinou tak obtizne (a casto to jde udelat i v realnem
> case).

Tim dostanete jen cache, ne autoritativni ns. Nesestreleni 
autoritativniho ns je mnohem jednodussi; to paket nikam do sve 
pameti neuklada - to si ho jen prohledne, a pak odesle patricnou 
odpoved.

> Bind samozrejme nesezere uplne vsechno,
> co mu prijde. Otazka zni, jak je tezke vyrobit presvedcivy podvrh
> spravne odpovedi. U bindu je to bohuzel pomerne snadne.

Spravne. U dnscache je to vyrazne obtiznejsi. (Musite podvrhnout 
paket prichazejici jakoby z autoritativniho nameserveru pro danou 
domenu, a navic obsahujici spravne, kryptograficky silne, id; navic 
musite vsechny ostatni pakety od jinych ns potlacit. To je 
ekvivalentni tomu, ze drzite v ruce celou linku, kterou dnscache jde 
do sveta. Proti tomuto stavu obrana stejne neni - protoze muzete 
cely Internet emulovat. DNS jeste stale - preze vsechna slibovani 
NSI od roku 1993 - neni chranena asymetrickym podpisem (takze 
by nesla odpoved root serveru zfalsovat). --- Na DNS spoofing pro 
BIND vam pouze staci poslat paket ve spravnem okamziku. Ten 
puvodni (dotazovy) paket videt nemusite.)

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60 
Comment: http://community.wow.net/grt/qdpgp.html

iQA/AwUBOOydB1MwP8g7qbw/EQLlFgCg3hDlBJ5xBBxmmT1aHw3bRevJv2YAnimg
b++LdkVyVFN+QzEjTnQcRNOY
=QJo5
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
Petr.Novotny na antek.cz
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
                                                             [Tom Waits]