Ochrana obětí před DNS amplification útoky

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 ‚ a budete tak blokovat všechny DNS odpovědi odcházející z vaší sítě.

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í.

linx_traffic

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

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

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

Honeynet: co se dělo v minulých měsících

Uběhly opět tři měsíce od doby, kdy jsme zveřejnili statistiku z našeho honeynetu. Kdo nezvaný tedy navštívil naše servery v nedávné době?

Tentokrát jsme útočníky seskupili podle jejich autonomních systémů, oproti původnímu přehledu jednotlivých adres. Důvodem je výskyt rovnoměrnějších útoků více strojů z jednoho AS, které by jinak obsadily většinu z prvních deseti míst v přehledu jednotlivců a tabulka by nebyla tak zajímavá. Nejčastěji se připojovaly adresy z AS3462 (Tchaj-wan) a šířily tuto verzi červa Conficker (konkrétně 19630 případů). Další místo patří ruskému AS8402, jehož stroje nás napadly jinou verzí (7472 případů). Soutěž jednotlivců by vyhrála IP adresa 212.56.215.250 z Moldavska, která se připojovala téměř stotisíckrát, což je více než dvojnásobek proti minulému období.

Nejčastější útočníci (srpen – říjen 2012)

Na mapě světa je Tchaj-wan jako hlavní zdroj útoků nenápadný. Z větších zemí lze vidět tradiční Rusko, pak Brazílii a Rumunsko. Menší množství útoků pocházelo také z Francie a Argentiny.

Zdroje útoků (srpen – říjen 2012)

Nejčastěji se útočníci připojovali na port 445 (SMB protokol), řádově méně pokusů bylo dále na porty 3306 (databáze MySQL), 1433 (Microsoft SQL Server), 80 (HTTP) a 5060 (SIP).

Cílové porty (srpen – říjen 2012), horizontální osa má logaritmickou škálu

Přehled zachyceného malware výrazně vedou zmiňované dvě varianty červa Conficker. Další místa jsou jen v řádech desítek případů a bez výjimky pouze jiné varianty stejného červa. Mimochodem pokud jste ISP a zajímají vás statistiky tohoto červa pro váš autonomní systém, můžete využít web Shadowserver.

Zachycený malware (srpen – říjen 2012)

Na závěr ještě přehled nejčastějších kombinací přihlašovacích údajů zkoušených na SSH službu: vede obligátní root/password, jediný nerootovský účet, který se do top 10 dostal, je Oracle.

Přihlašování na SSH (srpen – říjen 2012)

Jiří Machálek

P.S. Mimochodem, o projektu Honeynet bude také jedna z přednášek konference Internet a Technologie 12. Přijďte se podívat.

Kolik je v Evropě bezpečnostních týmů?

Bezpečnostní týmy typu CSIRT a CERT už nejsou žádnou neznámou. O aktivitách těch našich, tedy CSIRT.CZ a CZ.NIC-CSIRT se vás snažíme informovat jak na našem blogu, tak i na stránkách médií (naposledy vyšly dva texty ke cvičení Cyber Europe 2012 na serveru Root.cz – 1, 2).

Týmy z celé Evropy plní svoje povinnosti nejen v té konkrétní zemi, ale také, a to je velice důležité, spolupracují na mezinárodních bezpečnostních incidentech, a to v mnoha případech velice intenzivně. Velká část incidentů má totiž přesah do zahraničí a není výjimkou, když se na jedné události sejdou i tři nebo více bezpečnostních departmentů, každý z jiného státu.

Jednotlivé bezpečnostní týmy o sobě velice dobře vědí. Síť těchto oddělení je důkladně propracovaná a velký důraz je kladen na to, aby se jednotliví členové znali (nejlépe osobně) a aby spolupráce v případě incidentu fungovala. V důsledku přibývání nových bezpečnostních týmů nebo změn na poli působnosti (Constituency) současných týmů, se může zdát že tento organizmus není zrovna jednoduchý a přehledný. I proto se možná v organizaci ENISA rozhodli, že to změní a zveřejnili přehlednou mapu evropských CSIRT a CERT týmů. Ta nejen že ukazuje země, které mají své bezpečnostní týmy, ale zároveň také prezentuje přehled týmů v jednotlivých státech včetně kontaktních a dalších informací. Její další předností je například i to, že umožňuje zobrazit jednotlivá oddělení podle jejich charakteru. Právě tato funkce nám velice usnadňuje dohledání relevantních kontaktních údajů nejen na národní nebo vládní bezpečnostní týmy.

