Princip amplification útoků zneužívajících DNS, NTP a SNMP

Pavel Bašta 12. 1. 2015

V roce 2014 jsme byli svědky několika silných amplification (zesilujících) útoků, které nejčastěji zneužívaly služby DNS resolverů. Jeden z nejsilnějších amplification útoků loňského roku zneužil službu NTP a dosáhl úctyhodné síly až 400Gbps. Princip útoku je bez ohledu na službu, kterou zneužívá, stejný.

Aby bylo možné službu zneužít k amplification útokům, musí splňovat několik podmínek. Předně nesmí před samotným odesláním žádosti o poskytnutí dat probíhat TCP handshake, který by útočníkovi znemožnil podvrhnout zdrojovou IP adresu paketu. Další důležitou podmínkou z pohledu útočníka je získat co největší „amplifikaci“. Tedy dosáhnout toho, aby odpověď, která bude zaslána na podvrženou IP adresu oběti, byla pokud možno násobně větší, než původní útočníkův dotaz. Poslední podmínkou je, aby měl útočník přístup k dostatečnému množství špatně nakonfigurovaných systémů, které pak bude možné zneužít pro útok. Nejen v rámci našeho projektu Turris můžeme vidět, že o skenování známých portů takovýchto služeb je zájem. Útočníci si tak připravují seznamy špatně nakonfigurovaných služeb pro jejich případné pozdější zneužití. Zneužití služeb k amplification útokům je však možné zabránit správnou konfiguraci.

Seriál vznikl za přispění Národního CSIRT týmu České republiky CSIRT.CZ, který provozuje sdružení CZ.NIC, správce české národní domény. CSIRT.CZ je bezpečnostní tým pro koordinaci řešení bezpečnostních incidentů v počítačových sítích provozovaných v České republice. Cílem jeho členů je pomáhat provozovatelům internetových sítí v České republice zřizovat jejich vlastní bezpečnostní týmy a bezpečnostní infrastrukturu, řešit bezpečnostní incidenty a tím zlepšovat bezpečnost jejich sítí i globálního internetu. Více informací na www.csirt.cz.

csirt.cz

Z výše uvedeného tedy plyne, že pro provedení útoku je nezbytné, aby zneužívané služby využívaly ke své komunikaci protokol UDP, který je nespojovaný a neprobíhá u něj tedy na počátku komunikace třícestný handshake. Data z klientské aplikace jsou tak zasílaná rovnou na cílový server bez jakéhokoliv vzájemného ověření a případnou ztrátu paketů během komunikace si musí řešit samotná aplikace. Podmínka UDP protokolu je spojená s možností podvrhnutí zdrojové IP adresy tak, aby byla odpověď na zasílaný požadavek zaslaná na IP adresu zamýšlené oběti. Možnost podvrhnutí IP adresy v požadavku je možná pravě díky neexistujícímu mechanismu navazování komunikace v UDP protokolu. Na úrovní síti je sice možné změně zdrojové adresy zabránit, avšak tento mechanizmus je bohužel stále poměrně málo využíván. Jde o doporučení BCP38 od IETF (Internet Engineering Task Force). Tento mechanizmus filtruje odchozí IP adresy tak, aby síť nemohly opustit pakety s takovou zdrojovou IP adresou, která nepatří do rozsahů přiděleného dané sítí. Implementací tohoto mechanismu sice zabráníte, aby nebyla vaše síť zneužita útočníkem, avšak nezabráníte útočníkovi ve zneužití vašich služeb. Jak omezit nebo v některých případech zabránit útokům zneužívajícím amplifikace na službách DNS, NTP a SMTP si teď vysvětlíme blíže.

DNS amplification

Amplification útoky zneužívající DNS servery jsou nejčastější. Velké množství DNS odpovědí, které jsou zasílané na útočníkem podvrženou IP adresu oběti, může zařízení oběti vyřadit z provozu. K zneužití se přitom nejvíce využívají otevřené rekurzivní name servery. Vzhledem k rozdílu velikosti mezi zasílanými a přijímanými dotazy tak může i útočník s pomalejší linkou zahltit rychlejší linku oběti.

Porovnání zachyceného DNS dotazu typu ANY a odpovědi serveru.

Otevřené resolvery jsou DNS servery, které poskytují své služby také mimo svou síť. V případě, že se ve vaší síti nacházejí otevřené rekurzívní DNS servery, dejte si pozor na nedbalé nastavení, kdy je resolver přístupný neúmyslně taky z vnějšku. Dotazy je možné filtrovat například přes ACL (Access Control List). Abyste zneužití vašeho rekurzívního serveru k amplification útokům předešli, rekurzivní server by měl odpovědět jenom na dotazy přicházející z vašeho přiděleného rozsahu.

