Dotaz: Útok LAST_ACK

[srbt]

Provozuji službu - něco jako jízdní řády s následnou rezervací jízdenky. Někdo začal vytěžovat informace z těch jízdních řádů, aniž by prováděl rezervace, za což jsem dodavatelem dat finančně postihován. Když jsem těžaře začal odřezávat (vracel jsem mu zdvořilý text že je systém přetížený a kód 503), začaly mi na serveru zůstávat otevřené procesy httpd a spousta připojení ve stavu LAST_ACK. Když jsem protitěžební opatření odstranil, vše zas fungovalo korektně, jen přicházím zhruba o stovky vyhledávání každou minutu. Mám podezření, že těžař, když dostane nevyhovující odpověď, tak schválně neukončí spojení. Nějaká rada co s tím, prosím?

Systém: FreeBSD 7.3-RELEASE-p2
Httpd: Apache/2.2.15
Php: 5.2.13

---

---

Odpovědi

[Heron]

Nevím, zda je to totéž, ale nám se takto připojovalo tisíce spojení z Číny. Nevypadalo to jako útok, podle obsahu to spíš vypadalo na to, že ti klienti tu IP považují za webproxy (prostě někdo rozdával špatnou adresu proxy serveru). To se dalo snadno zablokovat, jednalo se o stránky českého ministerstva v češtině, tak příliš mnoho návštěvníků z Číny nechodí.

Ve vašem případě se může také jednat o cílený slow loris útok. I proti tomu se lze bránit.

[srbt]

Mám pocit, že proti slow loris útoku by měl být httpd téhle verze odolný, jestli si tedy pamatuju správně ten typ útoku.

[DarkKnight]

Pokud nepouzivate mod_reqtimeout, tak ne.

[srbt]

Ten používáme, ale děkuji za námět.

[bluem]

Nemůže mít jen těžař nějaký naivní script, který mu při odpověďi jiné než 200 prostě spadne, ale neukončí při tom spojení? Nešel by problém řešit na nižší úrovni - firewallem? Těžar se pravděpodobně bude ptát pořád ze stejné IP adresy resp. rozsahu. Dále mě napadá rate limiting na port 80 na unikatní IP adresu.

[srbt]

On těžař ze začátku používal řádově desítky adres z různých cloudových společností - zakazoval jsem je jednotlivě a zrovna když jsem dopsal geniální script na zakazování celých rozsahů dle whois, začal používat jednotlivé rozptýlené adresy, každou zpravidla jednou dvakrát - statistiky jsem dělal jen za omezený časový úsek, takže pak je možná používal znovu, ale i tak jde řádově o tisíce různých adres. Rate limiting máme, ale na tohle se zrovna moc nechytá. I tak děkuji za odpověď, udal jsem málo vstupních informací. (a i tak tiše doufám, že můj těžař nechodí na abclinuxu

[Atom321]

Zvláštní je, proč to ten "těžař" vlastně dělá. Musel si s tím dát docela dost práce. Co tím může získat?

[srbt]

Ta data - mohou být dost cenná.

[NN]

Obrat se na CSIRT a nahlas to jako utok. Odrizni to na subnety z CR. Pripadne vytvor signstury a blokuj pomoci IDS.

[srbt]

CSIRT mi asi nepomůže - na svých stránkách píše:
Spojení a spolupráce s CSIRT.CZ ve věcech internetového útoku však vyžaduje jistý stupeň profesionální komunikace a znalostí, tudíž je určeno pro ostatní týmy CSIRT jako poslední instance v řešení incidentu, nikoliv jako „help-line“ pro běžného uživatele. Ten by měl využívat služeb správce své firemní/školní sítě nebo lokálního týmu CSIRT poskytovatele svého internetového připojení.

Zkusím se tedy poradit se svým providerem, zatím mne nenapadlo, že by to mohl nějak řešit, ale je fakt, že by mohl mít více zkušeností a přístup k dalším instancím - třeba k tomu CSIRTu. Díky.

Oříznout na českou lokalitu to nemohu - většina řádných uživatelů je ze zahraničí.

IDS si nastuduju, děkuji za další námět.

[Matlák]

Mno, ono je dost zajímavé že jsi toho těžaře poznal i přes ty rozptýlené adresy. Přece jsi ho podle něčeho poznat musel? Jestli jsi to dokázal ty, dokáže to i stroj...

[srbt]

Ťěžař neposílá své požadavky přesně jako běžný uživatel - nerad bych to rozváděl víc . Ale tuším, že je jen otázka času .

[srbt]

tak tam daj pred to proxy a filtruj to tam.

[srbt]

To vypadá jako přesně to, co potřebuji. Děkuji velice, až se stydím, že mne to nenapadlo samotného.
Pro mne to má zvlášť přínos, protože na tom serveru běží i jiné služby a teď když mne shodili, tak je odrovnali všechny a byla to katastrofa - když zruší jen tu jednu, bude to jen pohroma. Navíc jsem zjistil, že je novější verze FreeBSD proti tomu útoku nejspíš imunní. https://www.freebsd.org/security/advisories/FreeBSD-SA-15:13.tcp.asc. Paráda, děkuji moc.

[GeorgeWH]

tak to som rad :), aj ked som to necakal, pretoze nejako automaticky predpokladam, ze pri vacsich/vaznejsich projektoch je to bezna/nevyhnutna vec.