Červen v akademii patřil učitelům

Na třetí ročník kurzu Internetové technologie pro pedagogické pracovníky, jak už název napovídá, přijeli učitelé z nejrůznějších míst České republiky, kteří se na svých školách věnují výuce informatických předmětů. Cílem programu bylo představit technologie, pomocí kterých Internet funguje a s nimiž učitelé na většině středních škol studenty detailněji neseznamují – IPv6, DNS a DNSSEC, či to, co najdete na webu http://www.háčkyčárky.cz, tedy používání znaků národních abeced v doménách, tzv. IDN.

ITPPP_1

Ačkoliv se termíny musely přesouvat kvůli povodňové situaci, která by komplikovala dopravu účastníků na kurz, byly nakonec oba dva obsazeny více než z poloviny. Nebylo snadné vyvážit obsah tak, aby si na své přišli jak učitelé na gymnáziích, tak i učitelé na středních odborných školách, kde se předpokládá hlubší znalost technických témat. Přesto z hodnocení vyplývá, že ač nebyla témata pro všechny stejně zajímavá, splnila akce svůj cíl – představit vybrané internetové technologie těm pedagogům, kteří o nich doposud příliš nevěděli, nebo se chtěli dozvědět více. V závěru dne pak došlo na přiblížení projektů pro školy, jimž se věnují kolegové v našich laboratořích.

Dva kurzy máme již letos za sebou. Ještě jeden plánujeme na 26. září. Pokud víte o někom, komu byste tento kurz doporučili, určitě neváhejte; několik volných míst ještě zbývá. Rezervace je možná na e-mailové adrese akademie@nic.cz. Více informací o projektech pro školy se dozvíte na webu http://www.nic.cz/skoly.

Igor Kytka

Distribuovaná kybernetická bezpečnost

Na konferenci IT 13 jsme mimo jiné představili nový projekt zaměřený na vývoj bezpečného domácího routeru. Ten je součástí většího projektu zaměřeného na zlepšení bezpečnosti v českém síťovém prostředí a to pomocí aktivního monitoringu a analýzy síťového provozu. Zmíněný domácí router bude v rámci tohoto projektu plnit roli síťové sondy a zároveň aktivního prvku v ochraně koncových uživatelů.

V tomto krátkém článku si představíme především hlavní důvody vzniku tohoto projektu a jeho cíle.

Motivace

Každý, kdo provozuje nějaký veřejně dostupný server a podívá se občas do jeho logů, ví, že internet není klidné a bezpečné místo. I bez jakéhokoli zásahu uživatele se s počítačem připojeným k internetu neustále pokouší spojit různé cizí stroje a to málo kdy s dobrými úmysly (vizte např. výsledky z našeho honeypotu).

Vzhledem k tomu, že většina domácích sítí je připojená k síti svého poskytovatele přes jeden přístupový bod, kterým je domácí router, a často používá NAT, který schovává celou domácí síť za jedinou IP adresu, vedou první útoky v podstatě vždy právě na domácí router. Ten je tedy ideálním místem jak pro detekci pokusů o neoprávněný přístup do sítě, tak pro aktivní ochranu před nimi. Pokud by si navíc routery byly schopny mezi sebou informace o detekovaných útocích vyměňovat, mohlo by to vést ke zvýšení účinnosti ochrany jednotlivých strojů a zároveň detekci velkých útočníků.

Protože se v našem sdružení dlouhodobě věnujeme problematice internetové bezpečnosti, rozhodli jsme se vytvořit systém, který by s pomocí sítě domácích routerů dokázal monitorovat podezřelý síťový provoz a reagovat na zjištěné bezpečnostní hrozby úpravou pravidel pro přístup do sítě. Takto získané výsledky by pak byly k dispozici i pro ochranu dalších uživatelů Internetu.

Distribuovaný adaptivní firewall

Systém, který jsem nastínil v minulém odstavci, interně nazýváme „distribuovaný adaptivní firewall“ a je v této chvíli ve fázi aktivního vývoje. Součástí systému je klientská část, která po aktivaci na domácím routeru monitoruje nevyžádané pokusy o přístup do sítě zastavené firewallem a také provádí analýzu protékajících dat. V těch se pokouší odhalit anomálie, které by mohly být příznakem úspěšného útoku nebo již existující nákazy. Výsledky obou zmíněných částí klientského systému jsou nahrávány na druhou část systému, kterou je centrální server, kde jsou data dále zpracovávána a porovnávána s výsledky z ostatních sond.

Pokud je systémem některá část provozu vyhodnocena jako anomální a odborná obsluha systému vyhodnotí danou anomálii jako potenciální útok, připraví pro ni nové pravidlo pro firewall. To je potom formou aktualizace nahráno zpět na všechna zařízení zapojená do sběru dat.

