Nový projekt: DNS Collector sbírá a analyzuje provoz v DNS

Primární účel DNS (Domain Name System) je zprostředkovat překlad doménových jmen na adresy v síti. Ve zjednodušené formě – klient generuje dotazy a server poskytuje odpovědi. Jako takový tvoří DNS jednu z důležitých služeb v IP sítích. Ve většině případů začíná komunikace na internetu právě DNS dotazem. Stopy této komunikace lze nalézt na různých úrovních DNS hierarchie. Analýzou těchto stop (DNS dotazů) lze získat užitečné informace o stavu sítě a chování jejích uživatelů.

Sběr DNS dat
DNS provoz je potřeba extrahovat z celkového síťového provozu. Převážná část DNS provozu je přenášena nefragmentovanými UDP pakety. Abychom získali pokud možno celistvý pohled na přenášená data, je nutné u zbylého provozu provést defragmentaci paketů a provést rekonstrukci TCP spojení. Je také nutné se vypořádat s poškozenými pakety nebo nedokončenými datovými přenosy.

V DNS provozu na serverech obsluhujících .cz TLD převládá síťový protokol IPv4. V závislosti na objemu provozu a umístění serveru se jeho zastoupení pohybuje kolem 90 %. Výjimku tvoří server akuma, umístěný v Japonsku, u kterého je poměr IPv4/IPv6 převrácený. Na transportní vrstvě dominuje UDP.

Aplikace DNS Collector zjednodušuje zpracování DNS provozu tím, že je schopna poslouchat provoz na několika síťových rozhraních současně. V současné  době k tomu využívá knihovnu libpcap. Zachycený síťový provoz je defragmentován. V případě TCP provozu je sledováno správné ustanovení a ukončení TCP relace. Přerušená TCP spojení nebo neúplné pakety jsou po čase zahozeny. Zrekonstruované surové (tak jak jsou přenášené po síti) DNS pakety jsou v závislosti na použité síťové a transportní vrstvě opatřeny daty z IPv4/IPv6 a UDP/TCP hlaviček. Takto připravená data jsou předána ke zpracování do modulů.

DNS Collector umožňuje zpracovávat také archivovaný provoz uložený v souborech na disku (ve formátu podporovaném knihovnou libpcap). V tom případě pak ale není možné současně zpracovávat archivovaný provoz s živým provozem ze síťových rozhraní. V současné době také není také možné zpracovávat více archivů (souborů) současně, protože doposud nebyl implementován mechanismus řazení paketů podle časových značek uložených v souborech. V případě, že je potřeba zpracovat více archivů současně, je nutné použít externí aplikaci jako je například mergecap nebo PCAPMerger.

Zpracování provozu v modulech
Modul je funkční jednotka, která se zabývá zpracováním surových DNS dat. Tyto data mu připravuje DNS Collector způsobem zmíněným v předcházející části. Moduly představují funkční abstrakci, umožňující izolovat jednotlivé činnosti nad DNS daty. Moduly si udržují vlastní kontexty, mohou tedy pracovat nezávisle na ostatních modulech.

Moduly lze nahrávat nebo uvolňovat za běhu celé aplikace. V porovnání se samostatnými aplikacemi provádějícími ekvivalentní činnost mají moduly výhodu menší režie. Všechny moduly totiž společně sdílí společnou vrstvu, která se stará o přípravu vstupních dat. Tato vrstva by v případě samostatných procesů musela existovat ve všech procesech.

DNS Collector neposkytuje žádné rozhraní pro parsování surových DNS dat. V závislosti na povaze zpracovávaných dat je možné implementovat vlastní jednoduchý parser DNS paketu, nebo v případě složitějších operací použít některou z existujících knihoven, jako je například ldns.

Detektor anomálií
Tento modul vychází ze samostatného projektu detektoru DNS anomálií. Původní samostatná aplikace prováděla statistickou analýzu části DNS provozu, která byla dostupná v úplných UDP paketech. Na základě vzájemné podobnosti zjištěných vzorů pak posuzovala, zda je provoz „normální“. Je nutné upozornit, že se jedná o hodnocení ve smyslu: normální je převažující chování. V tomto smyslu anomálie nemusí být nutně škodlivé, pouze se něčím vymykají charakteristice většiny. Díky použití v DNS Collectoru je možné zpracovávat data pocházející z fragmentovaných paketů a dat přenášených přes TCP.

Výstupem tohoto modulu je textové hlášení o detekovaných anomálních identifikátorech. Volitelným výstupem jsou soubory vykreslující výskyt detekovaných anomálií ve formátu vhodném pro zpracování gnuplotem.

Na následujících obrázcích je ukázka několika typů detekovaných anomálií. Data byla zachytávána a analyzována v desetiminutových intervalech 1. října na serveru dns-b-01. Grafy zobrazují zastoupení anomálního provozu v poměru k celkovém provozu. IP adresy jsou záměrně nahrazeny.

