Bots zorgen voor trage of niet bereikbare website

[nico_van_wijk]

Ik host een nieuwswebsite bij een Nederlands hostingbedrijf (denk dat het netjes is om de bedrijfsnaam niet te noemen).

Laatste paar maanden hebben veel last van een trage en soms een niet bereikbare website. Naar mijn inziens wordt dit veroorzaakt door veel requests die tegelijkertijd door bots worden afgevuurd.

Deze conclusie trek ik uit onderstaande info die ik log in een mysql database. Vanaf 1 ip-adres worden op een zelfde tijdstip meerdere artikelen opgevraagd.

IP Timestamp Artikel ID

64.227.16.77	1778971666	43021
64.227.16.77	1778971666	53022
64.227.16.77	1778971666	52443
64.227.16.77	1778971666	52199
64.227.16.77	1778971666	35576
64.227.16.77	1778971666	31554

Ik heb onze hoster om hulp gevraagd:

• WAF (Web Application Firewall)
• Rate limiting, blokkades op specifieke endpoints of IP ranges
• Meedenken voor een oplossing

Het kunnen ze ons niet verder helpen. Op het shared platform willen zij niet op accountniveau maatregelen nemen zoals bijvoorbeeld rate limiting of blokkades op IP-ranges.

Op dit moment probeer ik het onder controle te houden door in de htaccess file ip's en ip-ranges te blokkeren:

<RequireNone>
# Vultr / vergelijkbare VPS
Require ip 45.206.0.0/15
Require ip 45.207.0.0/16
Require ip 45.175.0.0/16
Require ip 45.171.0.0/16
enz...
</RequireNone>

Maar dit is dweilen met de kraan open. Niet echt een goede oplossing omdat ik waarschijnlijk ook legitiem verkeer blokkeer.

Mijn vragen zijn:

- Mag ik verwachten van onze hosting partij dat ze dit soort problemen kunnen oplossen?
- Zijn er hosters in Nederland waar we naar over kunnen stappen die dit soort zaken beter geregeld hebben?
- Is de gratis versie van Cloudflare mogelijk een oplossing.

Hoop dat jullie me van advies kunnen voorzien.

[FiscBiker]

Heb hier ook last van en ik heb zelf naar de HTTP_USER_AGENT zitten kijken. Bepaalde combinaties van "Mozilla" + "Windows" + "Safari 537.36" leken mij verdacht, dus daar heb ik een regex voor gebouwd.

Tevens viel me op dat veel bots ook Chrome in de 130-reeks rapporteren terwijl valide verkeer in de 140 reeks zit (maar dan doe je dus de aanname dat je bezoekers hun browser up-to-date houden).

De kans op het blokkeren van legitiem is met deze methode dan ook nog weer vele malen groter dan met IP-ranges blokkeren, daarom ga ik hier verder ook geen kant-en-klare regex voorkauwen, je kan beter even zelf in je logs controleren.

Tevens, een gokje: als het een Wordpress site is, verdiep je dan ook in wp-cron voor zover je dat nog niet had gedaan.

[Crazy-]

Kan je eventueel Cloudflare toevoegen?

[Detmer]

Een tijdje geleden heb ik iets vergelijkbaars ervaren. Na onderzoek bleek dat Meta/Facebook tienduizenden pagina's per dag opvroeg. Ik heb Cloudflare (gratis pakket) ertussen gezet en Meta geblokkeerd en toen was het probleem opgelost.

[Bertus]

Zelfde probleem, al zo'n 2 jaar op en af. Soms zijn er patronen, nu bvb veel oude firefox en chrome versies. Maar soms ook een boel fransozen.

[nico_van_wijk]

Crazy- schreef op zondag 17 mei 2026 @ 14:05:
Kan je eventueel Cloudflare toevoegen?

Ik denk dat ik deze optie maar eens ga proberen....

[Zenomyscus]

Wij hebben tientallen websites in beheer en verkeer van bots is er zeker niet minder geworden. Ik zie dit echter niet als iets dat de hoster moet oplossen. Willicht dat ze er wat hulpmiddelen voor aan kunnen bieden, maar zoiets implementeren voor al hun klanten in een shared omgeving moeten ze niet doen. Voor de ene website is 100 requests per seconde teveel, de andere kan er 10000 aan. Dat hangt van veel factoren af en daar kan en moet de hoster geen rekening mee houden.