Pro případy, kdy je třeba o dané anomálii získat doplňující informace, je součástí systému také nástroj na spouštění specializovaných „mikrosond“, které je možné formou modulů nahrávat na sledovaná zařízení. Ty pak umožní zaměřit analýzu na konkrétní typ provozu a získat detailnější data o daném jevu.

Výsledkem výše popsaných opatření je systém, v rámci kterého budou moci uživatelé chránit své sítě i sítě ostatních účastníků před vnějšími útoky a který se bude postupně „učit“ reagovat na nové hrozby. Navíc bude možné takto získaná data použít i pro ochranu další uživatelů Internetu, kteří nejsou do projektu přímo zapojeni, a také pro další analýzy získaných informací.

Závěr

V tomto článku jsme si představili nový projekt sdružení CZ.NIC zaměřený na distribuovanou kybernetickou bezpečnost. V blízké budoucnosti si v samostatném příspěvku ukážeme hlavního aktéra tohoto projektu, kterým je otevřený domácí router vyvíjený pod interním označením „CZ.NIC router“.

Bedřich Košata

Response rate limiting pod drobnohledem

O RRL již krátce psal Ondřej Surý v článku Ochrana obětí před DNS amplification útoky, tak tedy jen v rychlosti oč se jedná. RRL je jedna z metod, jak se poprat s amplifikačními útoky na DNS, která shlukuje podobné odpovědi do tříd a následně omezuje rychlost toku odpovědí v pro danou třídu. Jedná se v podstatě o opak filtrování dotazů na firewallu a výhodou je právě třeba identifikace různých dotazů vedoucí na podobnou odpověď, typicky na neexistující jméno. RRL v současné chvíli implementuje BIND9/10, NSD od verze 3.2.15 a Knot DNS od verze 1.2.0-rc3.

Vzhledem k tomu, že v současné chvíli není tento mechanismus nijak standardizován, každá implementace se chová mírně odlišně. Podívejme se trochu blíže na tři nejzajímavější rozdíly a to, jaký vliv mají na chování serveru pod útokem.

Základní časovou jednotkou pro měření rychlosti toku je vteřina, pro kterou do každé třídy přibyde počet tokenů odpovídající povolené rychlosti. S každou odpovědí se pak token odebírá, a pokud už jsme vše vyčerpali, odpověď zahazujeme. BIND9 k tomu navíc zavádí ještě jedno „makro okno“, které průměruje rychlost toku pro několik následujících vteřin. Zásadním rozdílem je, že v rámci tohoto okna se může počet dostupných tokenů snížit do záporných hodnot, a tím vyčerpat kapacitu pro celý zbytek okna. Jestli je například okno dlouhé 5 vteřin, limit je 10 odpovědí za vteřinu a v první vteřině přijde 50 podobných dotazů, tak následující 4 vteřiny nebude podobné dotazy zodpovídat. Knot DNS ani NSD takový koncept nemají, dá se tedy říct že délka časového okna je 1s. Důvodem je větší férovost odezvy, každá vteřina začíná s čistým štítem, avšak za cenu menší agresivity potlačení nárazových toků.

Co ale dělat v případě, že přijde legitimní dotaz v době, kdy byl vyčerpán počet tokenů? Úplně jej zahodit? Takový dotaz jen velmi těžko rozlišíme od útoku, ale přesto bychom měli dát legitimnímu tazateli možnost získat odpověď a ne jej úplně odstřihnout. Místo toho, aby tedy server dotaz zcela ignoroval, tak odešle prázdnou odpověď s nastaveným TrunCated bitem v hlavičce. Tazatel je pak nucen opakovat dotaz po TCP, na který už dostane odpověď. Takovému mechanismu se říká SLIP (podporují ho všechny implementace). Knot DNS se odlišuje tím, že má počítadlo pro každé vlákno zvlášť, a pro menší rychlost toku není tak přesný. Během testování se ale nepřesnost nijak zvlášť neprojevila a největší vliv má konzervativní výchozí nastavení.

dknight_rrl_measurement
(Zdroj: Comparison of RRL behaviour in BIND9, Knot DNS, and NSD, Dave Knight, DNS-OARC Spring 2013)

Třetí zásadní odlišností je způsob klasifikace odpovědí. Technické memo a BIND9 klasifikují odpověď pomocí:

  • Zdrojové adresy (podsítě)
  • Dotazovaného jména (nebo zóny v případě chyb, nadřazeného jména pokud je odpověď pokrytá wildcardem)
  • Návratové hodnoty (RCODE)

