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.

Blogpost_JP

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

Co byste rádi na konferenci Internet a Technologie 13?

Na květen opět připravujeme naši tradiční konferenci Internet a Technologie (08, 09, 10, 11. 12). V případě té letošní se vracíme k modelu, který jsme loni opustili, tedy tato akce se bude opět konat v půlce roku, bude v průběhu pracovního týdne, bude dvoudenní a chtěli bychom, aby byla v Národní technické knihovně v pražských Dejvicích, s níž máme bohaté a velice dobré zkušenosti. Možná se ptáte, proč další změna. Důvodem je naše druhá letošní konference, kterou po dobrých zkušenostech s IT 12 připravíme na listopad. O tom ale až v dalším blogpostu.

V těchto dnech dáváme dohromady témata a začínáme se ohlížet po přednáškách a hlavně přednášejících. Je více než pravděpodobné, že se budeme věnovat nejen aktuálním doménovým tématům, ale i IPv4 a IPv6, internetové/kybernetické bezpečnosti, novým internetovým technologiím, o nichž se v poslední době mluví, nebo internetovému hardwaru.

Protože předpokládáme, že řada čtenářů .blogu jsou také potenciální návštěvníci našich akcí, zajímalo by nás, co byste od letošní konferenci Internet a Technologie očekávali. Rádi bychom vás požádali o tipy na přednášky a třeba i na workshopy (na IT 13 nás mile překvapil zájem o speciální setkání věnované BIRDovi, třeba o něj bude zájem a my připravíme jeho pokračování).

Jestli tedy víte, co zajímavého byste chtěli na IT 13 vidět a slyšet, koho byste tam chtěli potkat atd., podělte se s námi v komentářích. Nebráníme se samozřejmě ani tipům na vystupující ze zahraničí. Čím dříve nám dáte vědět, tím lépe.

Předem vám děkujeme za spolupráci.

Vilém Sládek

Honeynet: útoky na přelomu roku

Poslední statistky z našeho honeynetu jsme zveřejnili počátkem listopadu, takže je opět vhodný čas se podívat, co se v uplynulých měsících dělo.

Nejvýrazněji se na statistikách podepsal autonomní systém AS3462 z Tchaj-wanu s počtem 372 unikátních IP adres. Opakuje se tak situace z minulého období. Počítače z tohoto rozsahu šířily 100 různých variant malware, z toho dvě se dostaly do TOP 10 za poslední sledované období (viz první a druhý malware na VirusTotal); jedna z těchto dvou byla šířena z jediné IP adresy. Tento AS sám o sobě zajistil Tchaj-wanu první příčku ve srovnání s ostatními státy světa.

Nejčastější útočníci (listopad 2012 – leden 2013)

Při pohledu na mapu světa jsou opět nejvýrazněji vidět Rusko a Brazílie. Oba státy vynesly na vysoké příčky stejné AS, jako v minulém období – ruský AS8402 a brazilský AS27699. Překonává je jen zmiňovaný Tchaj-wan a tentokrát i Arménie, která šířila tuto variantu viru Conficker. Menší množství útoků na nás směřovalo také z Německa a Srbska.

Zdroje útoků (listopad 2012 – leden 2013)

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

Cílové porty (listopad 2012 – leden 2013), horizontální osa má logaritmickou škálu

Nejčastěji nahrávaný malware tvořily různé varianty Confickeru. Většinou platí, že jeden typ šíří téměř výhradně jeden autonomní systém.

Zachycený malware (listopad 2012 – leden 2013)

Na konec ještě přehled nejčastějších kombinací přihlašovacích údajů na službu SSH. Proti minulému období se nově v TOP 10 objevila kombinace test-test a root-redhat.

Přihlašování na SSH (listopad 2012 – leden 2013)

Jiří Machálek

Datovka a verze Androidu

Jsou tomu již téměř dva měsíce co Datovku pro desktop a iDatovku doplnila Datovka pro Android. Jak si stojí, jak je to s podporou verzí Androidu a co jako vývojář očekávat po publikování aktualizace aplikace na Google Play? Na to se podíváme v tomto blogpostu.

Verze Androidu na trhu

