We hebben toch wat meer info nodig voor een zinnig advies: wat voor soort requests zie je? Kun je een stukje geanonimiseerd apache log posten? Wat zegt iptables? Waar denken de cores mee bezig te zijn?

Ik heb er gelukkig nog niet veel ervaring mee. Mijn eerste gedachte is logs verzamelen en daarmee naar je isp gaan.
Zij hebben wellicht meer mogelijkheden om het verkeer te temperen.

Succes iig

Gr D.

Wie zegt dat het een DOS is? Kan ook gewoon beperkt zijn tot een rot bot.

Er zijn veel partijen met bots die hele websites indexeren, zonder dat ze daarbij een vertraging inbouwen en daarmee iedere pagina direct scannen. Een bot als Google / Bing / etc doet het rustig aan om de server niet te belasten.

Je zou met fail2ban een blokkade kunnen opwerpen als een soort van hammer protection. Na b.v. 100 hits binnen een minuut het IP-adres blokkeren.

Ik mis nog welke software er draait op die website? Hoeveel tijd kost een request? Etc etc etc.
Gebruik Firebug (Net tab) en Apache JMeter om de site te analyseren qua load. En optioneel (in geval van PHP) met XDebug en WebGrind kijken waarom een pagina traag is.

Als je liever wilt wachten en de server down houdt, zet dan in je DNS het IP op 127.0.0.1 met een korte TTL. Dat kan er voor zorgen dat de DDoS op netwerkniveau ophoudt. Dan heeft er echt niemand meer last van het verkeer.

Als je actief iets wilt doen, probeer dan het verkeer te analyseren op packet niveau. Dat vergt wel kennis en een analytisch vermogen.

een optie die goed werkt is een dynamische ipset blacklist. je laat via cron elke 5 in de apache logs de ip nrs van de top 10 requesters in een ipset voor /24 te plaatsen (met een timeout) en een block op die ipset in je iptables (DROP en geen REJECT).

voorbeeldje, blacklist top 10 ips die meer dan 64 requests gedaan hebben in de laatste log en verdwijnen van de list na 28800 seconden als ze uiteraard niet meer in de top 10 zitten. gebruik een apache log rotate oid om elke dag met nieuwe stats te starten.

-------------------------------------
#!/bin/bash

/usr/sbin/ipset -exist create blacklist hash:ip family inet hashsize 4096 maxelem 65536 netmask 24 timeout 28800

grep eenstringdieikzoekenwaarikopfilter /var/log/httpd/*-access_log | grep -oE '([0-9]?*\.){3}([0-9]?*)' | sort | uniq -c | sort -rn > /tmp/ipsetlist

for i in `head -n 10 /tmp/ipsetlist | awk '{if ($1 > 64) { print $2 }}'`
do
/usr/sbin/ipset -exist add blacklist $i
done

/usr/sbin/ipset save blacklist > /etc/sysconfig/ipset
-------------------------------------

en met de volgende regel in iptables:

-A INPUT -m set --set blacklist src -j DROP

't is een beetje huisvlijt maar je kunt zo met wat testen in 10 min tijd een dynamische mitigation hebben die je rustig een poos kunt blijven draaien en klaar hebt voor de volgende dDOS.

Patiënt genezen!

Eeuwige hulde aan Gisteren, 20:23 door Anoniem. En natuurlijk aan de gastheer, security.nl!!!!!!!!

Het was wel een beetje uitzoeken (maar altijd leuk!!), en op Ubuntu (16.04) werkt het net allemaal even anders. De zoekstring was ook een leuke. Ik heb nogal veel talen. Maar Azebaaijaans was nog nooit door iemand gebruikt. Jammer, maar wel handig op dit moment. Ik heb h¡gewoon gefilterd op de taal URL. En het hakken richting blacklist daarna wat agressiever gezet.

Voor de Ubuntu gebruikers: Eerst even ipset installeren (apt-get ipset). Dan staat ipset niet in /usr/sbin, maar in /sbin/ipset. Scriptje updaten. Verder bestaat /etc/sysconfig niet op mijn server. Ik heb de sysconfig file maar even aangemaakt om errors te voor komen. Het is denk ik om na een reboot de blacklist niet te verliezen. Niet een groot probleem, want zoals ik het nu draaiend heb, werkt het antigif meteen. Geweldig.

Ik plak even mijn scriptje nu:

-----------------------------
#!/bin/bash

/sbin/ipset -exist create blacklist hash:ip family inet hashsize 4096 maxelem 65536 netmask 24 timeout 7200

grep /az/ /var/www/***mijndomein***/log/access.log |tail -10000 | grep -oE '([0-9]?*\.){3}([0-9]?*)' | sort | uniq -c | sort -rn > /tmp/ipsetlist

for i in `head -n 1000 /tmp/ipsetlist | awk '{if ($1 > 10) { print $2 }}'`
do
/sbin/ipset -exist add blacklist $i
done

