Slowloris elszabadult

Egy weboldal netről történő elakarításához az eddig leggyakrabban alkalmazott scriptkiddie módszer a DDoS támadás volt. Ez ellen jópár védekezési eljárás létezik, és mivel erősen terheli az infrastruktúrát, ezért sokszor már a szolgáltatók is szűrnek ilyen támadásokra.
A Slowloris újfajta megközelítést alkalmaz a szerver elérhetetlenné tételéhez. Azt használja ki, hogy a webszerverek egy része minden egyes új kéréshez egy új szálat indít, viszont egy azonos kapcsolattól érkező szálak számolása csak teljes kérés megérkezésekor történik. Ezért egyszerre nyit meg számos kapcsolatot a szerver felé de nem küldi el a teljes HTTP kérést, hanem csak részlegesen, mindig csak annyit, hogy a kapcsolat nyitva maradjon. Emiatt a szerveren hamar betelik thread limit és a következő felhasználó már nem tud kapcsolódni.
Az eljárás hátránya, hogy a szerver csak addig nem elérhető míg a támadás folyik, szemben a túlcsordulásra építő DDoS eljárásoknál.
Érintett wbszerverek: Apache 1.x, Apache 2.x, dhttpd, GoAhead WebServer, Squid
Nem, vagy csak részlegesen érintett szerverek: IIS6.0, IIS7.0, lighttpd
A teljes cikk a pearl kóddal:
http://ha.ckers.org/slowloris/

( numen v | 2009. 06. 19., p – 09:18 )

ötletes :)

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( hrgy84 | 2009. 06. 19., p – 11:49 )

Van egy jo issue fajlom :-)
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( sj | 2009. 06. 19., p – 12:05 )

azert az segit, ha az egy cimrol erkezo tcp/80 established kapcsolatok szamat limitaljuk egy kisse...

SPAMtelenul - POP3 spamszuro szolgaltatas

Kivéve, ha különböző IP-kről csinálják a támadást... csak egy botnet kell hozzá, az meg manapság már kinek nincs?! Talán csak úgy lehet védekezni ez ellen, hogy a szerver a kapcsolódott állapotban lévő threadek számának függvényében adaptívan csökkenti a socket timeoutot. Így először a lassú kliensek esnek áldozatul, a legitim kliensek pedig nyilván gyorsabbak lesznek a támadóknál.
---
Linux is bad juju.

( Replaced | 2009. 06. 19., p – 14:36 )

hah, elsore slowarist olvastam :p

--
When in doubt, use brute force.

( eax | 2009. 06. 20., szo – 16:15 )

"szemben a túlcsordulásra építő DDoS eljárásoknál"

e?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

