HTTP DDoS támadás elleni védekezés

Apache

Egészen véletlenül bukkantam erre az Apache modulra, s mivel a neve hangzatosnak ígérkezett, belenéztem. A kód írója nem kevesebbet ígér a README-ben, hogy védelemet tud nyújtani az Apache 1.3/2.0 és iPlanet webszerverek ellen irányuló kis-közepes lekérdezés-bázisú (request-based) DoS / DDoS vagy script/brute force támadásokkal szemben. Lássuk hogy is működik.Megérkezik a kérelem (http request).

  • Megnézi, hogy a kliens IP címe szerepel-e egy átmeneti feketelistán.
  • A kliens IP címéből és a lekért URI-ból egy hash key-t képez, majd megvizsgálja, hogy ezt a hash-t tartalmazza-e egy belső key-táblázat. Ha talál egyezést, az azt jelenti, hogy többször lekérdezték az oldalt egy másodpercen belül.
  • A kliens IP címéből egy kulcsot készít, összeveti egy belső táblázatban található adatokkal, így kiderül, hogy erről a címről érkezett-e az elmúlt egy másodpercben több, mint ötven objektum lekérdezés.

Ha a fenti három feltétel közül bármelyik teljesül, 403-as HTTP kódot kap vissza a lekérdező, ezzel sávszélességet és erőforrást megtakarítva. Lehetőség van triggerek használatára, vagyis egy ilyen esemény bekövetkeztekor lehet pl. emailt küldetni vagy külső paracsot futtatni.

Ha a mod_dosevasive egyszer kiküldte a 403-as hibakódot, akkor a cél kliens IP-je bekerül abba a bizonyos átmeneti feketelistába (alapértelmezetten) tíz másodpercre. (Természetesen állítható.)

Ha felkeltette az érdeklődésed, a http://www.nuclearelephant.com/projects/dosevasive/ címen letöltheted a forrást.

Gigabitet szaturalni is tudni kell valahogy. Mondjuk ha 128 kbit-es ADSL vonalak vegen uldogelo zombikrol van szo, abbol kell vagy 8 ezer darab csak matematikailag... Raadasul nem rossz, ha minden zombi mas es mas szolgaltatonal ul, mert nem nagyon szoktak az ISP-k minden egyes ugyfelre 100% uplink savszelesseget pazarolni, nem hiaba kerul(ne) olcsobba a letoltesi korlattal rendelkezo interneteleres.

Ez IMHO azert annyira nem lehet egyszeru ma Magyarorszagon.

Elmeletileg akademiai halozatrol kevesebb gep is eleg gigabitnyi forgalom generalasahoz, de az eleg hamar feltunhet az NIIF halozatuzemeltetesnek, es viszonylag konnyu tenni ellene - akar automatizalt modon is (mint amilyen a Schonherzben a halokorlat tullepese eseteni automatikus MAC cim kitiltas a halozatrol). Persze vannak jobban es kevesbe jobban vedett egyetemi halozatok Magyarorszagon.

Mint mondtam, a tulmeretezes (vas, savszelesseg, uzemeltetes oldalan) az egyetlen ami segit... Es persze a bunugyi felderites, ami elvileg nem lehetetlen ilyen esetben, a rendorsegnek elvileg hivatalbol kell eljarast inditania az ugyben... Azutan egyszercsak csongetnek Pistikenel es beviszik a fenekbetoszos bortonbe, jol... ha ilyenekkel szorakozik. :) Erkolcsileg semmi kulonbseget nem latok egy DDos elkovetoje meg egy atlag autot lekromofagozo bu

Bar jobban belegondolva, ez amellett, hogy noveli a szervereket ert terhelest, jobban elemezhetove is teszi azt, hiszen az ilyen jellegu keresek sokkal inkabb tekinthetoek Poisson eloszlas szerint erkezonek, es ezert a statisztikai analizisuk es a tomegkiszolgalasi modell megalkotasa is sokkal egyszerubb es pontosabb lesz. Wow...

( rigidus | 2005. 01. 03., h – 19:59 )

DDoS tamadasok, ip cimatejtesek, spammerek, ipv4 cimrendszer karcsusaga. Talan ez a harom dolog amirol napjainkban legtobbet hallani mint az internet ugynevezett gyengei.

