{Hosting} Bot aanval/oneindige requests

[Xanquezer]

Hoi,

Aantal jaren hosten we diverse websites, vanuit een cluster, aantal stevige HP servers, ssd`s etc..
Achtergrond is niet heel relevant voor deze info.
*sidenote: ik ga niet daadwerkelijke info geven zoals website naam etc..

Een van de servers heeft een wordpress website hobbelen. (16 cores, 32 gb ram 1tb ssd Debian, 3 levels of defence, firewall/IPS/DPI + FAIL2BAN + server security AV)
(PHP 8.4 / phpmyadmin, helemaal up to date, webshop en niet iets heel bijzonders in zich zitten)

Nu, wordt deze sinds afgelopen maandag erg enthousiast bezocht, 5 uur sochtens beginnen er 4 reuqests per seconden te lopen op de website.

*Even netjes IP uitgeblurt
Deze scenario heb ik nog niet mee gemaakt.
Misschien dat iemand toevallig er ervaring mee heeft?

Wat ik tot nu toe heb gedaan:

Maandag middag de PHP opgewaardeerd zodat er meer uit de cache word gelezen (wat mij meer ram kost, maar "boeie" we hebben 32 gb)
Wordfence geinstalleerd, heel leuk, ik zie kilometers requests binnen komen van 10.000 verschillende IP adressen over de hele wereld (Geoblocking is geen optie).
De website 5 min offline gehaald, lopen gapen naar tig fouten in het logboek wat ook achteraf niks heeft opgeleverd.
Handjevol ip adressen geblokkeerd, wat ook geen verschil gaf...

Het gaat met ups en downs... daardoor is het soms lastig een wijziging aan te brengen.
Ik vermoed dat een "scan" bot struikelt over het filter wat gebruikt word in de webshop.
Daardoor lijkt het alsof er een aanval plaats vind.

*note, cpuload is 100%+ op printscreen, totale cpu load van server ligt rond de 10-20% gemiddeld.

[ Voor 6% gewijzigd door Xanquezer op 10-07-2025 19:23 ]

[mfkne]

Ik zou er naar Crowdsec kijken en dat activeren.

[Xanquezer]

mfkne schreef op donderdag 10 juli 2025 @ 20:35:
Ik zou er naar Crowdsec kijken en dat activeren.

Dankje voor de tip.
Alleen het geeft erg weinig resultaat.
90% van de ip`s is "unknown" die ik even uit de losse hand invoer.