Ik weet niet wat je precies draait, maar met bijvoorbeeld c# is rate limiting binnen 10 minuten geregeld. Dat werkt goed tegen bots die verbinden met hetzelfde IP adres, wat de meeste bots doen. Het helpt niet tegen een DDOS, maar wat mij betreft is het iets wat je zelf zou kunnen regelen. Cloudflare kan ook, maar ik ben daar geen fan van.

[_JGC_]

Ratelimiting is idd iets wat je kunt inbouwen, maar bedenk je ook dat er botnets zijn die met een heel /24 subnet langskomen en met 252 IP adressen om beurten of tegelijk een paar requests doen.
En bedenk je dan ook dat IPv6 bestaat en die minimaal per /64 worden uitgegeven, wat 2^64 adressen toestaat.
Google, Apple en Meta doen dit idd, waarbij Google de enige is die zelf aan rate limiting doet als de boel niet snel genoeg reageert. Meta trekt gewoon je server compleet plat.

[Qwerty-273]

nico_van_wijk schreef op zondag 17 mei 2026 @ 01:05:
....hebben veel last van een trage en soms een niet bereikbare website.

Het kunnen ze ons niet verder helpen. Op het shared platform willen zij niet op accountniveau maatregelen nemen ....

Komt de traagheid door jouw website? Of is het shared platform op die momenten gewoon zwaar belast (door een andere klant op hetzelfde gedeelde platform)?

En specifiek voor jouw eigen nieuwswebsite, biedt je daar ook reactie mogelijkheden etc aan en dat je dus een goed presterende database nodig hebt, of zou je bij wijze van spreken ook gewoon platte statische website kunnen aanbieden (waarbij de nieuws artikelen gewoon als nieuwe platte data wordt toegevoegd - eventueel met een toolkit als Jekyll of Hugo).

[peize9]

Een cloudflare of iets er tussen is het beste. Deze heeft bot fighting en dergelijke dingen om hier tegen op te treden. Heb je ergens monitoring dat laat zijn hoeveel requests per seconde dit zijn? Ik betwijfel erg dat deze bots dat veroorzaken. Heb je ergens de data van monitoring dat iets zegt over wat het kan veroorzaken?

- Mag ik verwachten van onze hosting partij dat ze dit soort problemen kunnen oplossen?

Hangt compleet af van je SLA en hosting pakket. Daar kunnen wij niet echt iets over zeggen zonde meer info.

- Zijn er hosters in Nederland waar we naar over kunnen stappen die dit soort zaken beter geregeld hebben?

Er zijn heel veel hosters die alles goed geregeld hebben. Ik raad zelf aan te kijken bij internet.nl.

- Is de gratis versie van Cloudflare mogelijk een oplossing.

Ja. Zowel ivm caching als de bot fighting mode. Als je server echt in de problemen komt door bots dan is dit mogelijk de oplossing.

[ Voor 48% gewijzigd door peize9 op 18-05-2026 02:41 ]

[nico_van_wijk]

peize9 schreef op maandag 18 mei 2026 @ 02:34:
Een cloudflare of iets er tussen is het beste. Deze heeft bot fighting en dergelijke dingen om hier tegen op te treden. Heb je ergens monitoring dat laat zijn hoeveel requests per seconde dit zijn? Ik betwijfel erg dat deze bots dat veroorzaken. Heb je ergens de data van monitoring dat iets zegt over wat het kan veroorzaken?

Dank je wel 'peize9' voor je uitgebreide reactie. Als eerste wat meer info hoe onze site in elkaar zit:

Website draait niet op standaard cms maar is custom made programmeert in php met een mySQL database. Heeft jaren perfect gedraaid echter de laatste maanden regelmatig vertraging of zelfs niet bereikbaar door time outs.

In log file krijg ik om sommige momenten deze nginx error te zien: 2564108#0: *15455316 upstream timed out (110: Connection timed out) while connecting to upstream