Most bizonyara sokan fogtok engem utalni :) , ha azt mondom, hogy ezek ellen a problemak ellen rancfelvarrasokkal hosszutavon nem lehet vedekezni. Ideje egy teljesen uj rendszert fejleszteni, melynek a tervezese soran a gyokereitol fogva szem elott tartva azt, hogy mire lesz valojaban hasznalva es a jelenleg ismert problemakat. Ott ahol a "cimzett az valoban a cimzett" a "felado meg valoban a felado". Ahol nem egy vallalati NAT szerver ip cimet ficcenti be egy celalomasra, hanem a "kedves user"-et. Ahol nincsenek ELLENORZESEN KIVULI illegalis oldalak, ahol a gyerekek megtanulhatjuk, hogyan allithatnak elo hazilag robbanoszereket, (C4, nitroglicerin, stb.), majd, hogyan lehet ezeket elhelyezni epuletekben, hogy abbol sz@r se maradjon ha elpukkan. Vagy hogyan lehet embereket agyonkinozni stb. Ezek nem csak technologiai tervezesek hanem mindazok az infrastrukturak amik az internet szocialis hatteret is kepezik.

Pl, az interneten tortent buncslekmenyekre messze nem lehet egy adott orszagon belul lepni mert szinte 99,9% szazalekba a "cimzett" es "felado" kulonbozo orszagokban tartozkodik. Igaz vannak erre is probalkozasok, ilyen jellegu nemzetkozi szervezetekre, de ok, hogy nyomoznak? Hogy keresnek vissza pl tamadasok megtortentere kozvetlen bizonyitekokat barki ellen is? Egy rendszeren amely lyukasabb mint az ementali? Ott ahol a "kedves latogato" hamisitja a packet headereket, atirogatja sajat maga utan a log allomanyokat? Be kell latnunk, hogy az internetet kinottuk.

Akkor gondoljunk bele abba, hogy az egesz egy strukturalatlan adathalmaz nehol pedig kompromisszumos szabvanyokra epul, melyek picibol indultak, majd dagadtak, dagadtak, dagadtak, foltozgattak pofozgattak oket, majd a vilag masik oldalan valaki valamilyen okbol kiatalalja, hogy ez nam jo. Erre o is kitalal egyet teljesen ugyanerre a celra, elkezdi csiszolgatni pofozgatni, majd elterjed lassan, es jon egy harmadik, negyedik, stb. (Ez a mentalitas sajnos a mai szoftverkulturankbol fakad, ahol a problemak hasonloak)

Az ARPA rendszert eredetileg nem erre es nem ecelbol hoztak letre amire ma hasznaljuk, hanem csak csiszolgattak foltozgattak eveken keresztul, hogy mint vilaghalo megalja a helyet. Es amint nap mint nap tapasztaljuk es egyre jobban fogjuk tapasztalni, hogy egyre jobban kiut rajta az, hogy EZ NEM ERRE LETT TERVEZVE AMIRE HASZNALJUK! Atmeneti megoldasnak jo, de ismetlem: NEM HOSSZUTAVRA!

Vannak persze probalkozasok az ARPA rendszer teljes levaltasara, lasd: US Army altal tervezett rendszer, vagy a masik ami most hirtelen nem ugrik be. :D Szal, lehetne cifrazni. Egy qrva nagy tengeren hajozuk egy sz1r-sz@r hajoval, ahol a hullamok egyre nagyobak. Az mar csak a jo kormanyosok erdeme, hogy csak "kisebb koccanasok" voltak, hajotoresek meg nem!

Bocs, ha most nem tudok hosszabban irni ezzel kapcsolatban sajna, de rohadtul faradt vagyok :(, de ha vkinek volna kerdese ezzel kapcsolatban, arra kesobb szivesen valaszolok ill reszleteibe kifejtenem. :)

( Friczy v | 2005. 01. 03., h – 21:05 )


Érdekes. Mekkora lesz ez a hash táblázat egy nagyforgalmú server
esetében? Nem túl nagy overhead a végignyálazása?

--
--- Friczy ---
'Death is not a bug, it's a feature'

Friczy wrote:
>
> Érdekes. Mekkora lesz ez a hash táblázat egy nagyforgalmú server
> esetében? Nem túl nagy overhead a végignyálazása?

A README default ertekkent a 3097-t irja, ez egy primszam.

DOSHashTableSize
----------------

The hash table size defines the number of top-level nodes for each
child's hash table. Increasing this number will provide faster
performance by decreasing the number of iterations required to get to
the record, but consume more memory for table space. You should
increase this if you have a busy web server.

( Sea-you | 2005. 01. 04., k – 09:57 )

ize hamar apachenal tartunk. Ismer valaki olyan modult, ami limitalja az egy iprol jovo adott idon beluli .htaccess-es probalkozasok szamat? Van egy altalam uzemeltetett webszerver amin egy pornopicsa siteja fut es a fizetos reszeket folyamatosan probaljak megzuzni...

