Zabezpečení českých DNS resolverů

CZ.NIC se už po několik let účastní projektu DITL (A Day in the Life of the Internet), tedy volným překladem „Den života Internetu“, který je zastřešen organizacemi CAIDA a OARC. Účelem projektu je shromáždit datový provoz kořenových jmenných serverů a TLD autoritativních jmenných serverů z co nejvíce zdrojů a poskytnout tak možnost výzkumníkům zkoumat různé aspekty chování Internetu.

V letošním roce proběhl sběr dat v dubnu a trval dva dny. Využili jsme tedy nasbíraných dat a provedli analýzu českých resolverů na úroveň jejich zabezpečení z pohledu útoku typu otráveni „cache“ paměti DNS resolveru. Přesněji jsme zkoumali, jaké zdrojové porty daný DNS resolver používá u dotazů na autoritativní jmenné servery české domény .CZ. Pokud by resolver používal pořád stejný port (statický) či porty z posloupnosti (sekvenční), byl by velice snadno náchylný na Kaminského verzi DNS útoku na otrávení paměti DNS resolveru. Tím „snadno“ je myšleno útok v rámci sekund či minut bez potřeby náročného HW či velkokapacitního pásma pro připojení k Internetu. Raději ještě připomeneme, že pod pojmem otrávení paměti DNS resolveru si čtenář může představit situaci, kdy namísto své oblíbené webové stránky může být přesměrován na falešnou stránku útočníka a to změnou IP adresy k doméně v paměti jim používaného DNS resolveru.

A konečně se dostáváme k číslům. Z celkového počtu 32 408 českých DNS resolverů je snadno napadnutelných 6 519 serverů, což je 20.12 %. S ohledem na fakt, že už pěknou řádku let jsou k dispozici verze DNS serverů s pseudonáhodně generovanými zdrojovými porty, by mnozí z nás čekali toto číslo o něco nižší. Z výše uvedeného počtu napadnutelných serverů používá statické porty 4 017 serverů (12.40 %) a sekvenční porty 2 502 (7.72 %) serverů.

        

Dalším zajímavým údajem je procentuální zastoupení těchto snadno napadnutelných resolverů v celkovém provozu českých DNS serverů na .CZ domény a to je 12.15 %. Z něhož 10.76 % jsou resolvery používající statické a 1.39 % sekvenční porty. Dvanáct procent není zanedbatelných a proto už nyní CZ.NIC připravuje určité kroky pro zvýšení bezpečnosti uživatelů těchto DNS resolverů.

Výše uvedené statistiky napomáhají mapovat situaci zabezpečení DNS v České republice a proto budou ke konci roku 2011 doplněné ještě o analýzu DNSSEC; informace jsou pravidelně uveřejňovány na stránkách labs.nic.cz.

Emanuel Petr, Laboratoře CZ.NIC

Dodatek: Své DNS servery můžete otestovat webovým testem Web-based DNS Randomness Test nebo z příkazového řádku porttest.dns-oarc.net.

Světový den IPv6 je za námi

Světový den IPv6, který se konal 8. června 2011, je za námi a je tedy čas na zhodnocení této akce, alespoň z pohledu české domény.

Počet domén .CZ přístupných přes IPv6 před Světovým dnem byl celkem 62 931. Což přestavuje 7.90 % z celkového počtu domén. Oproti jiným státům je na tom Česká republika poměrně dobře; nejvíce se o to zasluhuje těchto deset poskytovatelů:

Pozn. Názvy společností byly převzaty z RIPE DB.

HofnerPavel-CZ = 14.8 %
Hosting90-CZ = 13.4 %
BANAN-1-IPV6-CZ-MAI = 12.6 %
CZ-INWAY-20051214 = 10.6 %
Blueboard-CZ = 7.7 %
CESKY-WEBHOSTING-1-IPV6-CZ-MAI = 6.8 %
CZ-WEDOS-20101129 = 5.9 %
IE-GOOGLE-20091005 = 5.5 %
CeskyWebhosting-CZ = 5.4 %
Tele3-CZ = 4.5 %

