Quantcast
Channel: NetCare: Alle Blogs
Viewing all articles
Browse latest Browse all 700

Distributed Denial of Service (DDOS) bestrijden.

$
0
0

Recent werd één van onze webservers aangevallen door een DDOS attack, het heeft me 6 uur gekost om een generieke oplossing hiervoor in te voeren. Ik deel deze ervaring zodat anderen dit sneller kunnen doen. 

Een DDOS attack wordt vaak veroorzaakt door zgn skript kiddies. Dit zijn vaak tieners die meestal zelf niet kunnen programmeren, maar maken gebruik van scripts op internet die ze relatief gemakkelijk aan elkaar kunnen klikken. Het effect van een aanval is er vaak niet minder om, maar is gelukkig ook makkelijker tegen te gaan dan een echte hardcore hacker/cracker. Ik geef verder geen details van de aanvaller hier.

In principe was het makkelijk de aanval tegen te gaan, zoek de USER_AGENT op in je LOG files en block deze in je .htaccess file (vervang badguy met de string uit je log).

RewriteCond %{HTTP_USER_AGENT} ^.*badguy* [NC]

RewriteRule ^.* - [F,L]

Dat zorgt direct dat de server lucht krijgt en je op zoek kunt gaan naar een iets breder toepasbare oplossing. Als de aanvaller namelijk merkt dat je dit hebt gedaan, verandert hij de USER_AGENT namelijk direct. 

Een niet erg structurele oplossing dus, verder zoeken maar. Er zijn vele "bad user agents" lijsten op internet en ik heb er een aantal geprobeerd. Hoewel dit al beter aanvoelde, was ik toch niet echt tevreden. 

Met iptables kun je connection rate limiting toepasssen, bijvoorbeeld: 

-A INPUT -p tcp -m limit --limit 5/s --limit-burst 20 -j LOG --log-prefix SYN-DROP:

Dat hielp ook niet echt omdat de aanvaller slim genoeg was om het aantal sessies per aanvallende machine niet substantieel hoger te zetten dan datgene wat een normale gebruiker ook zou doen. Om dit dus effectief te maken zou ik de lat zo hoog moeten leggen dat normale gebruikers er ook door werden tegengehouden. Dat maakt iptables als middel dus onpraktisch tegen een DDOS attack.

PSAD hielp ook niet,omdat het hetzelfde probleem had als iptables. Om dit effectief in te zetten zouden hier de wat zwaardere gebruikers worden geblocked. Ook een doodlopende weg dus.

Toen vond ik deze prachtige mod_security rule set op Github: https://github.com/SpiderLabs/owasp-modsecurity-crs

Je moet eerst mod_security aan hebben staan op Apache voordat het kan worden ingezet. Maar dat hadden we al, dus de rest is redelijk makkelijk. Download de rule set en plaats deze in /etc/httpd/modsecurity.d/ 

Wijzig daarna je apache config, meestal  "/etc/httpd/conf/httpd.conf"

<IfModule mod_security2.c>

Include modsecurity.d/modsecurity_crs_35_bad_robots.conf
Include modsecurity.d/modsecurity_crs_40_generic_attacks.conf
Include modsecurity.d/modsecurity_crs_41_sql_injection_attacks.conf
Include modsecurity.d/modsecurity_crs_41_xss_attacks.conf
Include modsecurity.d/modsecurity_crs_42_tight_security.conf
Include modsecurity.d/modsecurity_crs_45_trojans.conf
Include modsecurity.d/modsecurity_crs_47_common_exceptions.conf
Include modsecurity.d/modsecurity_crs_49_inbound_blocking.conf

</IfModule> 

En dit was direct effectief. De rules helpen niet alleen tegen DDOS aanvallen, maar eveneens tegen veel andere gebruikte aanvallen zoals sql injection xss attacks etc.. Het is dus absoluut een aanrader.

Een collega wees me later op een andere zeer interessante module mod_qos. Deze is zeker ook aan te raden om verder differentiatie te maken in type verkeer, maximum aantal concurrent requests en kent zelfs VIP's (soort uitzonderings lijsten). 

Helaas helpt niets als je aanvaller zoveel machines heeft dat de internet verbinding zelf verstopt raakt. Je zult dan upstream moeten gaan en de hulp van je ISP in moeten roepen. Colt bijvoorbeeld gebruikt hier een effectief tool IP guardian voor.

Mocht je ISP niet kunnen of willen helpen, is mijn advies "fight fire with fire". Overload de aanvallende machines met meer dan 64.000 half open sessions en de stack van het aanvallende systeem zal crashen. Niet echt een legitieme tegenmaatregel vermoed ik, maar het zal het botnet netwerk een voor een afbreken en de skript kiddie hulpeloos alleen achterlatend, wachtend totdat zijn nietsvermoedende slachtoffers hun PC opnieuw starten en hopelijk een keer een goed antivirus pakketje aanschaffen.


Viewing all articles
Browse latest Browse all 700