Historie nasazení technologie DNSSEC v doméně CZ je již víc než desetiletá a v jejím průběhu došlo k několika důležitým změnám. Vezměme například rok 2010, který byl z pohledu nasazení DNSSEC přímo nabitý událostmi. V první řadě proběhlo v červenci podepsání kořenové zóny a hned vzápětí také vůbec první rotace KSK klíče se změnou algoritmu mezi doménami nejvyšší úrovně, kterou jsme v doméně CZ provedli v srpnu. Po uplynutí osmi let si tento „double“ letos zopakujeme, jen v opačném pořadí. Na říjen je naplánována odložená první rotace KSK klíče kořenového zóny (bez změny algoritmu). No a v červnu provedeme v CZ doméně již avizovanou rotaci KSK klíče, opět se změnou algoritmu. Tentokrát ale jako první správci domény nejvyšší úrovně použijeme algoritmus ECDSA založený na eliptických křivkách.
Route Origin Validation v Internetu
Route Origin Validation (ROV) je komplementárním mechanismem k vydávání Route Origin Authorization (ROA). Dohromady pak tvoří bezpečnostní mechanismus Resource Public Key Infrastructure (RPKI), který má ambice potírat a nebo přinejmenším zmírnit následky chybně oznámených prefixů protokolem BGP. Nasazení mechanismu RPKI je však pomalé a to i navzdory jeho technologické vyspělosti, existenci všech potřebných standardů, software i detailní dokumentaci a propagaci standardu ze strany RIPE NCC. Článek se zabývá kvantifikací nasazení mechanismu ROV v současném Internetu.
Vlastní Certifikační Autorita v Letsencrypt kabátě
Napadlo Vás někdy automatizovat vydávání certifikátů z vaší interní certifikační autority uvnitř vaší organizace? A co třeba využít stejný postup, jakým to dělá Let’s Encrypt, a protokol Acme, včetně všech výhod, které protokol Acme nabízí? Řešením by mohlo být použití Boulderu. Nástin instalace Boulderu a úskalí, na která jsem při jeho zprovozňování narazil, se pokusím rozepsat.
RDAP – nástupce WHOIS protokolu
Jsou to už čtyři roky, co jsem zde na blogu poprvé zmiňoval iniciativu na vytvoření alternativního protokolu pro službu WHOIS. Tento „vousatý“ protokol z roku 1982 přežil několik pokusů o jeho nahrazení (1995 – Whois++, 1997 – RWhois, 2005 – IRIS) a bude zajímavé sledovat, zda-li mu stávající iniciativa zasadí pověstný poslední hřebíček do rakve.
OpenFlow s otazníky
Abych řekl pravdu, dosud jsem si myslel, že OpenFlow je záležitost povýtce akademická a nemá valného praktického významu. Přispěla k tomu jistě i prezentace „Software Defined Networking“ na IETF 82, která ve mně i řadě dalších posluchačů zanechala dojem ryzího slidewaru.
Krátká přednáška Todda Underwooda (Google) na nedávném RIPE 64 mě ale přivedla k úvahám, zda bych neměl svůj postoj k OpenFlow a SDN přehodnotit. Google totiž používá OpenFlow switche ve dvou svých produkčních páteřních sítích, které propojují lokality na třech kontinentech. OpenFlow jim umožňuje pojímat tyto sítě jako systém pro transport dat a ne pouze jako soubor jednotlivých switchů a linek.
OpenFlow je postaven na myšlence oddělení forwardovací logiky (data plane) od směrovacích, filtrovacích a jiných algoritmů (control plane). Zatímco data plane zůstává „zadrátovaná“ ve switchi, control plane se přesouvá na samostatný počítač (controller), který může řídit jeden nebo více switchů. Jádrem OpenFlow je protokol a API umožňující kontroléru konfigurovat zacházení s pakety ve switchi.
OpenFlow předpokládá, že data plane je ve switchi implementována ve formě tabulky toků s využitím hardwarové asociativní paměti (TCAM). V tom ovšem vidím jistý problém: špičkové TCAM čipy mají kapacitu jednotek až desítek tisíc položek, takže se do nich rozhodně nevejde kompletní směrovací tabulka BGP. Mohli bychom sice zvolit alternativní strategii – plnit tabulku na základě toků, které switch skutečně přenáší – ale ani s tou se moc daleko nedostaneme, protože typické počty aktivních toků v páteřních internetových směrovačích kapacitu TCAM rovněž vysoko překračují. Zdá se tedy, že kombinace OpenFlow switche a směrovacího démona není v roli obecného BGP routeru příliš použitelná.
Myslím si ale, že i tak bychom se v Laboratořích CZ.NIC mohli OpenFlow trochu podívat na zoubek. Minimálně by stálo za to demonstrovat, že OpenFlow switch může fungovat i s BIRDem v pozici kontroléru (Google používá Quaggu). Je docela možné, že takový hardwarově akcelerovaný směrovač by se mohl v některých situacích dobře uplatnit.
Za pozornost stojí také standard OF-CONFIG 1.0, který se zabývá konfigurací a správou „provozního kontextu“ OpenFlow switche, tedy de facto všeho kromě tabulky toků. Standard pro tento účel používá protokol NETCONF a datové modely zapsané v jazyku YANG. Jde zřejmě o dosud největší otevřeně dostupnou aplikaci technologií NETCONF/YANG.
Ladislav Lhotka
Liberální nebo striktní? A co na to All Blacks?
Když John Postel v roce 1980 definoval pravidlo robustnosti (známé také jako Postelův zákon), tak se zdálo být rozumné jej definovat jako: „Buď liberální v tom, co přijímáš, ale buď striktní v tom, co vysíláš.“ O pár let později bylo toto pravidlo rozšířeno v RFC 1122 o požadavek nejen přežít divoké prostředí špatně naformátovaných paketů, ale také nadále spolupracovat a komunikovat s implementacemi, které se takto neslušně chovají. Internet byl ve svých počátcích a bylo těžké odhadovat, jaká všechna zařízení budou do sítě připojena a jak dobře nebo špatně budou naprogramována.
Nicméně zpátky k návrhu internetových protokolů. Již o deset let později v roce 2001 popisuje Marshall Rose v RFC 3117 problémy, které přináší aplikace principu robustnosti do interoperability aplikací. Představte si, že máme dvě implementace:
- implementaci Locke, kterou psal hodně šikovný programátor a docela si s ní vyhrál, takže je velmi liberální a dokáže přijmout a zpracovat libovolně naformátovaný paket a…
- implementaci Demosthenes, kterou psal programátor hodně ve spěchu a posílá takové pakety, ze kterých se dělá trochu špatně i směrovačům po cestě.
Locke si s Démosthenem v klidu dokáží povídat. Locke se sice občas diví, co to Démosthenés říká, ale vcelku dobře si rozumějí a komunikace volně plyne. To se ovšem radikálně mění ve chvíli, kdy na scénu přichází implementace Rochester, kde byl programátor velmi striktní a naprogramoval Rochestera tak, že přesně odpovídá specifikaci protokolu a odmítá jakékoli odchylky od standardu, zatímco si Locke s Rochesterem může bez problému popovídat (ostatně jsou oba dva angličané). Dokonce pro Lockeho je komunikace s Rochesterem jednodušší, protože oba dva při komunikaci dodržují správný komunikační protokol. Naopak Démosthenés má se svou antickou řečtinou najednou problém. Démosthenés se může snažit mluvit s Rochesterem jak chce, ale ten mu prostě nemůže rozumět, protože nemluví společným jazykem.
A co by na to řekli All Blacks? Kdyby se o Postelově zákonu dozvěděli v půlce prosince minulého roku, tak by asi zareagovali takto:
Proč? Správci novozélandské domény .NZ v půlce prosince dokončili proces implementace DNSSEC, vypublikovali správný klíč a poslali jej do kořenové zóny. Následně byli upozorněni, že jejich klíč má nezvyklou sekvenci znaků v místě, kde je uveden RSA exponent. Pro srovnání si tento rozdíl pojďme ukázat konkrétně.
Klíč pro doménu .CZ vypadá takto:
cz. IN DNSKEY 257 3 10 ( AwEAAaVU8EMQrZ6Tix2zBaAmizMQ7W0m94qSJUXV4eVW S9ZpXh9t1uj8U/B5Nnqge4G0Te0/NJIqflihZKXs8Hyh JqjF852RKnvNWPu2wMujYjHP0T4lIhu4rTym9+sPNsfi oqvMyyDeqyhVPx21nvLW5oaKjaLd3XJxijRbDTddRU97 mJVVS50PKdDmh5n/4KdRKV7ifR2Ap8L1bvUiCOxl4GAq LoXft+L896bkVj6mefdCSyYaCbgsDc2+10ZBOSF1t89N J6O1yO+y5/7vS3dYKEqj+p4ygaCY0spvrhZxncUeASix g224bNYZM5TLk2/YoKgAEjaIoCwu7SAXB5iUvLU= ) ; key id = 14568
Pokud rozkódujeme prvních pár znaků, dostaneme následující výstup:
$ dig dnskey cz +short | grep '^257' | awk '{print $4}' | base64 -d | xxd -l 12 -b
0000000: 00000011 00000001 00000000 00000001 10100101 01010100 .....T
0000006: 11110000 01000011 00010000 10101101 10011110 10010011 .C....
Délka exponentu je uvedena na prvním místě (00000011), tj. exponent je dlouhý tři bajty. Exponent je v tomto případě 65537 (00000001 00000000 00000001).
DNSSEC klíč pro novozélandskou doménu vypadal takto:
nz. IN DNSKEY 257 3 8 (
BAABAAGwfTiEoh71o6S55+Mdy1qqVRnpKY1VHznrv+wx
rPfvRGB5VivFFPFN+33fsaTxJQTceOtOna7IKxTffj6p
bBG4a9vtk2FqF551IwXomKWJnzRVKqYzuAx+Os/5gLIN
BH7+qRWAkJwCdQXIaJGyGmshkO5Ci5Ex5Cm3EZCeVrie
0fLI03Ufjuhi6IJ7gLzjEWw84faLIxWHEj8w0UVcXfaI
2VL0oUC/R+9RaO7BJKv93ZqoZhTOSg9nH51qfubbK6FM
svOWEyVcUNE6NESYEbuCiUByKfxanvzzYUUCzmm+JwV7
7Ebj3XZSBnWnA2ylLXQ4+HD84rnqb1SgGXu9HZYn
) ; key id = 2517
Opět rozkódujeme prvních pár bajtů:
dig dnskey nz +short | grep '^257' | awk '{print $4}' | base64 -d | xxd
-l 12 -b
0000000: 00000100 00000000 00000001 00000000 00000001 10110000 ......
0000006: 01111101 00111000 10000100 10100010 00011110 11110101 }8....
Již na první pohled je vidět, že exponent je v tomto případě delší (00000100), tj. 4 bajty. Nicméně hodnota exponentu (00000000 00000001 00000000 00000001) zůstává stejná, tedy rovna 65537.
V čem je tedy zádrhel? Dle standardu RFC 3110, který definuje kódování RSA klíčů pro použití v DNS, jsou počáteční nuly v exponentu zakázány. A nyní se dostáváme zpátky k počátečnímu sporu Postel vs Rose.
Správci novozélandské domény samozřejmě nasazení DNSSEC klíče pečlivě otestovali a vše správně fungovalo. Jinými slovy Démosthenés si při testování povídal s Lockem. Nakonec se bohužel ukázalo, že na scéně se skrýval Rochester v podobě implementace rekurzivního resolveru od firmy Nominum, která je při dekódování exponentu velmi striktní a po přijetí klíče novozélandské domény selhala při DNSSEC validaci. Toto nakonec vedlo k tomu, že bylo zapotřebí klíč novozélandské domény opravit a do kořenové zóny poslat klíč ve správném kódování.
Jaké z toho nakonec plyne poučení? Druhá část pravidla robustnosti stále platí, je zapotřebí být velmi striktní při implementaci protokolu, aby byla zajištěna dobrá interoperabilita. Nicméně je jistě ke zvážení, jestli nebýt striktní také při implementaci přijímací části, aby bylo možné odhalit chyby včas již při testování.
A co si myslíte vy? Je lepší být v implementaci striktní nebo liberální?
Ondřej Surý
P.S. Tento článek, respektive odkaz na něj, zahajuje naši komunikaci na Google Plus. Pokud tedy tuto sociální síť využíváte a chcete být informováni o našich projektech a aktivitách, přidejte si nás do svých kruhů.
Máme se bát operace Global blackout?
Na pastebin.com se nedávno objevila zpráva, která slibuje, že 31. 3. 2012 proběhne masivní DDoS útok na DNS root servery v rámci tak zvané operace Global Blackout. Čtenářům našeho blogu je asi zbytečné připomínat, že znefunkčnění všech root serverů by znamenalo výpadek DNS a tím i de facto vypnutí Internetu. Tak jako u všech zpráv tohoto druhu je pochopitelně těžké určit, jak moc vážně se tím mají bezpečnostní týmy zabývat. O neuchopitelnosti Anonymous již bylo napsáno mnoho. Každopádně se tomuto možnému útoku věnovala některá poměrně čtená média a zdá se, že i DNS operátoři berou hrozbu částečně vážně; problém byl poměrně důkladně diskutován v uzavřených operátorských bezpečnostních listech. K tomuto oznámení se sluší odpovědět následující otázky:
- Jak těmto útokům čelit?
- Jakou mají vůbec šanci?
- Proběhne vůbec nějaký útok, je tato zpráva hodnověrná?
Jak útoku čelit
Především stojí za to ve stručnosti zmínit, jak vlastně tento útok funguje. Jde o takzvaný DNS amplification attack. Principem tohoto útoku je, že útočník posílá podvržené dotazy na DNS resolvery. Jako zdrojovou adresu dotazu podvrhne IP adresu cíle, na který chce útočit. Díky jednoduché vlastnosti DNS, že odpověď je vždy větší než dotaz, dosáhne zesílení svého útoku. Vhodně zvolenými typy dotazu lze i z domácího připojení vygenerovat poměrně slušný tok dat. Takto vygenerovaný datový tok od více útočníků, pak může zahltit DNS server(y) či přístupové linky k nim. Z principu útoku je zřejmé, že útočník potřebuje ke své činnosti otevřené DNS resolvery, ale je bohužel smutnou skutečností, že těch je v současném Internetu více než dost, ačkoliv na toto téma byla vydána celá řada varování.
Metod, jak útoku čelit, je celá řada. Především by velice pomohlo, kdyby koncoví ISP dodržovali doporučení z BCP-38 nebo-li kdyby filtrovali odchozí packety, které nemají ve zdrojové adrese IP z jejich rozsahu. Tím by zabránili svým uživatelům podvrhovat IP adresy.
Druhou, mnohem problematičtější možností, je filtrovat všechny DNS dotazy z root serverů. Tyto servery nemají důvod se nijak ptát. Problémem tohoto řešení je, že je šité na míru pouze tomuto jednotlivému útoku a změna cíle útoku by znamenala další konfigurace. Navíc i IP adresy root serverů se čas od času změní a je šance, že aplikace této obrany napáchá více škody než užitku.
No a samozřejmě nejpřirozenější je neinstalovat zbytečně otevřené DNS resolvery. Většina existuje bohužel jen jaksi „omylem“, někteří správci bohužel nejsou příliš pečliví a s konfigurací DNS resolverů si tolik hlavu nelámou.
Šance takového útoku
Ačkoliv se pořád hovoří o 13 root serverech, již to dávno není tak, že 13 počítačů drží kořenovou zónu. Naopak velká většina těchto serverů má zrcadla všude po světě. Rekordmanem v počtu kopií je písmeno J, jež spravovuje Verisign, a které je na 70 místech. Samozřejmě i v každém z těch míst není jeden počítač, ale farma serverů. Abychom i my, sdružení CZ.NIC, přispěli k bezpečnosti, financujeme provoz dvou zrcadel v Praze, a to serverů F a L. Jak už to bývá, technologicky pozadu jsou, alespoň v tomto směru, servery spravované státními institucemi. Anycasting nevyužívají servery spravované ISI, NASA a University of Maryland. Pouze dvě kopie má i server spravovaný americkou armádou. Je možné, že skutečně masivní útok by mohl vyřadit z provozu právě tyto servery s malým počtem zrcadel, ale je velice obtížné shodit službu, jež má desítky dobře spravovaných kopií. Nemyslím si tedy, že by Anonymous měli v tomto příliš velkou šanci. Shodit DNS systém je mnohem větší oříšek než útočit na webové servery. Mimochodem, v minulosti již několik masivních útoků na root servery proběhlo a zatím se nikomu nepodařilo shodit všech 13.
Bude útok?
Především s ohledem na předchozí informace si myslím, že 31. března se může stát hodně věcí, ale rozhodně to nebude útok na DNS. Celé toto prohlášení vnímám spíše jako hoax, může jít klidně o odpoutání pozornosti. Ani Anonymous se jistě nebudou pouštět do akcí, u kterých je v podstatě mizivá šance na úspěch. Navíc tento útok by byl poněkud v rozporu s jejich dosavadní snahou o „svobodný Internet“.
Každopádně pozitivní na tomto „hoaxu“ je, že trochu přitáhl pozornost směrem k nastavení filteringu podvržených zdrojových adres a k nastavení DNS resolverů. Správná konfigurace obou těchto věcí může obecně pomoci při zvýšení bezpečnosti Internetu. Schválně se zkuste zamyslet, jestli v tomto nemůžete něco vylepšit ve vlastní síti.
Ondřej Filip