NetCare logo

Distributed Denial of Service (DDOS) bestrijden.

Distributed Denial of Service (DDOS) bestrijden.

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.

Gerard Kanters

Gerard Kanters

Directeur van NetCare
Functie omschrijving

Ontzettend leuke job, waar alle aspecten van het bedrijf aandacht moeten krijgen. Persoonlijk ben ik erg enthousiast over ICT en de mogelijkheden die het biedt om alle aspecten van de maatschappij te...

  • Bezoeker (Werknemer niet meer in dienst bij NetCare)
    Bezoeker

    Als de 'aanval' applicatiespecifiek is bijv. voor WordPress / Joomla kan er ook gebruik worden gemaakt van een "Referer" check. Deze zorgt ervoor dat alleen legitieme verzoeken naar bijv. uw loginpagina doorgelaten worden. In dit voorbeeld gebruiken we Wordpress. Plaats deze code in een .htaccess bestand in de root van uw website en/of Apache configuratie.

    # Wordpress Anti-Flood Mechanisme

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
    RewriteCond %{HTTP_REFERER} !.*example.com.* [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule ^(.*)$ - [F,L]
    </ifModule>

    Tevens is het ook een tip om eens naar ConfigServer te kijken. Dit is een alles-in-1 tool die het een server-side anti-ddos tool is alsmede een iptables firewall ruleset bevat die out-of-the-box verdomde sterk is:

    http://configserver.com/cp/csf.html

     


    - Gijs Roeffen

    • Gerard Kanters
      Gerard Kanters

      Een dergelijke rewrite rule stuurt wel alle POSTs door. Ik neem aan dat je dat voorstelt als tijdelijke maatregelen: "while under attack". 

      Interessante aanvulling ook mbt configserver.

    • Bezoeker (Werknemer niet meer in dienst bij NetCare)
      Bezoeker

      Een dergelijke regel filtert juist enkel de POST requests. Deze regel is erop ontworpen om een "referer" te enforcen voordat er een login attempt / 'post gemaakt'  gedaan word op de Wordpress omgeving. Normale spambots / bruteforce tools honoreren het HTTP protocol niet en tonen afwijkend gedrag. Met deze regel filtert je diegene die zich 'fout gedragen' er tussen uit. Het kan een rate van false positives hebben maar die zijn minimaal of je website moet veel IE7 gebruikers hebben ;-)


      - Gijs Roeffen