Tue Oct  1 05:00:00 2013

Tue Oct  1 21:20:00 2013

Tue Oct  1 09:50:00 2013

Tue Oct  1 21:30:00 2013

Na grafech je zobrazeno zastoupení provozu označeného jako anomální:
IP A – hromadné rozesílání emailů, provoz obsahuje dotazy na MX a adresy mailserverů
IP B – opakovaný dotaz se stejným ID v krátkém intervalu (300x během 2ms)
IP C, D, F, G – rekurzivní resolvery
IP E – DKIM spam-filter
IP H – opakované dotazy na adresy tří nameserverů, postupně se zvyšující ID dotazů

Spouštění skriptů v Pythonu
Ne každá analýza si zaslouží samostatný modul psaný v C. V případech, kdy není jisté, zda bude výsledek použitelný, je výhodnější použít jazyk s méně pracnou správou paměti a přívětivější správou datových struktur, který je vhodnější pro prototypování. Teprve v případě, kdy je ověřeno, že testovaný postup bude fungovat, bude nutné algoritmus přepsat do C nebo C++.

Pro účely rychlého návrhu slouží modul pro spouštění pythoních skriptů. Modul implementuje wrapper pro rozhraní DNS Collectoru. Toto rozhraní je pak možné využívat ve spouštěném skriptu. Samotný modul volá interpret jazyka Python (libpython). Kód wrapperu obaluje předávané C-čkové struktury a vytváří z nich PyObjecty. Za cenu snížení výkonu aplikace, v důsledku obalování datových struktur, je možné využívat všechny výhody dynamicky typovaného interpretovaného jazyka s automatickou správou paměti. Surová DNS data je možné v Pythonu zpracovávat pomocí pyLDNS (wrapper okolo LDNS).

Použití tohoto modulu není pro jiné účely, než je testování, doporučeno. Důvodem je samotná knihovna libpython. Tato knihovna nepodporuje více samostatných interpretů v rámci jednoho procesu. Libpython nepoužívá kontext pro předávání konfigurace interpretru; kontext interpretu existuje jako globální struktura(y) v prostoru procesu. Libpython sice implementuje něco, čemu říká sub-interpreter, ale jak sami tvůrci v dokumentaci uvádí, izolace těchto „pod-interpretrů“ není úplná. Při použití funkcí z nízkoúrovňových operací připouštějí jejich vzájemné ovlivňování.

Konfigurace
DNS Collector je možné spouštět na popředí z příkazové řádky. V tom případě je možné konfigurovat a používat pouze jedno síťové rozhraní či archiv a jeden modul. Tento režim slouží zejména k testování modulů nebo ke spouštění v dávkovém režimu pro postupné zpracování více archivů. Primární určení DNS Collectoru je být spuštěn jako daemon pro monitorování DNS provozu. V tomto případě je vhodnější používat konfigurační soubor, ve kterém je možné současně specifikovat nastavení několika síťových rozhraní společně s několika moduly.

Experimentální konfigurace NETCONFem
Pro použití ve vzdálených zařízeních je experimentálně implementována možnost konfigurace pomocí protokolu NETCONF. NETCONF je protokol založený na XML, umožňující konfiguraci síťových zařízení. Funkce NETCONF serveru je naprogramována s využitím knihovny libnetconf. Tato knihovna implementuje NETCONF server a klient a bezpečný komunikační SSH kanál.

DNS Collector na listopadové konferenci CZ.NIC
Pokud vás tento projekt zaujal a máte k němu otázky, můžete samozřejmě využít komentářového formuláře. Jestli se ale chcete dozvědět více a zeptat se přímo, doporučil bych vám, abyste si udělali čas na naši konferenci Internet a Technologie 13.2 (30. 11., MFF UK, Praha), v jejímž již brzy zveřejněném programu prezentace na toto téma bude.

Karel Slaný

Jak ochránit svou doménu před chybou registrátora a neskončit jako avg.com?

Možná jste zaznamenali útok na doménu známého výrobce antivirového softwaru. Pokud ne, zde je krátké shrnutí.

Před několika dny byl palestinskou hackerskou skupinou KDSM v dopoledních hodinách změněn obsah stránky avg.com a dalších. Na stránce se objevilo politické prohlášení této skupiny, které se vztahovalo k problematice Palestiny a Izraele. Nutno dodat, že poškozených doménových jmen bylo údajně více, dalším z potvrzených je doména jiného antivirového produktu avira.com.

Prohlaseni

Prohlášení na stránce avg.com

Pro nás bezpečáky i pro držitele doménových jmen je však asi nejdůležitější vědět, co se stalo na pozadí a jak se proti takové situaci co nejlépe chránit. Podle dostupných informací se opakovala podobná situace, k jaké došlo v říjnu minulého roku u domény google.ie.

