Novinky v Knot DNS 2.0

Od vydání finální verze Knot DNS 2.0 uplynulo již několik týdnů. Dokud je to stále aktuální, rád bych sepsal, co nás vedlo k vydání této nové důležité verze, a shrnul nejdůležitější změny a novinky.

Připravte se na odborné kurzy Akademie CZ.NIC

Některé odborné kurzy v naší nabídce vyžadují aspoň základní znalost protokolů TCP/IP. A dosud bylo na účastnících, jakým způsobem si základy TCP/IP nastudovali. Nyní však mají možnost projít si před samotným workshopem bezplatný e-learningový kurzu v prostředí Moodle, kde si mohou osvěžit, co již možná zapomněli.

Zfušovaný Internet

Všichni se shodneme, že na Internetu najdeme spoustu věcí, které jsou nepříjemné, otravné či dokonce škodlivé. Stojí nás čas, peníze a vnitřní klid. Ale ne všechny tyto věci vznikají se zlým úmyslem. Často je tomu dokonce naopak. Ale jak se říká, cesta do pekel je dlážděna dobrými úmysly.

Ukázalo se, že projekt Turris je takovým magnetem na nepříjemnosti způsobené jinými subjekty.

Celý článek

Validace DNSSEC pomocí Dnsmasq

Dnsmasq je jednoduchá implementace základních síťových služeb — vše v jednom: DNS, DHCP, router advertisement a bootování ze sítě. Pro svou velikost (maličkost) a nenáročnost na systémové prostředky si našel místo na mnoha domácích routerech. Dnsmasq také spravuje virtuální sítě v sadě nástrojů libvirtd. A v neposlední řadě je k nalezení i na některých smartphonech (včetně Androidu), kde se používá pro tethering.

9. dubna 2014 vyšel Dnsmasq verze 2.69, který do vínku dostal podporu validace DNSSEC. To určitě stojí za vyzkoušení.

Knot DNS na OpenWRT

Projekt autoritativního serveru Knot DNS již není třeba představovat. Stojí však za zmínku, že lze server rovněž provozovat i v prostředí OpenWRT, a tedy i na routeru Turris. Dnes si tu popíšeme jak na to.

Ačkoli balíček Knota nebyl dosud začleněn do repozitáře OpenWRT, můžeme si ze stránek projektu stáhnout port balíčku, pomocí kterého si již snadno sestavíme binánární balíček pro naši konkrétní architekturu.

V našem příkladu budeme předpokládat, že pracujeme s OpenWRT verze 12.09. Některé starší verze jsou rovněž podporované. V případě hlavní vývojové větve je průběh ještě jednodušší, neboť potřebná závislost, knihovna liburcu, je v ní již začleněna.

Začneme stažením prostředí Buildroot:
git clone --depth 1 git://git.openwrt.org/12.09/openwrt.git

Jak již bylo zmíněno, OpenWRT 12.09 neobsahuje balíček knihovny liburcu. Proto si ho vypůjčíme z vývojové větve:
git clone --depth 1 git://git.openwrt.org/packages.git
cp -a ./packages/libs/liburcu ./openwrt/package/


Nyní už jen zbývá samotný port Knot DNS verze 1.4.4:
wget https://www.knot-dns.cz/static/download/knot-1.4.4-owrt.tar.gz
tar -xzf knot-1.4.4-owrt.tar.gz
cp -a ./knot ./openwrt/package/


Nastavení překladu provedeme následující sekvencí příkazů:
cd openwrt
make defconfig
make prereq
make menuconfig


V konfigurátoru nastavíme požadovanou platformu (např. ar71xx):
Target System>ar71xx
a zaškrtneme balíček serveru:
Network>IP Addresses and Names>knot
Dále můžeme zaškrtnout pomocné utility (kdig, khost, knsupdate a knsec3hash):
Network>IP Addresses and Names>knot-utils
A pokud si chceme ověřit, že Knot bude pracovat správně na naší platformě, zvolíme i sadu základních testů:
Network>IP Addresses and Names>knot-tests

Následuje překlad potřebných utilit a našich balíčků:
make tools/install
make toolchain/install
make package/knot/compile


Po několika desítkách minut se můžeme tešit na balíčky:
./bin/ar71xx/packages/knot_1.4.4-1_ar71xx.ipk
./bin/ar71xx/packages/knot-utils_1.4.4-1_ar71xx.ipk
./bin/ar71xx/packages/knot-tests_1.4.4-1_ar71xx.ipk
./bin/ar71xx/packages/liburcu_0.7.6-1_ar71xx.ipk


Předchozí soubory nakopírujeme na cílové zařízení (scp) a připojíme se na terminál (ssh).

Následuje instalace:
opkg install liburcu_0.7.6-1_ar71xx.ipk
opkg install knot_1.4.4-1_ar71xx.ipk
opkg install knot-utils_1.4.4-1_ar71xx.ipk
opkg install knot-tests_1.4.4-1_ar71xx.ipk