Pokud existují důvody k tomu, aby váš rekurzívní DNS server odpovídal také na vnější dotazy, či pokud provozujete autoritativní name servery, je nezbytné vytvořit dobrou politiku limitování dotazů. Technika RRL (Response Rate Limiting) umožní legitimním uživatelům dotazovat se na server, ale zároveň omezí účinek DNS amplification útoků. V současnosti je implementovaná podpora pro RRL u řady autoritativních serverů:

BIND 

V případě BINDu je RRL podporován od verze 9.9.4. Pokud si BIND konfigurujete sami, je třeba použít konfigurační switch. RRL je potřeba nakonfigurovat v konfiguračním souboru přes  --enable-rrl.

$ ./configure –enable-rrl.

Pokud máte BIND z distribučních balíčků, ověřte si v balíčku changelogu, zda podporuje RRL.
Dále je nutné RRL nastavit v konfiguraci daemona BIND.

Například:

options { directory "/var/named"; rate-limit {
responses-per-second 5; log-only yes; }; };

Knot DNS

V případě KnotDNS je RRL dostupný jako standard od verze 1.2.0. V systémové sekci je pak nutné nastavit nenulovou hodnotu parametru rate-limit. Nastavená hodnota znamená povolený počet odpovědí za sekundu (např. rate-limit 50; znamená 50 odpovědí za sekundu). Hodnota, kterou u rate-limit-slip  nastavíme bude znamenat poměr dotazů, na které odpoví truncated (zmenší je). Pokud nastavíme hodnotu rate-limit-slip například na 2, na každý druhý původně blokovaný dotaz odpoví server truncated. Doporučená hodnota 1 má tu výhodu, že amplifikaci omezí a zároveň žádný dotaz neignoruje.

Konfigurace by pak například mohla vypadat takto:

system {
    rate-limit 200; # Each flow is allowed to 200 resp. per second
    rate-limit-slip 1; # Every response is slipped (default)
}

NSD

NSD má od verze 3.2.15, podobně jako ostatní autoritativní servery, implementován Response Rate Limiting. V NSD3 a NSD4 je nutné RRL povolit přes -enable-ratelimit. Podobně jako v případě Knot DNS je možné nastavit také hodnotu RRL SLIP. Ve výchozím stavu je tato hodnota nastavená na 2. V případě, že zóna je pod NSD podepsaná DNSSEC, je možné tuto hodnotu ponechat. Reflektivní DoS by tak odpověděl s RRL SLIP hodnotou 2. DoS útok by tak ztratil polovinu své síly a zároveň by oběť ochránil.

V souboru nsd.conf je možné podle potřeby nastavit hodnoty rrl-size, rrl-ratelimit, rrl-whitelist-ratelimit či rrl-whitelist.

NTP amplification a obrana

NTP rovněž využívá UDP protokol a proto se může podobně jako DNS stát vektorem úspěšného DDoS útoku. NTP amplification pracuje na podobném principu jako DNS amplification útok. Útočník opět zašle NTP serveru požadavek s podvrženou zdrojovou IP adresou, která je zároveň adresou zamýšlené oběti. V odpovědi serveru se pak projeví i „amplification“, tedy zesílení či zvětšení, protože odpověď, kterou server zašle, je násobně větší než přijatý dotaz.

K provedení amplifikace se v případě NTP zneužívá příkazu monlist. Tento příkaz slouží k monitorování provozu na serveru. Pokud je server zranitelný, pak pomocí příkazu monlist můžeme získat seznam posledních až šesti set adres, které se k němu připojily. Skutečnost, že odpověď je mnohonásobně větší než samotný dotaz, je pro potřeby amplification útoku ideální. Zda je NTP server zranitelný zjistíte pomocí příkazu:

$ ntpdc -n -c monlist IP

IP znamená IP adresu serveru, na který se dotazujete. Pokud od serveru obdržíte odpověď, pak to znamená, že tento server může být zneužit k amplification útoku.

Ukázka obsahu datové části IP paketu zachyceného při hledání zneužitelných NTP serverů.

Obrana

Pokud provozujete NTP server, je nejjednodušším způsobem ochrany před zneužitím provedení upgradu na verzi 4.2.8 nebo provedení změny konfigurace. Od vyšších verzí je totiž příkaz monlist zcela odstraněn. Pokud se rozhodnete o změnu konfigurace, to je možné provést v souboru /etc/ntp.conf, přidáním direktivy „ noquery “ do řádků „ restrict default “. Konkrétně se jedná o tyto dva řádky:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

Některé operační systémy mají naštěstí tuto konfiguraci nastavenu ve výchozím stavu. Toto nastavení samozřejmě platí i pro veřejné NTP servery. Je také potřeba pamatovat na to, že se tento problém netýká pouze linuxových/unixových systémů, ale také dalších zařízení, jako jsou Cisco či Juniper routery. Celá zranitelnost byla popsána v CVE-2013–5211.