Dvě čísla na závěr. V Evropě v současnosti působí 195 bezpečnostních týmů z nichž pět je v České republice.

Michal Prokop

Honeypot: pokus o zvýšení privilegií

Nedávno jsem na našem honeypotu narazil na útočníka, který se nalogoval na neprivilegovaného uživatele a snažil se dostat na účet roota, aby měl kontrolu nad celým systémem. Neboli klasické privilege escalation. Jak konkrétně to vypadá? Pokud máte aktualizovaný systém, musí útočník přijít s exploitovanou zranitelností, která zatím není opravená, ideálně ani veřejně známá. V tomto případě si myslím, že by útočník využil tuto znalost pro cílený útok na server, kde lze očekávat nějaká zajímavá data nebo aspoň zářez na pažbě v podobě známého serveru. V našem případě spíš zkoušel náhodnou IP, kde běželo SSH a existoval uživatel se slabým heslem. Podle toho taky vypadala sada jeho nástrojů – samé veřejně dostupné exploity.

Útočník nejprve nasbíral základní informace o systému – zda je na systému sám (w), verzi jádra (uname -a), uživatelské účty (cat /etc/passwd) a jak dlouho je systém spuštěný (uptime). Následně změnil heslo uživatele, na kterého byl přihlášený a v jeho domovském adresáři vytvořil podadresář nazvaný „…“, kam stáhl potřebné nástroje. Postupně útočník zkoušel tyto:

  1. CVE-2009-2692: sock_sendpage() NULL Pointer Dereference Vulnerability (informace a exploitpopis)
  2. CVE-2010-4604: IBM Tivoli Storage Manager (TSM) Local Root (exploit)
  3. CVE-2010-0832: Ubuntu PAM MOTD local root (exploit)
  4. Geany 0.18 Local File Overwrite Exploit (exploit)
  5. CVE-2010-2961 : Ubuntu Linux mountall Privilege Escalation (popis a exploit)
  6. CVE-2010-3081: 64-bit Compatibility Mode Stack Pointer Underflow (exploitanalýza exploitu)
  7. CVE-2009-3001: AF_LLC getsockname 5-Byte Stack Disclosure (exploit)
  8. Linux Kernel CAP_SYS_ADMIN to Root Exploit 2 (exploitanalýza exploitu)

Kromě exploitů chtěl útočník spustit i dva IRC klienty:

  1. perlb0t ver 0.5:  IRC bot, který umožňuje vzdáleně provádět TCP/UDP/HTTP flooding, scanovat porty, hledat a útočit na nezáplatované verze CMS Mambo/Joomla.
  2. IRC klient BitchX: Standardní IRC klient. Předpokládám, že když už se útočník nedostal na roota, chtěl alespoň použít napadený systém k řízení jiných botů, které napadl dříve.

Vhledem k tomu, že se jednalo o honeypot, tak útočník nakonec neuspěl. Po těchto pokusech tedy za sebou smazal stopy a odhlásil se. Tento příklad však ukazuje, jak jednoduché je takový útok provést i pro útočníka bez hlubších znalostí systému a jak důležité je udržovat systémy aktualizované.

Jiří Machálek

Únos domény google.ie! Může se to stát i u nás?

Minulý týden došlo k velmi závažnému bezpečnostnímu incidentu v doméně .ie, což je doména Irské republiky. Podle dostupných informací se útočníkovi pravděpodobně podařilo získat přihlašovací údaje jednoho registrátora, díky nimž pak mohl v centrálním registru domény .ie změnit DNS servery domén google.ie a yahoo.ie. To mu poté umožnilo nasměrovat domény na vlastní servery, kde mohl vystavit svůj vlastní  obsah či přijímat poštu pro tyto domény. Některé služby registru .ie domény jsou ještě v době psaní tohoto článku nedostupné a vyšetřování stále pokračuje. Nás samozřejmě nejvíc zajímá, zda by k podobné situaci  mohlo dojít i u nás. Pojďme si tedy připomenout možnosti, kterými mohou držitelé své domény chránit před případnými neautorizovanými změnami provedenými registrátorem a možná i připomeňme, jakým způsobem je chráněn samotný centrální registr před neautorizovaným přístupem.