Wat de hoster gedaan heeft:

- Onze site extra geheugen en resources gegeven
- Het maximum aantal gelijktijdige PHP-processen verhoogd van 5 naar 30

Ik hou zelf een soort floodtabel bij mySQL, deze gebruik ik om er voor te zorgen dat de artikel views enigszins correct worden geregistreerd. Wanneer een bezoeker binnen 10 seconde hetzelfde artikel bezoekt wordt de teller niet opgehoogd. Op momenten van traagheid zie ik in deze tabel tussen de 300 en 400 ip's in de tabel staan. Heel veel verschillende ip-adressen van o.a. DigitalOcean, Alibaba Cloud, Southeast Asia, enz. Sommige ip-adressen vragen op exact hetzelfde tijdstip meerdere artikelen op, vandaar is mijn conclusie bots, gezien een mens dit niet kan doen.

[_JGC_]

Code of database kan misschien een optimalisatieslag gebruiken, vaak staan er geen indexen op de juiste velden en naarmate een site groeit wordt zo'n tabel groter en wordt het ontbreken van een index problematischer.

Het verkeer dat je omschrijft zijn idd crawlers, ik zie ze bij mijn klanten ook en meestal blokkeer ik dan complete ranges, hetzij in cloudflare, hetzij via de eigen mogelijkheden in de website (de website hebben we zelf controle over, cloudflare moeten we bij een support toko een ticket voor inschieten).

Ik denk dat het losgeslagen AI-traningsbots zijn die zo snel mogelijk je site willen crawlen, maar kan ook maar zo een DDOS zijn.

Overigens werken die bots zo, als jij de site sneller maakt of meer resources toewijst, gaan die bots gewoon nog harder trekken. Je zult dus vooral het verkeer moeten reguleren.

[peize9]

Als het apache draait en de host het niet alles juist heeft afgesteld zou het een "slow lorris" DDOS kunnen zijn... Maar wat je echt nodig hebt is meer inzicht in wat er gebeurd.

Ff wat vragen

Welke php versie? Is deze geüpdatet?

Wat staat er op de site?

Is er een update aan de code geweest tussen wanneer het goed was en wanneer er problemen ontstonden?

Php + framework?

Kan je ook iets zien van hoeveel internet traffic er nu eigenlijk gebruikt wordt?

[nico_van_wijk]

peize9 schreef op maandag 18 mei 2026 @ 13:14:
Als het apache draait en de host het niet alles juist heeft afgesteld zou het een "slow lorris" DDOS kunnen zijn... Maar wat je echt nodig hebt is meer inzicht in wat er gebeurd.

Ff wat vragen

Welke php versie? Is deze geüpdatet?

Wat staat er op de site?

Is er een update aan de code geweest tussen wanneer het goed was en wanneer er problemen ontstonden?

Php + framework?

Kan je ook iets zien van hoeveel internet traffic er nu eigenlijk gebruikt wordt?

PHP versie 8.2.31. Kan deze eventueel update...

Op de site staan nieuwsartikelen met foto's.

Geen framework, alles zelf geschreven. Althans, maar wel gebruik van bootstrap en jquery.

Data-trafic, deze maand 502.50 GB

[Patrock]

Controleer of de php-fpm opcache is ingeschakeld. de artikelcounter zou het mooiste via een JavaScript call lopen na x seconden. Daarmee pak je de reads van legitiem verkeer, maar bots (die geen JavaScript uitvoeren) doen er niets mee. Stuur wel een token mee die gevalideerd kan worden. Zodat enkel de url aanroepen niets doet.

met name calls naar een backend zijn zwaar. Oftewel je database queries. Mochten pagina’s statisch kunnen. Nog mooier!

rate limiting kun je ook instellen via de htaccess.

Controleer je robots.txt (statische file) en probeer te voorkomen dat 404 pagina’s door de applicatie gegenereerd moeten worden.

Scherm je admin omgeving altijd goed af. Indien mogelijk met een htaccess op whitelist.


Mocht het een lokale site zijn. Kun je ook kijken naar geoip blokkades. Bijvoorbeeld enkel verkeer vanuit benelux doorlaten. Of rate limits strakker buiten nl.

