Érdekes Apache DoS eszközre figyelmeztet az ISC

 ( trey | 2009. június 20., szombat - 10:04 )

Az Internet Storm Center arra figyelmeztet, hogy olyan DoS (Denial of Service) támadást lehetővé tevő eszköz érhető el szabadon az interneten, amellyel rendkívül egyszerűen lehet sikeres szolgáltatás-megtagadást előidéző támadást indítani az Apache 1.x, 2.x verziók, a dhttpd, a GoAhead WebServer és a Squid ellen. Az eszköz az elérhető kapcsolatok felemésztésével okoz problémát a webszerver tulajdonosoknak. Jó hír a Microsoft IIS-t, lighttpd-t futtatóknak, hogy ezek a verziók az eddigi ismeretek szerint nem érintettek a problémában. Maga a probléma már régóta ismert, az újdonság annyi, hogy eddig nem jelent meg rá publikusan olyan eszköz, amellyel ki lehetett volna használni. A részletek itt olvashatók.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nézzétek meg a linket weboldal legalján lévő képet :D LOL

Az Apache1-2 elleni (d)dos-t simán meglehet kerülni. Aki nem ért hozza, ne csináljon szervert!

igen?

hogyan kerulod meg a ddost?

--
.

mondjuk mod_evasive-al?
---
Tévedni mindenkinek szabad, csak a mérnöknek észre kell vennie.

Lattal te mar ddost kozelrol?

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

lattam, at is eltem. btw tuzfal alap, hogy rendesen be van love, csak gondoltam megosztok egy segedmodult.
---
Tévedni mindenkinek szabad, csak a mérnöknek észre kell vennie.

:DDD

probald meg ugy felfogni mint egy csovezetek rendszert hatha ugy megerted h itt mennyisegi problemarol van szo
--
.

Ez pont nem mennyiségi probléma, legalábbis nem adatmennyiségi.
Azt csinálja, hogy felépít egy kérést, aztán hagyja, hogy timeout-ig várjon az apache szál vagy processz.
Aztán csinálja a következő kapcsolatot.
Mivel az apache véges számú kapcsolatot kezel és alapból nincs korlátozva az egy ip-ről jövő kapcsolatok száma, előbb utóbb megdöglik.

A probléma alapját Dan Kegel már vagy 8-10 éve leírta itt: http://www.kegel.com/c10k.html

Ebben a szalban mar nem errol van szo. :)

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

Ja, gonosz módon ontopic válasszal próbálja meg elterelni a szálat. Vezessük be az ilyenre az offol mintájára az onol kifejezést. :)
---
Linux is bad juju.

ONanizál

:D


No rainbow, no sugar

> csak gondoltam megosztok egy segedmodult.

Olvasd el a linkelt oldalakat, aztán meséld el hogyan lehet használni az általad említett modult a leírt jelenség elleni védekezésül. Köszi.

az megvan hogy mondjuk 10.000 gep kuldi az adatot neked es az elotted levo ruter kapacitasa nem eleg erre?

--
.

Akkor az IIS is sebezhető ezek szerint.

--
Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag van.

Meg lett itt keverve a dolog. Mégpedig azzal, hogy idekeverték a DDoS-t. Itt erről szó sincs.

--
trey @ gépház

Én pl. ipt_recent modullal. Egy éjszaka alatt 15ezer IP-t banolt és máris nem volt leterhelve az apache...

jo mert te HC linuxos vagy, de vannak itt kezdok is azert
--
.

Leirnad nagy vonalakban konkretan mit es hogyan szursz?

Koszonom!

jopofa advanced megoldas

egyetlen problemat ott latom h spoofolt ipvel kuldok csomagokat :)

az ellen nem ved?

--
.

Az ellen meglehet, hogy nem, de szerencsére a támadások nem spoofolt IP-kkel történtek, azzal nem tudom még mit kezdenék.

Az iptables-szintu ban kb. semmit sem er, ha mar az interrupt load is elviszi a gepet.

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

Ha már az interrupt load-nál tart a dolog, akkor már elég kevés az esély

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Pedig altalaban 100 mbitnel a savszel fogy el elobb, felette meg a proci az interruptoktol.

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

