Administrace komentářů

A to "nepadnutí do oka" standardů, které jsou na tom špatně s bezpečností se zatím docela vyplácí

Ale no tak, vážně mi chcete namlouvat, že všechno, co se panu Bernsteinovi nelíbí, je problematické z bezpečnostního hlediska? Co si tak matně vzpomínám, třeba RFC 2317 (reverzní lookup pro classless rozdahy) nebo záznamy pro IPv6 jsou bezpečnostně problematické?

jeho programy se ve výčtech bezpečnostních chyb v sw objevují zřídka

To je sice pravda, ale na druhou stranu jsou také ve své čisté podobě většinou prakticky nepoužitelné, takže většina uživatelů je nucena používat verze upravené třetími stranami - a od těch už samozřejmě DJB dává ruce pryč, takže mu nekazí statistiky. Navíc jeho produkty kvůli licenčním problémům nenajdete v distribucích, což dále omezuje jejich nasazení. V tomto konkrétním případě jsem navíc hodně alergický na porovnávání BINDu a djbdns, kdy se BINDu jako přitěžující okolnost přičítají problémy verze 4, což byl de facto úplně jiný program, navíc v době, kdy žádný djbdns ještě neexistoval. V okamžiku, kdy se začne porovnávat porovnatelné, už ty statistiky tak efektně nevypadají.

obecně se taky považuje normální mít všechny autoritativní servery jedné domény na jednom fyzickém stroji s jednou konektivitou

To se rozhodně obecně za normální nepovažuje, většina systémáků, pokud takovou věc nasadí, dělá to spíš z donucení manažery.

záložní mail server se taky obecně považuje za přežitek

Záložní mail exchanger se nepovažuje za přežitek, ale v současné době, kdy je několikadenní výpadek konektivity záležitostí naprosto mimořádnou, je jeho potřeba podstatně nižší než dříve. Navíc (na rozdíl od NS záznamů) nevím o žádném RFC, které by nařizovalo, že doména přijímající poštu má mít aspoň dva MX záznamy. A konečně, pokud se sekundární mail exchanger nenasazuje, nebývá to důsledek neznalosti nebo odmítání standardů, ale výsledek logické analýzy problému. Jde např. o to, že zatímco finální příjemce pošty může mail pro neexistující schránku hned v reakci na 'MAIL From:' rovnou odmítnout s pětkovým kódem, záložnímu nezbývá než ho přijmout a zkusit doručit na primární; ten mu ho teprve omlátí o hlavu a chudák záložní, chce-li se chovat korektně, navíc nějakého nevinného chudáka obšťastní nesmyslným hlášením o nedoručitelnosti. Proto velká část spammerů posílá své výtvory rovnou na záložní mail exchanger; sice tím podle mne nic nezískají, ale reálná pozorování ukazují, že to tak je. Bohužel, SMTP protokol je v dnešní době svou koncepcí naprostým anachronismem, ale v dohledné době lze jen těžko očekávat jeho nahrazení něčím, co by více odpovídalo současným podmínkám.

Implementace, která by se chovala stejně k autoritativním záznamům i ke kešovaným záznamům, by nestála za moc. Třeba přepisovat autoritativní údaje zadané adminem tím, co jako cache někde splaší na internetu, a pak to dál publikovat jako autoritativní údaje, to by asi nebylo moc šťastné.

To ale nemění nic na tom, zda se jedná o dvě různé služby. Jedná se o jednu službu, která používá jeden protokol, je definována jednou sadou RFC a má přidělen jeden rezervovaný port (OK, dva, jeden UDP a jeden TCP). Stejně jako nejsou dvě různé služby MTA fungující jako relay pro poštu odcházející z lokální sítě a MTA přijímající poštu pro doménu jen proto, že tyto role lze oddělit a mnohdy tak oddělené jsou. Celý protokol je postaven na principu, že se kteréhokoli nameserveru a priori můžete zeptat na jakýkoli záznam (samozřejmě to neznamená, že vám odpoví), u vámi zmíněného HTTP je to úplně jinak.

Historickým reliktem nejsou v žádném případě, a škodu dělají pouze pokud jsou špatně implementovány, nebo je špatně implementována zdrojová webová aplikace.

Některé škody páchají proxy zcela systémově (např. výrazně komplikují snahy o traffic control, jiné jsou skutečně většinou chybou implementace, ale na rozdíl od vás vídám chyby nejen na straně webových aplikací). Např. nedávno jsem tu s někým absolvoval poměrně dlouhou debatu, kde dotyčný tvrdošíjně obhajoval deklarování HTTP/1.0 v hlavičce dotazu kvůli proxy, a to i u dotazů, obsahujících prvky HTTP/1.1 (např. hlavička Host:), přestože se jedná o jednoznačné porušení RFC. A pak jsou tu škody morální, kdy proxy pomáhá v uživatelích deformovat představu, co je to vlastně Internet - např. tento týden jsem zrovna školil ve firmě, kde mne předem tvrdili, že učebna je připojena na Internet; realita byla taková, že byl přístup pouze na web, a to ještě přes proxy (autentizovanou). Historicky měly proxy smysl hlavně kvůli omezení datového toku, dnes už je podle mých zkušeností tento efekt zanedbatelný, takže zbývá jen použití k filtraci nebo auditování HTTP provozu.