Příchodem Světového dne IPv6 se nám výše uvedené pořadí na přední pozici změnilo, protože bylo nově zpřístupněno 18 092 IPv6 domén, což představovalo téměř 29procentní nárůst. Za aktivní účast na mezinárodním dni IPv6 musíme pochválit především společnost ACTIVE24, která se o to zasloužila z 95 procent.

Seznam deseti poskytovatelů s největším podílem IPv6 domén při Světovém dni pak vypadá takto:

Pozn. Názvy společností byly převzaty z RIPE DB.

ACTIVE24-CZ-SERVERS-6NET1 = 21.9 %
HofnerPavel-CZ = 11.6 %
Hosting90-CZ = 10.4 %
BANAN-1-IPV6-CZ-MAI = 9.7 %
CZ-INWAY-20051214 = 8.2 %
Blueboard-CZ = 6.0 %
CESKY-WEBHOSTING-1-IPV6-CZ-MAI = 5.3 %
CZ-WEDOS-20101129 = 4.6 %
IE-GOOGLE-20091005 = 4.3 %
CeskyWebhosting-CZ = 4.2 %

A jak se Světový den projevil na grafech z našich obvyklých IPv6 statistik můžete vidět na následujícím obrázku.

Počet IPv6 domén .CZ při Světovém dni IPv6

Světovým dnem jsme tedy v České republice překonali desetiprocentní hranici přístupnosti domén přes IPv6.

Doufejme jen, že se časem přidají další společnosti a obsah českého internetu bude více a více dostupný přes IPv6. Aby ti uživatelé, kteří už mají IPv6 konektivitu a na rozhraní IPv6 adresu, ji mohli už konečně řádně používat.

Emanuel Petr

IPv6 ohlédnutí za rokem 2010

Letošní rok bude určitě pro IPv6 velmi zajímavý a to ať už z důvodu blížícího se konce volných IPv4 adres, různých propagačních akcí nebo plánovaného nasazení IPv6 u jednoho z velkých poskytovatelů Internetu v České republice.

My se dnes však poohlédneme za rokem minulým a popíšeme si vývoj IPv6 z pohledu české .CZ domény nejvyšší úrovně (TLD). Jako zdroj dat k hodnocení vývoje nám poslouží měsíční IPv6 statistiky, které CZ.NIC spravuje od konce roku 2009.

Počet IPv6 domén v .CZ doméně

IPv6 domény

Procentuální zastoupení domén s IPv6 adresou vzrostlo o 4,20 % a to z 0,99 % na 5,19 %, což ke konci roku 2010 odpovídalo 38 453 doménám z celkového počtu 741 162. Pouhých pět procent domén dostupných po IPv6 není to, co by si mnozí od roku 2010 slibovali. Snad více překvapující ale je, že v porovnání s některými TLD jsme na tom poměrně dobře.

TLD IPv6 zastoupení Celkem domén IPv6 domén
.cz 5,1882 % 741 162 38 453
.sk 4,93886 % 223 655 11 046
.mobi 2,6361 % 965 251 25 445
.us 1,84764 % 1 638 790 30 279
.com 1,10785 % 92 080 772 1 020 118
.info 1,10291 % 7 386 477 81 466
.net 0,994626 % 13 627 530 135 543
.biz 0,959339 % 2 057 563 19 739
.org 0,95281 % 8 873 853 84 551

O pětiprocentní nárůst IPv6 dostupných domén v České republice se nejvíce zasloužili tito vlastnící IPv6 adresního prostoru (názvy byly převzaty z položky „netname:“ v RIPE databázi):

BANAN-1-IPV6-CZ-MAI
Hosting90-CZ
CESKY-WEBHOSTING-1-IPV6-CZ-MAI
IE-GOOGLE-20091005
CeskyWebhosting-CZ
Tele3-CZ
COOLHOUSING-TELE3
Gransy-CZ

Počet domén s alespoň jednou IPv6 adresou jmenného serveru

IPv6 NS

U procentuálního zastoupení českých domén s alespoň jednou IPv6 adresou svého autoritativního jmenného serveru došlo k navýšení o 16,78 % a to z 3,53 % na 20,31 %, což ke konci roku 2010 odpovídalo 150 512 doménám z celkového počtu 741 162.