Android je tu s námi přibližně 4,5 roku a během této doby bylo vydáno poměrně velké množství jeho verzí. Ty nejsou z pohledu vývojáře ani tak podstatné jako verze API, se kterou byla daná verze Androidu sestavena. Jednotlivé verze API se mezi sebou liší zejména podporou nových funkcí systému a bohužel občas i jinými chybami, které vývojář musí ošetřit. V praxi to znamená, že se vývojář musí na počátku rozhodnout, pro jaké rozpětí verzí API bude svou aplikaci psát. Zahrnout dnes do podpory například API verze 4 (což odpovídá Androidu 1.6 Donut) by sice mohlo přinést několik uživatelů navíc, ale komplikace, které bychom si tímto krokem do kódu a vývoje celé aplikace zanesli, za to ve většině případů nestojí. Dobrým pomocníkem v tomto rozhodování jsou grafy obsazení trhu, které Google poskytuje.

Obsazeni_trhu

Obsazení trhu

Obsazeni_trhu_vyvoj

Obsazení trhu, vývoj

Z prvního grafu je patrné, že majoritní podíl, téměř 50 procent, obsazuje API verze 10, které odpovídá Androidu 2.3 Gingerbread. Přestože je tato verze již téměř 2 roky stará, její ústup z trhu je, jak vidno z druhého grafu, pozvolný a proto bude určitě vhodné s touto verzí při vývoji nové aplikace ještě nějaký čas počítat.

Verze Androidu u uživatelů Datovky

Výše zmíněným rozložením jsme se řídili i při vývoji Datovky pro Android a rozhodli se podporovat pouze API verze 8 (Android 2.2 Froyo) a novější. Při pohledu na další graf, který již ukazuje zastoupení verzí Androidu pro naši aplikaci, je evidentní, že naše rozhodnutí bylo více než velkorysé. Datovka na Androidu 2.2 je na pouhých 22 zařízeních (což je něco málo přes 2 %) a dokonce ani Android 2.3 nemá na počtu instalací příliš velký podíl. Sečteme-li počty instalací na Androidu verze 4.x, zjistíme, že tato skupina zaujímá téměř 80 % procent všech instalací, což rozhodně nekoresponduje s předchozími grafy obsazení trhu ani s obecným zastoupením verzí v dané skupině aplikací. Navíc si lze všimnout, že se zvětšujícím se počtem instalací roste zejména podíl právě Androidu 4.x.

Verze_Androidu_Datovka

Vývoj verze Datovky pro Android

Domníváme se, že toto netypické rozložení verzí Androidu je dáno především specifickým obecenstvem aplikace, protože mezi uživatele datových schránek patří především manažeři, podnikatelé a další uživatelé z vyšších příjmových skupin. To je koneckonců zřejmé i z nejpoužívanějších zařízení, kde vede high-end telefon Samsung Galaxy S III.

Šíření aktualizací v Google Play

V ideálním světě by se aktualizace šířily lusknutím prstu a v té samé vteřině by byly všechny staré verze a tím i chyby nás vývojářů zapomenuty. Bohužel takto to minimálně v případě Androidu nechodí. Jak vidno z posledního grafu, Datovka byla uveřejněna na Google Play 30. listopadu 2012, tisková zpráva vyšla až o dva dny později, ale přesto si ji v tomto mezičase nainstalovalo 7 uživatelů. Následoval raketový start a další den již Developer Console hlásila 111 uživatelů. S nimi přišly první nahlášené chyby a první opravené vydání. To mělo následující den nainstalováno 208 uživatelů, 48 stále čekalo na doručení aktualizace. Podíl verze 1 se další dny dále snižoval, ale přesto i po 2 měsících a 3 vydaných aktualizacích Developer Console stále eviduje 4 uživatele s verzí 1.

Dále jde z grafu odvodit, že s rostoucím počtem instalací a uveřejněných verzí klesá rychlost šíření nové verze. Druhé verzi Datovky trvalo 2 dny, než se rozšířila na více než 90 % všech zařízení, v případě verze 3 to bylo 6 dní a poslední uveřejněné verzi číslo 4 zabralo dosažení stejného cíle již 15 dní.

Vyvoj_verze_Datovka

Vývoj Datovky

V každém případě počty stažení i hodnocení aplikace uživateli ukazují, že si Datovka pro Android své příznivce v české internetové komunitě našla. Na vylepšování této aplikace samozřejmě budeme dále pracovat a o nových verzích vás budeme informovat na stránkách Laboratoří CZ.NIC. Stejně tak budeme rádi, pokud se vy ozvete nám a dáte nám vědět o případných problémech s aplikací nebo vašich nápadech na její vylepšení.

