Útok typu Slowloris

Zdravím, nedávno jsem na jednom spravovaném WEBu zaznamenal zajímavý útok, kdy velké množství IP adres dělalo na server jen založení TCP spojení a dál nic. Apache měl pak všechny workery ve stavu "Reading Request" a na běžné požadavky se nedostalo. Jednalo se o téměř ukázkové chování BotNetu - problém začal z ničeho nic a po 14ti dnech téměř z 90% přestal. Původně jsem měl podezření na Slowloris a rychlé nasazení "mod_reqtimeout" problém zafixovalo. Ale pak se analýzou síťového provozu zjistilo, že opravdu dojde jen k hand-shake a dál nic. Takže nalezení nějaké signatury pro IPS, nebo něco podobného nešlo řešit. Zajímá mě, jestli jste se s tím někdo setkal a jak to případně (vy)řešil? Stručná charakteristika útoku: - Byl proveden z velkého množství IP adres (žádné omezení na skupinu sítí, nebo země). - IP vytvoří pouze základní TCP hand-shake a neposílá data. - V rámci 60min (z cca 60%) tato IP nevytvoří další spojení. (Nelze účinně zahazovat na základě IP adresy). - Tato spojení nejsou ničím divná (to, že se jedná o nechtěné spojení se pozná až tím, že do doby, kterou si určím, resp. spojení zahodím, tak nezažádá klient o data).

Jak jsi psal, RequestReadTimeout a krátký čas pro header, potom záleží kolik je zdrojových adres. Případně dočasně navýšit počet vláken Apache, pokud jsou na to prostředky. A pokud to bude pořád málo, začal bych odřezávat nejaktivnější subnety, jestli to tedy není až příliš distribuované.IP byly i České? Kolik spojení to zhruba bylo?

IP byly z úplně celýho světa. Ještě si sjedu odrotovaný logy a udělám třeba nějaký souhrn, ale budou to tisíce - spíš desetitisíce, ale nebude to moc vypovídající (viz. dále). Ono při ceně botnezu od 60USD / 10 000 nódů na 14 dní se neni co divit. Zajímavé bylo i jejich chování. Např. během jednoho dne se vyskytly IP, které to udělaly řádově v jednotkách (to mohl být normální provoz) až po 183 (byl max. co jem zaznamenal v jeden den). Nikdy víc. Horší byl absoultní počet unikátních IP.Trochu se bojím, aby to nebyla příprava/oťukávání na něco většího.

vyřešil jsem to nasazením reverzní proxy (nginx), který je proti slowloris imunní (prakticky otestováno)