Posledních pár měsíců jsme byli svědky DNS útoků, které k amplifikaci používaly ANY dotazy na autoritativní servery s dostatečnou kapacitou. Jako reakce na tento druh útoků přišla DNS komunita s technikou Response Rate Limiting, takže kromě rate-limiting pravidel ve firewallu můžete dnes najít podporu RRL ve všech důležitých autoritativních serverech: BIND 9 (ve formě patche), NSD (od verze 3.2.15) a Knot DNS (od verze 1.2.0-rc3). Knot DNS navíc od verze 1.1.0 podporuje blokování dotazů na ANY; v případě, že DNS server dostane DNS dotaz na typ ANY, vrátí se pouze malá odpověď s nastaveným truncate (TC) bitem, která resolveru říká, že se má zeptat znovu přes TCP. Velcí operátoři DNS serverů tedy zareagovali poměrně rychle a nasadili buď novější nebo opatchované verze DNS serverů, nebo případně pravidla ve firewallech.
Dnes se zdá, že sezóna útoků založených na ANY dotazech je za námi a útočníci se v případě masivního DDoS útoku na Spamhaus vrátili k osvědčené technice zneužívání otevřených resolverů a TXT záznamů.
Důležité je zdůraznit, že jediná spolehlivá ochrana proti těmto útokům je buď omezení přístupu na otevřené resolvery pouze ze sítě, kde mají být dostupné, nebo v případě, že je takový resolver otevřený cíleně, tak přísný rate-limiting, který neomezí legitimní uživatele, ale útočníkům znemožní využívat DNS amplifikaci ve velké míře. Osobně se ovšem domnívám, že případů, kdy je otevřený resolver opravdu zapotřebí, by se dalo napočítat na prstech jedné ruky.
Pokud se budeme bavit o ochraně na trochu vyšší úrovni, tak finálním cílem bude donutit (nejlépe všechny) operátory k ingress filteringu (tedy BCP38), který by zabránil možnosti masově podvrhávat zdrojové IP adresy. Zde by byla zapotřebí spolupráce všech operátorů, aby při uzavírání smluv se zákazníky toto filtrování vyžadovali a vynucovali. Bude to ze začátku bolestivé, ale domnívám se, že se pomalu blížíme do situace, kdy liberální přístup nepomáhá vůbec nikomu kromě útočníků.
A protože lov na všechny otevřené resolvery, což si například klade za cíl Open DNS Resolver Project, je běh na dlouhou trať (skeptik by dodal, že je to spíše boj s větrnými mlýny), tak si pojďme rychle ukázat, jak se dá pomoci obětem DNS DDoS útoků pokud máte v síti otevřené resolvery zapojené do útoku.
Samozřejmě nejjednodušší řešení je na odchozím firewallu nastavit blokování veškerého UDP provozu na IP adresy cíle. Ale to bychom tak říkajíc s vaničkou vylili i dítě a zaDoSovali cílový server ještě lépe než útočník, protože na postižené DNS servery občas také chodí legitimní dotazy, které je zapotřebí zodpovědět.
Pro blokování pouze takových DNS zpráv, které jsou součástí útoku, se dá využít jednoduchý příznak dotazy (QUERY) v hlavičce DNS zprávy. Legitimní DNS zprávy od klientů, které opravdu zajímá odpověď a nejsou jen součástí útoku, budou mít tento příznak nastavený na 0. Odražené DNS zprávy budou mít tento příznak nastavený na 1, což znamená odpověď. Na firewallu pak můžeme jednoduše spárovat cílovou IP adresu s tímto příznakem v DNS zprávě (v iptables například pomocí modulu u32), a odražené DNS zprávy blokovat.
Pomocí iptables bude tedy konfigurace na firewallu vypadat nějak takto:
iptables -A FORWARD -s <vase_sit/maska> -d <victim_ip>
-p udp --sport 53 \! -f
-m u32 --u32 "0>>22&0x3C@8>>15&0x01=1" -j LOGDROP
Toto pravidlo loguje a blokuje (v případě, že máte nadefinovaný chain LOGDROP) všechny UDP odpovědi na portu 53 (-p udp --dport 53), které nejsou fragmentované (\! -f) a na nejvyšší pozici dvou bajtu DNS hlavičky je nastavená 1. (Mimochodem se zdá, že v příkladu z manuálu netfilteru, který jsem použil je chyba, a autora příkladu zmátlo to, že DNS dotaz je specifikován bitem QR=0.)
Pokud jste si jistí, že síť, kterou firewallujete nemá obsahovat žádné DNS servery, které by měly dávat odpovědi ven, tak můžete vyhodit část pravidlo s ‚-d
V případě jiných firewallů je zapotřebí se začíst do dokumentace, v komentářích pak uvítám, pokud se podělíte s tím, jak dosáhnout podobné kontroly v BSD ipf, na Ciscu nebo Juniperu.
Ondřej Surý
Zpomalování Internetu?
V souvislosti s nedávnými DDoS útoky proti službě SpamHaus.org otisklo mnoho médií názor, že tento útok je natolik masivní, že údajně dochází ke zpomalování Internetu. To je trochu silné vyjádření, které patrně pochází z blogpostu šéfa CloudFlare Matthew Prince. Pojďme se tedy na tuto věc podívat blíže.
Intenzita útoku byla skutečně mimořádně velká, hovoří se o cca 300Gbps provozu generovaného pomocí DNS amplification útoku. To skutečně není málo, a nesnese to samozřejmě vůbec srovnání s útoky, které se nedávno udály u nás. Ale je to dost na zpomalení Internetu? Odpovědí může být například pohled na tuto tabulku, která ukazuje kolik běžně proudí největšími peeringovými uzly. Když sečtete špičkové toky alespoň dvaceti největších z nich (mezi které mimochodem patří i Český NIX.CZ), dostanete se bohatě nad 10000Gbps (=10Tbps). A to pochopitelně zdaleka nereprezentuje veškeré toky Internetu. Jinými slovy, navýšení celkového toku Internetu bylo sotva v řádu pár procent. Uvědomme si, že nějaké globálně sledované události, jako třeba olympiády, v poslední době vygenerují toků mnohem více. Mohlo tedy dojít k významnému vlivu na rychlost globálního Internetu? Rozhodně ne!
Samozřejmě, mohlo dojít ke zpomalení Internetu lokálně, sám Prince ve svém článku výslovně uvádí, že někteří Britští zákazníci jejich společnosti měli potíže. To je poměrně logické, ale ostatní sítě nijak poškozeny nebyly. Prince ještě ukazuje graf, který má navodit dojem, že došlo k nějakým výpadkům v londýnském peeringovém centru LINX, ale pravdou je, že nikdo žádné problémy nedetekoval, že šlo spíše o problémy systému, který tyto grafy kreslí.
Mimochodem, povšimněte si, že toky samotného LINXu jsou v normálu hodně velké a 300Gbps navíc by jejich infrastruktura měla rozhodně ustát.
Tedy, ke zpomalení Internetu nedošlo, žádná velká senzace se nekoná. Prostě jsme jen byli svědky většího DDoSu. No a v dalším článku si povíme, jak by se těmto útokům mělo předcházet.
Ondřej Filip
Zajímavosti z průzkumu mezi českými uživateli internetu
Agentura Markent připravila před časem pro CZ.NIC průzkum, který byl věnovaný především zavedení znaků národních abeced do domény .CZ. Dokument však není jen o tomto tématu, zájemci v něm najdou řadu dalších statistik a informací. Výběr z nich najdete v tomto blogpostu.
Jedna z otázek určená respondentům se týkala povědomí o doménách prvního řádu. Jistě není překvapením, že za .CZ skončila .com, kterou uvedlo 89 % dotázaných, následovaná .eu (69 %), .sk (67 %), .org (45 %) a .co.uk (23 %).
Jedním ze zkoumaných témat bylo také psaní diakritiky ve zprávách. Téměř polovina uživatelů internetu háčky a čárky při psaní e-mailů nepoužívá. Převažují mezi nimi lidé mladší 20 let a obyvatelé měst s více než 100 000 obyvateli.
Vzhledem ke zpřístupňování internetu všem vrstvám a skupinám obyvatel v posledních letech není překvapivé, že 93 % respondentů uvedlo, že vlastní e-mailovou schránku. Následují graf zachycuje rozdělení mezi freemailovými a pracovními nebo školními e-mailovými schránkami a jejich průnik.
Další skupina dotazů se týkala provozu vlastního webu a provozování e-mailu na vlastní doméně. Zatímco vlastní WWW stránky provozují 2 procenta dotázaných, e-mail na vlastní doméně provozuje pouze několik respondentů. Nejčastěji využívanými webhostingy jsou Web zdarma, Forpsi, Banan.cz a Netstranky.cz. Mezi nejrozšířenějšími redakčními systémy patří PrestaShop, Joomla, web.dnes, Active24 nebo Bohemiasoft.
Více informací z průzkumu najdete na stránkách www.háčkyčárky.cz.
Vilém Sládek
Zprávy ze světa: MDM pomáhá s bezpečnostními incidenty na Slovensku
O aplikaci MDM jsme na tomto blogu již několikrát psali. Tentokrát se s vámi chci podělit o informace, které mě velmi potěšily. Před několika týdny jsem mluvil o MDM s kolegy z CSIRT.SK. Při tom jsem se dozvěděl, že u nich naše aplikace zaznamenala velký úspěch.
V polovině roku 2012 si kolegové ze Slovenska dali za úkol najít nástroj, který by jim zkrátil čas při vyhodnocování a následné správě incidentů, které obdrží od zahraničních partnerů. Trh s těmito nástroji je opravdu veliký a každému vyhovuje jiný model na správu incidentů. Mezi testovanými aplikacemi bylo i naše MDM, které kolegy zaujalo doslova na první pohled; sympatie si získalo i díky tomu, že je open source.
Slovenský bezpečnostní tým se rozhodl používat aplikaci MDM nejen pro zpracování informací o hrozbách v doméně .sk, ale také jako základní nástroj pro zpracovávání všech incidentů přijatých tímto národním CSIRT týmem. Proto změnili původní zpracování a zobrazení incidentů v samotné aplikaci a rozšířili také možnost administrovat jak incidenty s URL, tak i bez URL, například na základě IP adresy.
První testovací verze MDM byla na Slovensku nasazena od 24. září loňského roku do konce prosince. V tomto období zkoumali v CSIRT.SK funkčnost a přijímali připomínky a návrhy na zlepšení tohoto softwaru. Od 1. ledna mají naši aplikaci již pevně pod kontrolou. Aktuálně se jedná o verzi 2.0. a počet incidentů, které touto aplikací spravují, převýšil 27 tisíc.
Rádi bychom tedy našim slovenským „bratrům“ (jmenovitě kolegovi Martinu Jurčíkovi) poděkovali nejen za poskytnuté informace k tomuto článku, ale také za spolupráci. A samozřejmě také přejeme jen samá pozitiva a sociální jistoty :-) při používání naší aplikace.
Michal Prokop
DNSSEC validace na Google Public DNS. Jak to vlastně je?
Když před dvěma dny Google ohlásil, že na svém veřejném DNS podporuje DNSSEC validaci, tak mnohá srdce zaplesala. O to pak bylo větší zklamání, když se ukázalo, že tato služba v současné době validuje pouze na vyžádání. DNSSEC validace na vyžádání pak v podání Google Public DNS validuje DNSSEC pouze v případě, že byl dotaz zaslán s příznakem DO (DNSSEC OK) nebo AD (Authenticated Data).
Co to tedy přesně znamená, a proč je to vlastně jeden velký test?
První důvod je velmi jednoduchý. Takové chování je v rozporu se standardem RFC, které definuje chování validujícího resolveru (RFC 4033). Dle DNSSEC standardu tedy nelze nazývat Google Public DNS jako validující resolvery. Možná si řeknete, že nějaké dodržování standardů není důležité, ale pak si zkuste vzpomenout, jak jsme dopadli s prohlížeči a HTML, a jak dlouho se z toho už dostáváme.
Druhý důvod je techničtější a poněkud více komplikovaný. Aby systém používající Google Public DNS mohl využívat všechny výhody validace, musel by stub resolver v systémové knihovně podporovat zasílání DNS dotazů s příznakem DO nebo AD. Přiznám se, že jsem žádný takový stub resolver ještě neviděl. Druhá varianta je pak instalace lokálního resolveru, který takové dotazy posílat již umí. Jenže pak už asi neexistuje žádný rozumný důvod, proč nedělat validaci přímo na tomto resolveru, protože tím dosáhnete výrazného zvýšení bezpečnosti DNS ve vaší síti.
Naštěstí to není tak černé, jak to vypadá. Google po počáteční smršti jednak aktualizoval FAQ a jednak Ben Laurie z Google ohlásil, že toto je pouze počáteční testovací fáze, po které bude následovat zapnutí DNSSEC validace pro všechny uživatele této služby.
Takže i přes počáteční nevoli dávám Google palec nahoru za odvážný krok správným směrem. A teď už jenom potichu, ale třeba i nahlas, doufejme, aby také udělali krok na druhé straně a postupně začali podepisovat své domény. V České republice nás to tolik netrápí, protože co se týče validace i podepisování patříme mezi špičku, ale oba dva budoucí kroky na straně Google mají hlavně na mezinárodní úrovni velkou šanci rozseknout vejco-slepičí problém, kdy nikdo nevaliduje, protože nikdo nepodepisuje, a nikdo nepodepisuje, protože nikdo nevaliduje.
Ondřej Surý
Vláda podpořila nezávislý internet i zavádění DNSSEC a IPv6
Na dnešním jednání vláda schválila rovněž strategii „Digitální Česko 2.0 – Cesta k digitální ekonomice“. Cílem tohoto dokumentu je aktualizovat původní verzi Digitálního Česka, která byla již v mnohých ohledech zastaralá, případně její cíle byly nastaveny jako nereálné. Pokud dnes necháme stranou naší pozornosti využití rádiového spektra, najdeme v dokumentu minimálně tři kapitoly, které se přímo či nepřímo týkají doménového světa.
Pro CZ.NIC i internetovou komunitu mezi nejdůležitější ustanovení patří nově vložená kapitola „Doménová jména“, která částečně reaguje na regulační snahy Evropské komise i celosvětový vývoj v oblasti internetu a snahu některých, zejm. mimo-evropských států, o kontrolu nad internetem. Nejen ve světle uplynulé Světové konference k mezinárodním telekomunikacím (WCIT 2012) nalezneme v Digitálním Česku 2.0 důležité prohlášení potvrzující v otázkách správy internetu upřednostnění samoregulačních principů před případnými legislativními opatřeními.
Další z nově přidaných kapitol se zaměřuje na podporu DNSSEC, který je autory strategie správě zasazen zejména do souvislosti s důvěrou uživatelů. V rámci podpory DNSSEC se Ministerstvo průmyslu a obchodu zavazuje předložit vládě ke schválení materiál zaměřený na podporu rozšíření technologie DNSSEC ve veřejné správě a při využívání jejích elektronických služeb. Podle průzkumu provedeného sdružením CZ.NIC na 250 doménách úřadů včetně měst a obcí využívá DNSSEC 28,8 % institucí veřejné správy méně, tj. přibližně o 10 % bodů méně než činí průměr v doméně .cz. Situace je tak zde zcela opačná, než u IPv6, kde stát, zejm. Ministerstvo průmyslu a obchodu, sehrálo při zavádění této technologie pozitivní roli. K rozšíření DNSSEC ze strany veřejné správy by měl přispět i připravovaný „Strategický rámec rozvoje veřejné správy a e-Governmentu 2014+“ z dílny Ministerstva vnitra, který počítá s podepsáním všech domén klíčových služeb eGovernmentu za pomoci DNSSEC do konce roku 2014 a všech elektronických služeb veřejné správy do konce roku 2015.
Při pohledu na legislativní nástroje, které má Ministerstvo průmyslu a obchodu, potažmo vláda k dispozici, se celkem logicky nabízí stejný postup jako v případě IPv6, tj. příprava a přijetí usnesení vlády. Někteří škarohlídové by možná mohli namítnout, že přijetí usnesení nemající žádné sankce je bezzubé, pokud však srovnáme Českou republiku a např. Slovensko (viz níže) i situace v celé doméně .cz, vidíme, jaký pozitivní vliv naše Usnesení vlády mělo a že ministerstva ostatní orgány státní správy podporují IPv6 na svých webových serverech přibližně 3x častěji než je celostátní průměr. Z tohoto důvodu si myslím, že je na místě říci Usnesení vlády jasné ANO a podpořit tak rozšíření DNSSEC i do státní správy.
Ve vztahu k IPv6 pak nelze nezmínit kapitolu, která v Digitálním Česku byla již na začátku, ale nyní došlo k její aktualizaci. Ministerstvo zde přiznává (jak můžeme vidět i z výše uvedené tabulky), že zatím neimplementovaly všechny orgány státní správy a slibuje aktivní prosazování povinností, které jednotlivým orgánům státní správy z Usnesení vyplývají. Ke kladům strategie lze přičíst i to, že Ministerstvo průmyslu a obchodu se nebálo věci pojmenovat pravými jmény a upozornit na stěžejní zajištění podpory IPv6 v rámci KIVS (Komunikační infrastruktury veřejné správy) včetně CMS (Centrální místo služeb).
Z dalších kapitol je jistě zajímavé si přečíst v Digitálním Česku 2.0 i tu zaměřenou na svobodu internetu či podporu legální nabídky digitální obsahu.
Jiří Průša
Komu klasická CAPTCHA až tak úplně nepomáhá
Kolega Petr Závodský vede v CZ.NIC tým testerů. Mimo to ale stojí za projektem Dobrý kód, který pomáhá handicapovaným lidem při práci s Internetem, konkrétně v případech, kdy narazí na Turingův test CAPTCHA; ne pro každého představuje tato součást celé řady webů snadno řešitelnou „překážku“. Jeho projekt je nejen prospěšný, ale také zajímavý a určitě si zaslouží minimálně trochu pozornosti. Rádi vám ho proto představíme formou rozhovoru s jeho autorem.
Co je Dobrý kód zač?
Na webových stránkách se čas od času každý z nás setká s obrázkovým CAPTCHA kódem. Ten, kdo vidí a nemá problém s pořadím znaků, prostě řetězec znaků opíše do formulářového okýnka a dál nic moc neřeší. Takový obrázkový CAPTCHA je však obrovskou překážku pro postižené, například zrakově. Když zrakově postižený narazí na takovou bariéru, dál se prostě bez cizí pomoci nepohne. Je pravda, že CAPTCHA se někdy opatřuje i zvukovým výstupem, to ale skýtá řadu neduhů. Jednak je zvukový CAPTCHA často špatně implementovaný, takže je postiženému prakticky k ničemu. Další problém hlasového výstupu představuje snížení zabezpečení. Tak se neimplementuje, protože snižuje úroveň zabezpečení toho obrázkového. A proto projekt Dobrý kód, kterým chci řešit nepřístupnost CAPTCHA. Dobry kód je také o lidské důstojnosti, kterou by jakékoliv zabezpečení nemělo snižovat nikomu z nás.
Pro koho je Tvůj projekt určený?
Dobry kód je primárně určen webovým uživatelům se specifickými potřebami a aktuálně nabízí dvě služby. U služby Screenshot uživatel zašle snímek obrazovky CAPTCHA Dobrému kódu a jako odpověď obdrží přečtený kód, s kterým může dál bez překážek zacházet. Druhá služba Encrypted CAPTCHA nabízí řešení zpřístupnění prakticky jakéhokoliv CAPTCHA. Aktuálně to je ale spíš na vývojářích, zda službu použijí a zpřístupní tak web i handicapovaným.
Jak jsi se k této aktivitě dostal a jak dlouho Tvůj projekt vzniká nebo vznikal?
Cesta k tomuto projektu byla dána konstelací několika okolností. Bratrovo postižení, můj zájem o aplikační bezpečnost, dřívější práce s různě handicapovanými, je toho více. Přibližně před dvanácti lety jsem pracoval na projektu o astronomickém vzdělávání zrakově postižených. Tehdy vzniklo několik konkrétních unikátních výstupů – hmatové planetárium, hmatové publikace s astronomickou tematikou, první hybridní publikace v Česku a další věci. Bavilo mě řešit různé technické překážky a těšilo mě, když výstupy byly k užitku. A tak teď to není o astronomickém vzdělávání zrakově postižených, ale o praktické pomoci tam, kde je více než potřeba.
Dobrý kód reálně začal vznikat přibližně před třemi měsíci. Původně jsem uvažoval jen o službě Encrypted CAPTCHA, později jsem připojil, po vzoru prolamování CAPTCHA armádami Indů, službu Screenshot.
V jaké je teď Dobrý kód fázi a kolik lidí na něm pracuje?
Aktuálně se s projektem seznamují první uživatelé. K dnešku službu Screenshot používá 29 uživatelů, bylo zpracováno něco přes 120 požadavků na opis CAPTCHA kódu, úspěšnost v použití služby je něco kolem 85 procent, 15 procent jde na vrub softwarových chyb a chybného uživatelského použití. V projektu jsou zapojeni tři lidé. Vývoj si vedu sám, dva lidé mi sporadicky pomáhají v rolích operátorů.
Co Dobrý kód v blízké nebo vzdálené budoucnosti čeká, jaké má ambice?
Teď je zapotřebí služby po softwarové stránce stabilizovat, opravit některé nedostatky, zakomponovat podněty od uživatelů, například zvýšit ochranu soukromí uživatelů deformací okolí CAPTCHA obrázku. Pak se budu věnovat šíření služeb mezi uživatele a rozšiřování funkcionalit. Služba Screenshot bude zpřístupněna prakticky komukoliv, operátorem bude moci být také kdokoliv. Služba bude samozřejmě propojena se sociálními sítěmi.
A na konec – co Tě vedlo k tomu, že jsi se do tohoto projektu pustil?
Jeden z hlavních důvodů jsem uvedl v předešlé odpovědi. Dalším může být to, že je obrázkový CAPTCHA pro mnohé více bariérou než ochranou, o čemž se možná až příliš hovoří, konferuje, ale neřeší se to. Posledním racionálním krokem ve zpřístupnění CAPTCHA bylo zavádění zvukového CAPTCHA. Zvukový CAPTCHA má však mnoho neduhů – často je nesrozumitelný, snižující úroveň zabezpečení toho obrazového CAPTCHA, někdy drahé pořízení. Zbytečná tlachání o tom, jak je problém neřešitelný, to byl asi velmi důležitý impuls.
Díky Petře za odpovědi. A pro vás, kteří by chtěli vědět více, je tu webová stránka projektu nebo kontakt na jeho realizátora.
Vilém Sládek
Zlatý erb přispěl k rozšíření „šestky“ a DNSSEC v českých městech a obcích
Spolu s posledním únorovým dnem skončilo rovněž krajské hodnocení webových stránek měst a obcí, které se přihlásily do již 15. ročníku soutěže Zlatý erb. Na začátku ledna jsme na našem blogu psali o novince, kterou je hodnocení podpory DNSSEC a IPv6. Za CZ.NIC jsem měl tu čest zasednout v porotě a podílet se na hodnocení jednotlivých webů. Do krajských kol soutěže o nejlepší web samosprávy se přihlásilo celkem 84 měst a 131 obcí. Nyní se pojďme podívat, jak si zúčastnění v podpoře IPv6 a DNSSEC vedli a kdo získal zvláštní cenu CZ.NIC.
Jak se hodnotilo
V rámci nové kategorie Zlatého erbu, pojmenované „Podpora IPv6 a DNSSEC“, mohli v uplynulých krajských kolech jednotliví soutěžící získat maximálně 5 bodů. Jeden bod byl přidělen těm, kteří měli svoji doménu podepsánu prostřednictvím DNSSEC, další čtyři body bylo možno obdržet za podporu IPv6, kdy se zvlášť posuzovala podpora u web serveru, name serverů a e-mailových serverů. Za podporu u každého typu serverů získali soutěžící po bodu, přičemž bylo důležité mít nejen AAAA záznam, ale i fungující služby, tedy například u WWW úspěšnou odpověď přes HTTP protokol. Pokud některý ze soutěžících pak podporoval IPv6 jak u webového serveru, name serverů i poštovního serveru, získal zvláštní, bonusový bod. Stejné hodnocení a jeho váha pak bude použita i v začínajícím celostátním kole.
Pro dokreslení celkového obrázku o hodnocení Zlatého erbu je třeba si uvědomit, že kritérium „Podpora IPv6 a DNSSEC“ představuje v krajských kolech, stejně jako v kole národním, pouze jedno z kritérií. Mezi ta další patří např. zveřejňování tzv. povinných informací, vedení elektronické úřední desky, ovládání webu či jeho přístupnost pro zdravotně postižené a další kriteria.
Kdo vyhrál?
Z celkem 215 webů, které se zúčastnily krajských kol Zlatého erbu, získalo plný počet bodů celkem „sedm statečných“, z toho překvapivě 5 obcí (Čížkov, Petrovice, Podomí, Vranov nad Dyjí a Vranovice), jedna pražská městská část (Praha 19) a jen jedno město (Úštěk). Zvláštní uznání si pak zaslouží dvě obce z Jihomoravského kraje a to Vranov nad Dyjí a Vranovice, které měly podporu IPv6 zapnutou vedle web serveru rovněž na všech name a mail serverech. V případě Vranova se jednalo o celkem 3 name servery a 2 mail servery, u Vranovic pak dokonce 4 name servery a 7 mail serverů.
Na druhou nejvyšší příčku (tj. 4 body) pak dosáhlo rovněž 7 zástupců a to obce Bělušice, Skršín, Podkopná Lhota, Pustina a městské části Praha Dolní Počernice, Satalice a Vinoř. Podpora IPv6 u nich byla vynikající, bohužel však chybělo podepsání domény přes DNSSEC. Ve třech případech bylo důvodem to, že jejich registrátor toto zabezpečení webových stránek zatím nenabízí, ve třech případech pak tím, že obce svého registrátora o zapnutí této služby nepožádaly. Jedna obec (Pustina) pak má svoje stránky umístěny na doméně .info, kde je podpora DNSSEC opět především správnou volbou registrátora.
Do celostátního kola soutěže o nejlepší web města a obce nyní postoupí vítězové jednotlivých krajských kol. Jména celkových vítězů se pak dozvíme 8. dubna 2013 na konferenci ISSS (Internet ve státní správě a samosprávě) v Hradci Králové. Vzhledem k tomu, že podpora DNSSEC a IPv6 bude hodnocena i v celostátním kole, mají města a obce ještě čas své hodnocení zlepšit. Zatím nulové hodnocení za DNSSEC získalo 77 měst a obcí, které mají své stránky umístěny na doméně .cz, přičemž 71 % z nich má svoji doménu u registrátora, který DNSSEC podporuje. Do začátku dubna je ještě poměrně dost času a zavedení podpory DNSSEC je často otázkou 5 minut. V závěrečném celorepublikovém finiši se počítá každý bod a byla by škoda o tento snadno získatelný přijít.
Jak jsou na tom ostatní města a obce?
Při pohledu na celkové výsledky je potěšující, že jak podpora IPv6, tak DNSSEC je u přihlášených soutěžících mnohem vyšší, než u ostatních měst v České republice, tak i než je celorepublikový průměr. Svoji doménu mělo přes DNSSEC podepsáno 53 % měst a obcí, IPv6 pak na svém webovém serveru podporovalo 54 % přihlášených. Ještě vyšší byla podpora u name serverů (60 %). Potěšitelná je ve srovnání s republikovým průměrem i podpora u mail serverů (18 %).
Jiří Průša
DDoS nebo DoS? Aneb jak se dá udělat útok
Odborná i všeobecná média chrlí v současné době velké množství článků na téma kybernetických útoků z minulého týdne. Téměř všechny články označují útok jako DDoS, mluví se o pronájmu botnetů a podobně. Minulý týden jsem já a především moji kolegové strávili analýzou celého problému a z dosud známých dat bych si dovolil jít proti tomuto mediálnímu proudu a představit jinou teorii opřenou o důkaz proveditelnosti. Dopředu podotýkám, že jde spíše o technickou nuanci, která nám patrně nijak zásadně nepomůže v pátrání po skutečnému útočníkovi.
Především musím uvést, že útok měl vlastně dvě různé fáze. V té první v začátku týdne šlo o klasický SYN Flood útok s podvrženou zdrojovou adresou. Tedy, že útočník či útočnici emitovali velmi rychle úvodní packety TCP komunikace (SYN), které směřovaly přímo na cíl. V druhé fázi emitovali útočníci SYN packety se zdrojovou adresou cíle, které směřovaly na některé české servery s kvalitním připojením. Tyto servery odpovídaly druhým packetem úvodní TCP sekvence neboli SYNACK a tím zahlcovaly cíl, působily tedy jako jakýsi reflektor.
Nicméně co zajímavé je, že téměř všichni napadení v první fázi nebo ti, kteří byli zneužiti jako reflektor v druhé fázi, se shodují v tom, že útoky přicházely víceméně z jednoho směru ze zahraničí a to silou o řádu set tisíců až miliónů packetů za vteřinu. Nejčastěji je skloňována ruská síť RETN, ale hovoří se i o jiných sítích. A to je právě to nečekané. Při klasickém DDoS útoku, který používá botnet, přicházejí packety z různých směrů a obvykle nejde žádný dominantní směr určit. Pokud by útočník využil takovýto botnet, jistě by měl největší zájem o zapojení uzlů právě z našeho území, které mají k cíli nejlepší spojení. Ale k tomu pravděpodobně (krom toho odrazu z druhé fáze) nedošlo. Netvrdím tedy, že nešlo o distribuovaný útok, ale rozhodně byla primární útočící síť (nebo alespoň její dominantní část) poměrně geograficky omezená. Spíše mě to tedy vede k myšlence, že jde spíše o DoS než DDoS. Opět je pochopitelně možné, že si onu infrastrukturu někdo pronajal na stejném principu jako botnet.
A pokud se někdo zamýšlíte nad tím, zdali je možné takový útok uskutečnit pouze z jednoho centra, tak vězte, že to není nic moc komplikovaného. V rámci našeho bezpečnostního týmu jsme postavili řešení, které je schopno vygenerovat tok o síle cca deseti miliónů packetu za vteřinu. Tedy více, než kolik bylo emitováno v proběhlých útocích. Packety generuje menší farma v podstatě běžných PC, takže náklady na pořízení takového generátoru jsou velmi nízké. Trochu náročnější je mít kvalitní přípojku do Internetu a dostatečně silný router. Tok takového útoku je totiž cca 5Gbps a to již přeci jenom každý doma nemá. V současné době toto řešení používáme pro testování vlastní infrastruktury a již se nám přihlásili první zájemci, kteří by si rádi otestovali jejich vlastní systémy.
Tedy útoky, kterých jsme byli v nedávné minulosti svědky, nemusely nutně pocházet ze zavirovaných počítačů nic netušících lidí, mohly klidně vycházet z jednoho centra, sami jsme si takové centrum během pár hodin dokázali postavit. Nicméně pochopitelně netvrdím, že to nemohla být nějaká geograficky omezená část botnetu. Každopádně bych se přimlouval, aby toto první písmenko bylo v té zkratce dDoS co nejmenší. :-)
Váš ONdŘEJ FILIP