Martin Strbačka

Laboratoře CZ.NIC včera, dnes a zítra

Konec roku bývá často využíván k bilancování a začátek nového roku je zase dobrou příležitostí k prognózám, předsevzetím a plánování věcí příštích. Protože jsme si nechali ohlédnutí na konci roku v návalu práce utéct, dovolím si v tomto příspěvku spojit oba pohledy dohromady a krátce popsat historii, současnost a blízkou budoucnost Laboratoří CZ.NIC.

Zárodek Laboratoří CZ.NIC vznikl v průběhu roku 2008 oddělením od produkční části CZ.NIC. Cílem nových laboratoří byla práce na projektech bez přímé vazby na registr domén a s ním spojený vývoj a infrastrukturu.

Během roku 2009 a 2010 se počet členů laboratoří pomalu zvyšoval, což vyvrcholilo vytvořením nové pobočky v Brně. Zároveň s růstem počtu zaměstnanců se zvyšovalo i množství realizovaných projektů – např. v roce 2009 převzaly laboratoře vývoj routovacího démona BIRD a vznikly projekty DNSSEC hardware tester, DNSSEC validátor pro Firefox, dsgui alias Datovka; v roce 2010 přibyly ZFO Editor, iDatovka a první interní verze Knot DNS.

V letech 2011 a 2012 pak již počet zaměstnanců laboratoří stagnoval a docházelo spíše k přirozené obměně osazenstva. I přesto se ale růst počtu projektů nezastavil, spíše naopak – v roce 2011 přibyla první ostrá verze Knot DNS, IPv6 widget, DNSSEC validátor pro Chrome a spolupráce na BIND 10; v roce 2012 pak např. KATR, DNSSEC Validátor pro IE, Malicious Domain Manager, nové statistiky CZ.NIC a Datovka pro Android.

V roce 2013 nechceme za dosavadním vývojem zaostat a kromě rozvoje a údržby stávajících projektů startujeme hned dva nové velké projekty v oblasti internetové bezpečnosti a interaktivního vzdělávání. S tím je samozřejmě spojená i další nutná expanze laboratoří, a to jak v našich současných pobočkách v Praze a Brně, tak v nejbližších měsících také v nové pobočce v Plzni.

Pokud byste tedy měli zájem podílet se na vývoji inovativních projektů v renomované společnosti, jejichž výstupem je v naprosté většině případů otevřený software, dejte nám vědět. Seznam otevřených pozic a kontakt na nás najdete na našich stránkách v sekci kariéra.

Věřím, že i v případě, že mezi zájemce o práci na našich projektech nepatříte, zaujmou vás alespoň jejich výsledky. Určitě je na co se těšit.

Bedřich Košata

Přístup k systému Request Tracker z Pythonu

Závěrem loňského roku Laboratoře CZ.NIC vydaly první verzi modulu python-rt. Ten umožňuje přistupovat z Pythonu k API systému pro správu požadavků Request Tracker. Původně byl tento modul vyvinut v rámci projektu MDM, nakonec je ovšem použitelný i samostatně. Podrobnosti o modulu naleznete na stránce projektu a v jeho dokumentaci.