O nasazení IPv6 na autoritativní jmenné servery českých domén se nejvíce podíleli tito vlastníci adresního prostoru, kam jednotlivé IPv6 adresy jmenných serverů spadaly (názvy byly převzaty z položky „netname:“ v RIPE databázi):

Active24-CZ
KRAXNET
Gransy-CZ
CZ-INWAY-20051214
Hosting90-CZ

Počet domén s alespoň jednou IPv6 adresou poštovního serveru

IPv6 MX

U poštovních serverů českých domén došlo také k nárůstu IPv6 dostupnosti a to z 1,35 % na 8,61 %, což ke konci roku 2010 odpovídalo 63 838 doménám z celkového počtu 741 162.

Nejvíce českých domén používá poštovní servery, které spadají do těchto IPv6 adresních prostorů (názvy vlastníků byly převzaty z položky „netname:“ v RIPE databázi):

Active24-CZ
Gransy-CZ
BANAN-1-IPV6-CZ-MAI
Hosting90-CZ
CeskyWebhosting-CZ

Poslední graf se liší od předchozích, protože popisuje stav zavedení IPv6 z pohledu českých autonomních systémů. Zdrojová data byla převzata z BGP směrovací tabulky a RIPE databáze.

IPv6 v českých autonomních systémech

BGP

Rok/Měsíc # AS # alokovaných prefixů (%) # propagovaných prefixů
2009/12 345 38 (11,01 %) 29 (8,41 %)
2010/12 600 77 (12,83 %) 70 (11,67 %)

Počet autonomních systémů se za rok 2010 téměř zdvojnásobil a to z 345 na rovných 600. Každý z nich je dostupný po IPv4, jinak řečeno propaguje do světa svůj IPv4 prefix. S IPv6 prefixem to už tak dobré není. Ke konci roku 2010 byl celkový počet žádostí o přidělení IPv6 prefixu pouhých 77. Z toho se 70 odhodlalo svůj prefix propagovat do světa a zajistit si tak IPv6 konektivitu. Na druhou stranu lze sledovat za rok 2010 malý nárůst aktivity, alokace IPv6 vzrostly o 1,82 % a ve světové IPv6 směrovací tabulce se nachází o 3,26 % více českých autonomních systémů než tomu bylo v roce minulém.

Na závěr můžeme říci, že výše uvedené statistiky české TLD .CZ a českých autonomních systémů za rok 2010 signalizují postupně vzrůstající zavedení IPv6. Výsledná čísla by však mohla být mnohem větší. Nezbývá tedy než doufat, že nás v tomto roce potká dramatičtější vývoj než tomu bylo v roce minulém a konečně se IPv6 dostane na na úroveň, kde by mohla začít IPv4 alespoň trochu konkurovat.

Emanuel Petr

Červ Conficker

Červ Conficker, známý také pod názvy Downup, Downadup a Kido, napadl už milióny počítačů. Patříte mezi ně? Jednoduchý test máte přímo před sebou.


Conficker Eye Chart/Detekční tabulka

openbsd linux freebsd

zdroj: http://www.joestewart.org/cfeyechart.html

Interpretace detekční tabulky v původním znění najdete zde, nebo můžete použít volný překlad z anglického originálu.

Výtažek z překladu:
„Jestliže je Vám zablokován přístup k zobrazení obrázků (log antivirových firem) v prvním řádku horní tabulky a zároveň se zobrazují loga alternativních operačních systémů v druhém řádku tabulky, pak může být Vaše Windows PC infikováno červem Conficker (nebo jiným škodlivým programem).“

Jste-li napadeni, využijte některý z dostupných nástrojů a červa Conficker co nejdříve odstraňte. Odkazy na nástroje:
Downadup-removal
Obsáhlý seznam nástrojů

Světová mapa infikovaných počítačů. Další mapy naleznete zde.
conficker_world_infection_hybrid-480x239

Pokud Vás zajímají bližší informace o červu Conficker, následující výběr Vám může usnadnit hledání. Doporučuji zahraniční odkazy.

