{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

[Xanquezer]

Ik vraag me af, wanneer het stopt....
Ben er bang voor dat er nooit n einde aan gaat komen.

Iemand suggesties? het lijkt erop dat de halve wereld een bezoekje brengt aan onze website.

[Drs_Ben]

Zo te zien een webshop. Misschien een klant die goed aan het adverteren is op social media/tiktok etc?

Tsja, dan kun je maar 1 ding doen en dat is de klant aanspreken en wellicht aansporen om geschiktere hosting te vinden. Of dat zelf aanbieden maar dat gaat een dure oplossing worden.

[Xanquezer]

Drs_Ben schreef op maandag 21 juli 2025 @ 09:41:
Zo te zien een webshop. Misschien een klant die goed aan het adverteren is op social media/tiktok etc?

Tsja, dan kun je maar 1 ding doen en dat is de klant aanspreken en wellicht aansporen om geschiktere hosting te vinden. Of dat zelf aanbieden maar dat gaat een dure oplossing worden.

Correct, webshop(je).
Nee, niet actief adverteren, er is wel een "marketing" dame bezig geweest met "SEO" dingentjes.

Aansporen voor betere of andere hosting is ook niet de oplossing gezien ik zelf een hoster ben.
Als ik de website op een andere server (met ander ip) zet/migreer, loopt het net zo hard door.

[Drardollan]

Dit hoort toch gewoon bij het hoster zijn? Zoals aangegeven, zorg dat je klanten afbakent middels de genoemde opties.

[Xanquezer]

Klopt, dat doen we ook, we hebben al tientallen aanvallen (zoniet honderden) weten te verweren.
Alleen deze lijkt op een bot-net. ondertussen al 50.000 verschillende IP adressen verspreid over de wereld.
Nieuwe uitdaging die inmiddels aantal weken loopt, eigenlijk de eerste keer dat ik achter me oren zit te krabbelen hoe we dit gaan oplossen...

[DukeBox]

Xanquezer schreef op maandag 21 juli 2025 @ 08:59:
Iemand suggesties? het lijkt erop dat de halve wereld een bezoekje brengt aan onze website.

Kan je het niet achter cloudflare plaatsen? Ik was daar niet echt fan van maar ik ben maanden bezig geweest de boel handmatig bij te sturen/blocken etc.. Uiteindelijk toch voor cloudflare gekozen en moet eerlijk zijn, ik had dat eerder moeten doen.

[RaZ]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 9% gewijzigd door RaZ op 21-07-2025 12:07 ]

[Xanquezer]

RaZ schreef op maandag 21 juli 2025 @ 12:03:
***members only***

Die ga ik eens proberen dmv .htaccessss

[Xanquezer]

RaZ schreef op maandag 21 juli 2025 @ 12:03:
***members only***

Members only: title

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Code aangepast aan htaccess, zal van de week even resultaat geven.

[Thijn41]

Xanquezer schreef op maandag 21 juli 2025 @ 12:32:
[...]

Die ga ik eens proberen dmv .htaccessss

Je zou die rules ook in Cloudflare kunnen toepassen, dan heeft je eigen server er helemaal geen last van.

Of gewoon een managed challenge tonen wanneer die wprfilters= in de url staat:
Security > WAF > Custom Rules.

[Xanquezer]

Thijn41 schreef op maandag 21 juli 2025 @ 13:59:
[...]

Je zou die rules ook in Cloudflare kunnen toepassen, dan heeft je eigen server er helemaal geen last van.

Of gewoon een managed challenge tonen wanneer die wprfilters= in de url staat:
Security > WAF > Custom Rules.
[Afbeelding]

Dankje, alleen zo liep ik tegen de CRON jobs aan enzo.. paar kleine dingentjes...

Nu loopt t via de server (htaccess), load is nu zo`n 2 tot 5 % (Cgroup = medium, 100% website load is 10% server load)
Logboek loopt wel snel over (retentie logboek).
T zal mij benieuwen!

[Xanquezer]

Hoi,

Even nog n keer n update tussendoor.



Ze blijven komen en gaat.
De code in HTacces werkt perfect!

Alleen wil je dit bij de bron aanpakken, heeft iemand enig idee hoe je dit in vredesnaam stopt?
Of heeft iemand dit al vaker mee gemaakt in de tussentijd?
De servers worden nauwelijks beinvloed kwa performance, maar t is weer iets wat zo nu en dan komt en gaat.

[Zenomyscus]

Misschien is het handig om een rate limiter toe te voegen als extra ondersteuning. Wij hebben hier ook last van, vele scans, crawlers en andere tools die voorbij komen en de volledige website in een seconde leeg willen trekken. Met een rate limiter kun je (afhankelijk van het type) bijvoorbeeld 10 requests doorlaten per 5 seconden. Er zijn allerlei implementatiemogelijkheden. Onze backend is c# en de rate limiter houdt een hoop zooi tegen. Dat werkt overigens alleen voor requests die binnenkomen met hetzelfde IP. Wat bij ons in elk geval bijna altijd zo is. De spammers krijgen vrij snel een 429 statuscode. De Googlebot kan er goed mee omgaan, mits het dus een 429 terugkrijgt en niet iets anders.

[Zenomyscus]

Oh en je kunt er weinig aan doen. Je weet pas welk verkeer je wilt uitsluiten zodra het binnen is. Kwestie van zoveel mogelijk afvangen en verder negeren.

[will3m]

Als ik het goed zag heb je Cloudflare actief, deze twee opties kunnen ook nog helpen:

• Security > Settings > Browser integrity check activeren
• Security > Settings > Bot fight mode

Dan doe je het maximale om te checken of het een echte gebruiker is. Je hebt ook nog op je overview pagina "I'm under attack mode" maar die kan ik niet adviseren op dit moment. Als het scannen/crawlen de server om zeep helpt werkt dat wel goed.