Základní myšlenkou DNS spoofingu je vystihnout okamžik, kdy se server ptá na určitou informaci a místo správné odpovědi mu pak podstrčit falešnou. Útok se samozřejmě týká pouze rekurzivních serverů, které přijímají dotazy od klientů, vyřeší je, pošlou tazateli odpověď a uloží ji do vyrovnávací paměti. Z ní ji pak poskytují při opakujících se dotazech na totéž. V koncové síti typicky bývá takový server, jenž díky vyrovnávací paměti zrychluje odezvy DNS pro místní klienty.
Pokud se podaří podstrčit mu padělanou odpověď, budou místní klienti po dobu životnosti falešného záznamu ve vyrovnávací paměti přesměrováni na jinou adresu. Předstíráním přihlašovací stránky pravého cílového stroje lze pak například sbírat uživatelská jména a hesla či jiné důvěrné informace.
Nejnebezpečnější je situace, kdy útočník ovládne některý ze strojů, jímž procházejí DNS dotazy daného serveru a odpovědi na ně. Pak může procházející pakety zachytávat, vysílat a měnit podle libosti a pomůže proti němu pouze podepisování záznamů (DNSSEC). K tomu však dochází velmi vzácně. Daleko častěji sídlí útočník mimo přenosovou trasu, dotazy přímo nevidí a do odpovědí se musí strefovat poslepu.
RFC 1034 doporučuje, aby byl tazatel vůči odpovědím maximálně ostražitý. Doporučuje se, aby akceptoval jen odpověď splňující následujících pět podmínek:
- Dotaz citovaný v odpovědi je totožný s původním. To se dá zařídit například tak, že se útočník sám zeptá (a dotaz tedy zná). Případně jej u vybrané adresy dokáže předvídat.
- Identifikátor odpovědi je totožný s identifikátorem dotazu. Při náhodné volbě identifikátorů nezbývá než zkoušet hrubou silou všechny možné alternativy a chrlit na server hromady falešných odpovědí s tím, že se snad některá z nich ujme. Bohužel z článku, analyzujícího bezpečnost vyrovnávací paměti DNS serverů vyplývá, že náhodnost identifikátorů není nijak oslňující (viz pravidelné vzory na obrázcích rozložení „náhodných“ hodnot). Navíc lze pravděpodobnost úspěchu výrazně zvýšit, pokud se podaří přimět server k odeslání několika dotazů se stejným obsahem, avšak odlišnými identifikátory (tzv. narozeninový útok).
- Odpověď přichází z IP adresy, na niž server poslal dotaz. Domény typicky mívají dva až tři autoritativní servery. Vložit jejich adresy do odpovědi nepředstavuje pro útočníka problém.
- Cílová IP adresa a port v odpovědi se shodují s údaji o odesilateli z dotazu. IP adresa serveru je známá. Mnoho serverů (nejrozšířenější BIND nevyjímaje) dostane při spuštění určitý port, který pak používá po celou dobu svého běhu. V těchto případech je splnění podmínky triviální.
- Odpověď dorazila jako první. To je dobrá i špatná zpráva. Útok je časově omezen do doby příchodu korektní odpovědi. Pokud se nestihne prolomit do vyrovnávací paměti v této době, dostane další šanci až po vypršení platnosti správné odpovědi. Ovšem pokud se mu podaří být první, později dorazivší správná odpověď již nemá šanci. Útočníci si často pomáhají tím, že autoritativní server zavalí dotazy (DOS útok) a zpomalí tak jeho odezvy.
Problematiku hádání identifikátorů rozebírá dokument Measures to prevent DNS spoofing. Najdete v něm vzorečky pro výpočet pravděpodobnosti úspěchu i určité konkrétní hodnoty.
Jak se bránit
Především je potřeba zdůraznit, že stoprocentní ochranu před DNS spoofingem poskytuje pouze DNSSEC. Dá se však velmi radikálně snížit pravděpodobnost úspěchu. Tato obrana má dvě fronty: ochranu domény (aby cizí uživatelé směřující na naše servery nebyli odkláněni jinam) a ochranu místního serveru (aby naši uživatelé nebyli klamáni).
Základní formule pro obranu domény je velmi prostá: nastavit dostatečnou životnost (TTL) záznamů. TTL určuje, s jakou frekvencí může útočník opakovat své pokusy. Výpočty ve výše citované zprávě uvádějí, že při životnosti 60 sekund se pravděpodobnost úspěchu spoofingu po nějakých devíti hodinách útočení přehoupne přes 90 %. Ovšem na druhé straně si řekněme, že správce, který nastavil minutovou životnost, si nic lepšího nezaslouží.
Doporučenou hodnotou TTL je jeden den (86 400 s) a záznamy pro významná jména, které bývají velmi konzervativní, klidně mohou mít týden. Zkrácení má smysl pouze v odůvodněných případech (např. před chystaným přeadresováním).
Obrana serveru by měla především omezit komunikační možnosti útočníka. Řada serverů je zcela otevřených a ochotně řeší rekurzivní dotazy položené kýmkoli. To znamená, že server skáče, jak útočník píská (a otevírá prostor i pro další typy útoků). Používáte-li BIND server verze 8 a vyšší (všeobecně se vřele doporučuje verze 9), můžete omezit příjem rekurzivních dotazů na místní počítače. Jestliže místní síť má adresu řekněme 10.1.0.0/16, můžete si pro ni definovat přístupový seznam a jím omezit rekurzivní dotazy:
acl nasi { 10.1.0.0/16; };
options { ...
allow-recursion { nasi; };
}; V tomto případě server nebude ochoten přijímat rekurzivní dotazy zvenčí, ovšem pokud bude dotázán na data z vyrovnávací paměti, ochotně je poskytne, a to včetně údaje o životnosti. Útočník se tedy dozví, kdy jim vyprší platnost a kdy lze očekávat dotaz do Internetu. Díky tomu dokáže útok časovat.
Vyplatí se proto uvažovat o ještě přísnějším nastavení, kdy se server s externisty je ochoten bavit pouze o doménách, pro něž je autoritativní. V globálních volbách se nastaví, že dotazy se mají přijímat jen od místních:
options { ...
allow-query { nasi; };
}; a pro každou vlastní zónu se pak explicitně povolí dotazování komukoli:
zone "nasedomena.cz" {
type master;
file "nasedomena.cz";
allow-query { any; };
}; V případě BINDu verze 9 si alternativně můžete pohrát s pohledy (view), které umožňují, aby se server choval vůči různým klientům diametrálně odlišně.
Pokud snad používáte BIND verze 8, měli byste se:
- vážně zamyslet nad důvody, které vás k tomu vedou,
- urychleně zkontrolovat, zda jeho konfigurace obsahuje volbu
use-id-pool yes;bez ní identifikátory dotazů nejsou náhodné, což pravděpodobnost úspěchu spoofingu posouvá do kategorie „tutovka“.
Velmi drasticky se sníží pravděpodobnost spoofingu, pokud server používá i náhodné UDP porty. A tím se dostáváme k PowerDNS.
PowerDNS server
Tento server představuje jednu z možných alternativ BINDu. Pravda, je ve výrazné menšině, ale není úplným exotem. Podle průzkumů z roku 2004 jej používala necelá tři procenta německých domén (zhruba stejně jako MS DNS) a necelá dvě procenta vybraných globálních domén. Vznikl původně jako pokus o komerční DNS server. Ekonomicky ovšem ztroskotal a v roce 2002 změnil licenci a otevřel svůj kód.
Základní server má sloužit výlučně jako autoritativní a vůbec nepodporuje rekurzivní dotazy (ne, nejsem úplně mimo, o rekurzi ještě bude řeč). Nepochybně nejzajímavější na jeho koncepci je, že striktně odděluje kód serveru od dat. Server řeší výlučně síťovou komunikaci spojenou s příjmem a obsluhou dotazů.
Data poskytují tak zvané backendy. Autoři PowerDNS si v roli backendů oblibují zejména různé databáze – od MySQL až po DB2. Data však může poskytovat i LDAP a díky obecnému aplikačnímu rozhraní si můžete vytvořit backend sami. Zejména pro počáteční zkoušení bude asi zajímavým backendem bind, který dokáže analyzovat konfigurační soubor BINDu a podle něj si vyzvednout data ze zónových souborů. Vlastnosti a volby se nepřebírají, jen zóny. V takovém případě je třeba PowerDNS sdělit, kde najde konfigurační soubor BINDu. pdns.conf by měl obsahovat něco jako:
launch=bind
bind-config=/etc/named.conf
Lid si ovšem žádá rekurzi, proto vznikl PowerDNS recursor jako doplněk základního serveru. Kromě něj můžete server naučit spolupracovat i s libovolným jiným rekurzivním serverem, a to i když běží na jiném stroji. PowerDNS recursor se ovšem pyšní mimořádnou odolností proti spoofingu. Především používá náhodná čísla UDP portů, a radikálně tak snižuje pravděpodobnost uhodnutí všech potřebných údajů v odpovědi. Kromě toho je odolný vůči narozeninovému útoku – pokud již řeší určitý dotaz, nebude jej opakovat (a zvyšovat počet identifikátorů, do nichž se útočník strefuje).
Pokud si jej chcete vyzkoušet, s vysokou pravděpodobností najdete binární verzi pro svou oblíbenou platformu. Doporučuji vaší pozornosti též návod ke konfiguraci na Linuchu.
ČLÁNKY DO MAILU