/sbin/ipset save blacklist > /etc/sysconfig/ipset
------------------------------------------------------------------------

Accesslog locatie standaard pad in ISPConfig.

Dan nog de blacklist in iptables metselen. Die zegt in mijn Ubuntu versie: --set option deprecated, please use --match-set

Dat doen we dan braaf. Dus het moet zijn: iptables -A INPUT -m set --match-set blacklist src -j DROP

Daarna is het net of je kokend water op een mierennest hebt gegooid. Of zoals ooit iemand voor het eerst penicilline in een petrischaaltje gooide. Het werkt beter dan Glorix! Briljant!

Op de vraag naar een rijtje IP's, dat zal ik in een aparte comment zetten. Want ik weet niet of de moderator alhier het gezellig vindt dat er überhaupt IP's worden gepost. Het zijn ook geen IP's om aan te vallen. Vermoedelijk wordt dan enkel iemand zijn smart TV traag, of zijn smart koelkast, of die nieuwe led lampjes op de wifi reageren ineens zo traag op de app. Heeft weinig zin denk ik.

Verder eeuwige dank verschuldigd aan dit forum. Zò werkte internet in de begin dagen ook. Je komt er niet uit en post wat in een newsgroup. En dan komt er een aardig iemand voorbij die dat leest, en die je eigenlijk ook helemaal niet kent, en die gaat er even voor zitten. Het bestaat nog!

geen dank, voorbeeld en scripts waren voor een rhel systeem, maar je hebt het begrepen :).

cool spul he die ipsets in combi met iptables?

btw die zoekstring is er enkel en alleen om geschikte log regels uit je apache log te halen. ikzelf had ooit eens last van een bot die fake accuonts aanmaakte op een forum. ik zocht dus in mijn logs naar die regels die een request deden naar de 'maak een account aan' pagina waartoe gePOST werd door die bots. daar pakte ik de IPs van die die dag meer dan 10 maal de POST deden. een scriptje van 10 regels met een cronnetje elke 5 min deed wonderen toen :).

dit soort dingen werken dus ook heel goed tegen IoT rommel dat std accounts via ssh proberen te bruteforcen.

ja ik ken fail2ban, en gebruik het ook, maar als je veel gerammel aan de poort hebt, krijg je wel heel veel iptables regels door fail2ban en dat komt ook met perfomance zaken. ipset is er voor gebouwd met hashes maar minder bekend. 'k weet eigenlijk niet of je een jail in fail2ban kunt maken die ipset gebruikt. denk het eigenlijk wel. anyway, ik maak zelf vaker even vlug een script en dat kan ik tweaken naar mijn mensen vwb drempels en gebruikt basis tools die op elke unix wel beschikbaar moet zijn.

Beste Vandaag, 17:12 door Anoniem,

Ik ga tòch even wat herkenbaars doen. Even eruit en een een borrel pakken. Ik denk dat het een pacharan gaat worden, maar misschien wel een brandy. Vieren hoe geweldig ik ben ;-)

Ken je dat, je geeft iemand een geweldig idee, en 5 minuten later zijn ze er serieus van overtuigd dat ze het allemaal zelf bedacht hebben.... Maar ik moet het toch even vieren! Drie dagen 16 VU meters op tilt in mijn htop. En totale zondagsrust nu. Ik heb de mooiste opgeDOSte website van de wereld. Tot vandaag dan, hè?

Nogmaals bedankt!

PS: Ik had een rijtje IP's gepost, maar die zijn niet door de keuring gekomen. Kan ik begrijpen. Straks zitten ze bij security.nl ook met rooie VU-meters. En... het blijft een privacy gegeven natuurlijk.

@TS
Je kan proberen apache te ontlasten, door er varnish voor te zetten (kan op de zelfde server) en agressief te gaan cachen.
Is dit te lastig voor je kan je kijken naar een oplossing als Cloudflare of AWS Cloudfront. Deze hebben gezien capaciteit, zodat je ddosser het alleen maar meer geld kost en hopelijk stopt.

@Vandaag, 17:06 door Anoniem

Cloudflare is een MITM systeem en daarmee gratis. Uitgesloten. Ik wil niet eens zeggen dat privacy van "mijn" gebruikers te belangrijk is, want het zijn niet "mijn" gebruikers. Het zijn gasten die mijn site vertrouwen. Ook als ze alles gratis gebruiken. AWM was leuk om mee te spelen. Een tijdje geleden alweer zag ik bij wat googlen op iets, ineens mijn laatste aankopen bij Amazon verschijnen. Zal een foutje in de regie zijn geweest. Maar toen ging wel eerst mijn AWS account eruit, en onlangs ook mijn Amazon account. Ik ga wel weer in de rij staan in de winkel. Dat ze, als ik wat terug stuur (nog nooit gedaan trouwens) alles vernietigen en niet eens aan de armen schenken, of aan de voedselbanken, ook al zo iets. Maar wel raketten naar de maan sturen.