Útočníkům se tedy opět podařilo přes registrátora změnit informace o DNS serverech, na kterých je doména spravována. Na DNS serveru ovládaném útočníky pak již útočníci nasměrovali záznam na své webové stránky, tedy na stránku s již zmiňovaným prohlášením.

Podle prohlášení společnosti Avira se zdá, že v tomto případě buď zafungovalo sociální inženýrství nebo nějak selhala logika aplikace, která je u registrátora Network Solutions používaná při resetování hesel. Doufejme, že se společnost Network Solution k celé věci později vyjádří, abychom si mohli o útoku udělat co nejpřesnější obrázek.

A jak se tedy podobné chybě na straně registrátora bránit? Již v odkazovaném blogpostu o únosu domény google.ie jsem upozorňoval, že pomocí formuláře na našich stránkách je možné požádat o zablokování veškerých změn na konkrétní doméně v registru .cz domén. V té době však bylo možné blokaci i odblokování provést pouze pomocí žádosti s úředně ověřeným podpisem, či pomocí e-mailu podepsaného kvalifikovaným certifikátem. Díky nové službě doménový prohlížeč se však situace velice zjednodušila a samotnou blokaci či odblokování lze provést on-line a to dokonce nad více objekty najednou. Výhodou je, že stačí jednou validovat váš účet služby mojeID a získáte možnost kdykoliv zapnout či vypnout rozšířenou ochranu vaší domény v centrálním registru. Při původní metodě bylo potřeba se pro každou změnu autorizovat zvlášť.

Možnost zablokovat provádění změn na doméně se ve světle množících se útoků na registrátory domén ukazuje jako čím dál důležitější. Nově zavedená možnost provádět tyto změny on-line pomocí služby doménový prohlížeč usnadňuje používání této služby a přímo vybízí k jejímu většímu využívání. Pokud je pro vás vaše doména a její správné fungování důležité, měli byste využití této nově nabízené možnosti co nejdříve zvážit.

Pavel Bašta

Proč je opravdu zapotřebí DNSSEC?

Amir Herzberg a Haya Shulmanová z izraelské Bar Ilan University na konferenci IETF 87 v Berlíně představili novou variantu otrávení DNS pomocí fragmentace IP paketů. Kompletní prezentaci lze najít v IETF 87 Proceedings.

Doporučuji si pro osvěžení tématu znovu přečíst o útoku na DNS, který před pěti lety objevil Dan Kaminsky. Kromě použití technologie DNSSEC, která je jedinou opravdu funkční ochranou proti podvrhávání DNS odpovědí, se jako jedna z obran začaly používat náhodné zdrojové porty, které přidaly dalších ~16 bitů entropie.

Už v té době jsme ve studii (kratší shrnutí) upozorňovali, že ani větší počet náhodných bitů nezaručuje ochranu před podvržením a otrávením DNS, a s dostatečně velkým datovým tokem (~100Mbps) je možné otrávit DNS za dobu lehce překračující jeden den (~25 hodin).

Izraelští výzkumníci nyní přišli s novými variacemi útoku na DNS, které ukazují, že opravdu potřebujeme kryptograficky silné DNS a potřebujeme jej pokud možno ihned.

Hlavička IPv4 paketu vypadá takto:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          <strong>Total Length</strong>         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         <strong>Identification</strong>        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    <strong>Destination Address</strong>                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Celá hlavička UDP datagramu vypadá takto:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    <strong>Destination Address</strong>                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Důležité je vědět, že v případě, že spojení mezi dvěma směrovači má nižší MTU (Maximum Transmission Unit) dojde k fragmentaci paketu na několik částí, které jsou identifikovány stejným číslem v poli Identification (dále IP-ID). Fragmentovaný provoz může vypadat například takto:

14:56:02.608188 IP (tos 0x0, ttl 64, id 47557, offset 0, flags [+], proto ICMP (1), length 1500)
    217.31.204.249 > 12.22.58.30: ICMP echo request, id 22368, seq 1, length 1480
14:56:02.608193 IP (tos 0x0, ttl 64, id 47557, offset 1480, flags [none], proto ICMP (1), length 48)
    217.31.204.249 > 12.22.58.30: ip-proto-1
14:56:02.797078 IP (tos 0x0, ttl 60, id 61513, offset 0, flags [none], proto ICMP (1), length 1528)
    12.22.58.30 > 217.31.204.249: ICMP echo reply, id 22368, seq 1, length 1508

Jak lze vidět, tak odchozí ICMP zpráva typu echo request (tj. ping) byla rozdělena na dvě části s IP-ID = 47557 a rozdílnými offsety. Fragmentované části paketu pak budou v cíli spojeny do jednoho a aplikace, která přenesenou zprávu zpracovává, ji dostane v jednom bloku. A protože k defragmentaci paketů dochází až v cílové destinaci a směrovače fragmentované pakety nijak speciálně nesledují, tak je možné, že každá část fragmentovaného paketu dorazí k cíli například jinou cestou nebo v jiném pořadí, než byly fragmenty odeslány.

