Ondřej Filip: projekt Turris
O projektu distribuované kybernetické bezpečnosti, který byl představen na jarní konferenci IT 13, jehož nejviditelnějším prvkem je domácí router Turris, jsme na zde již několikrát psali. Na konferenci mu byl věnován celý blok, takže bylo možné seznámit se s výstupy několikaměsíční práce ve velkém detailu.
Úvodní příspěvek shrnul vize a cíle projektu. Samotný router Turris rozhodně není cílem tohoto projektu. Je to jen nutný krok k tomu získat dostatečně výkonný hardware pro provádění analýzy provozu v reálném čase.
připomenul Ondřej Filip. Také dodal, že většina obav uživatelů o soukromí není na místě, protože router rozhodně nesbírá víc než libovolný antivirus: Kdekoli o routeru mluvíme, vyvolá to vždy flamewar na téma ochrany soukromí. Přitom pokud někdo s umístěním routeru ve své domácí síti nesouhlasí, nemusí si jej pořizovat. Je ale spousta lidí, kterým se myšlenka kompletně open source hardwarového routeru libí.
První série routerů Turris byla předána do výroby. Očekává se, že první zájemci se routeru dočkají počátkem roku 2014.
Tomáš Rykl: Návrh hardware pro router Turris
Tomáš Rykl je jedním z hlavních návrhářů hardware pro Turris. Přednášku začal statistickými údaji: Deska routeru je velká 20 × 17 centimetrů, je na ní asi 1400 součástek, na 4000 spojů a prokovených děr. Vývoj prvního prototypu trval asi 700 hodin.
Základními požadavky byl dostatečný výkon, aspoň 2GB RAM, jeden WAN port, 4× LAN, vše gigabitové a WiFi v pásmu 2,4 i 5 GHz. Měly být k dispozici USB porty pro připojení externích disků a tiskáren. Mysleli jsme i na připojení nízkoúrovňového hardwaru, k tomu účelu jsou na desce kolíkové lišty.
Vzhledem ke krátkému vývojovému termínu nebylo možné začít úplně od nuly, autoři tedy hledali vhodný vývojový kit, sloužící jako výchozí platforma. Požadavkem bylo také, aby periferie byly podporovány v OpenWRT a jejich dokumentace byla volně dostupná bez nutnosti podpisu NDA. Také jsme chtěli součástky s dostatečně velkou roztečí vývodů, aby nebylo nutné vytvářet drahé desky plošných spojů vysoké jakosti.
Nakonec byl zvolen dvoujádrový procesor Freescale P2020NSE2MHC, u kterého výrobce garantuje jeho výrobu po dobu 10 let. Výběru podléhal také obvod pro ethernetový přepínač. Kandidátem byl třeba Broadcom, výrobce se však diskvalifikoval požadovaným objemem zakázky: „Nejmenší odebrané množství bylo v milionech kusů,“ dodává Rykl.
Po výběru všech komponent bylo potřeba vytvořit z dokumentace výrobců knihovny součástek pro návrhový systém, nakreslit schéma zapojení a začít navrhovat desku plošných spojů. Návrháři byli dva, jeden se věnoval jen napájecím zdrojům, druhý navrhoval ostatní elektroniku. Rozhodli jsme se pro šest vodivých vrstev, z toho čtyři signálové a dvě napájecí. Cílová tloušťka desky byla kolem 1,6 mm.
Nejtěžší částí plošného spoje je spojení procesoru a DDR3 paměti, které je velmi náročné na časování, neboť signály dosahují frekvence kolem 1 GHz. Tuto část je třeba dělat velmi pečlivě. Když to uděláte špatně, zařízení se vůbec nerozběhne, protože procesor nebude schopný komunikovat s pamětí RAM.
Je důležité, aby všechny spoje byly stejně dlouhé s tolerancí přibližně 0,1 mm. Z toho důvodu se spoje různě klikatí, aby se případné rozdíly délek vyrovnaly.
Propojení CPU a RAM
Po dokončení návrhu byl plošný spoj předán do výroby prvního prototypu. U prvního prototypu nefungovaly napájecí zdroje, ale bylo možné si dočasně vypomoci externím zdrojem a oživit zbytek desky. Závěrem byla předvedena jedna speciální vlastnost routeru Turris − uživatelsky regulovatelný jas indikačních LED diod, který je implementován přímo v CPLD řadiči desky, takže funguje nezávisle na operačním systému.
Náhradní napájecí zdroje pro první prototyp
Martin Strbačka: Portace OpenWRT na router Turris
Na přednášku o vývoji hardwaru plynule navázal Martin Strbačka příspěvkem o tom, kterak dojít od rozsvícení diody a až k funkční WiFi. Na začátku byla věta od Tomáše Rykla, že v routeru bude procesor Freescale P2020. Platforma se v OpenWRT nazývá mpc85×x a v aktuální verzi byla označena jako „broken“, tedy nebylo ji možné ani zkompilovat. Ve vývojové verzi OpenWRT to bylo o něco lepší, bylo podporováno několik vývojových kitů, jejich uživatelé jsou ale obvykle natolik zkušení, že si byly schopni zdrojový kód „přiohnout“ tak, aby pro jejich desku fungoval. Nebyli přitom nijak motivováni vracet změny zpět.
Zlom nastal s uvedením routeru TP-Link WDR-4900 na trh. Jedná se o high-end router známého čínského výrobce, který je postavený na stejné platformě jako Turris. Od té chvíle se začaly dít divy. Mohli jsme sledovat, jak se takový SoHo router v OpenWRT etabluje, denně chodily patche vylepšující jeho podporu.
Pak přišel první prototyp Turrise, který bylo zapotřebí oživit. Začali jsme bootloaderem U-boot. Ten se do desky nahraje rozhraním JTAG. Zkusili jsme použít U-boot pro vývojovou desku od Freescale. Sice vypisoval nějaké chyby kvůli odlišnosti hardware, ale aspoň minimálně fungoval. My jsme ale chtěli U-boot podporovaný upstreamem, vytvořili jsme tedy z Freescale verze sadu patchů.
S funkčním U-bootem bylo možné posunout se dál a zavést samotné linuxové jádro. Pro první pokus zvolili vývojáři kernel pro router od TP-Linku. Sice nefungoval správně, protože je hardware Turrisu odlišný, ale samotný fakt, že se jej podařilo zavést, svědčí o tom, že toolchain použitý pro jeho sestavení fungoval bezchybně. Dále bylo možné založit v OpenWRT nový subtarget P2020 a sepsat definici hardwaru do DTS. Tato datová struktura se následně zkompiluje do bytekódu DTB/FDT, který se uloží do flash paměti. Z ní si pak linuxové jádro přečte, kde jsou zapojeny jaké periferie a jak k nim přistupovat.
Martin Strbačka dále popsal zásadní odlišnost portu OpenWRT pro Turris, vycházející z potřeby často systém aktualizovat. Standardně je kořenový filesystém rozdělen na základní systém pouze pro čtení a zapisovatený overlay, do kterého se ukládají změny. My bychom ale radi měli každý balíček samostatně aktualizovatelný, což se standardním OpenWRT moc dobře nejde. Můžete zvolit, aby byl celý kořenový filesystém zapisovatelný, tím ale přijdete o záchranný režim, kdy podržením resetovacího tlačítka vrátíte systém do použitelného stavu.
Turris proto používá dvě flash paměti. V základním režimu běží z hlavní paměti typu NAND o velikosti 256 MB, která je celá přepisovatelná. V případě poškození dat v této paměti je možné zavést minimalistický systém z paměti typu NOR o velikosti 16 MB, ze kterého se může obnovit čistý systém do paměti NAND. V nouzi je možné systém obnovit i z SD karty.
Michal Vaner: uCollect – monitoring sítě a detekce anomálií
Michal Vaner je autorem programu uCollect, který se v projektu Turris bude starat o sběr dat. Je sice nejméně vidět, ale z hlediska uživatelů je nejkontroverznější. Žádné stávající řešení sběru dat nám nevyhovovalo. Existují systémy pro sběr na velkých serverech, které nejsou vhodné pro tak malá zařízení. Další druhy jsou určené pro ISP, kde měří zejména toky dat, aby bylo možné zjišťovat, kde je potřeba navýšit kapacitu. Posledním druhem jsou systémy paranoidních správců korporátních sítí. Takový systém jsme nechtěli, protože sami budeme uživateli routerů Turris.
Měřicí systém je stavěn jako modulární, dokáže za běhu načítat novou sondu v podobě sdílené knihovny. Díky tomu je možné za běhu přidávat sondy a případně v nich i hledat chyby. Pokud plugin spadne, je restartován, pokud spadne pětkrát po sobě, je z měření vyhozen jako vadný.
Komunikace se serverem probíhá trvalým TCP spojením, které se automaticky obnovuje. Nepoužíváme HTTP, nepřinášelo by nám žádnou výhodu, protože jak klient, tak server je náš. Jednoduchý binární protokol se snáze programuje.
Přenos na server je samozřejmě šifrovaný: Používáme TLS, nevěříme ale velkým autoritám, v zařízení je napevno uložen certifikát serveru. Autentizace klienta probíhá systémem Challenge-Response, máme na to dedikovaný hardware, který heslo nevyzradí ani operačnímu systému.
Data s naměřeným provozem včetně aktualizací a logů by neměla použít víc než 50 MiB za týden.
Vlastní sběr dat probíhá pomocí standardního rozhraní pcap, připojeného na WAN port, takže provoz na LAN straně není vůbec sledován. Pcap neumožňuje provoz měnit, jen přesně zachycuje existující provoz. V případě nedostatku výkonu se některé pakety vynechají, tok dat není za žádných okolností zpomalen. Jádro démona uCollect zachytané pakety rozloží a ve strukturované formě předá pluginům. Nikdy se nedíváme do obsahu dat a nezajímá nás ani lokální IP adresa,
zdůrazňuje Vaner.
První plugin, který byl spíše testovací, se jmenuje count a počítá spojení. Přestože jde spíše o demo, data jsou z něj zajímavá. „Například je vidět, že většina uživatelů používá zastaralou verzi protokolu IP,“ glosuje Michal Vaner poměr toků IPv4 a IPv6.
Druhý plugin buckets (kyblíčky) hledá anomálie v provozu. Plugin proto hashuje IP adresu a port pomocí několika funkcí, do několika málo přihrádek. Počty paketů v přihrádkách se akumulují přes všechny routery. Pokud z dat mnoha klientů zjistíme, že nějaká přihrádka je výrazně odlišná od ostatních, budeme detailně sledovat, o jaký se jedná provoz.
Michal Vaner dále pohovořil o plánech na další pluginy do budocna: Plánujeme plugin histogram, podporu více WAN portů a případně podporu jiných protokolů spojové vrstvy.
Foto: Igor Kytka, CZ.NIC
ČLÁNKY DO MAILU