Router Turris je zaměřený především na bezpečnost. Samozřejmě, že v každém softwaru může být chyba, ale my jsme se snažili udělat vždy více než jednu vrstvu zabezpečení. Co všechno je tedy kolem Turrisu za zabezpečující mechanizmy?

Předně, na rozdíl od mnohých routerů, Turris má automatické aktualizace. Ty slouží nejen k instalaci novějších verzí sond, ale také k opravám bezpečnostních chyb. Průběžné vylepšování softwaru je už jen bonus.

Bezpečné SSL

Aktualizace si router stahuje ze serveru api.turris.cz přes šifrovaný protokol HTTPS. Dobře nastavené HTTPS ale není jen o tom vygenerovat pár klíčů a získat odpovídající certifikát. Dobře nastavený server nedovolí například použít staré a děravé verze protokolů. Když se podíváte na tento odkaz, zjistíte, že jsme nastavení šifrování nenechali náhodě a zapnuli jen to, co je opravdu bezpečné.

Router také kontroluje, že certifikát je od konkrétní autority. Důvodem je, aby útočníkovi nestačilo požádat nějakou jeho spřátelenou autoritu o vydání odpovídajícího certifikátu a úspěšně se pak při komunikaci vydávat za náš server. Turris také kontroluje revokace certifikátů, ne jen jejich vypršení, jako většina softwaru. To je důležitý bezpečnostní mechanismus v případě bezpečnostních incidentů, které vyžadují rychlou výměnu certifikátu, jako tomu bylo například v případě nedávné chyby Heartbleed. Výměna ukradeného certifikátu totiž pozbývá smyslu, pokud klient nemá jak zjistit, že původní certifikát již není platný.

Podepsané aktualizace

Šifrování a především ověření protistrany je při stahování aktualizací důležitá, ale ne jediná vrstva ochrany. Všechny aktualizace jsou navíc podepsané RSA klíčem na jiném počítači, který není dostupný z Internetu. Tyto podpisy se pak ověřují před samotnou instalací aktualizací, takže i kdyby se útočníkovi povedlo získat přístup na api.turris.cz a nahrát tam svůj pozměněný kód, k jeho nainstalování na routery to nestačí.

Tento způsob stahování a ověřování aktualizací využívají nejen balíčky software, ale i firewall, který si obdobným způsobem stahuje aktualizace pravidel (opět, přes HTTPS a podepsané klíčem na jiném stroji).

DNSSEC

Věc, která by již měla být samozřejmostí, ale bohužel není, je ověřování záznamů v DNS pomocí DNSSEC. Rekurzivní resolver Unbound, který na routeru běží, tyto podpisy kontroluje a zabraňuje tak útoku pomocí podvržení DNS odpovědi.

Pro většinu uživatelů tato kontrola funguje naprosto transparentně, což je u zabezpečení ideální stav. Trochu nepříjemné je, že někteří poskytovatelé internetového připojení (ISP) nám to kazí tím, že mají stále ještě s DNSSEC problémy a jejich resolvery neumí podepsané odpovědi správně předat dál klientovi. Co je horší, najdou se i takoví, kteří nejenže „osekávají“ DNS zprávy s DNSSEC podpisy, ale ještě blokují provoz na portu 53 (DNS), který směřuje jinam, než na jejich resolvery. Tím brání i možnosti, že bude router Turris dělat veškerý DNS resolving sám, bez pomoci resolveru ISP. Chudák uživatel je pak v situaci, kdy mu DNS nefunguje a nemá cesty, jak situaci vyřešit.

Problém s časem

Kdo dnes nemá problém s časem. V oblasti elektronických podpisů však nejde ani tak o jeho nedostatek, jako o nutnost jej znát. Certifikáty mají omezenou časovou platnost a to nejen do budoucnosti, ale i do minulosti. Tím pádem je nezbytné, aby stroj, který kontroluje elektronické podpisy, znal přesný čas nebo alespoň datum.

Tento problém je společný jak pro kontrolu SSL certifikátů pro HTTPS a podepisování balíčků, tak pro podpisy v DNSSEC. Komplikovaný je navíc tím, že nejde jen o problém, že systém může po restartu čas zapomenout, ale může také zapomenout veškeré aktualizace, pokud dojde k obnovení továrního nastavení. S oběma těmito problémy jsme se museli vypořádat.

Problém synchronizace času se na Internetu standardně řeší použitím protokolu NTP, kdy počítač získá čas z k tomu určeného serveru. Tuto metodu používá samozřejmě i router Turris. Komplikací však je, že pro zjištění adresy NTP serveru potřebuje router DNS a pro ověření DNS odpovědi podepsané DNSSEC potřebuje víceméně přesný čas. Tím se dostáváme k problému slepice a vejce. V případě routeru Turris jsme jej vyřešili už na úrovni hardware přidáním hodin (RTC, Real Time Clock) s vlastním zdrojem napájení.

Problém s nutností udržovat seznam certifikátů aktuální i v případě uvedení do továrního nastavení jsme vyřešili s pomocí záložní paměti routeru. Ten totiž obsahuje dvě paměti, z nichž jedna obsahuje normální a druhá záchranný systém. V případě obnovení systému do továrního nastavení je první paměť smazána a nahrán obraz ze záchranného systému. Aby byly certifikáty i po takové operaci aktuální, jsou při jejich aktualizaci ukládány do vyhraženého oddílu právě v záložní paměti. Je to tedy jediná část záchranného systému, která se průběžně aktualizuje.

Kryptografický čip

Poslední vychytávka, kterou pravděpodobně nenajdete na jiném routeru, je čip ATSHA204 sloužící k autentikaci. Při výrobě routeru jsou do něj nahrány klíče, kterými router umí podepsat (pomocí HMAC-SHA-256) předloženou výzvu a tím se prokázat. Tento čip se používá k ověřování přihlášení a dat zaslaných routerem. Taktéž se pomocí něj generují registrační klíče, které slouží k ověření, že uživatel dostal správný router.

Na rozdíl od softwarového řešení čip samotné klíče nikdy nevydá, takže nejde zkopírovat. Je tedy zaručeno, že se žádný útočník nemůže vydávat za některého z našich uživatelů.

Ukradení klíčů z routeru možné není, avšak ze serveru to teoreticky možné je. Rozhodně to ale není nic snadného. Klíče má právo číst jen jeden program, který ověřuje hesla. Jiný program mu pošle výzvu a odpověď od klienta a on odpoví, jestli je to správně. Toto probíhá, samozřejmě, na serveru, který není přístupný z Internetu. Pokud by k ukradení klíčů přeci jen došlo, můžeme přejít na novou sadu, protože v každém ATSHA204 čipu je klíčů několik. Který klíč se použije, to se vybírá podle hodnoty získané z DNS záznamu. Ten je samozřejmě podepsaný DNSSEC a podpis se ověřuje. Na server by se tedy nahrála nová sada (v tuto chvíli uložená
v trezoru) a hodnota v DNS by se změnila.

Mimochodem, čip ATSHA204 se používá i pro získání dodatečné entropie pro generátor náhodných čísel, který je u normálních routerů po bootu notoricky špatný.

Závěr

V tomto článku jsem se pokusil stručně popsat, jak jsou zabezpečeny jednotlivé části routeru Turris a jeho komunikace s okolím. Snad tento text uspokojil ty čtenáře, kteří se na zabezpečení přenosu dat z routeru dotazovali, a zároveň i ukázal, že to s bezpečností myslíme opravdu vážně.