A DDoS elsődleges célja az adott szolgáltatásokat kiszolgáló szoftverek túlterhelése és ezáltal olyan állapotba hozni őket, hogy összeomoljanak, hibás működést eredményezzenek. Leggyakribb a alloc => notfreed korrupció ez, aminek hatására "elfolyik" a memória, vagy címzési hiba lép fel. Az igénytelen kódolási eljárások (majd a "garbage kollektor elintézi", kit érdekel az a 2 bájt) igen gyakori okok emögött, és sajnos egyes környezetek még rá is tesznek pár lapáttal.
A fenti elgondolás hátulütője a hálózati infrastrukúrában lévő szűk keresztmetszetek, és egy ilyen támadás könnyű felfedezhetősége. Ezt próbálják megkerülni az elosztottsággal.
Amennyiben a szolgáltatást végző gép limitált hálózati kapcsolaton foglal helyet a DDoS nem tudja elsődlegesen feladatát megoldani, és ilyenkor jön a képbe azon tulajdonsága, hogy felzabálja a hálózati erőforrásokat, de ez ellen könnyű védekeznie a szolgáltatóknak.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Itt alapvetoen nem a GC-s nyelvek szapulasa van, hanem egyes emberek programozasi stilusa. Nyilvan javaban is lehet segiteni a GC mukodeset azzal, hogy ha mar nem kell egy szep hatalmas objektum, akkor a ra mutato valtozot kinullazzuk. Azonban itt megis inkabb a C-ben elofordulo memoriaszivarogtatasok vannak teriteken (malloc() utan elmarad a free(), c++-ban hianyzo/rosszul megirt destruktorok, etc.), melyek eleg nagy problemat tudnak jelenteni.
Sajnos vannak olyan emberek, akik C/C++ -t ugy programoznak, mintha Java lenne, holott errol szo nincsen. Es ezekkel van a baj.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A GC-vel alapvetoen nincs problema. A problema az igenytelen koderekkel van. Olyanokkal akik ugy irjak az eljarasokat, hogy pl. a destructor helyett hagyjak, hogy a GC vegezze a piszkos munkat.
Ezzel addig nincs gond amig a GC el tudja vegezni a feladatat, viszont egy extrem terhelesnel ez megborul. Az mar csak az egesz szituacio diszkret baja, hogy az ilyen kodot sokkal egyszerubb megboritani, mivel maga a GC is igenyel eroforrast (kulonosen a mark-and-sweep GC eseteben).
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"Leggyakribb a alloc => notfreed korrupció ez"

Ezt honnan szeded? A a ddos-tamadasok kb. egesze az eroforrasok tulterhelesere jatszik - elsosorban savszel, es proci, mert ezt konnyu kivitelezni (== nem kell hozza vegignyalazni a kodot, kb. minden ellen ugyanugy jo), konnyu elrejteni (ip spoofing, dns reflection attack, ...), es nehez ellene vedekezni.

Az altalad emlitett memleak-ek gyakran nem triggerelhetoek "gazdasagosan" - pl. kell hozza nyitni egy csomo tcp sessiont, ami a tamado oldalan is eroforrasigenyes. Ennel sokkal celszerubb (bar elesben a fenti okok miatt ritkak) a kulonfele nullptr deref, vagy assertion failure jellegu hibak kihasznalasa, vagy a feldolgozo-kodok vegtelen ciklusba kergetese (pl. unzip a mailszerver viruskergetojeben) - de ezeknek semmi kozunk sincs az overflow-okhoz.

"A fenti elgondolás hátulütője (...) egy ilyen támadás könnyű felfedezhetősége."

Egy sikeres ddost felfedezni nem olyan nehez. :)

"Amennyiben a szolgáltatást végző gép limitált hálózati kapcsolaton foglal helyet a DDoS nem tudja elsődlegesen feladatát megoldani, és ilyenkor jön a képbe azon tulajdonsága, hogy felzabálja a hálózati erőforrásokat"

Ez ket kulon masik tamadasi mod.

"de ez ellen könnyű védekeznie a szolgáltatóknak"

Hmmm? Omlik be a tcp syn a 80-as portodra tobb gbit/s mennyisegben random (spoofolt) ipk-rol. Mit tud ezzel csinalni a szolgaltatod?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Eroforras tulterheles a leakek kihasznalasa is.
A jo DDOS olyan metodust hasznal, ami rovid tamadas utan kepes leallitani az adott szolgaltatast, es csak figyel a susnyakosban amig ujra nem inditjak azt.
A ddos tamadasoknal a szolgaltatoknak lehetosege van statisztika, allapot alapu szurest alkalmazni ami minimalis eroforrast igenyel. Legegyszerubb egy adott ip fele erkezo keresek szamanak es tipusanak a merese.
Pl. Az ujabb DDOS scriptek ez ellen ugy vedekeznek, hogy skalazzak az idoben kikuldott csomagok szamat.
Spoofolt IP-ket forras es utvonal validalassal lehet szurni.
Altalaban, minden komoly szolgaltato veges valamilyen DDOS elleni szurest, mivel egy ilyen tamadas egesz halozati szegmenseket benithat le.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "