NLNOG Day: budoucnost NAT64, DNS i RPKI

NAT64 Check 2.0

Počet sítí, kde funguje pouze IPv6 a podpora protokolu IPv4 je zajišťována kombinací NAT64 a DNS64, se pomalu zvyšuje. Bohužel se tím také ukazují některé problémy, které za jisté nepříjemné shody okolností mohou nastat. Jan Žorž provozuje v Go6lab už několik let veřejný test NAT64. Stačí mít IPv6 konektivitu a nastavit adresu DNS resolveru na jeden z uvedených na stránce. „Když koukám do logů, vidím zajímavé věci, které se najdou na internetu,“ poznamenává. Ukazuje například doménová jména, kde AAAA záznamy míří do nesmyslných adresních rozsahů jako:

• ::
• ::1
• ::ffff:<IPv4 addresa>
• fe80::<něco>
• 64:ff9b::<něco>
• 2001:db8::<něco>

Funkce DNS64 přitom funguje tak, že syntetizuje IPv6 adresu jen v případě, že AAAA záznam neexistuje. Pokud existuje, a jde o nějaký nesmysl, k syntéze nedojde a zařízení, které je na překladové technologii závislé, se na stránku jednoduše nedostane.

Sander Steffan a Jan Žorž

Nástroj NAT64 Check má pomoci v odhalování podobných problémů. Na zadanou adresu webové stránky se připojí z IPv4-only, IPv6-only a IPv6-only sítě s NAT64 a vytvoří náhledy stránek v prohlížeči, které se dají porovnat. Problém první verze nástroje, která je v současnosti stále provozována, je nepříliš jasná interpretace výsledků pro laika, co přesně je rozbité a jak to opravit. Také se testovací systém čas od času rozbil a čekal, až si závady někdo všimne a opraví ji.

Druhá verze, která právě vzniká a brzy bude spuštěna, je plně distribuovaný systém, který dokáže testovat z více lokalit s jedním společným rozhraním. Nově je také snadné tester nainstalovat – jde o jeden virtuální stroj, který v sobě obsahuje několik dockerových kontejnerů pro vlastní testování. „Chceme také vyhodnocovat špatná data v DNS a na základě toho vytvořit blacklist pro DNS64 servery, který by měl vynutit syntézu IPv6 adresy pro vyjmenované domény z blacklistu,“ říká Sander Steffan, autor testovacího softwaru.

Architektura NAT64 Check 2.0

Nově je možné spustit jedno měření ve více lokalitách, což je důležité zejména pro analýzu chování CDN sítí. Na pozadí běží Chromium, takže snímky obrazovky vypadají opravdu stejně jako obrazovka návštěvníka s prohlížečem Chrome. Služba také nově podporuje opakované testy. „Známe třeba případy, kdy někdo stěhuje web z jednoho serveru na druhý a změní jen IPv4 adresu. Zatímco v okamžiku změny si nikdo problému nevšimne, časem začne IPv6 verze zastarávat.“

Verze 2.0 měla podle plánu vyjít v lednu 2018, projekt však nabral zpoždění, nicméně v blízké budoucnosti by tato verze už skutečně měla být spuštěna.

DNS odolné proti budoucnosti

Před dvaceti lety bylo zavedeno rozšíření EDNS. Jde o teoreticky zpětně kompatibilní rozšíření DNS protokolu. V praxi je na dotaz obsahující rozšíření EDNS0 možné získat nejrůznější chybové návratové kódy:

• FORMERR  – chyba formátu zprávy
• SERVFAIL  – selhání serveru
• NXDOMAIN  – daný DNS podstrom neexistuje
• NOTIMP  – funkce není implementována

Nejhorší ze všeho ovšem je žádná odpověď – vypršení časového limitu. V tuto chvíli se problém v resolverech obchází tak, že resolver se zeptá s volbou EDNS, a pokud nedostane odpověď, po určité době se zeptá znovu bez EDNS. Po prvním únoru 2019 dojde ke koordinované změně chování všech velkých open source resolverů: když autoritativní server na dotaz s EDNS neodpoví, bude prostě ignorován.

Peter van Dijk