Ik had gehoopt dat er iets uit kwam om gerichter te gaan zoeken....
Overigens komen de IP`s echt van alle hoeken van de wereld... (van USA tot aan China tot aan Turkije tot aan zuid Africa)

[mfkne]

Kun je wellicht aan de hand van de User Agent iets?

[Xanquezer]

mfkne schreef op donderdag 10 juli 2025 @ 20:52:
Kun je wellicht aan de hand van de User Agent iets?

Je bedoelt op de server(s) zelf iets installeren?

[sig69]

Elke browser stuurt een user agent mee, bijvoorbeeld: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Mobile Safari/537.36
Als het een slecht geschreven bot is is die leeg, of iets raars misschien. Dan zou je daar iets meer kunnen.

[Xanquezer]

sig69 schreef op donderdag 10 juli 2025 @ 21:11:
Elke browser stuurt een user agent mee, bijvoorbeeld: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Mobile Safari/537.36
Als het een slecht geschreven bot is is die leeg, of iets raars misschien. Dan zou je daar iets meer kunnen.

Ja, die, oja, dat is nogal een leuke, ze zijn zo willekeurig dat ik er geen peil op kan trekken.

Even een greep uit de collectie:

code:

Mozilla/5.0 (iPod; U; CPU iPhone OS 3_3 like Mac OS X; lij-IT) AppleWebKit/535.27.7 (KHTML, like Gecko) Version/4.0.5 Mobile/8B111 Safari/6535.27.7

Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.01; Trident/5.1)

Mozilla/5.0 (Android 2.0; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0

Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.0; Trident/5.0)

Opera/8.42.(Windows NT 5.2; sk-SK) Presto/2.9.164 Version/12.00

Mozilla/5.0 (Windows; U; Windows 98) AppleWebKit/532.14.5 (KHTML, like Gecko) Version/5.1 Safari/532.14.5

And so on (random)... t lijkt net, "Spaar ze allemaal!"
Sommige werkelijk geen flauw idee dat dat de dag van vandaag nog zou bestaan.

Ik sta nog open voor verdere suggesties, we waarderen jullie mee denk werk.

[sig69]

Er is vast wel ergens een lijst te vinden met gangbare user agents. De rest (tijdelijk) blokkeren. Dit is allemaal rommel.

[Xanquezer]

sig69 schreef op donderdag 10 juli 2025 @ 21:24:
Er is vast wel ergens een lijst te vinden met gangbare user agents. De rest (tijdelijk) blokkeren. Dit is allemaal rommel.

True.
De gangbare zit degelijk verschil in, ook aan de file requests te zien.
Ik zal eens de server AV verhogen, kijken of dat verschil geeft.

[mrmrmr]

Als je volledige logging aan zet en de regels toont valt er misschien een regel van te maken. Complete HTTP headers kunnen helpen. Elke HTTP request bestaat uit meerdere headers.

Misschien kun de logs ergens neerzetten en delen, tussen member only tags. IP's kun je cryptografisch hashen zodanig dat herhaling zichtbaar is.

[RaZ]

Die =HTTP/1.0 achter de urls is genoeg om ze ergens anders naar toe te sturen

PHP:

if(strpos($_SERVER["REQUEST_URI"],"HTTP/") > 0) {
  sleep(5);
  header("Location: http://!/");
  die();
}

quick'n'dirty en niet getest

Zou je in de index.php kunnen zetten (of als een appart bestand opslaan, en een include() zetten in je index.php

[ Voor 63% gewijzigd door RaZ op 11-07-2025 00:22 ]

[Detmer]

Ik heb recent iets vergelijkbaars gehad en bij mij bleek de Facebook crawler te spammen. Ruim 50.000 request per dag. Uiteindelijk heb ik Cloudflare er maar voor gehangen met het gratis pakket en een block op Facebook. Wellicht een optie?

[MasterL]

Wat voor IDS/IPS systeem heb je? Kun je daar niks uit halen?
Hier heb je weinig aan als je dit niet gebruikt natuurlijk en gewoon een DNAT (HTTPS) naar je
webserver hebt.

[servicedb]

Er zijn een aantal oplossingen, maar dit is voor ons de gouden combo:

CloudLinux -> Hiermee beperken we de hoeveelheid resources per klant. Mocht een website aangevallen worden, dan wordt die hiermee beperkt. Veel panelen hebben iets vergelijkbaars, maar voor ons is ook key de PHP selector met de modules die je kan toevoegen. Dit geeft veel vrijheid aan klanten.

Initieel was dit onze gouden ei omdat de servers niet meer offline gingen bij aanvallen. Maar, individuele websites gingen vaak alsnog offline. De support load werd iets minder en bereikbaarheid van andere klanten werd stukken beter.

Imunify360 -> Raad ik in dit geval aan. Hiermee blokkeren we veel aanvallen. Bots krijgen netjes een ik ben geen robot variant te zien. En veel virussen/hacks worden al geblokkeerd of achteraf er uit gefilterd. Tot nu toe gaat het verwijderen van virussen zonder het terugzetten van een back-up in 99% van de gevallen goed.

De support load ging bizar omlaag als gevolg hier van. Klanten zijn meer tevreden omdat we hacks preventief tegenhouden of éénvoudig kunnen oplossen. Maar belangrijker nog: de servers en stabiliteit werd enorm verhoogd. En het aantal meldingen van hacks (ondanks flinke groei) ging flink omlaag.

Het is geen verkooppraatje, maar een oprechte ervaring. Je kan het hier gratis proberen: https://cloudlinux.com/trial-imunify360/

Kleine disclaimer: Soms gaat het ook fout. Vroeger waren de regels meer geoptimaliseerd voor WordPress dan de rest, met als gevolg dat Joomla soms door WordPress regels geblokkeerd werd. Inmiddels is dit niet meer het geval. Daarbij had ik de suggestie gemaakt om de WAF regels per applicatie te activeren, en dat hebben ze inmiddels ook ingebouwd als optie.

[mrmrmr]

@RaZ

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

PHP:

<?php

foreach ($_SERVER as $parm => $value)  echo "$parm = '$value'<br>\n";

?>

[Xanquezer]

Detmer schreef op donderdag 10 juli 2025 @ 21:45:
Ik heb recent iets vergelijkbaars gehad en bij mij bleek de Facebook crawler te spammen. Ruim 50.000 request per dag. Uiteindelijk heb ik Cloudflare er maar voor gehangen met het gratis pakket en een block op Facebook. Wellicht een optie?

Deze heb ik nu draaien, even kijken wat het resultaat geeft.
Aanval modus is actief (paar sec wachten) hoop dat t werkt.

[Xanquezer]

MasterL schreef op vrijdag 11 juli 2025 @ 08:07:
Wat voor IDS/IPS systeem heb je? Kun je daar niks uit halen?
Hier heb je weinig aan als je dit niet gebruikt natuurlijk en gewoon een DNAT (HTTPS) naar je
webserver hebt.

Er worden zo`n tienduizenden adressen geblokkerd per dag, daarnaast ook dat het "te willekeurig" is in de logs.
Te veel random IPs`s die n link opvragen, er is geen peil op te trekken.

[Xanquezer]

servicedb schreef op vrijdag 11 juli 2025 @ 09:45:
Er zijn een aantal oplossingen, maar dit is voor ons de gouden combo:

CloudLinux -> Hiermee beperken we de hoeveelheid resources per klant. Mocht een website aangevallen worden, dan wordt die hiermee beperkt. Veel panelen hebben iets vergelijkbaars, maar voor ons is ook key de PHP selector met de modules die je kan toevoegen. Dit geeft veel vrijheid aan klanten.

Initieel was dit onze gouden ei omdat de servers niet meer offline gingen bij aanvallen. Maar, individuele websites gingen vaak alsnog offline. De support load werd iets minder en bereikbaarheid van andere klanten werd stukken beter.

Imunify360 -> Raad ik in dit geval aan. Hiermee blokkeren we veel aanvallen. Bots krijgen netjes een ik ben geen robot variant te zien. En veel virussen/hacks worden al geblokkeerd of achteraf er uit gefilterd. Tot nu toe gaat het verwijderen van virussen zonder het terugzetten van een back-up in 99% van de gevallen goed.

De support load ging bizar omlaag als gevolg hier van. Klanten zijn meer tevreden omdat we hacks preventief tegenhouden of éénvoudig kunnen oplossen. Maar belangrijker nog: de servers en stabiliteit werd enorm verhoogd. En het aantal meldingen van hacks (ondanks flinke groei) ging flink omlaag.

Het is geen verkooppraatje, maar een oprechte ervaring. Je kan het hier gratis proberen: https://cloudlinux.com/trial-imunify360/

Kleine disclaimer: Soms gaat het ook fout. Vroeger waren de regels meer geoptimaliseerd voor WordPress dan de rest, met als gevolg dat Joomla soms door WordPress regels geblokkeerd werd. Inmiddels is dit niet meer het geval. Daarbij had ik de suggestie gemaakt om de WAF regels per applicatie te activeren, en dat hebben ze inmiddels ook ingebouwd als optie.

Cloud diensten zijn een no go... er staan hier zo`n 22 severs (van intel Xeon gold tot Amd Epyc).
Dan ben ik "bakken" met geld kwijt aan "cloud hosting".
Om 1 incidentje ga ik niet zo snel naar de cloud.