Zahraniční odkazy: České odkazy:
1. An Analysis of Conficker’s Logic
and Rendezvous Points
1. Červ Win32/Conficker letí světem!
2. Conficker C Analysis 2. Buďte fikanější než Conficker
3. Wikipedia Conficker 3. BitDefender má lék na Conficker
4. Conficker Working Group
5. RepairTools
6. Third party information on conficker
7. InfectionDistribution

Emanuel Petr

AS path prepending

AS path je BGP povinný atribut. Obsahuje seznam čísel autonomních systémů (ASNs), přes které je prefix (rozsah adres) propagován. Například AS path pro ripe.net 193.0.19.25 může vypadat:

<code>test@juniper&gt; show route protocol bgp 193.0.19.25

inet.0: 275156 destinations, 374067 routes (275106 active,
 0 holddown, 76 hidden)

+ = Active Route, - = Last Active, * = Both

193.0.18.0/23      *[BGP/170] 1w0d 17:01:53, localpref 100
                               <strong>AS path: 15685 1299 3333 I</strong>
                             &gt; to 10.0.0.254 via ge-0/0/0.0
</code>

Má-li směrovač k danému prefixu více cest, může být délka AS path při výběru nejlepší cesty rozhodující.

AS path prepending neboli „umělé“ prodloužení AS path se užije v případě multihomingu, kdy chceme pro příchozí provoz preferovat jeden upstream před druhým.

Dne 16.2.2008 si takto svoji cestičku v globální směrovací tabulce do Uherského Hradiště/Broda (AS47868) prodloužila společnost SUPRO-NET. Využila zmiňované možnosti “AS path prependingu“ pro svůj druhý upstream a nešetřila.
Běžně stačí svoje AS znásobit jednociferným číslem. Ale 251x se ukázalo, jako velké sousto pro starší směrovače/staré verze IOSu či jakékoliv implementace BGP, které si neporadí s delším AS path. Následkem bylo rozpojení BGP sezení, velké BGP updaty a výpadky konektivity.

Článek na renesys.com popisuje, že to nebyl úmysl, ale chyba správce a bug routeru MikroTik.

Že prefixy s delším AS path nejsou ojedinělé, se můžete přesvědčit na http://bgpmon.net/maxASpath.php

Velmi dlouhé AS path jsou nerozumné, protože zbytečně zabírají systémové prostředky na směrovačích. Nejsou však v rozporu s RFC4271 . V BGP UPDATE zprávě jsou pro délku atributů vyhrazeny 2 Byty (64KB), takže AS path je omezeno snad jen samotnou velikostí BGP UPDATE zprávy, která je 4KB.

Zajímalo mě, jak se k tomu staví jednotlivé implementace. Zkoušel jsem příkazy pro omezení délky AS path, možnosti prodloužení AS path a nakonec import prefixu s velmi dlouhým AS path. Testovány byly tyto implementace Cisco, Juniper, Quagga a BIRD.


logo_cisco
Testováno s IOS 12.4(11)T2.

Cisco ve starších IOSech mělo s delším AS path vážné problémy! Jak se jim vyvarovat?

Od IOS 12.0(17)S by měl být implementován příkaz „bgp maxas-limit

#bgp maxas-limit ?
  <1-2000> Number of ASes in the AS-PATH attribute

pokud příkaz není dostupný, můžete použít „ip as-path access-list“ a „filter-list/route-map“ nebo sáhnout po novějším IOS.

Maximální hodnota 2000 u „bgp maxas-limit“ je taková Cisco hrátka, protože v aktuální dokumentaci uvádí <1-255>. I když je Vám umožněno zadat více, bude limit pro importované prefixy stále 255 a to i v případě, neuvedete-li příkaz „bgp maxas-limit“ vůbec.

A aby to nebylo tak jednoduché, je tu ještě odlišnost ve výpisech.
# sh ip bgp neighbors 10.0.0.22 route … zobrazuje přijaté a akceptované prefixy

V případě „bgp maxas-limit“ s hodnotou < 255, nejsou ve výstupu prefixy s delším AS path logicky zobrazeny. Ale s hodnotou >= 255 nebo bez samotného příkazu pro omezení AS path, jsou zobrazeny jako akceptované, nejsou však zařazeny do směrovací tabulky.