Toto skládání částí paketu mimo pořadí nahrává útočníkovi. Pokud ví, jaké je po cestě MTU, což nemusí být tak složité zjistit, tak může začít podvrhovat následné (tedy druhé a vyšší) části paketů. Takto podvrhnuté fragmenty můžou mít dvojí efekt – jednak je možné do druhé části paketu vložit vlastní obsah a jednak v případě rozdílné udané velikosti celého paketu je možné donutit operační systém, který je zodpovědný za defragmentaci paketu, aby (pro útočníka) nežádoucí pakety zahazoval (tj. taková trochu chytřejší varianta DDoS útoku).

Další (a poslední) část fragmentační skládačky spočívá v tom, že existuje ICMP zpráva typu fragmentation needed, kterou si počítače na cestě domlouvají maximální velikost paketu, kterou dokážou přenést. V případě IPv4 je minimální velikost MTU 68, v případě IPv6 je to 1280. Bohužel tuto zprávu lze celkem dobře podvrhnout a cílový server donutit snížit MTU na hodnotu, která je pro útočníka výhodná. Tato nová hodnota je v operačních systémech držena v dočasné paměti až několik minut.

Jaké to tedy má důsledky pro DNS? Na to se musíme podívat do hlavičky DNS zprávy:

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Již jsme si řekli, že ochranu proti spoofingu nám zajišťuje ID v hlavičce zprávy (16 bit) společně se zdrojovým portem v UDP zprávě (16 bit).

Když se ale podíváme zpátky pouze na IP vrstvu, tak zjistíte, že obě informace (DNS-ID i source port) jsou vždy uloženy pouze v prvním IP fragmentu, tudíž útočníkovi stačí podvrhnout druhou část paketu, kterou nahradí vlastním obsahem. Při podvrhávání potřebuje útočník uhádnout jenom správné IP-ID, aby se podvržený fragment spojil se začátkem platné odpovědi. Kromě toho, že hádání 16-bitového IP-ID je velmi jednoduché provést pouhou hrubou silou, tak celou situaci ještě zjednodušuje fakt, že hodnoty IP-ID se většinou negenerují úplně náhodně. Na některých operačních systémech existuje globální counter IP-ID, takže hodnotu aktuálního IP-ID systém vyzrazuje s každým odeslaným paketem (a útočník tedy přibližně ví, do jakého rozsahu se má trefovat). Pokud cíl útoku běží na Linuxu, tak je to pro útočníka naštěstí trochu složitější, protože pro každou cílovou adresu má Linuxové jádro zvláštní IP-ID counter, ale i toho však lze bohužel zneužít.

Poslední komplikace, kterou útočník musí vyřešit, je kontrolní součet v UDP hlavičce. Nicméně ani to není velký problém, protože jednak útočník ví, jak bude odpověď DNS serveru vypadat, protože se sám může zeptat, a v DNS paketu je vetšinou dost místa na to, aby kromě falešné odpovědi do DNS paketu ještě nacpal další data, kterými 16-bitový kontrolní součet nastaví na požadovanou hodnotu.

Poslední zefektivnění útoku probíhá opět již na IP vrstvě a závisí na implementaci IP stacku v jednotlivých operačních systémech, nicméně je možné říci, že ve většině případů je možné tuto optimalizaci dost efektivně využít. Již jsme si výše řekli, že fragmentované pakety mohou přijít mimo pořadí, a protože je UDP nespojovaný protokol a zároveň vrstva, která dělá defragmentaci v IP stacku nemá moc ponětí o vrstvách vyšších, je možné podvržené druhé fragmenty poslat dopředu na náš cíl útoku a ony se uloží do vyrovnávací paměti operačního systému. Teprve po tomto „nahrání“ druhých fragmentů útočník vyvolá Kaminsky-style dotaz, a odpověď, kterou cílová aplikace dostane, bude složena z přednahraného části a prvního fragmentu správné odpovědi.

Celý koncept útoku dále v Laboratořích CZ.NIC zkoumáme, a mimo jiné bychom rádi v rámci ověření efektivity takového útoku vyrobili funkční PoC (Proof of Concept) implementaci celého útoku. O tom, zda-li jsme uspěli, Vás budeme dále informovat.

Na závěr bych rád řekl jednu špatnou a jednu dobrou zprávu. Ta špatná zpráva je, že v současné době není proti tomuto útoku známa žádná jiná efektivní obrana než nasazení DNSSECu. Ta dobrá zpráva je, že pokud máte doménu .CZ, tak máte skoro 40% šanci, že Vás DNSSEC chrání. Jestli chcete vědět, jak s DNSSEC pracovat, přijďte do naší akademie. Kurz se jmenuje více než prozaicky – DNSSEC – zabezpečení DNS.

Ondřej Surý

Response rate limiting pod drobnohledem