Vyzkoušet chování své domény lze na stránce dnsflagday.net. „Při té přiležitosti také zkontrolujte svou doménu nástrojem DNSviz. Pokud stále hledáte důvod, proč EDNS řešit, uvědomte si, že neodpovídáním na dotazy otevíráte prostor pro útočníky, aby odpověď podvrhli,“ uzavřel svou přednášku Peter van Dijk, vývojář PowerDNS.

V následné diskuzi poznamenal Jan Žorž z pozice síťového operátora, že změna uskutečněná v únoru 2019 se ke koncovým uživatelům ve skutečnosti dostane mnohem později. „Síťoví operátoři jsou obvykle velmi konzervativní a dokud DNS infrastruktura funguje, nesahají na ni.“

Po stopách napadeného operátora

Pascal Gloor popsal vlastní zkušenost s napadením sítě telekomunikačního operátora. Quickline je druhý největší kabelový operátor ve Švýcarsku, má asi 400 tisíc zákazníků. Celý příběh začal stížností zákazníka na odmítanou poštu do sítě Swisscom, což je největší tamní operátor. Když lístek došel k technikům, zjistilo se, že pošta byla odmítnuta kvůli tomu, že síť Quickline se octla na blacklistu. Odpověď Swisscomu na důvod blacklistování byla jednoduchá: „chodí od vás spam“. Spam chodil ze specifického IP rozsahu FTTH směrovačů, nikoli z rozsahu kabelových klientů. Jako CPE se používá zařízení Huawei HG8247H.

Bylo jasné, že nejde o provoz od zákazníků. „Na CPE je jakýsi příkazový řádek, ale nic jsme jeho pomocí nenašli,“ popisuje Pascal Gloor začátky vyšetřování a pokračuje: „Udělali jsme několik chybných předpokladů. Například jsme ignorovali SSH provoz, protože skeny SSH jsou běžným šumem, který je na internetu neustále. To byla chyba.“

Když zkusili SSH přístup na CPE, následoval dotaz na heslo. „Když jsme vyplnili špatné, objevila se přesto další výzva k přihlášení.“ Do vlastního systému se tedy nedalo dostat, ale SSH relace byla navázána. Stačilo tedy například otevřít přesměrování portů a dalo se tímto způsobem tunelovat provoz. Tímto způsobem tedy útočníci rozesílali spamy z domácích směrovačů nic netušících zákazníků.

První chyba byla, že služba SSH na CPE byla otevřena do internetu. Dokumentace výrobce byla v tomto ohledu ne zcela jasná, takže takovou chybu šlo udělat snadno. „Otevřeli jsme případ u výrobce, že chování SSH démona v CPE není úplně v pořádku. Výrobce odpověděl, že zařízení pracuje podle předpokladů.“ Časem chybu přesto opravili.

Na samý konec příběhu přišly požadavky na vydání dat o telekomunikačním provozu. Bylo jasné, že tunely nešel jenom spam, ale i další škodlivý provoz, který se objevil v hledáčku policejních složek. Z dosavadních několika desítek požadavků na poskytnutí dat jich najednou bylo několik stovek. „Snažili jsme se domluvit s orgány, že tohle nemá cenu, protože víme, že závadný provoz nebyl pořízen zákazníkem, ale jeho hacknutým routerem.“ To ale policii úplně nezajímalo, stále chtěla jména a adresy zákazníků. Nakonec jim tedy vyhověli ale do poznámky vždy napsali, že jsou si jisti, že daný provoz nebyl proveden zákazníkem. „Dalo se také neodpovědět, ale to by znamenalo, že bychom byli sami předvoláni před soud pro neplnění zákonné povinnosti.“ Vydání dat je tedy pro operátora nejjednodušší řešení.

RPKI do každé sítě!

Velká část akce byla věnována technologii Resource Public Key Infrastructure. V přednášce o RPKI pro manažery byly popsány základní principy: jde o řešení, jak zastavit únosy adres protokolem BGP, které je realizováno kryptograficky zabezpečenou databází autonomních systémů, k nim přiřazených adresních prefixů a jejich největších povolených délek.