Het hierboven gesuggereerde scriptje werkt perfect. Je hebt meestal helemaal geen Cloudflares nodig of AWS bedrijven. Gewoon iemand die zo aardig is om een kunstje te delen. Én een beetje huisvlijt natuurlijk! Vandaan nog wat zitten tunen. Als je een een dagelijkse logrotate hebt (had ik al) dan begint het script na de rotate eerst met een lege acces.log. Ik had alles ook wat minder fanatiek gezet. Maar vanmorgen toch weer even feest. Ik gebruik ISPConfig, dat ook een mooie symbolic link naar de acces log van yesterday maakt. Die append ik nu aan de files van IP's. Zodat er direct na de logrotate de dag niet begint met een lege access.log:

grep membership /var/www/***mijndomein***/log/yesterday-access.log | grep -oE '([0-9]?*\.){3}([0-9]?*)' | sort | uniq -c | sort -rn > /tmp/ipsetlist
grep membership /var/www/***mijndomein***/log/access.log | grep -oE '([0-9]?*\.){3}([0-9]?*)' | sort | uniq -c | sort -rn >> /tmp/ipsetlist

Het for-next loopjestaat nu zo:
for i in `head -n 5000 /tmp/ipsetlist | awk '{if ($1 > 10) { print $2 }}'`

Werkt nog beter.
Resultaat: 463 klasse C netwerken in mijn blacklist.
En bijna 38.000 IP's in mijn /tmp/ipsetlist

Mijn site weer supersnel. Terug op A in pingdom. OWA - echte bezoekers terug naar normaal. En er registreren zich weer mensen in het zelfde tempo als ervoor. Plus natuurlijk alle andere sites op mijn server weer normaal bereikbaar.

Huisvlijt. Met de bescheidenheid dat ik het zelf niet heb bedacht, maar er dankbaar gebruik van maak.

En zo, beste mensen, hoort Security.nl te zijn... Technisch, to the point, en aan het einde het succes vieren! :)

follow up:

na wat uitzoeken ben ik erachter gekomen dat je dit ook met fail2ban allemaal kunt doen. Je moet alleen wel precies de details weten hoe je fail2ban moet configureren en wat dat betreft is de documentatie wat spartaans en moet je met python regexps aan de slag die ik niet op 4am-je-maakt-me-wakker-uit-mijn-hoofd beheers. maar het kan wel door een eigen filter in filter.d te plempen (eentje die lijkt op apache-pass bijv) die je apche logs parsed en de action iptables-ipset-proto4 bijv te gebruiken voor je jail.

iptables -I INPUT -p tcp -m geoip --source-country AZ -m tcp --dport 80 -j DROP

Doei AZerbaijan ... ;)

Kan iptables ook zelf met b.v.: -m limit --limit 3/min --limit-burst 10 -j RETURN waardoor het aantal max connecties gelimiteerd wordt tot 3 per minuut.

De iptables limit module limiteert op (bv) 3 verbindingen, maar kan niet achterhalen of de verbinding goed of fout was.

Met fail2ban kan je beperken op specifieke fouten, b.v. 3x incorrecte user. Fail2ban is een goeie toevoeging.

Je wilt niet het _totaal_ aantal connecties limiten, maar alleen de connecties van 'verdachte' clients of netblocks.

Anders wordt je limit volgeduwd door 99% DoS botjes, en krijgen 'normale' users daarna geen service meer .
Mooi, server load is beperkt, systeem draait , maar geen service voor gebruikers.

Zo te zien is er wel de module 'hashlimit' die een dergelijke functionaliteit heeft , maar anders kun je beter terug vallen op het gescript processen van applicatie logs en die in ipsets stoppen - zoals fail2ban doet .

Het is ook zaak bekend te zijn met de (standaard) limieten van connection tracking modules qua aantallen state entries - dat kan heel makkelijk een beperking zijn zonder dat de service er al last van hoeft te hebben. Een stateful firewall is heel makkelijk een DoS waiting to happen .

Klopt, die limiet ziet niet of een verbinding goed of fout was, het kan wel beperken in het aantal Apache processen (buiten dat Apache dat ook zelf kan) zoals OP oorspronkelijk vroeg om de load terug te brengen.

beetje off topic, maar iptables hashlimit ook vaker al gebruikt om bijv dns cache poisening te mitgeren:

-A INPUT -p udp --dport 53 -m hashlimit --hashlimit-name dnsqueries --hashlimit-upto 25/second --hashlimit-burst 250 --hashlimit-mode srcip -j ACCEPT
-A INPUT -p udp --dport 53 -m limit --limit 1/second --limit-burst 5 -j LOG
-A INPUT -p udp --dport 53 -j DROP

dit limit dns queries tot 25/s per ip met een burst van 250 queries. normaal verkeer zit hier binnen (is mijn ervaring) en als je een dns cache poisening attack krijgt trigger je de limiet al heel vlug. dat verkeer wordt dan geloged (throttled) en gedropped.