ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző FreeBSD Project NewsOpenBSD Journal |
Érdekes Apache DoS eszközre figyelmeztet az ISCAz 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.
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekSzavazásNálunk rendszeresen van ISO audit és rendszeradminként ... nekem is van munkám vele. 21% engem nem érint. 16% nálunk nincs minőségirányítási rendszer bevezetve. 31% mi az az ISO audit? 29% Egyéb. Leírom. 4% Összes szavazat: 325
InformációKövess minket!Partnerünk |
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!
Nagyvonalakban:
http://hup.hu/node/68698#comment-753685
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...