Základní testy spustíme:
cd /usr/share/knot/tests
./runtests -l TESTS -b /tmp

Postfix dostal podporu pro DANE protokol

Podporu pro protokol DANE již nějakou dobu můžete v prohlížeči používat pomocí rozšíření DNSSEC Validator dostupné pro prohlížeče Firefox, Chrome/Chromium a Internet Explorer. A hned na začátku tohoto roku bych rád přivítal prvního zástupce serverové aplikace s podporou protokolu DANE, jelikož 15. ledna vyšla nová stabilní verze poštovního démona Postfix, která mimo jiné přináší podporu pro protokol DANE. Autoři Postfixu se rozhodli, že pro poštovní servery, které ve valné většině používají self-signed certifikáty, nemá moc smysl podporovat duální kontrolu CA + DANE a tudíž implementace v Postfixu podporuje pouze Certifikate Usage 2 – „Vlastní kořen důvěry (CA)“ a 3 – „Vlastní self-signed certifikát“. Certificate Usage 0 – „Omezení na konkrétní CA“ a 1 „Omezení na konkrétní certifikát od CA“ se mapují na typy 2 a 3.

Pojďme si nyní rychle ukázat, jak takovou podporu na Vašem serveru zapnout.

Na straně přijímající je potřeba mít vygenerovaný certifikát a zapnuté TLS. A jelikož toto není nic nového a dokonce možná toto za Vás udělal rovnou instalační balíček Vaší distribuce, odkázal bych Vás jen na dokumentaci.

Ta zajímavější část přichází ve chvíli, kdy do DNS chceme umístit TLSA záznam, kterým dáme světu vědět, že s námi může komunikovat zabezpečeně, a náš certifikát má odpovídat tomu, který jsme vygenerovali na serveru. Na generování mohu s klidným srdcem doporučit utilitu swede, případně utilitu hash-slinger.

TLSA záznam pomocí utility swede vygenerujeme následujícím způsobem:

swede create --port 25 --protocol tcp --output rfc --usage 3 --selector 1 --mtype 1 --certificate název.serveru

Vygenerovaný záznam, který bude vypadat například takto:

_25._tcp.mail.rfc1925.org. IN TLSA 3 1 1 5afe6a99c7d658a5cee951da6ebe7a21e0d7604f831248177f4283ecf639fad6

vložíte do příslušného zónového souboru a DNS server reloadnete. Pokud Váš DNS server nepodporuje TLSA záznamy, máte dvě možnosti: buď server vyměníte za nějaký modernější (např. Knot DNS) nebo místo volby --output rfc použijete volbu --output generic, která vygeneruje TLSA záznam v obecném formátu, který by měly podporovat i DNS servery bez přímé podpory pro TLSA záznamy.

Tímto jsme zapnuli podporu pro DANE protokol na straně serveru, který poštu přijímá. Jak tedy nastavit ověřování TLSA záznamů na straně odesílajícího serveru?

Předně musíte mít nainstalovaný postfix 2.11.0 a vyšší. Balíčky pro Ubuntu jsou k dispozici například v tomto PPA. Konfigurace je pak velmi jednoduchá, do konfiguračního souboru přidáte tři řádky:

postconf -e "smtp_dns_support_level = dnssec"
postconf -e "smtp_tls_security_level = dane"
postconf -e "smtp_tls_loglevel = 1"

a restartujete Postfix.

Následně se stačí podívat do mail.logu, kde by se měl objevovat pro servery s podporou DANE protokolu následující záznam:

Aug 2 10:35:49 jedi postfix/smtp[24161]: ***Verified*** TLS connection established to mail.nic.cz[217.31.204.67]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

a pro servery bez podpory:

Aug 2 10:46:54 jedi postfix/smtp[24300]: ***Untrusted*** TLS connection established to aspmx.l.google.com[2a00:1450:4001:c02::1b]:25: TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

Na závěr bych chtěl poděkovat Viktoru Dukhovnimu, za jeho práci na implementaci protokolu DANE v Postfixu a Vám popřát šťastné a veselé šifrování v novém roce :).

Ondřej Surý

Generace Y? Ne! Generace DNS!

evolution-man-computer

Generace Y je termín, který používají sociologové pro populaci, která se narodila na začátku 80. let a tedy vyrůstala převážně v době, kdy už byly dostupné mnohé moderní technologie včetně Internetu. A jelikož úplně první standardy, definující protokol DNS, RFC 882 a RFC 883 vznikly v listopadu 1983, tedy akorát před třiceti lety, dala by se Generace Y s trochou nadsázky označit také termínem Generace DNS.

Ať už patříte ke Generaci X, Y nebo Z, tak v každém případě si s námi můžete tuto sobotu DNS připomenout a to na konferenci Internet a Technologie 13.2, kde mu bude patřit celý jeden blok. Kapacita v sále je už delší dobu vyčerpána, ale pokud byste měli zájem, živý přenos z akce začne přibližně v 9:20.

Ondřej Surý

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ý