O RRL již krátce psal Ondřej Surý v článku Ochrana obětí před DNS amplification útoky, tak tedy jen v rychlosti oč se jedná. RRL je jedna z metod, jak se poprat s amplifikačními útoky na DNS, která shlukuje podobné odpovědi do tříd a následně omezuje rychlost toku odpovědí v pro danou třídu. Jedná se v podstatě o opak filtrování dotazů na firewallu a výhodou je právě třeba identifikace různých dotazů vedoucí na podobnou odpověď, typicky na neexistující jméno. RRL v současné chvíli implementuje BIND9/10, NSD od verze 3.2.15 a Knot DNS od verze 1.2.0-rc3.

Vzhledem k tomu, že v současné chvíli není tento mechanismus nijak standardizován, každá implementace se chová mírně odlišně. Podívejme se trochu blíže na tři nejzajímavější rozdíly a to, jaký vliv mají na chování serveru pod útokem.

Základní časovou jednotkou pro měření rychlosti toku je vteřina, pro kterou do každé třídy přibyde počet tokenů odpovídající povolené rychlosti. S každou odpovědí se pak token odebírá, a pokud už jsme vše vyčerpali, odpověď zahazujeme. BIND9 k tomu navíc zavádí ještě jedno „makro okno“, které průměruje rychlost toku pro několik následujících vteřin. Zásadním rozdílem je, že v rámci tohoto okna se může počet dostupných tokenů snížit do záporných hodnot, a tím vyčerpat kapacitu pro celý zbytek okna. Jestli je například okno dlouhé 5 vteřin, limit je 10 odpovědí za vteřinu a v první vteřině přijde 50 podobných dotazů, tak následující 4 vteřiny nebude podobné dotazy zodpovídat. Knot DNS ani NSD takový koncept nemají, dá se tedy říct že délka časového okna je 1s. Důvodem je větší férovost odezvy, každá vteřina začíná s čistým štítem, avšak za cenu menší agresivity potlačení nárazových toků.

Co ale dělat v případě, že přijde legitimní dotaz v době, kdy byl vyčerpán počet tokenů? Úplně jej zahodit? Takový dotaz jen velmi těžko rozlišíme od útoku, ale přesto bychom měli dát legitimnímu tazateli možnost získat odpověď a ne jej úplně odstřihnout. Místo toho, aby tedy server dotaz zcela ignoroval, tak odešle prázdnou odpověď s nastaveným TrunCated bitem v hlavičce. Tazatel je pak nucen opakovat dotaz po TCP, na který už dostane odpověď. Takovému mechanismu se říká SLIP (podporují ho všechny implementace). Knot DNS se odlišuje tím, že má počítadlo pro každé vlákno zvlášť, a pro menší rychlost toku není tak přesný. Během testování se ale nepřesnost nijak zvlášť neprojevila a největší vliv má konzervativní výchozí nastavení.

dknight_rrl_measurement
(Zdroj: Comparison of RRL behaviour in BIND9, Knot DNS, and NSD, Dave Knight, DNS-OARC Spring 2013)

Třetí zásadní odlišností je způsob klasifikace odpovědí. Technické memo a BIND9 klasifikují odpověď pomocí:

  • Zdrojové adresy (podsítě)
  • Dotazovaného jména (nebo zóny v případě chyb, nadřazeného jména pokud je odpověď pokrytá wildcardem)
  • Návratové hodnoty (RCODE)

NSD navíc rozlišuje několik podtříd dotazu, např. pokud je dotaz na typ ANY, Knot DNS dotazy navíc ještě klasifikuje podle velikosti. Všechny současné implementace jsou založené na hash tabulkách. Liší se ale výrazně v tom, jakým způsobem řeší kolize. Implementace v BIND9 je založená na přeplňování tabulek, přičemž kolidující klíče se řetězí za sebe (do omezeného počtu). A právě o kolizích probíhala na mailinglistu RRL dost živá diskuze. Abych to vysvětlil, řetězení dobře řeší kolize pokud je zdrojová podsíť různá, ale pořád zůstává možnost kolize hashe dotazovaného jména, které se neukládá celé. Nově ale zavádí potenciální problém, a to že útočníkovi do určité míry možnost kontrolovat množství alokované paměti pro tabulku a ztrácí výkon na procházení zřetězených hodnot.

NSD používá tabulku pevné velikosti, bez řetězení. Netrpí tedy na výše popsané problémy, ale s větší pravděpodobností umožňuje útočníkovi předem spočítat kolidující odpovědi (Birthday attack) v závislosti na velikosti tabulky. Protože není kolize kam řetězit, tak pro danou třídu resetuje počet tokenů, což sice na jednu stranu vylučuje riziko omezení kolidujících odpovědí, ale umožňuje při nalezení dvou kolidujících dotazů rate limiting zcela obejít.