NSD navíc rozlišuje několik podtříd dotazu, např. pokud je dotaz na typ ANY, Knot DNS dotazy navíc ještě klasifikuje podle velikosti. Všechny současné implementace jsou založené na hash tabulkách. Liší se ale výrazně v tom, jakým způsobem řeší kolize. Implementace v BIND9 je založená na přeplňování tabulek, přičemž kolidující klíče se řetězí za sebe (do omezeného počtu). A právě o kolizích probíhala na mailinglistu RRL dost živá diskuze. Abych to vysvětlil, řetězení dobře řeší kolize pokud je zdrojová podsíť různá, ale pořád zůstává možnost kolize hashe dotazovaného jména, které se neukládá celé. Nově ale zavádí potenciální problém, a to že útočníkovi do určité míry možnost kontrolovat množství alokované paměti pro tabulku a ztrácí výkon na procházení zřetězených hodnot.

NSD používá tabulku pevné velikosti, bez řetězení. Netrpí tedy na výše popsané problémy, ale s větší pravděpodobností umožňuje útočníkovi předem spočítat kolidující odpovědi (Birthday attack) v závislosti na velikosti tabulky. Protože není kolize kam řetězit, tak pro danou třídu resetuje počet tokenů, což sice na jednu stranu vylučuje riziko omezení kolidujících odpovědí, ale umožňuje při nalezení dvou kolidujících dotazů rate limiting zcela obejít.

Knot DNS využívá hopscotch hashing, který je velmi dobrým kompromisem s nízkou pravděpodobností kolize (1/32!) při zachování pevné velikosti. Zároveň do klíče přidává náhodně generované tajemství pro znesnadnění predikce kolizí a umožní jen jeden reset počítadla třídy za vteřinu.

rrl_effective

Ze zatím dostupných měření na reálných datech vyplývá, že chování všech implementací je i přes popsané rozdíly velmi podobné a liší se především citlivostí u pomalého toku dotazů. Hlavním omezením metody založené na rate limitingu je především nemožnost rozlišit právoplatný dotaz od útoku, což ale při rozumné spolehlivosti není ani prakticky možné. Příliš agresivní omezení by tak mohlo vést k přílišnému zahazování právoplatných dotazů, konzervativní zase k nižší účinnosti. BIND9 doporučuje agresivnější nastavení, Knot DNS je spolu s NSD spíše na konzervativní straně (RRL ve výchozím nastavení vypnuté, v dokumentaci 50 r/s).

Marek Vavruša

mojeID se začíná zabydlovat v městech a obcích

Dlouhou dobu bylo mojeID využíváno zejména elektronickými obchody a zpravodajskými portály a jejich návštěvníky. V loňském roce se tuto skupinu podařilo rozšířit o komunitní servery a knihovny. Další skupinou provozovatelů, jimž může mojeID hodně přinést, je více než 6 000 měst a obcí, z nichž drtivá většina má svoje webové stránky a chce (především se svými občany) komunikovat rovněž elektronicky. Přesto, že využití mojeID není v některých případech z legislativních důvodů možné, objevily se v samosprávě již první vlaštovky, v jejichž webech mojeID zahnízdilo.

Zkušenosti s anonymními anketami a podezřelým „nárůstem hlasů“ již zaznamenala vybraná města. V loňském roce se jednalo například o výběr nové podoby Elsnicova náměstí na Praze 8, v letošním zase o pojmenování Havlovy ulice v Brně.

Také na základě těchto zkušeností se společnost Galileo Corporation rozhodla své více než tisícovce zákazníků z řad měst a obcí nabídnout ankety, do kterých mohou hlasovat pouze uživatelé mojeID a tím se vyhnout problémům s podvodným hlasováním pomocí robotů či díky mazání tzv. cookies. Jako první zprovoznila důvěryhodnou anketu obec Droužkovice, ke které se nedávno přidal Rožmitál pod Třemšínem. Jeho zastupitelé se rozhodli návštěvníkům webu položit zajímavou otázku, a to který zastupitel je nejprospěšnější :).

mojeID_Drouzkovice

Výhodou anket za použití mojeID je především možnost snadno odlišit ty, kteří mají v daném městě (či obci) trvalé bydliště. Z pohledu ochrany osobních údajů je klíčové, že při hlasování nedochází k předávání atributu jméno a příjmení, resp. adresa, ale pouze atributu města, případně věku. Anketa tak zůstává nadále neadresná, ale přesto díky atributu z mojeID umí rozlišit v anonymním prostředí internetu hlasující z daného města.

Třetí vlaštovkou, která začala používat mojeID, jsou Hořice v Podkrkonoší. Tamní zastupitelé se rozhodli, podobně jako některé české zpravodajské servery, skoncovat s anonymními a často urážlivými komentáři v diskuzích a vkládání názorů pod jednotlivé články umožnili jen těm, kteří se přihlásí přes mojeID a zveřejní své jméno, příjmení a e-mail.