SNMP amplification a obrana

Simple Network Management Protocol (SNMP) je internetový protokol, který je používán na sběr statistik, testování stavu zařízení a případný aktivní management síťových zařízení a serverů. Nejčastěji se jedná o routery, switche, servery, racky a podobně. SNMP pracuje stejně jako DNS a NTP na UDP protokolu. Na jedné straně komunikace je monitorující zařízení, tzv. „SNMP manager“, na druhé straně jsou pak monitorovaná zařízení, tzv. „SNMP agenti“. SNMP umožňuje administrátorům sledovat z jednoho místa stav všech síťových zařízení.

Útočník může podvrhnout zdrojovou IP adresu v hlavičce paketu nesoucího požadavek SNMP GET. Takto zaslaný SNMP dotaz se bude koncovému zařízení jevit jako legitimní a odpověď bude zaslaná na podvrženou IP adresu patřící oběti.

V tomto případě je potřeba se rozhodnout, která zařízení by měla SNMP podporovat a na kterých to naopak není třeba. Pokud jde o zařízení, u kterých SNMP nevyužíváte, je vhodné u nich SNMP vypnout. Pokud však tento protokol někde využíváte, nejlepší je přejít na SNMPv3, který vyžaduje ověření prostřednictvím jména a hesla a zároveň používá šifrované spojení. Community strings, které slouží jako uživatelské jméno a heslo pro přístup ke statistikám v zařízení, jsou podporovány pouze ve verzi 1 a 2.

Pokud se rozhodnete přejít na verzi 3, nezapomeňte na svých zařízeních starší verze zakázat. Velkou výhodou, kterou oproti předchozím verzím přináší verze 3, je také možnost šifrovaného přenosu informací. Pokud se z nějakého důvodu rozhodnete zůstat u verzí 1 a 2, přesvědčte se, že community strings nejsou veřejně dostupné (ani v read-only souboru).

Pokud SNMP používáte, je vhodné zabezpečit přístup pomocí ACL (Access Control List). Monitorování pomocí SNMP může být kromě amplification útoku využito útočníkem také pro získávání informací o zařízeních ve vaší síti.  

Našli jste v článku chybu?
Lupa.cz: Pokémon GO není jediná rozšířená realita. Co dál?

Pokémon GO není jediná rozšířená realita. Co dál?

Vitalia.cz: Signál roztroušené sklerózy: brnění končetin

Signál roztroušené sklerózy: brnění končetin

Měšec.cz: TEST: Vyzkoušeli jsme pražské taxikáře

TEST: Vyzkoušeli jsme pražské taxikáře

120na80.cz: Jak se zbavit nadměrného pocení?

Jak se zbavit nadměrného pocení?

Vitalia.cz: Taky je nosíte? Barefoot není pro každého

Taky je nosíte? Barefoot není pro každého

DigiZone.cz: Sázka na e-sporty stanici Prima vychází

Sázka na e-sporty stanici Prima vychází

Podnikatel.cz: Účtenky v rámci EET? Klidně emailem

Účtenky v rámci EET? Klidně emailem

Vitalia.cz: Bio vejce nepoznají ani veterináři

Bio vejce nepoznají ani veterináři

DigiZone.cz: Epson: 4K projektory s podporou HDR

Epson: 4K projektory s podporou HDR

DigiZone.cz: Skylink o půlnoci vypnul 12 525

Skylink o půlnoci vypnul 12 525

Lupa.cz: Tudy proudí váš hlas i data. V zákulisí CETINu

Tudy proudí váš hlas i data. V zákulisí CETINu

120na80.cz: Tipy pro odvodnění organismu

Tipy pro odvodnění organismu

Lupa.cz: Japonská invaze. Proč SoftBank kupuje ARM?

Japonská invaze. Proč SoftBank kupuje ARM?

DigiZone.cz: Sat novinky: Skylink skončil s kanály ČT

Sat novinky: Skylink skončil s kanály ČT

Lupa.cz: IT scéna po brexitu: přijde exodus vývojářů?

IT scéna po brexitu: přijde exodus vývojářů?

Měšec.cz: Kurzy platebních karet: vyplatí se platit? (TEST)

Kurzy platebních karet: vyplatí se platit? (TEST)

120na80.cz: I tuto vodu můžete pít

I tuto vodu můžete pít

Podnikatel.cz: Od baletu k požární ochraně. A jiné rarity

Od baletu k požární ochraně. A jiné rarity

Vitalia.cz: Klíšťata letos řádí, skvrna se udělá jen někomu

Klíšťata letos řádí, skvrna se udělá jen někomu

Podnikatel.cz: Daň z nemovitosti? Změny budou v říjnu

Daň z nemovitosti? Změny budou v říjnu