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.
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.
ČLÁNKY DO MAILU