Jako obvykle má takový proces dvě strany – publikování certifikátů a takzvaných ROA na straně jedné a jejich validace na druhé straně. K zavedení RPKI je potřeba především rozhodnutí vedení, že odmítání nevalidních ROA je dobrá věc. „Co když přijde moment, že vás zákazník dá k soudu za to, že jste propustili nevalidní prefix a on tím přišel ke škodě?“ Tímto příkladem Niels Raijer zdůvodňuje, proč by se manažeři měli o RPKI zajímat. Ostatně v nedávné historii se odehrál případ odcizených kryptoměn, který skutečně začal únosem IP adres, tedy jevem, před kterým RPKI chrání.

Pokud se RPKI rozhodneme implementovat, je potřeba publikovat správně ROA. V RIPE regionu stačí ROA naklikat na LIR portálu. Je potřeba proškolit technickou podporu, aby chápala, jak se projevují problémy způsobené RPKI validací. Když si někdo bude stěžovat, že se nemůže spojit s nějakou adresou, technická podpora musí umět prozkoumat stav RPKI validace pro danou adresu. Problém se také pozná podle výpisu nástroje traceroute končícího na posledním směrovači sítě operátora – pro další směrovače kvůli nevalidnímu ROA neexistuje cesta zpět.

K validaci je třeba nějaký virtuální stroj s Linuxem, na který se nainstaluje některý z dostupných RPKI validátorů, třeba ten od RIPE NCC, který je napsaný v Javě. Validátor stahuje certifikáty a ROA z úložišť jednotlivých regionálních registrů, validuje jejich digitální podpisy a výsledek validace – seznam autonomních systémů a prefixů – posílá do směrovače. Není třeba se bát přetížení směrovačů, hlavní práci dělá validátor, směrovač pouze porovnává přijaté prefixy s předem vygenerovaným seznamem.

Nakonec je potřeba dát dohromady pravidla, co dělat s jednotlivými záznamy ve směrovací tabulce podle stavu valid (ROA odpovídá), invalid (ROA je porušeno), nebo unknown (ROA pro daný prefix neexistuje). „Pokud se rozhodnete prefixům ve stavu invalid pouze snížit preferenci, žádnou skutečnou ochranu proti útokům nedostanete − útočí se obvykle specifičtějšími prefixy, které vyhrají i s nízkou lokální preferencí,“ upozorňuje Niels Raijer na problém výchozí konfigurace. Závěrem také shrnul vlastní zkušenosti, že počet zákaznických problémů s nedostupnými cíli kvůli RPKI validaci je mnohonásobně nižší než počet BGP únosů, které správná validace zastaví.

Většina RPKI se validuje v Nizozemsku

Ben Cartwright-Cox následně pokračoval přednáškou o testování validace RPKI. Podobným měřením se ostatně nedávno zabýval i Tomáš Hlaváček z laboratoří CZ.NIC. Ben Cartwright-Cox zjistil, že ROA validuje celkem asi 128 tisíc IPv4 adres, většina z Nizozemska. Také upozornil na některá úskalí: „Pokud vám některý z partnerů posílá výchozí cestu, validace RPKI nebude fungovat.“ Upozornil také na problém se severoamerickým registrem ARIN, který stažení svého seznamu pevných bodů důvěry (TAL) podmiňuje odsouhlasením podmínek. Kvůli tomu není zahrnut v balíčcích RPKI validátorů a každý operátor je nucen stažení provést ručně, což bohužel spousta lidí neudělá.

Routinator 3000

Martin Hoffman z NLnet Labs představil projekt Routinator. Dnes je možné získat certifikát pro RPKI snadno z portálu na stránkách RIPE NCC. „To funguje dobře, pokud máte pár prefixů. Pokud jich máte stovky, potřebujete vlastní CA a vytvářet certifikáty pro prefixy tak, jak se ve vaší síti objevují.“ Takové řešení je v současné době na roadmapě. Druhá část RPKI, validace podpisů (ROA), se zdá být jednodušší, s ní tedy v NLnet Labs začali. „Zkoušeli jsme nový jazyk Rust, za 6 týdnů se nám povedlo vytvořit funkční program, další týden trval návrh loga,“ vtipkuje Martin Hoffman. Ke spuštění stačí Rust a rsync pro stažení pevných bodů důvěry od jednotlivých regionálních registrů. Výstupem je text ve tvaru ASN,prefix,délka, v podobné podobě jako RPKI Validátor z dílny RIPE NCC. V tuto chvíli se jedná spíše o veřejnou ukázku, v budoucnu dojde k vyčištění kódu. Verze 1.0 by také měla mít rozhraní RPKI-RTR pro přímou komunikaci se směrovači.