heh kerdes h ebbol mennyit ertenek meg itt a hupon az iptables haxorok
--
.

És milyen limitet állítasz be a recentnek. A mai böngészők ui. egyszerre akár 5-30 paralell kapcsolatot is nyithatnak egy szerver felé, azaz kb.5-6 ip is elég lehet, hogy egy default apache-t lekókasszon. Kitilthatod persze azokat, akik egyszere túl sok kapcsolatot nyitnak, de akkor esetleg egyes böngészőkben be sem fognak jönni a szerver által hostolt oldalak.

Az apache keepalive ezen sokat segít.
Kipróbáltam firefox,ie,opera jól megy, a többi nem érdekel annyira.

A mai böngészők ui. egyszerre akár 5-30 paralell kapcsolatot is nyithatnak egy szerver felé, azaz kb.5-6 ip is elég lehet, hogy egy default apache-t lekókasszon.

vs

What is Keep-Alive?

The Keep-Alive extension to HTTP, as defined by the HTTP/1.1 draft, allows persistent connections. These long-lived HTTP sessions allow multiple requests to be send over the same TCP connection, and in some cases have been shown to result in an almost 50% speedup in latency times for HTML documents with lots of images.

--
.

10-nél több kapcsolatot oldalanként még nem tapasztaltam böngészőtől, a keepalive meg pont azért jó, hogy ha 40 kép van egy oldalon, ne nyisson 40 kapcsolatot, hanem megoldja azzal a 10-el.

a keep-alive nem azert jo

hanem azert hogy az ujabb es ujabb GET/PUT/... ugyanabban a TCP kapcsolatban tortenik

ergo ha kezdetkor nyit 10et akkor azt a 10et fogja hasznalni, ha 40et akkor 40et

nem ez limitalja nyilvan a server oldalon a max kapcsolat/ip-t

--
.

Az még hagyján, de NAT mögött lévő gépek? (Egyébként a legtöbb böngésző nem 8 kapcsolatot használ max? Másik: az, hogy hány szállal áll neki tölteni, az a fejlesztők felelőssége is.)

----------------
Lvl86 Troll

Hát ezaz. Érdekelne a megoldásra ide is egy jó ötlet...

+1 az ipt_recent-nek

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

pound+iptables

Jelen pillanatban úgy néz ki, hogy az apache önmaga nem tudja ezt a problémát megoldani. A javítás egyszerűnek tűnik, kellene olyan timeout beállítás, amelyik a kapcsolatot akkor is megszakítja, ha az éppen csinál valami hasznosat (pl. kéri le a lapot). Ha valakinek a gépe nem képes egy elfogadható időn belül egy oldalt lekérni, az menjen inkább moziba, vagy nézzen tévét ne az internetet.

Ezt a specifikus DoS tipust, kerlek szemleltesd peldaval is hogyan orvosolnad, hogy a hozzam hasonlo tudatlanok is okulhassanak.

Koszonom.

ebbol is latszik, hogy az apache mennyire elavult

--
When in doubt, use brute force.

még az a jó, hogy az internet meg jó friss, ropogós...


No rainbow, no sugar

nem baj, keszul mar az internet2 :P
___
info

Csak egyet tudok érteni. Múltkor kicsit mélyebben belenéztem a forráskódjába... el kellene már oda egy ráncfelvarrás. Az egyetlen ok amiért érdemes használni, az a végtelen mennyiségű modul és a mod_php.

Mar nem azert, de az, hogy ciklusban nyit egy tcp kapcsolatot, es var, az kb. 20 sor kod. Egy ilyen dolognal mit szamit, hogy van-e olyan _publikus_ progi, ami ezt kihasznalja? Script kiddie-k eseteben persze sokat, amugy semmit. Szerintem..

--
"ne támogasd az erdők kiírtását mozijeggyel, töltsd le a netről!" - killllll, asva.info

Mivel "scriptie"-bol van sok, igy aztan szamit.
Aki kodolni is tud, es rosszindulatu is abbol kevesebb van mint a szinmplan rosszindulatu...