"Ugye, hogy mennyi problemara megoldast nyujt es mennyivel jobban atgondolt az IPv6..?:)"

Persze. Ott is kell proxy, így ugyanoda jutottunk. S a proxy duplán javasolt, mindkét oldal miatt.

Milyen jó is az, amikor minden gép csatlakozási kérelme előtt le kell játszani egy kis IPSec-et, hogy mindenki elégedett legyen! :) S akkor már nem is kell DDOS :)

Remélem, hamarosan lesznek olyan rendszerek, melyek már rendes profilokkal jönnek, s nem kell szívni az elindításukhoz! (S persze meglesz az indulás szabványa is :) )

a futó programok kérésének értéke vlóban periódikusan jósolható, ugyanakkor a kliensek elindulása/leállása (s így a görbe telítettsége) viszont már nem annyira jósolható, max statisztikai alapon, tanulással javítható. Pl. a munkaidő alapján jól közelíthető.

Hm. a telítési görbére s az időváltozásra lehet, hogy lehet valamit lőni, de az már nem lesz általános.

Ettől még benzinkút marad, hiába csak nappal tankolnak...

( macroharddoors v | 2005. 01. 03., h – 13:48 )

Hmmm, ez csak akkor kritikus ha egy nat hálózatból mondjuk 100-an ugyanazt a weboldalt kérik le...

( Hunger | 2005. 01. 03., h – 14:02 )

Én nem látom túl sok értelmét...

Szerintem a problémát nem tudja megszüntetni teljes egészében ez a megoldás és csak feleslegesen lesz terhelve a webszerver azzal, hogy még ilyen hashelésekkel meg listakezelésekkel is foglalkoznia kell. Ráadásul ha ebben a modulban is van valamilyen bug (és ugye miért ne lenne), akkor csak újabb rizikófaktort jelent, melynek hibáját esetleg szintén kihasználhatják. A másik ami még eszembe jutott, hogy az ilyen feketelistázás elég sok problémát vet fel. A browserek tele vannak olyan bugokkal amik miatt egy oldalt akár többször egymás után is megpróbálnak lekérni és ennek következtében az ilyen kliensek is gyönyörűen ki lesznek tiltva (false positive).

Mellesleg nem is látom, hogy hogyan fogja blokkolni azt a DDoS támadási formát, hogy:

1.2.3.4 -> GET /file1

5.6.7.8 -> GET /file2

9.10.11.12 -> GET /file3

13.14.15.16 -> GET /file4

stb.

Nyilván az igazi DDoS olyan sok különböző IP-vel és olyan random lekérésekkel történhet, amelyet nem lehet egyszerűen kiszűrni, hogy DDoS vagy valódi forgalom.

Naigen. Engem a slashdot tilt le allandoan, mert ugyanarrol a proxyrol valoszinuleg meg parezer kollega keri le nehanyszor tiz masodpercenkent az RSS feed-et...

Monduk /.-ek komolyan gondoljak, mert 10 sec helyett 72 orara kitiltotidk ilyenkor az ember... vagyis a ceg:)

Ugye, hogy mennyi problemara megoldast nyujt es mennyivel jobban atgondolt az IPv6..?:)

Nyilván, az ellenn nem véd. Ha majd irsz egy olyan modult amiben nem lesz hiba, es mindenfele tamadas ellen ved, akkor --ha ugyes vagy-- te leszel a masodik leggazdagabb ember Bill utan. ;-) Nyilvan nem corporate kornyezetbe valo ez a megoldas, es igen, lehet bug a modulban, eppugy mintahogy a mod_rewriteban is volt, pedig az nativ apache modul.

A NAT-olt halobol jovo keresek mar inkabb szamitanak gondnak...

"Nyilván az igazi DDoS olyan sok különböző IP-vel és olyan random lekérésekkel történhet, amelyet nem lehet egyszerűen kiszűrni, hogy DDoS vagy valódi forgalom."

Mondjuk van egy 100 ip-ből álló DDoS hálózatod (szerintem 100 ip-s abszolút nem nevezhető nagynak, egy rosszul megtervezett egyetemi hálózatnál akár egy /20-as ip-tartományt is simán lehet spoofolni a feltört szerverről/tűzfalról, láttam már ilyet, nem egyet), ha a 100 ip-ről másodpercenként 40 lekérést végzel (minden lekérés random filera történik), akkor az másodpercenként 4000 lekérés anélkül hogy kiszűrödnének az IP-k...