Cestovní mapa bezpečného směrování

„Každý dělá chyby. Jeden překlep může způsobit velké škody,“ uvádí Job Snijders nejčastější příčinu výpadků internetových sítí. Právě proto existuje iniciativa bezpečnějšího směrování, která se postupnými kroky snaží internet zabezpečit jak proti překlepům, tak i proti úmyslným útokům.

První problém je v databázích IRR, které se používají pro filtrování přijatých prefixů. Některé databáze nevalidují držitele adres, takže v podstatě kdokoli může vyrobit záznam pro kohokoli. V RIPE databázi byly uloženy jak validované route objekty, tak i zcela nechráněné objekty pro adresy mimo region RIPE NCC. Toto bylo nedávno rozděleno na databázi RIPE a RIPE-NONAUTH. Stejně se již dříve zachovaly databáze APNIC a AfriNIC. ARIN provozuje databázi, který není úplně napojená na interní databázi členů. Právě probíhá jednání v NANOGu a ARINu, že databáze bude buď vypnuta nebo vylepšena.

Přístup k IRR je v nástrojích OpenBSD zadrátován na adresy whois.radb.net a rr.ntt.net. Sice je možné adresu změnit, ale většina uživatelů používá výchozí volbu. Obě adresy jsou provozovány podobnými společnostmi. Tato vstupní brána může IRR databázi filtrovat pomocí RPKI, takže pokud ROA záznamy budou v rozporu se záznamy v IRR, nebudou danými nástroji viditelné.

Dalším bodem je filtrování v peeringových centrech. Devět z deseti největších peeringových center filtruje podle IRR. „Když to může dělat devět největších, můžou to dělat všichni.“ Existují softwary arouteserver a ixpmanager, které dokáží vygenerovat filtrovací pravidla. Monopol na pokročilé filtrování, který v peeringových centrech drží český démon BIRD, je také pouze krátkodobý problém – OpenBGPd dostalo sponzorský dar pro doprogramování požadované funkcionality, aby mohla být zachována diverzita implementací route serverů.

Route servery v peeringových centrech musí začít zahazovat nevalidní RPKI prefixy. Jsou v roli, že negarantují, že přes ně všechno projde, nikdy nemají výchozí cestu a když přestanou fungovat, data protečou tranzitním spojem. Není tedy žádný důvod, proč by route servery neměly RPKI filtrovat. „K tomu, aby RPKI technologie byla prospěšná, není nezbytné, aby validovali všichni, stačí, když budou validovat největší hráči na dnes již velmi globalizovaném internetu.“ V úvahu připadají zejména provozovatelé velkých rekurzivních DNS serverů a největších cloudových služeb.

RPKI však validuje pouze shodu zdrojového autonomního systému, pokud bude provoz unášen uvnitř tranzitního autonomního systému, aniž by došlo ke změně zdrojového autonomního systému, RPKI takový útok nepozná. Tento problém řeší standard BGPSEC, který kryptograficky zabezpečuje celou cestu. „Bohužel je stále v plenkách, nikdo to nenasazuje, výrobci to nenabízí. Nicméně internet je dnes velmi hustě propojen a třeba ke Google je cesta tak krátká, že unášet provoz v tranzitním AS je nepraktické a takových únosů se moc neobjevuje.“

Validátory RPKI jsou už teď dva – jeden od RIPE NCC, druhý od NLNetlabs, vzniká i další. Výrobci hardwaru přidávají podporu RPKI (Cisco, Juniper, BIRD, Nokia, FRR i další). „Důležité je, že software se nemůže rozvíjet bez uživatelů, takže je potřeba, aby to lidé začali používat,“ uzavřel přednášku Job Snijders.