pagina’s met filteropties zijn lastig met bots. Die proberen vaak alle mogelijke opties in alle volgordes. Of kunnen vastlopen in de argumenten die meegestuurd kunnen worden waardoor je duizenden calls kunt krijgen op search of filter pagina’s. Hou hier rekening mee met robots.txt en zet de canonical url goed in pagina’s. Een product is bijvoorbeeld canonical. Hier hoort geen taal selectie, filteropties of opties bij in de url te staan. Anders gaan bots alle mogelijke opties scrapen.

[moepie]

De upstream timeout error heb ik ook gehad. Van de ene dag op de andere ging het verkeer van mijn kleine prive website x100.

Mijn php server maakt een session file aan per verzoek van metacrawler en andere bots (want die geven geen cookies mee). Daardoor stonden er miljoenen lege sessie files in /var/lib/php/sessions. En ook al is /var/lib/php/sessions een memory disk, dat gaf zoveel vertraging dat de php server in de timeout ging.

Ben een dag bezig geweest om de multi-layered defense te verbeteren
- session file cleaning, mijn website heeft lang levende sessie cookie files nodig voor ingelogde gebruikers. Met een cronjob worden alle sessies van niet-ingelogde gebruikers verwijderd.

/15 * * * find /var/lib/php/sessions -type f -empty -mmin +10 -delete

- nginx reverse proxy met explicite 403 entries. De bad agent check bracht de php server load terug normale proporties

map $http_user_agent $is_bad_agent {
default 0;
"~*meta-externalagent" 1;
.... meer entries
}

en dan in de server sectie

# block bad agents
if ($is_bad_agent) { return 403 "bok of"; }
# block by country
if ( $http_cf_ipcountry = "SG" ) { return 403 ""; }
# .... meer landen

# block known paths used to probe
location ~ ^/wordpress.*$ { return 403 "bok of"; }
location ~ ^/wp.*$ { return 403 "bok of"; }
# .... meer paths

- bescherm de php server, de php site zit niet op de root, maar in een folder. bv '/dokuwiki/doku.php'. Als je naar de root van de server gaat, dan served nginx een static html file met een javascript redirect.

- daarna vond ik de cloudflare botfighting mode, als je die aanzet wordt bekende crawlers en ai bots tegen gehouden.

[TD-er]

Ik heb er met het ESPEasy forum ook enorm veel last van.

Al zo'n anderhalf jaar lang ben ik met dergelijke bots aan het vechten. (zie: https://github.com/letscontrolit/ESPEasy/issues/5398 )

Cloudflare helpt maar een beetje. Uiteindelijk ben je zelf nog veel te lang bezig om pro-actief nieuwe AS-num waarden toe te voegen aan de filters.

Cpguard leek te helpen, maar de laatste paar dagen is het weer compleet mis.


Wat ik zie is dat het met vlagen komt en het gedrag ook nog wisselt per keer.

De ene keer heb je 10k - 100k bots tegelijkertijd (althans in een 5-min window) en de andere keer zijn het veel meer requests per IP.
Met die vlagen van enorm veel bots tegelijkertijd heb je op een dag makkelijk 1 - 2.5 miljoen verschillende IPs in de logs en elk doet 1 request. Geen typisch DDoS gedrag, maar meer alsof elk een lijstje URLs heeft gekregen om de boel te scrapen.

We hebben ook wel tijden gehad dat er idioot veel data getrokken werd van 50+ GByte/dag met pieken van meerdere Gbps (even aangenomen dat de monitoring goed ging onder load, weet niet of die server uberhaupt wel 6 Gbps kan trekken) maar de laatste tijd is het met name veel CPU-intensieve requests.

Kan ook zijn dat de filters nu zo groot zijn dat puur alleen al het filteren de server al plat legt.

Afgelopen dagen was het voornamelijk verkeer van subnetten van Microsoft, Google, Apple en Amazon.

En het erge is, je voegt een blokkade toe voor het ene subnet en nog geen 5 minuten later gaat een volgend subnet (soms zelf in ander land of continent) vrolijk verder, vanaf een subnet van dezezelfde eigenaar.