Ukázka omezení délky AS path na 15:

cisco(config)#router bgp 64551
cisco(config-router)#bgp maxas-limit 15

Při překročení limitu 15 ASNs se prefix ignoruje a důvod je zalogován.

*Feb 19 20:12:27.057: %BGP-6-ASPATH: Long AS path 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 15685 1299 3333
received from 10.0.0.20: More than configured MAXAS-LIMIT

Pravděpodobně jako prevence dlouhých AS path, je v IOS prodloužení AS path omezeno na maximálně 10 ASNs pro jednotlivé příkazy.

cisco(config)# route-map prepend-as permit 10
cisco(config-route-map)#set as-path prepend 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551
cisco(config-route-map)#set as-path prepend last-as 10

Při pokusu zadat více, skončíte s chybovou zprávou.

cisco(config-route-map)#set as-path prepend 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551 64551
% Cannot have more than 10 as-paths prepended
% Cannot have more than 10 as-paths prepended

Pokud upravujete AS path pro prefix, který nemá původ u Vás, můžete přidat dalších 20 ASNs aplikací route-mapy při importu.

<code>cisco(config-router)#neighbor 10.0.0.22 route-map prepand-as ?
in   Apply map to incoming routes
out  Apply map to outbound routes </code> 

Celkem lze prodloužit AS path až o 40 ASNs + 1 ASN implicitně. Tranzitní AS s Cisco směrovači si musí dát pozor na novou chybu a omezit AS path. V opačném případě může dojít při exportu k přerušení BGP spojení.



logo_juniper

Testováno s JUNOS verzí 9.2R2.15.

Alternativou pro „bgp maxas-limit number“ je AS path regulární výraz, který následně aplikujeme ve směrovací politice.

AS path regulární výraz pro 91 ASNs a více.


[edit policy-options]
test@juniper# set as-path maxas-limit ".{91,}"

Rozšíření importovací politiky o zamítnutí všech prefixů s delším AS path než 90.

[edit policy-options policy-statement nix-import term reject-long-aspath]
test@juniper# set from as-path maxas-limit
test@juniper# set then reject

Výsledná konfigurace.

<code>[edit policy-options ]
test@juniper# show
policy-statement nix-import {
...
  <strong>term reject-long-aspath {
    from as-path maxas-limit;
    then reject;
  }
</strong>...
}
<strong>set as-path maxas-limit ".{91,}"</strong>
</code>

Odmítnuté prefixy pak naleznete takto:

<code>test@juniper&gt; <strong>show route receive-protocol bgp 10.0.0.21 hidden</strong>

inet.0: 249888 destinations, 249891 routes (249886 active, 
0 holddown, 4 hidden)
Prefix                Nexthop         MED     Lclpref    AS path
10.123.0.0/16         10.0.0.1        0               64551 64551 
64551 ... výpis zkrácen ... 64551 64551 64551 64551 64551 64551 I
10.124.0.0/16         10.0.0.25       0              64551 64551 
64551 ... výpis zkrácen ... 64551 64551 64551 64551 64551 64551 I
</code>

Také Juniper omezuje vytvoření velmi dlouhých AS path. Prodloužit AS path se dá třemi příkazy:

as-path-prepend as-path-string ... omezuje na 30 ASNs nebo na maximální délku řetězce 256
as-path-expand last-as count n ... n = kolikrát se poslední ASNs zopakuje a to v rozmezí 1..32
as-path-expand as-path-string ... omezuje na 30 ASNs nebo na maximální délku řetězce 256

Maximálně tedy můžeme prodloužit AS path o 62 ASNs.

V případě překročení limitu 30ti ASNs pro daný příkaz dostaneme chybovou zprávu:
AS path too complex
error: configuration check-out failed

A pokusíme-li zadat řetězec delší než 256 znaků, budeme informováni o invalidním řetězci a prefix nebude vůbec propagován.