Nejprve tedy zkusme vysvětlit, jakým způsobem je chráněn samotný přístup do registru domény .cz. Přístup k registru je možný pouze na základě platných přihlašovacích údajů, s platným certifikátem a z předem dohodnutých IP adres. Samotná znalost přihlašovacích údajů není tedy pro přístup dostatečná. Útočník by musel proniknout na server registrátora, který má do registru povolený přístup z konkrétní IP adresy, má k dipozici platný certifikát a přihlašovací údaje. Z tohoto serveru by pak bylo možné změnu záznamů uskutečnit. V současné chvíli nemáme k dispozici informace o způsobu zabezpečení irského registru. Není tedy možné vyloučit, že irský registr má stejné zabezpečení jako ten český a že se skutečně podařilo útočníkovi proniknout na server registrátora a z něj změny uskutečnit.

I pro tento případ nabízí centrální registr domén .cz držitelům domén další stupeň zabezpečení. Na našich stránkách je možné pomocí jednoduchého formuláře požádat o zablokování transferu domény nebo dokonce zablokování provedení jakékoliv změny na objektech v doméně. V případě, kdy držitel na doméně zablokuje veškeré změny, nemůže k takovému problému, jaký nastal v doméně .ie, vůbec dojít. Na rozdíl od žádosti o heslo nelze odblokování a zablokování domény uskutečnit s pomocí registrátora. Pokud chce držitel zablokovat nebo odblokovat svou doménu, musí se obrátit přímo na naše sdružení.

Jak je vidět z příkladu incidentu v registru .ie, bylo zavedení této nadstandardní možnosti pro naši národní doménu velmi užitečným krokem. Jeho využití lze proto držitelům důležitých domén rozhodně doporučit.

Pavel Bašta

Těžko na cvičišti, lehko na bojišti

Minulý týden jsme na serveru Root.cz publikovali dva články (1, 2) o celoevropském cvičení bezpečnostních týmů CSIRT/CERT. Články vzbudily poměrně živou diskuzi, která se věnovala především smysluplnosti konání takovýchto akcí.

Přesně týden po tomto cvičení došlo k phishingovému útoku na uživatele jedné z našich největších bank – ČSOB. Její zástupci nás okamžitě po vypuknutí incidentu kontaktovali s žádostí o pomoc při řešení jejich problému, a to především kvůli skutečnosti, že phisingové e-mailové zprávy byly rozeslány z nejrůznějších IP adres z celého světa. V každé zprávě byl navíc odkaz na podvodnou stránku sbírající data od uživatelů. Ani v tomto případě se nejednalo o jednu doménu či IP adresu, ale šlo o desítky zneužitých počítačů v podstatě po celém světě. Útok byl zjevně pečlivě připraven a promyšlen, některé z phishingových zpráv měly i podvržené hlavičky.

I podle tohoto faktu se jednalo o poměrně propracovaný útok, s kterým se nesetkáváme každý den. Také z tohoto pohledu jeden ocení, když se na takovéto situace může připravit. Ale kde a jak? Shodou okolností jsme se týden před spuštěním uvedeného útoku zúčastnili cvičení evropských CSIRT týmů, které testovalo vzájemnou komunikaci a spolupráci mezi bezpečnostními specialisty. Že nám tato příprava bude rychle k užitku, to tenkrát netušil nikdo z nás.

Po vyhodnocení celé situace jsme se rozhodli kontaktovat jak držitele IP adres, na kterých byly umístěny phishingové stránky, tak také držitele IP adres zneužitých k rozesílání phishingových e-mailů. Během této akce se nám velmi osvědčilo využít spolupráci s CSIRT týmy (pochopitelně tam, kde nějaké existují). Velmi nám také pomohlo, že jsme podobnou situaci, vyžadující mezinárodní spolupráci měli možnost nedávno absolvovat nanečisto. Díky tomu se velké množství nebezpečných phishingových stránek podařilo odstranit během několika hodin po oznámení útoku. Mimochodem, asi nejvzdálenější tým, který jsme během této akce požádali o spolupráci byl Panamský národní CSIRT tým.