mojeID_RpT

Byť Droužkovice, Rožmitál pod Třemšínem či Hořice v Podkrkonoší jsou vlaštovkami, které jaro zatím nedělají, v CZ.NICu věříme, že se mojeID postupně mezi městy a obcemi zabydlí a příští rok na jaře těchto vlaštovek bude už několik stovek. A to je již pořádné hejno, které může ukázat cestu k elektronické demokracii v českých luzích a hájích.

Jiří Průša

Nová podoba Katalogu routerů

Loni spuštěný projekt Katalog routerů, mapující podporu IPv6 u aktuálně prodávaných routerů, se letos dočkal aktualizace. Kromě nové várky testovaných modelů nastaly změny i v samotném pojetí stránek – rozhodli jsme se zaměřit na běžnějšího uživatele a koncipovat stránky tak, aby dokázaly posloužit jako rádce pro nákup domácího zařízení. Tedy strohé přehledy parametrů doplňují slovní hodnotící komentáře a modely jsou ohodnoceny informativním skóre, které umožňuje řazení modelů podle pořadí do kategorií Výhodná koupě, Špičkové routery a IPv6 za dobrou cenu.

V naší laboratoři máme k testování připraveno téměř 30 modelů, od miniaturních zařízení s jedním ethernetovým portem až po luxusní routery s integrovaným pevným diskem. Testováním zatím prošla jen část z nich, další recenze budou publikovány průběžně, jak se je podaří dokončit. Oproti předchozímu kolu testujeme veškerá zařízení s ethernetovým WAN portem, takže už není nutná deklarovaná podpora IPv6. Zůstává zaměření na domácí routery, neboť tam vidíme největší potenciál v zavádění IPv6.

Katalog_routeru

Novinkou v metodice testování jsou testy rychlostí routingu jak pro IPv4, tak i IPv6, rychlost downloadu a uploadu pomocí FTP, sdílení ve Windows (samba) a případně stahování z webového rozhraní.

Na rozdíl od dosavadní praxe hromadného testování velkého množství zařízení budou nové modely do Katalogu přibývat postupně, tak jak je budou distributoři uvádět na náš trh.

Jako marketingovou podporu projektu se chystáme nabídnout distributorům možnost opatřovat zařízení, která projdou testováním a splní uspokojivě daná kritéria, speciální pečetí.

Martin Sojka

Náš IPv6 den se blíží, tentokrát i s netradiční nabídkou

Zítra je 6. 6.! Přesně před rokem jsme v tento den pořádali konferenci ke Světovému dni IPv6 (IPv6 Day), od něhož řada renomovaných společností začala trvale využívat IPv6. Cílem akce bylo upozornit na blížící se konec protokolu IPv4, připomenout si důležitost přechodu na IPv6 a ukázat, jak jsme na tom v České republice s jeho zaváděním . Záznamy jednotlivých vystoupení včetně zajímavé panelové diskuse, v níž se představili zástupci firem Telefónica, T-Mobile nebo UPC najdete na stránkách naší konference. Tolik historie. Pojďme do současnosti.

Letos IPv6 den na mezinárodní úrovni nebude. Není asi také třeba, vždyť ti, kteří za touto zajímavou a účinnou akcí stáli, mají prakticky splněno. My jsme ale co se osvěty v oblasti IPv6 týká vytrvalí, což snad potvrdila i nedávná konferenci Internet a Technologie (13), kde téma přechodu a zhodnocení stavu (po roce) bylo opět jedno z hlavních témat. Na zítřek tedy něco k IPv6 chystáme, to hlavní si necháme až na 6. 6. Dnes prozradíme jen něco na úvod.

Součástí vzdělávacího centra Akademie CZ.NIC je také kurz o IPv6, který patří k jednomu z nejnavštěvovanějších. Proto jsme na zítřek, kdy se mimochodem jeden jeho běh koná, připravili speciální akci. Kdo se v průběhu čtvrtka (6. 6.) zaregistruje na libovolný kurz z nabídky Akademie CZ.NIC, dostane při příchodu populární a jedinečnou knihu IPv6 od „IPv6 guru“ Pavla Satrapy zdarma a navíc s autorovým podpisem.

Pavel_Satrapa_IPv6

Co tomu říkáte? Přihlásit samozřejmě můžete nejen sebe, ale i některého z kolegů, přátel, známých, rodinných příslušníků :). Děkujeme za váš zájem o toto téma. Budeme se mu věnovat i nadále a nejdříve už zítra – 6. 6.

Igor Kytka