"DDOS preventie" Apache wordt geflood

[BarthezZ]

De laatste tijd is het opgevallen dat mijn server (hoogst waarschijnlijk met kwade bedoelingen) "aangevallen" wordt. Dit uit zich in de site die onbereikbaar is en een énorme hoeveelheid entries bij een netstat -anp gericht op de webserver (op dit moment tijdens weer een van de aanvallen zo'n 17.000). Maar een beperkt aantal van deze requests weergeeft een apache PID in de laatste tabel van netstat en een zeer groot gedeelte hiervan staat op TIME_WAIT. Het aantal Apache processen schiet naar het maximum (mpm_prefork_module::Serverlimit en MaxClients) en zolang het maximum niet bereikt is is de site opzich redelijk bereikbaar. Zodra het aantal processen over dat maximum is duurt het tijden voordat je er weer een requests doorheen krijgt (tenzij ik apache restart, dan werkt het even weer tot het maximum weer bereikt is). Ook heb ik tijdens de aanvallen een tail -f gedaan op de Apache log files, maar er valt mij niets vreemds op.

Ik heb al een aantal dingen geprobeerd om dit te voorkomen, maar ik vroeg mij af of er betere mogelijkheden zijn.
- mod_evasive geinstalleerd en daarbij als het iets detecteert het ip in iptables te gooien
- MaxClients drastisch verhoogd. Dit heeft tijdelijk resultaat totdat het maximum weer bereikt wordt.
- Een scriptje gemaakt wat alles wat in TIME_WAIT staat in iptables met een drop gooit (niet echt fijn aangezien daar ook legitieme dingen in kunnen staan)
- Squid Snort geinstalleerd (maar na een aantal uur documentatie doorlezen is het me nog niet gelukt om het meer te laten doen dan de default debian installatie)
- Hoop kernel opties getweaked wat betreft timeouts en dergelijke van het tcp protocol (ook hier ben ik bang dat het ook nadelig kan zijn voor legitieme requests)
Wordt eventueel nog bijgevuld maar kan even niet op meer komen

Ik heb gelezen dat uiteindelijk bij een DDOS de beperking gaat zitten in de server (te hoge load bijvoorbeeld) of netwerk infra (teveel verkeer); in dit geval is geen van beide van toepassing. De server load komt niet hoger van 0.8 en het netwerk verkeer is ook nog geen 1% op de 100/100 uplink. Vandaar dat ik het zo vreemd vind dat het me niet lukt om degelijk te weren tegen deze aanvallen.

Kan iemand me verder helpen met het voorkomen van dit soort aanvallen en het bereikbaar houden van mijn site?

De omgeving:
- Debian etch
- Apache 2.2.3 (met mod_evasive2, php5.2.0 als module)
- MySQL 5.0.32
- Server: Intel Quadcore (Q6600), 8GB RAM
- In normale omstandigheden zo'n 42 hits / seconde average met een load van 0.32

[ Voor 0% gewijzigd door BarthezZ op 13-06-2009 13:00 . Reden: Squid -> snort :X (het moet vast de tijd zijn) ]

[serkoon]

Je zou zeggen dat adressen in je firewall gooien als ze teveel requests per minuut doen prima zou moeten werken.

Waarom werkt je mod_evasive-oplossing niet afdoende?

[Verwijderd]

Interessant Apache/Linux linkje. Preventing DDOS:

http://www.linuxsecurity.com/content/view/121960/49/

[X-DraGoN]

een DDOS aanval komt meestal van verschillende adressen, maar toch kan het soms handig zijn om bepaalde ranges te blokkeren, zoals ook ik gedaan heb met de meest simpele methode die er bestaat voor Apache: .htaccess => zet daar een deny rule in van bv. een bepaalde range en je heb geen last meer van die range. Werkt zeer effectief.

[ Voor 0% gewijzigd door X-DraGoN op 13-06-2009 10:31 . Reden: typ'o ]

[_JGC_]

Hoe staan je keepalive instellingen? Ik beheer zelf een serverpark van 45 webservers, en daar hebben we de keepalive timeout op iets van 3-5 seconden staan. Als je veel clients hebt die zo nu en dan een pagina opvragen blijven deze allemaal verbonden, maar doen geen klap behalve een connection slot op je webserver in beslag nemen.

[BarthezZ]

serkoon schreef op zaterdag 13 juni 2009 @ 02:34:
Waarom werkt je mod_evasive-oplossing niet afdoende?

Het lijkt erop dat het niet bepaald "veel" requests zijn, anders zou ik het wel in mijn logs terug kunnen zien. Wat ik ook vooral vervelend vind aan mod_evasive is het gebrek aan transparantie. Ik zie in de ingesteld log map een bestand dos-xxx.xxx.xxx.xxx staan met niet meer dan een nummer. Geen idee wat het aan het doen is. en de ddos notify email wilt niet lekker werken

Verwijderd schreef op zaterdag 13 juni 2009 @ 03:38:
Interessant Apache/Linux linkje. Preventing DDOS:

http://www.linuxsecurity.com/content/view/121960/49/

Het enige wat ik direct toe kan passen daar is mod_security, maar na even globaal de documentatie te hebben gelezen heb moet ik denk ik eerst maar even de documentatie goed doorlezen voordat ik het installeer, om de werking en het nut daarvan te doorgronden.

_JGC_ schreef op zaterdag 13 juni 2009 @ 12:16:
Hoe staan je keepalive instellingen? Ik beheer zelf een serverpark van 45 webservers, en daar hebben we de keepalive timeout op iets van 3-5 seconden staan. Als je veel clients hebt die zo nu en dan een pagina opvragen blijven deze allemaal verbonden, maar doen geen klap behalve een connection slot op je webserver in beslag nemen.

Keepalive heb ik op 3 seconden staan, met in gedachte dat eventuele plaatjes wel meteen over dezelfde connectie geladen kunnen worden, maar een volgende request weer opnieuw moet gebeuren. Met keepalive uitzetten tijdens een aanval schoot ik weinig op.

En ze zijn weer bezig atm

[Verwijderd]

• mod_defensible voor dnsbl checks
• mod_security voor meer checks (zoals je zelf al gevonden had)
• fail2ban voor afvangen en bannen van ongeauthoriseerde acties
• iptables icm state-based firewalling en goed doordachte rules (max conn per IP per minuut, etc).

[ Voor 4% gewijzigd door Verwijderd op 13-06-2009 14:52 ]

[moto-moi]

een 'goede' ddos doe je niets aan, behalve afwachten, als je een 1gbit lijntje hebt, en ze sturen 2 gbit naar je toe, boeit het niet meer of je het nou wel of niet verwerkt, je bent dan gewoon onbereikbaar.

Kansloze halfslachtige ddossen kun je op de manieren zoals hier aangedragen worden grotendeels teniet doen.

[Xorsist]

Een DDOS kun je je relatief gemakkelijk tegen weren met medewerking van je provider, zie hier voor een leuke case study.

[eghie]

Probeer er eens een reverse proxy voor te zetten.

Zie voor een artikel erover: Online Wars: Surviving DDoS Attacks en Varnish proves itself against a DDOS

Aangeraden reverse proxy is Varnish. (te installeren via aptitude install varnish)

Voorbeeld configuratie: (/etc/varnish/vcl.conf)

code:

#documentatie: http://varnish.projects.linpro.no/wiki/WikiStart#Documentation
backend default {
         set backend.host = "127.0.0.1";
         set backend.port = "81";
}

sub vcl_recv {
         set req.backend = default;

         if (req.request == "POST") {
                #not going to cache POST requests
                pipe;
        }

        lookup;
}

sub vcl_fetch {
        # force minimum ttl of 1 day
        if (obj.ttl < 1d) {
                set obj.ttl = 1d;
        }
}

Draai varnish op poort 80 en apache op poort 81 met die beveiligingsmaatregelen. En gebruik de volgende apache Log regel, om de echte IP's te loggen:

code:

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-A
gent}i\"" varnishcombined

aan te raden is om de obj.ttl (Time To Live) hoog te zetten, als je onder een DDOS aanval zit. Bijvoorbeeld een dag ofzo.

Daarnaast zet korte timeouts op de webserver. En handig is ook syncookies aan te zetten. En Fail2ban heeft een Apache DDOS module, waarbij hij dus DDOS hosts probeerd te blokken.


Gebruik het volgende commando om te kijken welke host het meeste verbindingen met je maakt:

netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

[ Voor 42% gewijzigd door eghie op 13-06-2009 17:25 ]

[BarthezZ]

Ik heb mod_security geinstalleerd, maar ook dat mocht niet heel erg baten. Varnish ga ik later nog testen want er moet eerst eea aan code aangepast worden voordat ik met een reverse-proxy ervoor kan werken.

Op dit moment is het enige echt effectieve om maar gewoon heel rusland, letland, polen, etc te blockeren in iptables

[Capa]

Ben 100% noob op dit gebied hoor (so done blame me if I'm wrong ), maar zou er niet iemand bezig kunnen zijn met iets vergelijkbaars van dit?
nieuws: Hacktool legt 'kwetsbaarheid' Apache bloot

[eghie]

Deze iptables regels willen ook wel helpen. Ik heb het iig ook met success getest tegen slowloris.

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Je moet uiteraard even voor jezelf bepalen welke hitcount je acceptabel vind.

By the way, Apache heeft ook nog wat anti-DOS tips: http://httpd.apache.org/d...sc/security_tips.html#dos

[ Voor 6% gewijzigd door eghie op 20-06-2009 14:41 ]

[BarthezZ]

Capa schreef op zaterdag 20 juni 2009 @ 02:02:
Ben 100% noob op dit gebied hoor (so done blame me if I'm wrong ), maar zou er niet iemand bezig kunnen zijn met iets vergelijkbaars van dit?
nieuws: Hacktool legt 'kwetsbaarheid' Apache bloot

Neeh slowloris was het niet. Die heb ik ook zelf zitten testen tegen mijn server aan, en zelfs met 2000 connecties kreeg die het niet onbereikbaar.

[Snow_King]

Om even een oude koe uit de sloot te halen!

Afgelopen week ontvingen wij (bedrijf waar ik werk) voor de zoveelste keer een flood op Apache, een soort slowloris (google maar) attack, maar dan vanaf vele duizenden hosts tegelijk.

Apache lag uiteraard direct plat, die spawnde al zijn slots en daardoor lag alles plat.

Omdat we out of options waren (duurste Cisco firewalls met HTTP inspectie waren nutteloos), uiteindelijk Varnish er voor gezet en daarmee was alles direct weer online.

Nog wel mod_extract_forwarded2 geïnstalleerd om zo alles geheel transparant te laten plaats vinden.

[CyBeR]

Nog even toevoegend: ik log waar ik varnish gebruik met varnishncsa in plaats van apache, dat scheelt ook weer wat omdat 't geen blocking operatie is in de request maar in een apart proces gedaan wordt via shared memory. Als je alle requests wilt loggen bij gebruik van varnish als cache (en dus niet puur als reverse proxy) is dat zelfs nodig-- requests uit de varnish cache komen tenslotte niet bij apache aan.

[ Voor 30% gewijzigd door CyBeR op 01-01-2010 22:43 ]