Daar bovenop had ik gisteren volgens mij ook een DDoS ertussendoor vanuit Irak (????) en ook een subnet wat niet te tracen was (elk andere IP uit die range kwam totaal ergens anders uit) maar de laatste hop zat wel in Irak.
Die DDoS viel echter in het niet bij wat de big-tech subnetten aan crawlers op het forum afstuurden.

Gisteren was het zelfs zo erg dat ik met veel moeite de server kon laten rebooten en voordat ik in kon loggen was de server alweer onbereikbaar.


Al met al maakt dat het niet echt leuk meer om een forum te hosten.

[NiGeLaToR]

@TD-er hoe moeten de co-pilots van deze wereld anders getraind worden?

Ik zie dat verkeer op een site van ons sinds 2-3 jaar flink terugloopt, de inhoud is immers via AI ook te verkrijgen dus is het bezoeken van de website niet meer nodig. Stekker gaat er wel een keer uit, maar dan is de vraag - wie zoekt die dingen dan nog uit en publiceert ze?

[TD-er]

NiGeLaToR schreef op dinsdag 19 mei 2026 @ 12:16:
@TD-er hoe moeten de co-pilots van deze wereld anders getraind worden?

Ehh niet?

Laat de programmeurs maar wat basiskennis opdoen.

[NiGeLaToR]

TD-er schreef op dinsdag 19 mei 2026 @ 12:18:
[...]

Ehh niet?

Laat de programmeurs maar wat basiskennis opdoen.

Was cynisch bedoeld, uiteraard. Sloeg aan op je laatste zin - over dat het zo niet leuk meer is, herkenbaar.

[TD-er]

Ja dat cynische had ik wel opgepikt, dat voel ik namelijk ook overal waar het over AI gaat.

Zie ook mijn laatste opmerking in de issue die ik linkte:

AI: "Aggravated Insanity"

[_JGC_]

@TD-er Niet alleen forums... ik beheer servers voor een grote webshop met automaterialen, die hebben er ook last van. Op sommige momenten komen de bots over de hele wereld hele bulten requests tegelijk ophalen, allemaal productdetail pagina's. Google doet het ook, maar die luistert tenminste naar ratelimiting en laat de snelheid droppen als het trager wordt. Meta trekt gewoon full pull je hele server op z'n rug en Apple zit nog net op randje van acceptabel.
In cloudflare kan je hele rulesets invoeren om dingen te blokkeren, we hebben er al vele rules voor staan, maar ze komen gewoon weer met wat nieuws.

Probleem is dat veel bots zich ook niet als bot identificeren. De website draait hier vnml op cache, een bot kan van zichzelf de cache niet verversen.

De sessies waar @moepie hierboven over spreekt is een goede om over na te denken, ik zit nu op 30K sessies en de meesten zijn leeg of hebben standaard waardes. Elke session_start die je niet doet is een aantal file lookups minder. Zal hier bij de eerstvolgende bot aanval weer eens kijken wat er aan sessies opbouwt.

[DexterDee]

Cloudflare heeft hier goede tools voor en nee, dan bedoel ik niet hun WAF, rule engine en crawler settings. Die werken zoals gezegd okay, maar hebben veel onderhoud nodig en zijn verre van waterdicht.

Ik heb het dan over Cloudflare Turnstile. Hiermee introduceer je een onzichtbare CAPTCHA die controleert of de bezoeker een mens of bot is. Voor alle web requests die niet van caching gebruik kunnen maken kun je deze methode toepassen. Ik heb deze functionaliteit initieel gebruikt om geautomatiseerde sign-up en form spam tegen te gaan, maar het blijkt uitstekend te werken tegen al het bot verkeer, ook de AI bot scrapers.

Verder raakt dit issue wel de achilleshiel van PHP, elk individueel request wat concurrent afgehandeld moet worden pakt minimaal 15-20 Mb geheugen. Bij veel gelijktijdige requests is dat niet schaalbaar te maken. De beste tip die ik op dat vlak kan geven (naast weg migreren van PHP) is de standaard stack (Apache/Nginx/PHP-FPM) in te ruilen voor FrankenPHP of RoadRunner. Daar draaien we al jaren onze legacy PHP applicaties op en dit levert meetbare performance winst op.