Co vlastně je Request Tracker a kde se podobné systémy uplatní? Jedná se o webové aplikace, které přehledně evidují požadavky (typicky nahlášené e-mailem) a umožňují skupině lidí spolupracovat na jejich řešení. Běžně takové tyto systémy používají například oddělení zákaznické podpory. Veřejně dostupné demo systému Request Tracker si můžete vyzkoušet zde. A právě na něm si ukážeme, jak se modul používá.

  1. Na testování si vytvoříme nové virtuální prostředí v adresáři env-rt, přesuneme se do něj a aktivujeme jej:
    $ virtualenv env-rt
    $ cd env-rt
    $ source bin/activate
  2. Nainstalujeme modul rt:
    (env-rt)$ pip install rt
  3. Spustíme Python v interaktivním režimu:
    (env-rt)$ python
  4. Importujeme modul rt a vytvoříme instanci jeho třídy rt (tři parametry: adresa REST API systému Request Tracker., uživatelské jméno, heslo):
    >>> import rt
    >>> tracker = rt.Rt('http://rt.easter-eggs.org/demos/stable/REST/1.0',
    ... 'mike.bar', 'mike.bar')
  5. Přihlásíme se do systému a vyhledáme všechny vlastníky požadavků ve frontě Helpdesk:
    >>> tracker.login()
    True
    >>> set(map(lambda x: x['Owner'], tracker.search(Queue="Helpdesk")))
    set([u'admin', u'john.foo', u'Nobody', u'mike.bar'])
  6. Dále například můžeme vytvořit nový požadavek:
    >>> tracker.create_ticket(Queue='Helpdesk',
    ... Subject='Coffee (important)', Text='Help I ran out of coffee!')
    113
  7. Vrácené číslo je ID požadavku, které můžeme využít pokud chceme například požadavek editovat:
    >>> tracker.edit_ticket(113, Requestors='addicted@example.com')
    True
  8. Důležitá je také možnost na požadavky reagovat:
    >>> tracker.reply(113, text='Do you know Starbucks?')
    True
  9. Na konci se odhlásíme:
    >>> tracker.logout()
    True

Pokud se rozhodnete modul používat, budeme rádi za vaši zpětnou vazbu.

Jiří Machálek

Šťastné a veselé a všechno nejlepší

Vážení čtenáři našeho .blogu, rádi bychom vám poděkovali za pozornost, kterou jste nám věnovali v tomto roce, a popřáli vám hezké a klidné svátky a vše nejlepší v roce příštím.

Od ledna vám na těchto stránkách budeme opět přinášet zajímavé postřehy a komentáře spojené nejen s našimi projekty, ale i s událostmi a tématy věnované doménám, doménovým technologiím a Internetu.

Ještě jednou děkujeme za vaši přízeň a za 14 dní opět zde, na .blogu.

Tým zaměstnanců sdružení CZ.NIC

PF_2013_CZ_NIC

It’s getting better all the time….

Jak se zpívá v jedné geniální písni od Beatles, pořád se to zlepšuje. A o čem že to mluvím? Přece o statistikách APWG, o kterých jsem tu již jednou psal. Minulý měsíc totiž APWG vydalo svou zprávu zaobírající se čím jiným než problematikou phishingu. Zpráva se týkala prvního pololetí roku 2012.

Počet phishingových útoků v doméně .cz se sice od minulého pololetí již příliš nezměnil, v 2/2011 to bylo 171, v minulém pololetí pak 170, ale průměrný uptime opět poklesl, tentokrát ze 41 hodin a 10 minut v 2/2011 na 39 hodin a 41 minut v prvním pololetí tohoto roku. Také medián uptimu poklesl ze 14 hodin a 46 minut na 13 hodin a 54 minut. Počet domén .cz zneužitých k phishingu na 10 tisíc registrovaných domén se pak snížil z 1,2 na 1,1.

Bohužel druhý z našich zdrojů, organizace phishtank, již nadále nezobrazuje informace o phishingových aktivitách v souvislosti s delegací IP adres do jednotlivých států. Přišli jsme tak o zajímavý zdroj informací, který je těžké nahradit. Většina analýz a reportů týkajících se bezpečnosti se totiž zabývá pouze prvními deseti či dvaceti státy, které jsou na tom v dané problematice nejhůře. Může nás tedy hřát fakt, že se v těchto nelichotivých žebříčcích nevyskytujeme. Na druhou stranu by bylo pěkné vědět, jak si naše země stojí například v meziročních, či mezičtvrtletních porovnáních.

Závěrem tedy aspoň jeden optimistický obrázek ze zprávy IT Threat Evolution za třetí čtvrtletí tohoto roku, který ukazuje, že Česká republika je na tom z hlediska rizika nákazy prostřednictvím webových stránek velmi dobře. Lépe jsou na tom pouze některé africké země, kde je to však dáno především nízkou penetrací internetu jako takového.

Riziko online infekce podle zemí, Q3 2012:

Obr1

Pokud byste o nějaké databázi zneužitých IP adres, kde by bylo možno zjistit, jak si vedou jednotlivé státy, věděli, budeme rádi, pokud se s námi o ni podělíte v diskuzi pod článkem. A nemusí se jednat pouze o databáze IP adres či domén zneužitých k phishingovým útokům, ale obecně k jakémukoliv útoku na uživatele.

Pavel Bašta