Z této akce plyne několik zajímavých závěrů, které jsou zároveň odpovědí na kritické příspěvky pod našimi články:

1) podobná cvičení jako bylo to z předminulého týdne smysl mají, stejně jako má smysl, aby svou schopnost koordinace cvičili například jednotlivé složky záchranných sborů

2) není pravdou, že by CSIRT týmy byly něčím, co je záležitostí čistě evropskou, jak se někteří snažili pod články naznačovat, naopak, tento druh bezpečnostních týmů se začíná objevovat po celém světě a umožňuje rychlou mezinárodní reakci na vzniklé incidenty

3) určitě se nejedná o nepotřebnou záležitost, ostatně věřím, že v době, kdy se začaly objevovat první hasičské záchranné sbory, se také našli jednotlivci, kteří argumentovali tím, že doteď se přece podávaly kýble s vodou a nějak to fungovalo, tak proč to tak nedělat i nadále.

Pavel Bašta

Hodí Evropská komise VeriSign a další přes palubu?

Na začátku června Evropská komise s více než půlročním zpožděním představila návrh nové legislativy zaměřené na elektronickou identifikaci, autentizaci a elektronické transakce. Přesto, že hlavním cílem návrhu je sjednocení pravidel pro elektronický podpis a nahrazení, resp. novelizace Směrnice č. 1999/93/ES o zásadách pro elektronické podpisy, se zdá, že předkládaný návrh jde mnohem dál a postihuje nejen certifikáty pro elektronický podpis, ale rovněž certifikáty, které jsou využívány pro zajištění důvěryhodnosti webových stránek a zabezpečení komunikace s nimi, např. VeriSign patřící dnes pod křídla Symantec.

Obdobně jako současná Směrnice o elektronických podpisech upravuje návrh nařízení zohledňuje rovněž činnost certifikačních autorit. Ty rozděluje do dvou úrovní – poskytovatele důvěryhodných služeb a kvalifikované poskytovatele důvěryhodných služeb.

Zatímco na ty první nejsou, podobně jako dnes na vydavatele tzv. komerčních certifikátů, kladeny žádné požadavky, činnost těch druhých lze připodobnit k současným akreditovaným poskytovatelům certifikačních služeb typu První certifikační autorita (ICA) či PostSignum. Činnost těchto poskytovatelů je však oproti současné praxi vymezena mnohem šířeji a nově rozšiřuje oblast regulace nejen na vytváření, ověřování, potvrzování, zpracovávání a uchovávání elektronických podpisů, elektronických značek, elektronických časových razítek, ale rovněž na elektronické dokumenty, elektronické doručování a ověřování webových stránek.

Evropská komise se tak snaží zabrousit do vod, kde působí např. americký VeriSign a po nápadu na zřízení evropské ratingové agentury je zde snaha o zřízení evropských certifikačních autorit, které by vytvořily protiváhu americkým konkurentům. Jejich certifikáty by pak mohly být v Evropské unii přijímány pouze v okamžiku uzavření mezinárodní dohod. Proces uzavření takovéto smlouvy je upraven ve Smlouvě o fungování EU, konkrétně čl. 218, který mj. předpokládá zmocnění ze strany Rady (tj. členských států), kdy např. uzavření dohody s USA by pravděpodobně nebyla záležitost týdnů ani měsíců, ale spíše roků.

Návrh vzešlý z pera Komise zároveň opomíjí současnou praxi, kdy zajištění důvěryhodnosti dané webové stránky, resp. certifikátu, nepředstavuje otázku legislativy, ale zejména otázku, jak „dostat“ svůj certifikát do prohlížeče tak, aby se daná stránka nezobrazovala jako nedůvěryhodná. V této souvislosti lze zmínit např. americký certifikát GeoTrust, který nahradil certifikát PostSignum používaný informačním systémem datových schránek. Vzhledem k tomu, že návrh se akceptování certifikátů vůbec nevěnuje, je možné, že bychom se mohli v budoucnu setkávat s tím, že zejména vládní servery by nám nabízely „důvěryhodné certifikáty“, které by se však v prohlížeči zobrazovaly jako nedůvěryhodné, zatímco ty důvěryhodné z druhé břehu Atlantiku by zase neodpovídaly požadavkům evropské legislativy.

Jiří Průša