Knot DNS využívá hopscotch hashing, který je velmi dobrým kompromisem s nízkou pravděpodobností kolize (1/32!) při zachování pevné velikosti. Zároveň do klíče přidává náhodně generované tajemství pro znesnadnění predikce kolizí a umožní jen jeden reset počítadla třídy za vteřinu.

rrl_effective

Ze zatím dostupných měření na reálných datech vyplývá, že chování všech implementací je i přes popsané rozdíly velmi podobné a liší se především citlivostí u pomalého toku dotazů. Hlavním omezením metody založené na rate limitingu je především nemožnost rozlišit právoplatný dotaz od útoku, což ale při rozumné spolehlivosti není ani prakticky možné. Příliš agresivní omezení by tak mohlo vést k přílišnému zahazování právoplatných dotazů, konzervativní zase k nižší účinnosti. BIND9 doporučuje agresivnější nastavení, Knot DNS je spolu s NSD spíše na konzervativní straně (RRL ve výchozím nastavení vypnuté, v dokumentaci 50 r/s).

Marek Vavruša

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ý

Quo vadis Knot DNS?

Uběhl téměř rok od doby, kdy z Laboratoří CZ.NIC vyšla první ostrá verze autoritativního DNS serveru Knot DNS. Kde všude běží a co na něj říkají uživatelé?

Začátky byly skromné, o to více nás proto potěšil zájem komunity, která se nám stará o balíčky a porty. Můžete nás najít například v linuxových distribucích Ubuntu, Fedora, Gentoo a openSUSE. Co se BSD balíčků a portů týče, tak FreeBSD a NetBSD. Zároveň nás velmi potěšilo zařazení do programu Coverity Scan, nástroje pro statickou analýzu kódu, která je pro open-source software zcela zdarma. Statická analýza nám pomohla odhalit několik zajímavých chyb a přispěla tak celkově ke zkvalitnění kódu.

Ale zpět k uživatelům. Prvním velkým nasazením byly domény CZ.NICu. První vlaštovkou byla doména knot-dns.cz, později se přidávaly další a nakonec i samotná doména .cz, kde Knot DNS můžete najít v anycastovém uzlu. Počáteční problémy nám byly neocenitelnou zpětnou vazbou a napomohly k odladění řady chyb. Přestože byl Knot DNS původně zaměřen pro větší TLD, našel si cestu i k hostingovým společnostem a jednotlivcům. Z českých mohu zmínit například společnosti HOSTING90 a igloonet.

Naším nejnovějším velkým přírůstkem v zahraničí je dánská .dk doména, kde se Knot DNS zatím zdárně rozbíhá :). V experimentálním provozu server kořenové zóny L-root a ruská .ru doména. U kořenové zóny se projevil problém s nedostatečnou kompresí jmen mimo zónu, do odpovědi se tak bez EDNS0 nevešla část záznamů v Additionals sekci. Tento problém byl již odstraněn, snad se tedy dostane do ostrého provozu. Nejčastěji si pak uživatelé chválí jednoduchost, rychlost a také možnost přidávat a odebírat zóny za běhu. Co naopak doposud chybělo, je DDNS, jednoduché statistiky a možnost vzdáleného ovládání.

A co máme v plánu do budoucna? K Vánocům vám nadělíme verzi 1.2, která přinese podporu pro DDNS a po novém roce dlouho chystanou verzi s optimalizovanou spotřebou paměti, novou ovládací utilitou a bleskurychlým načítáním zón.

Marek Vavruša

DNSCheck – otestujte si svoji doménu!

Sdružení CZ.NIC před nedávnem zveřejnilo stránky http://dnscheck.labs.nic.cz sloužící ke kontrole správného nastavení domény. Na těchto stránkách si můžete otestovat svou doménu a zjistit, zda máte všechna nastavení v pořádku, případně opravit nalezené chyby.

Logickou otázkou je, co znamená „v pořádku“. Zde se můžou názory lišit a proto vycházíme z norem (RFC) a z dlouhodobých zkušeností. Pokud přesto narazíte na chybu, kterou za chybu nepovažujete, nebo naopak budete mít pocit, že určitý stav by měl být chybou, dejte nám samozřejmě vědět a můžeme metodiku přehodnotit. K dispozici máte i historii testů pro danou doménu, kde si můžete prohlédnou výsledky dřívějších testů. V záložce „Detailní výsledky“ najdete popis jednotlivých testů, které byly prováděny, včetně jejich výsledků.

Pokud se budete chtít se svým výsledkem pochlubit ostatním nebo budete chtít požádat o radu s odstraněním problémů, máte pod každým testem k dispozici trvalý odkaz, s nímž potom můžete dál pracovat.

Nezbývá tedy než vám popřát mnoho testů bez chyb a pro inspiraci se můžete podívat, jak by to v ideálním případě mělo vypadat.

Petr Černohouz

Slabé RSA kľúče v TLS a DNSSEC