Imunify draait al op de server, als 4de layer verdediging.
Deze geeft helaas weinig resultaat mbt dit probleem.
Die houd inderdaad wel veel tegen, daarin kan ik je bevestigen, prima spul.

[Xanquezer]

Xanquezer schreef op zondag 13 juli 2025 @ 17:13:
[...]

Deze heb ik nu draaien, even kijken wat het resultaat geeft.
Aanval modus is actief (paar sec wachten) hoop dat t werkt.

Het ziet er naar uit dat het weer wat rustiger wordt bij dat domeintje... dat uurtje wachten heeft al 3600 requests afgeweerd...

[servicedb]

Xanquezer schreef op zondag 13 juli 2025 @ 17:18:
[...]


Cloud diensten zijn een no go... er staan hier zo`n 22 severs (van intel Xeon gold tot Amd Epyc).
Dan ben ik "bakken" met geld kwijt aan "cloud hosting".
Om 1 incidentje ga ik niet zo snel naar de cloud.

Imunify draait al op de server, als 4de layer verdediging.
Deze geeft helaas weinig resultaat mbt dit probleem.
Die houd inderdaad wel veel tegen, daarin kan ik je bevestigen, prima spul.

Cloudlinux is geen cloud dienst en draait lokaal op je server. De trial link verraad het al, Imunify360 is van CloudLinux.

Ik raad aan om contact op tenemen met Imunify360, dan kunnen ze met je meekijken en zoeken naar een oplossing. De support is
Vaak erg snel en best goed.

[Xanquezer]

servicedb schreef op maandag 14 juli 2025 @ 07:14:
[...]


Cloudlinux is geen cloud dienst en draait lokaal op je server. De trial link verraad het al, Imunify360 is van CloudLinux.

Ik raad aan om contact op tenemen met Imunify360, dan kunnen ze met je meekijken en zoeken naar een oplossing. De support is
Vaak erg snel en best goed.

Ik zal eens informeren, dankje voor de tip