Security Professionals - ipfw add deny all from eindgebruikers to any

DDos vraagje

23-06-2018, 14:21 door Anoniem, 20 reacties
Sinds afgelopen nacht is het feest op mijn server. Alle 16 cpu's heel druk, zitten bijna overwerk papiertjes in te vullen. Het is een aanval op één domein, waarop zo'n 65.000 pagina's staan. Het lijkt erop dat mijn sitemap wordt gebruikt om alle url's door te ploegen. Die heb ik maar even weggehaald. Maar ja, eenmaal ingelezen, weinig zin natuurlijk.

In mijn apache logs zie ik veel verschillende IP adressen, een lookup steekproef geeft aan de ze vrijwel allemaal geen reverse lookup hebben. Een experiment met handmatig één voor één met iptables te blokkeren levert niks op. Het lijkt of er dan enkel maar meer hosts bijkomen. In mijn OWA statistiek van het domein zie ik echt geen enkele echte user visit erbij komen. Ook de agent strings zijn telkens verschillend. Er zit geen enkele spider bij (nou ja, goole en yandex en zo komen ook voorbij, maar bijten niet), maar wel alle denkbare browsers en andere vreemde agent strings.

Als ik het bewuste domein de-activeer, keert de rust terug in huis. Maar activeer ik weer, dan gaat het weer vrolijk door. Ik heb het domein maar even helemaal ge-deactiveerd. Zodat alle andere sites in elk geval er geen last van hebben. En natuurlijk gelijk de gelegenheid benut om Ubuntu te updaten en graden en te rebooten.

De andere sites op de server zijn (nog geen) grote sites. Op ps -ae|grep apache2|wc -l, zie ik echter dat er met de site op het domein in-actief, vrolijk 153 apache processen lopen. Dat zijn er veel, denk ik.

De enige last die er overigens van heb, is dat alles er traag van wordt. Ik heb een dusdanig hoge limiet in datatraffic, dat ik op er op dat gebied nog wel tien van die aanvallen bij kan hebben, voordat het me een cent extra gaat kosten. Degene die kliert is denk ik een stuk duurder uit, want zulke kunstjes, zeker nu het al bijna 24 uur duurt, zijn volgens mij niet goedkoop.

Heeft er iemand tips?

Mijn idee is om maar even een paar uurtjes net te doen of de site zogenaamd dood is, nog even apache te herstarten, en te kijken hoeveel er lopen. En dan gewoon weer in de lucht gaan. Dan maar even traag nog. Dan haal ik er wel een bakje nootjes bij terwijl iemand anders zijn paypal of bitcoins account zit leeg te DDossen. Ook wel een soort van grappig dat iemand zo los gaat op me, want ik verdien er zelf nog helemaal geen ene cent me!

Maarrrrrr, ik kan wel wat slimme tips gebruiken! Iemand?
Reacties (20)
23-06-2018, 15:24 door Anoniem
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?
23-06-2018, 16:13 door Anoniem
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.
23-06-2018, 17:02 door Anoniem
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.
23-06-2018, 19:26 door Anoniem
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.
23-06-2018, 20:23 door Anoniem
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.
23-06-2018, 20:42 door heyya
[Verwijderd door moderator]
23-06-2018, 23:19 door Anoniem
[Verwijderd door moderator]
24-06-2018, 14:44 door Anoniem
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!
24-06-2018, 17:12 door Anoniem
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.
24-06-2018, 18:37 door Anoniem
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.
25-06-2018, 17:06 door Anoniem
@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.
25-06-2018, 20:56 door Anoniem
@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.
26-06-2018, 08:17 door PietdeVries
En zo, beste mensen, hoort Security.nl te zijn... Technisch, to the point, en aan het einde het succes vieren! :)
26-06-2018, 11:00 door Anoniem
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.
26-06-2018, 13:10 door Anoniem
iptables -I INPUT -p tcp -m geoip --source-country AZ -m tcp --dport 80 -j DROP

Doei AZerbaijan ... ;)
26-06-2018, 13:15 door Anoniem
Door Anoniem:

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.


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.
26-06-2018, 14:26 door Anoniem
Door Anoniem:
Door Anoniem:

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.


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.
26-06-2018, 15:20 door Anoniem
Door Anoniem:
Door Anoniem:

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.


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.

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 .
26-06-2018, 17:43 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:

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.


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.

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.
26-06-2018, 21:23 door Anoniem
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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.