[ThinkPad]

@TD-er en anderen, wellicht is https://github.com/TecharoHQ/anubis iets? Dat gebruiken ze bij openwrt.org

Anubis is a Web AI Firewall Utility that weighs the soul of your connection using one or more challenges in order to protect upstream resources from scraper bots.

This program is designed to help protect the small internet from the endless storm of requests that flood in from AI companies. Anubis is as lightweight as possible to ensure that everyone can afford to protect the communities closest to them.
[...]

[DexterDee]

ThinkPad schreef op dinsdag 19 mei 2026 @ 13:07:
@TD-er en anderen, wellicht is https://github.com/TecharoHQ/anubis iets? Dat gebruiken ze bij openwrt.org

Anubis heeft twee serieuze tekortkomingen waar je rekening mee zou moeten houden. Ten eerste is de filter heel makkelijk te omzeilen voor bots door de string "GoogleBot" in de User-Agent te zetten. Ten tweede is Anubis heel picky met betrekking tot Browser support. Elke user die niet een mainstream browser gebruikt heeft een grotere kans om geblokkeerd te worden. Verder is het scherm waar je altijd "doorheen" moet niet bijzonder fraai. Als je met deze beperkingen kan leven is de tool wel erg effectief.

[Patrock]

Sessies kun je in plaats van disk ook in redis bij houden. of valkey. Dat is in memory. vergeet ook niet /tmp te controleren. wordt ook vaak misbruikt.

[TD-er]

Ik heb zojuist de robots.txt een beetje uitgebreid met de laatste versie van deze lijst en de 'search related AI bots'

Daar heb ik zelf nog deze aan toegevoegd, omdat die nogal hardnekkig aan het crawlen was:

code:

User-agent: Facebot Twitterbot

Binnen een uurtje was het aantal 'actieve bezoekers' van ruim 2000 naar nu rond de 100 gezakt.

Ben benieuwd hoe lang dit blijft werken.

[ Voor 6% gewijzigd door TD-er op 20-05-2026 10:36 ]

[SgtElPotato]

Crazy- schreef op zondag 17 mei 2026 @ 14:05:
Kan je eventueel Cloudflare toevoegen?

Ik zou hieraan toe willen voegen om eens te kijken naar een EU alternatief.

[TD-er]

OK, de robots.txt aanpassing heeft zeker effect...

Nu komt er alleen nog bot-traffic zonder herkenbare user agents.

[Juup]

SgtElPotato schreef op woensdag 20 mei 2026 @ 10:43:
Ik zou hieraan toe willen voegen om eens te kijken naar een EU alternatief.

Zoals?

[SgtElPotato]

Juup schreef op woensdag 20 mei 2026 @ 11:57:
[...]

Zoals?

Ik heb er geen ervaring mee, maar ik neem aan dat er alternatieven zijn in de EU. CF is een prima service, maar wel Amerikaans

[TD-er]