Praktických dôkazov, že RSA kľúče s modulum menším 1024 bitov (špeciálne 512-bitových) môžu predstavovať bezpečnostné riziko, sa za posledný rok objavilo viacero. Autori malware zneužili slabé 512-bitové RSA kľúče z certifikátov, ktoré mali vhodnú kombináciu X.509v3 extensions a podpisovali nimi malware. Útočníci v tomto prípade pravdepodobne faktorizovali modulus a získali tak privátny kľúč. Výskumníci tiež ukázali, že „okamžitá“ faktorizácia 512-bit RSA modulu je uskutočniteľná a relatívne lacná (menej než cca $150).

Aj keď to boli najskôr posledné X.509 certifikáty zneužiteľné na podpis kódu (ostatné známe sme našli a sú revokované), stále existuje mnoho serverov, ktoré posielajú 512-bitové certifikáty v TLS handshake, napríklad pri naväzovaní HTTPS komunikácie. Doporučené veľkosti kľúčov k rôznym algoritmom uvádza prehľadná tabuľka vychádzajúca z doporučení ECRYPT II (podrobný popis ako sa k hodnotám dostali obsahuje objemný ECRYPT II Yearly Report on Algorithms and Keysizes 2011).

Našťastie od júla 2012 platia nové požiadavky CAB fóra na certifikáty vydávané od CA – už nesmú mať RSA moduly menšie než 1024 bitov, naviac tie s dlhodobou platnosťou musia mať modulus veľkosti aspoň 2048 bitov. Microsoft tiež čoskoro začne blokovať certifikáty s RSA modulom menším než 1024 bitov. Zmeny k lepšiemu je už vidieť ako postupne CA revokujú staršie certifikáty so slabými RSA modulmi, ale stále sa občas nejaký 512-bit nájde.

Podobný problém so slabými RSA sa samozrejme netýka len TLS komunikácie, ale môže nastať tiež v DNSSEC. Ak útočník kľúč faktorizuje, môže pri man-in-the-middle útoku na DNSSEC falšovať podpisy DNS záznamov (tým pádom aj prípadne meniť asociácie na kľúče a certifikáty pinované cez záznamy typu SSHFP alebo TLSA).

Ako to vyzerá s RSA kľúčmi v doméne CZ? Keď sme robili prieskum DNSSEC kľúčov používaných v doméne .CZ pred pol rokom, tak domén s DNSSEC kľúčom s RSA modulom menším než 1024 bitov bolo mnoho (rádovo stotisíc), pri teste 20. júla 2012 už je ich zásadne menej:

  • domén s kľúčom menším ako 1023 bitov: 6635
  • unikátnych kľúčov so slabým modulom: 5209
  • v dvoch prípadoch sa jedná o Key Signing Key, zbytok sú Zone Signing Keys; jeden z týchto KSK už nie je používaný (ale je v zóne)
  • päť kľúčov má 768-bit modulus, zbytok 512-bit
  • jedna doména má kľúč so slabým verejným exponentom (3)
  • existuje jeden revokovaný DNSKEY RSA kľúč s malým modulom

Pre porovnanie veľkosti kľúča a periódy zmeny ZSK odkážem na blog Erica Rescorlu, kde ukazuje, že priame použitie silnejšieho kľúča prináša lepšiu bezpečnosť než častá zmena (key rollover).

Súčasné doporučenia pre KSK a ZSK RSA kľúče znejú:

  • KSK  2048 bitov
  • ZSK  1024 bitov
  • verejný exponent 65537 (0x10001 hex)

Uvedené hodnoty sú minimálne. Tu zase platí, že ani s veľkosťou kľúčov to netreba preháňat – príliš veľké moduly alebo exponenty majú za následok spomalenie overovania RSA podpisu.

