Slow dos tegen gaan

Ik heb een webserver hier met een populare site erop. CentOS 4 (2.6.9-67.0.22.EL)

Nu is de laatste paar weken al iemand aan de gang om hem down te krijgen, oid, met dos aanvallen. De server kan het makkelijk aan, want de site is nogsteeds snel en goed bereikbaar. Ik denk dat het maar 1 mannetje is omdat het elke avond rond 10 uur stopt en 's ochtends weer begint.

Ik begon eerst met het bannen van IP's maar het is elke keer een ander IP, wat het onmogelijk maakt. Toen heb ik mod_evasive geïnstalleerd, welke niet goed werkt met Apache 2.2. IPTables heeft helaas geen ondersteuning met het limiteren van connecties per IP, teminste IPTables wel, maar de kernel niet, en ik kan deze helaas nu niet hercompileren.

Nu wordt ik er gewoon gek van aangezien stats niet kloppen en het log elke dag met 200MB groter wordt.

Het log ziet er ongeveer zo uit:

195.240.246.236 - - [12/Oct/2008:20:41:31 +0200] "GET /index.php HTTP/1.1" 302 -
195.240.246.236 - - [12/Oct/2008:20:41:31 +0200] "GET /index.php HTTP/1.1" 302 - "http://domain/forum/login.php?do=login" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"
195.240.246.236 - - [12/Oct/2008:20:41:31 +0200] "GET /index.php HTTP/1.1" 302 -
195.240.246.236 - - [12/Oct/2008:20:41:31 +0200] "GET /index.php HTTP/1.1" 302 - "http://domain/forum/login.php?do=login" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"
195.240.246.236 - - [12/Oct/2008:20:41:32 +0200] "GET /index.php HTTP/1.1" 302 -
195.240.246.236 - - [12/Oct/2008:20:41:32 +0200] "GET /index.php HTTP/1.1" 302 - "http://domain/forum/login.php?do=login" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"

Alleen dan 10x per seconde.

Hoe kan ik dit nu slim tegengaan? Ik heb al veeel gezocht op google, maar ik kan eigenlijk niks concreets vinden...

Ik zie dat er alleen bij de aanvallen een response code 302 - found wordt gegeven, maar ik kon niet vinden dat je dit kan blokkeren met bv mod_rewrite.

Heb ik geprobeerd inderdaad. Want die mod_evasive die schreef nog wel ip's weg naar /tmp die gebanned werden, en deze werden elke minuut door een cron in iptables gegooid.

Grote probleem was dat 90% van die IP's van normale leden waren, aangezien de aanvallende IP's gespoofd worden, met allemaal nederlandse IP's + dat er al na een dag 200 IP's instonden en na een week er bijna 1000 instonden en na 10.000 IP's het niet meer lekker werkde, dus moest ik het weer resetten, en ben ik nu opzoek naar een normale oplossing.

Ik ben maar aan het kijken naar een hardware matige firewall die dat kan overnemen, hoe doen de tweakers servers dit precies? Die zullen toch ook wel elke keer onder vuur liggen van script kiddies?

Deze site + code draait al 3 jaar zonder problemen, maar het is sinds 2 maanden geleden dat het gebeurd. Ik heb natuurlijk de code al gecheckt, met mijn eigen IP terug gezocht in de logs maar niks speciaals.

En dan nog een 302 resonse code is gewoon found, wat vaak duid op een TCP spoofer die geen 3 way handshake kan doen.

Je ziet wel dat de aanvallen vaak van Media center hosts komen, maarja om nou direct deze te blokkeren...

Osiris schreef op maandag 13 oktober 2008 @ 03:02:
[...]

Euhm, voordat een client een "GET / HTTP/1.1" überhaupt kán versturen, moet er toch eerst een fatsoenlijke TCP-verbinding gestart worden? Dus inclusief three-way-handshake?

Hm dat is zo inderdaad, ik dacht dat je namelijk wel een gemanipuleerd TCP pakket kon sturen die de server wel kan verwerken maar niks naar kan antwoorden.

Maar microsofty710 en Kanarie bedankt

Door een upgrade van vBulletin forum werd de uitlog procedure natuurlijk wéér veranderd, waar niet goed op getest is, en in sommige gevallen kwam het voor dat niet alle cookies verwijderd werden, en de frontpage deze ook niet kon verwijderd, dus in een loop kwam!

Erg erg erg stom, het was een aantal mede devvers ook opgevallen, maar die hadden niks gezegd

In ieder geval opgelost...