Je zou kunnen kijken naar cPGuard ( https://manage.opsshield.com/ )

In het begin leek deze beter te werken dan CloudFlare, maar de laatste paar dagen lijkt er geen houden meer aan qua AI bots. Het is echt meer een continue DDoS en je ziet in de stats van ze ook de grafieken van "blocked connections" en "Web Attacks Stopped" behoorlijk teruglopen.

Als ik de laatste 7 dagen vergelijk met de 7 dagen ervoor, krijg je Trumpiaanse percentages te zien.

There is a 227.55% decrease

[nico_van_wijk]

Inmiddels 2 weken verder. Alle reacties in dit topic goed gelezen. Iedereen bedankt voor zijn reactie!

Ik lees dat niet iedereen enthousiast is over Cloudflare, die ga ik voorlopig maar niet proberen.

Inmiddels zelf in php wel wat maatregelen genomen: een burst-detector en rate-limiter gemaakt. Voordat er content wordt geladen wordt hierop gecheckt en een deny gegeven.

Ik zie in de log die ik bij hou dat de vooral de burst-detector veel aanslaat. Helaas is dit nog niet genoeg. Ik zie ook heel veel verschillende IP-adressen die op een zelfde moment requests sturen. Veel ook vanuit een zelfde subnet. Ik denk dat ik ga proberen om op subnet /24 te detecteren.

Ik snap niet helemaal waarom ons dit overkomt. We zien dat die bots willekeurig een nieuwsartikel url benaderd in dit formaat: www.xxxxxx.nl/98127/nieuwsartikel_titel.

Hoe houden andere nieuwssites dit in toom?

[Erulezz]

SgtElPotato schreef op woensdag 20 mei 2026 @ 12:02:
[...]

Ik heb er geen ervaring mee, maar ik neem aan dat er alternatieven zijn in de EU. CF is een prima service, maar wel Amerikaans

https://bunny.net/shield/

Is er een, volledig EU

[WargamingPlayer]

Cloudflare is geweldig maar bepaal je doelgroep en gooi de volgende vraag Claude:

I have a web site, written in php. I want to redirect all non eu traffic to an page showing a simple message. I want to have the ability to add countries to block or to pass. I want it in php.

En je krijgt fantastische code om in je site op te nemen.

[davefox]

Ik heb met mijn website ook last van deze botnet.

Nu was het eerst dat deze botnet voornamelijk van bepaalde Datacentra's kwamen, die ik via mijn firewall kon blokkeren. Maar nu zijn het gewoon volledig willekeurige IP adressen van gewone internet aansluitingen.

De ergste piek kwam op 23 mei, toen mijn forum 650 MB aan bandbreedte zag op een dag (normaal ziet hij zo'n 5 MB per dag, tis een kleinschalig forum).

Wat ik heb opgemerkt is dat deze botnet het vooral gemunt heeft op fora, ik zie op mijn blog ook hier en daar eens wat voorbij schieten, maar het forum wordt gewoon constant gehamerd met verzoeken. (dit met de firewall blokkades nog actief)

Ik heb nu Chrome UA's versie 139 en lager geblokkerd via het htaccess bestand, en de gastenlijst is weer schoon. Heb ook de 8G-firewall van perishable press toegepast op mijn forum, en blog.

Wat ik het allerraarste vind is dat deze botnet precies de link herkent terwijl de website door het IP nooit bezocht is geweest, op het forum met SID en al.

[Ramon]

nico_van_wijk schreef op zondag 31 mei 2026 @ 20:09:
Inmiddels 2 weken verder. Alle reacties in dit topic goed gelezen. Iedereen bedankt voor zijn reactie!

Ik lees dat niet iedereen enthousiast is over Cloudflare, die ga ik voorlopig maar niet proberen.

Inmiddels zelf in php wel wat maatregelen genomen: een burst-detector en rate-limiter gemaakt. Voordat er content wordt geladen wordt hierop gecheckt en een deny gegeven.

Ik zie in de log die ik bij hou dat de vooral de burst-detector veel aanslaat. Helaas is dit nog niet genoeg. Ik zie ook heel veel verschillende IP-adressen die op een zelfde moment requests sturen. Veel ook vanuit een zelfde subnet. Ik denk dat ik ga proberen om op subnet /24 te detecteren.

Ik snap niet helemaal waarom ons dit overkomt. We zien dat die bots willekeurig een nieuwsartikel url benaderd in dit formaat: www.xxxxxx.nl/98127/nieuwsartikel_titel.

Hoe houden andere nieuwssites dit in toom?

Nou is het al lang geleden dat ik met PHP heb gewerkt maar ik zou zeggen dat je in dit geval al te laat bent (in de lifecycle van de request) als je met php aan de slag gaat voor rate-limiting. Ik zou kijken of je aan de kant van de webserver een aanpassing kan doen zodat de foute requests al geblokkeerd worden voordat je bij PHP aankomt. Hier een artikel over rate limiting in nginx.

Verder zou je natuurlijk ook de code van de website onder de loep kunnen nemen. Misschien kan je caching inbouwen, queries optimaliseren, of plaatjes verkleinen (of lazy loading maken). In het uiterste geval kan je, afhankelijk van de functionaliteit van je website, je website statisch maken?