Poznámka na koniec: Teoreticky verejný exponent môže byť aj menší (napr. 3), vyšší exponent ale bráni proti implementačným chybám umožňujúcim varianty Bleichenbacherovho útoku (u schém používajícich PKCS#1 v1.5 RSA padding, stalo sa nedávno u openssl – netýkalo sa SSL/TLS, ale CMS).

Ondrej Mikle

Závažná vzdálená zranitelnost v DNS serveru NSD

Kolegové z vývojového týmu Knot DNS se kromě vývoje také velmi pečlivě věnují testování, kterým se snažíme odhalit jednak chyby v samotném kódu našeho serveru, ale také odchylky od „standardu“ s důrazem na interoperabilitu jednotlivých serverů. Píši „standard“ DNS s uvozovkami, jelikož se jedná o souhrn dokumentů, které jsou někdy velmi nejasné, a jejich výklad záleží spíš na dohodě celého DNS ekosystému.

V rámci tohoto testování kolegové z Laboratoří CZ.NIC připravují také sadu DNS dotazů, které jsou nestandardní a zjišťují chování vybraných open-source DNS serverů (Bind 9, NSD 3,…). Jeden z uměle vytvořených testů, které připravili mí kolegové Marek Vavruša a Ľuboš Slovák, za TSIG podpis DNS zprávy připojoval další prázdný RR záznam (konkrétně prázdný TXT záznam). Při testování se ukázalo, že NSD ve všech verzích 3.x (i vývojové verzi 4.x) obsahuje zranitelnost, která je zneužitelná pro pád DNS serveru z libovolného místa v Internetu. Při přijmutí takové DNS zprávy dojde k dereferenci NULL pointru a NSD spadne s chybou SIGSEGV.

Tento problém jsme kolegům z NLnet Labs nahlásili v pondělí krátce po poledni a hned další den ráno jsme měli v poště opravný patch, který přikládám na konec tohoto blogpostu. V době vydání tohoto blogpostu by také na stránkách NSD měla být k dispozici verze 3.2.12, která tento bezpečnostní problém opravuje.

Jelikož se jedná o vzdálenou zranitelnost, na kterou neexistuje žádný workaround, důrazně doporučujeme v případě, že používáte NSD 3, okamžitě záplatovat vaše DNS servery.

Patch:

--- query.c (revision 3609)
+++ query.c (working copy)
@@ -1379,6 +1379,9 @@
edns = &nsd->edns_ipv6;
}
#endif
+ if (RCODE(q->packet) == RCODE_FORMAT) {
+ return;
+ }
switch (q->edns.status) {
case EDNS_NOT_PRESENT:
break;

Ondřej Surý

Test dnes: jak si vedl Knot DNS

Při příležitosti nedávné prezentace Knot DNS na Tech26 (CENTR Jamboree) jsme aktualizovali metodiku měření a chtěli bychom se podělit o nové výsledky.

Testování nyní proběhlo na syntetické zóně se zastoupením podporovaných RR typů na testovaných serverech (Knot DNS, BIND 9, NSD 3 a YADIFA[*]). Zóna obsahuje 1 324 899 záznamů, velikost zónového souboru je 76MB. Zároveň byly aktualizované testovací sady dotazů, které se nyní skládají z dotazů jak na existující, tak neexistující jména v poměru 1:1. Důvodem bylo prověřit výkon datových struktur serveru i při vyhledávání neexistujících jmen. Existující jména byla vybrána náhodným způsobem z tohoto zónového souboru. Konfigurace, zónový soubor, testovací sada pro program dnsperf (1 000 000 dotazů, 18MB) i syntetický provoz ve formátu pcap (50 000 dotazů, 4,2MB) jsou včetně dalších nástrojů volně ke stažení v Git repozitáři.

Prvním testem je škálovatelnost, kdy se měří závislost výkonu serveru na počtu spuštěných vláken/procesů. Výkon serveru je měřen programem dnsperf od společnosti Nominum. Tento test je specificky navržen pro měření výkonnosti autoritativních DNS serverů a mezi jeho přednosti patří regulace rychlosti dotazování, čímž poměrně věrně simuluje reálný síťový provoz. Jak je z grafu pro Linux patrné, podařilo se nám oproti verzi 1.0.3 vyřešit problém s plánováním vláken a nyní téměř dosahujeme naměřené propustnosti sítě. Ta byla změřena utilitou trafgen s malými UDP pakety (payload 60B) a zanesena do grafu. V případě tohoto testu nebylo možné určit u serveru Yadifa zadaný počet vláken, proto běží stále ve výchozím nastavení.


K testu škálovatelnosti nám přibyl nový test, který měří závislost podílu zodpovězených dotazů na rychlosti odesílaných odpovědí. Tento test byl dříve použit např. pro měření výkonnosti serveru NSD nebo nově Yadifa. V tomto testu figurují všechny tři stroje, kdy na prvním běží testovaný server, druhý pouze generuje provoz zadanou rychlostí a třetí zachytává odpovědi ze serveru. Pro testování byly využity standardní nástroje tcpreplaytcpdump. Ze získaných dat se vypočte procento zodpovězených dotazů pro danou rychlost. Každý test je třikrát opakován a jako výsledek se počítá průměrná hodnota. Z grafu je patrné, že Knot DNS 1.0.6rc1 i na Linuxu zodpověděl téměř všechny všechny dotazy zaslané maximální dosažitelnou rychlostí.

Samotné testování probíhalo na třech shodných strojích osazených procesorem Intel Xeon X3430 a 2GB RAM, propojených 1Gb ethernet linkou se síťovými kartami Broadcom BCM5723. První stroj slouží k běhu serveru, druhý ke generování dotazů a třetí k zachytávání odpovědí. Testy byly prováděny na 64bit OS Linux 3.0.0 a FreeBSD-8.2. V současné době je výkon omezen dosaženou propustností sítě, nicméně chystáme testování s rychlejší síťovou kartou a věříme, že je ještě prostor pro další zlepšení.

Marek Vavruša

* – Yadifa bohužel podporuje jen omezenou sadu RR typů, nicméně pro tento druh testování to nevadí