Nejdříve si řekněme, co to vlastně SYN flooding je. Jde o útok typu DoS (Denial of Service – odepření služby), jeho cílem tedy není vstoupit do systému, získat nebo poškodit nějaká data a podobně. DoS útoky způsobují obvykle dočasnou nefunkčnost určité služby, například HTTP (web) nebo SMTP (e-mail).
Podstatou SF je využití jedné z vlastností TCP protokolu, zvaného three-way handshake, neboli třísměrné potřesení rukou, které si klade za cíl ověřit, zda obě strany o spojení opravdu stojí.
Představme si, že KLIENT iniciuje spojení se SERVEREM. KLIENT tedy pošle první paket s nastaveným SYN bitem.
SERVER odpoví paketem, který má nastaven SYN a ACK bit a uloží si informaci o nadcházejícím spojení do interní datové struktury. Tomuto stavu se říká polootevřené spojení (half-open connection).
Klient nyní za normálních okolností dokončí potřesení třetím krokem, kterým je odeslání paketu s nastaveným ACK bitem. V tuto chvíli je úvodní část spojení dokončena a po síti mohou začít proudit data.
SF vlastně nedělá nic jiného, než že začne odesílat množství paketů se SYN bitem, jako kdyby chtěl normálně komunikovat, neprovádí však již třetí fázi handshaku, takže na stroji, který je cílem útoku, dojde postupně k zaplnění bufferů pro polootevřená spojení. Cíle bylo dosaženo, server není schopen přijímat další pokusy o spojení a tudíž se stává nedostupným. Případnou horší alternativou může být úplné vyčerpání volné paměti, pakliže není omezen maximální počet spojení – to najisto způsobí pád serveru s možným poškozením dat.
Výše uvedený příklad má pro útočníka jednu slabinu: velice snadno by šlo vypátrat, odkud je útok veden a správce serveru by mohl podniknout účinná protiopatření. Záškodníci jsou ovšem vynalézaví a tak SF zdokonalili o funkci zvanou IP spoofing, neboli falšování IP adres.
Za normálních okolností samozřejmě nelze dost dobře falšovat IP adresu, protože potřebujete, aby data dorazila na váš počítač (ovšem úplně vyloučeno to není). V okamžiku, kdy však vlastně o spojení nestojíte, není vůbec problém vydávat se třeba za Altavistu nebo Pentagon. Kromě maskovacího účelu přináší ale toto „vylepšení“ ještě další prvek do hry. Když totiž počítač, jehož IP adresu si útočník vypůjčil, najednou obdrží paket SYN+ACK, ačkoliv předtím neposlal SYN paket, odpoví paketem RST, který okamžitě polootevřené spojení ukončuje. Tím se ovšem značně snižuje síla útoku a tak si útočníci vybírají pokud možno IP adresy strojů, které momentálně nejsou dostupné. Cíl útoku je tak nucen držet polootevřené spojení až do vypršení timeoutu, který se obvykle pohybuje okolo 75 vteřin!
A jak se tedy lze bránit? Možností je několik, ale bohužel jsem nucen konstatovat, že ani jedna z metod není stoprocentní.
Možností, která se jaksi automaticky nabízí, je zvětšení prostoru pro polootevřená spojení. Prakticky vzato to ale neřeší vůbec nic: váš OS zvýší své paměťové nároky, zatímco útočník se zasměje a snadno zvýší intenzitu útoku.
Další metodou ochrany by mohlo být snížení timeoutu pro polootevřená spojení, ale zde opět platí to samé – zvýšením intenzity útoku by zřejmě záškodník dosáhl stejného výsledku a navíc hrozí, že při příliš nízkém timeoutu server zahodí i některá korektní spojení.
Třetí možností ochrany jsou speciální firewally. Principů, na kterých fungují je několik. FW se například předřadí serveru, tak, že každé spojení přejde přes něj. FW pak při obdržení SYN paketu otevře úplné spojení se serverem, čímž docílí toho, že server nedrží polootevřené spojení. Pokud žadatel o spojení správně dokončí handshake, funguje pak FW jako relay – tedy přesměrovává pakety mezi žadatelem a serverem. Je zřejmé, že podobný FW musí být speciální zařízení, neboť jinak by šlo pouze o přesunutí problému na jiný stroj.
Firewally vypadají zajímavě, ale zřejmě zdaleka ne všechny (pokud vůbec nějaké) jsou opravdu spolehlivou ochranou. Nedávno jsem se bavil s provozovatelem jednoho z největších českých serverů a postěžoval jsem si na problémy se SF. Onen člověk mi povídá: „My jsme si na to pořídili firewall“
A já na to: „A pomáhá to?“
Odpověď: „Spíš ne.“
Jak povzbudivé, že?
Čtvrtou možností je inteligentní filtrování paketů. Server by si v tomto případě udržoval spojový seznam všech SYN paketů za určitý časový úsek. Pokud by počet SYN paketů přicházejících na jeden soket přesáhl určitou míru, porovnala by se charakteristika takových paketů se staršími záznamy a pokud by to vypadalo podezřele, okamžitě by se toto spojení stornovalo. Nevýhody jsou myslím zřejmé: detekční algoritmus byt musel být velice „chytrý“ a také rychlý. Nicméně myšlenka je to zajímavá.
Poslední mě známou možností aktivní ochrany je použití tzv. SYN-cookies (neplést s cookies v prohlížeči, s těmi to nemá co dělat). Když server odpovídá na prvotní SYN paket, přidává do odpovědi tzv. initial sequence number. Toto číslo bude následně sloužit jako základ pro číslování oktetů v rámci spojení. Jeho hodnota je více méně v rukou serveru. Této vlastnosti cookies právě využívají: server jednoduše vypočítá rekonstruovatelné číslo (hash) ze zdrojové IP adresy, portu a dalších údajů žadatele o spojení, odešle SYN+ACK odpověď a polootevřené spojení úplně zahodí. Pakliže obdrží ACK paket obsahující sequence number, které odpovídá tomu, co mohl sám vygenerovat, otevře spojení, jako kdyby existovalo polootevřené spojení. I tato metoda má své pro i proti. Pro hovoří relativní jednoduchost a účinnost, proti naopak to, že existuje (zřejmě jenom teoretická) možnost uhodnutí hashe a rovněž to, že kvalitní hashovací funkce stojí nějaký ten výpočetní čas a paradoxně může vést ke zvyšování zatížení stroje. Proto se tato metoda začíná používat až v okamžiku, kdy jsou buffery pro polootevřená spojení zaplněny. Zabrání se tak pádu, případně nedostupnosti serveru, ale u hodně navštěvovaného serveru se nevyhnete velkému přetížení. Podpora SYN-cookies je v linuxovém jádře zahrnuta tuším od verze 2.0.33 nebo 2.0.34.
Existuje ještě pátá možnost obrany a tou je prevence. Jde o metodu potenciálně nejspolehlivější, ale bohužel prakticky nedosažitelnou. Jak jsem již říkal, při SF se používá falšování IP adres. Kdyby všichni poskytovatelé měli na svých routerech filtrovací pravidlo, které by zabraňovalo průchodu směrem ven paketům se zdrojovou IP adresou, která se v této síti nemůže vyskytovat, bylo by po problému (nebo by byl alespoň menší). Bylo by totiž výrazně snazší vypátrat alespoň přibližnou lokaci útočníka a ve spolupráci s jeho providerem pak učinit jeho řádění přítrž. Proto se zeptejte svého poskytovatele, zda má takto nastavené routery. Pomůžete tím dobré věci.
Doporučená četba:
RFC 793 – TRANSMISSION CONTROL PROTOCOL
Phrack Magazine, Volume Seven, Issue Forty-Eight, File 13 of 18