Meg persze ha több webszerverrel végzel terhelés elosztást, akkor felvetődnek újabb kérdések, pl. a különböző szerveren futó apache modulok hogyan fogják megosztani egymással a feketelistájukat és hashtáblájukat... ;)

( handler | 2005. 01. 03., h – 14:40 )

van ilyen netfilter modul is:

http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html

"3.5 iplimit patch

This patch by Gerd Knorr adds a new match that will allow you to restrict the number of parallel TCP connections from a particular host or network.

For example, let's limit the number of parallel HTTP connections made by a single IP address to 4 :

# iptables -A INPUT -p tcp --syn --dport http -m iplimit --iplimit-above 4 -j REJECT

[..]"

ha a 100 ip-ről másodpercenként 40 lekérést végzel (minden lekérés random filera történik), akkor az másodpercenként 4000 lekérés anélkül hogy kiszűrödnének az IP-k...

Ezek az ertekek amik a README-ben vannak defaultok. Nem jelenti azt, hogy mindenhol ez az optimalis. Persze megtalalni az arany kozeputat, nos az nem kis munka.

Meg persze ha több webszerverrel végzel terhelés elosztást, akkor felvetődnek újabb kérdések

Nem tudom, ilyen szinten nem melyedtem bele. De nem hiszem, hogy implementalt lenne (jelenleg).

Amit a horizontalis skalazhatosagrol irtok azzal total egyetertek, de az szerintem mar boven kimeriti a corporate kornyezet fogalmat.

Ne mondd nekem, hogy olyan oldalak megabites linken lognak, amiket erdemes DDos-olni. A DDos arrol szol, hogy egy bizonyos szervezetnek kart akarsz okozni azzal, hogy, elerhetetlenne teszed a szolgaltatast. Pl egy Amazon, aminek egy oras elerhetetlenseg valoszinuleg millios nagysagrendu karokat okoz (mert a vasarlo inkabb a Barnes and Nobles-rol veszi meg a Gyuruk ura DVD-t, mert az elerheto, az amazon meg be sem jon). Vagy ugyancsak jo pelda Tomcat meg a blogja, amit tudomasom szerint tobbszor is ert ilyen tamadas, es ott konkretan egy ember eletminoseget csokkenti, ha par napig/hetig senki se tud polot rendelni...

100 Mbit es felette viszont nem is olyan egyszeru szaturalni a link visszameno oldalat. Bar tudom, a PHP skalazodik, es a MySQL is barom gyors, de azert gondold csak vegig... A felmeno savszelesseg szaturacioja elott sokkal hamarabb bekovetkezik egy szerver tulterhelese (nem olyan konnyu 100 Mbit-et megtolteni GET /index.php keresekkel).

Ami az egyiknek DDos nagysagrendu forgalom, az a masiknak normalis terheles... tehat lehet ra rendszert meretezni es kivitelezni.

A fenti megoldassal nekem a legnagyobb problemam az, hogy a webszerverbe integralodik, es nem egy kulon content switch/IDS reteg vegzi el a rendszer hatarvedelmet. Persze nem automatikus IDS/tuzfalasdi kombinacio lebegjen a szemeitek elott: azzal lehet igazan labon loni a rendszert.

Egy aktiv DDos tamadas ellen a legjobb a szomszedos szobaban uldogelo operator, aki aktivan be tud avatkozni, es akar /16-os halozatokat tehet blacklistre egyetlen masodperc alatt a webszerverek elotti vedelmi retegben. (Nekem anno a freenet.hu operatori helyisege tetszett nagyon, szepen projektorokkal a falra vetitett aktualis szerverterhelesi grafikonokkal, meg avg load szamokkal).

Hobbi weblapoknak nem kell imho DDos ellen tenniuk dolgokat.

Ugyanmar, ki a fenet erdekel az sco honlapja? Csodalkoznek, ha napi ezres nagysagrendet meghaladna a latogatok szama (gondolom foleg a For investors oldalak a nezettek). A mucsarocsogei leninova mgtsz B2B portaljat sem tobbezer latogatora kell meretezni, penzkidobas lenne az ablakon...

A DDos foleg a B2C esetleg G2C portalok eseten erdekes. Ha a szervezetnek nincs kozvetlen kara abbol, hogy a szolgaltatasa nem elerheto, akkor felesleges DDos elleni tulmeretezesre kolteni. Ha abbol el, hogy interneten ad el dolgokat, akkor meg kotelezo!!!

Gy.k.: B2C: Business to Consumer, G2C: Government to Citizen