test@juniper# commit
[edit policy-options policy-statement export-limited term allow-ripe-prefix then as-path-prepend]
'as-path-prepend "25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 ... výpis zkrácen ... 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 "'
Insufficient buffer space for string
[edit policy-options policy-statement export-limited term allow-ripe-prefix then as-path-prepend]
'as-path-prepend "25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 ... výpis zkrácen ... 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 25192 "'
Policy: Invalid string
commit complete



logo_quagga

testovaná verze 0.99.9

Omezení délky AS path na 30 ASNs:
ip as-path access-list maxas-path deny ( [0-9]+){30}$
ip as-path access-list maxas-path permit .*

Aplikujeme na příchozí prefixy:
neighbor 10.0.0.21 filter-list maxas-path in

Quagga neumožní prodloužit AS path více než o 24 ASNs.

Při pokusu zadat více, dostaneme chybovou zprávu a BGP démon se nespustí. Přes VTY sice můžete zadat více, ale příkaz bude tiše ignorován.

There is no such command.
Error occured during reading below line.
set as-path prepend 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 64502 3333



log_bird

testovaná verze 1.0.12

Omezení délky AS path na 35 ASNs:

<code>protocol bgp {
    export all;
<strong>    import filter {
           if bgp_path.len &gt; 35 then reject;
           accept;
        };
</strong>
    local as 64502;
    neighbor 10.0.0.20 as 25192;
}
</code>

Filtry můžete testovat pohodlně z příkazové řádky BIRD klienta.
V ukázce má importovaný prefix 193.0.18.0/23 délku AS path 35.

<code>
# ./birdc -s bird.ctl
BIRD 1.0.12 ready.
bird&gt; show route all filter {if bgp_path.len &gt; 35 then reject; accept;}
193.0.18.0/23    via 10.0.0.20 on eth0 [bgp1 17:21] (100) [AS3333i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 25192 25192 25192 25192 25192 25192 25192
  25192 25192 25192 25192 25192 25192 25192 25192 25192 25192
  25192 25192 25192 25192 25192 25192 25192 25192 25192 25192
  25192 25192 25192 25192 25192 15685 1299 3333
        BGP.next_hop: 10.0.0.20
        BGP.local_pref: 0
bird&gt; show route all filter {if bgp_path.len &gt; 34 then reject; accept;}
bird&gt;
</code>

Prodloužení AS path je omezeno interní velikostí atributů 1KB. Limitu je většinou dosaženo při cca 250 ASNs. Při překročení, obdržíme chybovou zprávu a BGP prefix nebude správně propagován.

20-02-2009 14:08:35 <ERR> BGP: attribute list too long, ignoring the remaining attributes


Import prefixu s velmi dlouhým AS path

A jak si poradily jednotlivé implementace s importem prefixu, jehož AS PATH čítala 560 ASNs. Takto dlouhý BGP update byl vytvořen úpravou zdrojových kódů BIRD.

Cisco import zvládne, ale prefix nezařadí do směrovací tabulky
Juniper OK
Quagga OK
BIRD OK

Závěr
Máte-li na svém směrovači alespoň verze, které byly testovány, tak nebudete mít při samotném importu prefixu s dlouhým AS path problém.
Na směrovačích Cisco se však objevila nová chyba. Překročíte-li při prodloužení AS path délku 255 ASNs a tento prefix vypropagujete, bude BGP sezení přerušeno a následně cyklicky restartováno. Detailně se této nové chybě budu věnovat v dalším článku.

Dodatek:
1.3.2009 – Quagga má obdobný problém při exportu s AS path > 255, a to i bez dodatečného prependingu. Ve verzi 0.99.10 byla chyba opravena.
2.3.2009 – Rozbor Cisco chyby je součástí článku Proč a zda Supronet shodil Internet.

Emanuel Petr

Zdroje:
http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml
http://wiki.nil.com/Limit_the_maximum_BGP_AS-path_length
http://bgpmon.net/maxASpath.php
http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp1.html#wp1013932
http://www.juniper.net/
http://www.quagga.net/
http://bird.network.cz/
http://www.ietf.org/rfc/rfc4271.txt
http://blog.ioshints.info/2009/02/oversized-as-paths-cisco-ios-bug.html