Overspoeld door GET-request

[Conrado]

Mijn vraag
Onze nieuwe website wordt overspoeld met GET-request, met allemaal dezelfde format:
GET /product/extern?select=aaa-bbb-ccc-ddd-eee
Dat aaa-bbb- etc als voorbeeld, het zijn nogal wat 3-karakter varianten. Ik heb ze al in honderden varianten gezien, soms. kort, soms een serie van 10. Het gaat om vele berichten per seconde en het is al weken aan de gang. Het is afkomstig van 1000e IP's.
Hoe kom ik er vanaf?

Relevante software en hardware die ik gebruik
VPS bij TransIP achter Cloudflare, Ubuntu 24.04, NGINX, PHP8.4, MariaDB, WP7, WooCommerce

Wat ik al gevonden of geprobeerd heb
Als ik niets doe, is de site niet meer bereikbaar, zo ontdekte ook het probleem. Nu pas ik het volgende toe: In NGNIX herken ik de '?select' en geneer ik unieke foutcode. In fail2ban levert die foutcode in de access log direct een ban op van 7 uur, daarna steeds langer. Ik heb op dit moment zo'n 8000 bans in de jail.
Dat werkt maar ik zie in htop de CPU-load oplopen. Nu al pieken tot 70%. Die CPU-kracht gaat in fail2ban zitten.
De website zelf is niet gecompromitteerd. Ik check met hashes op de Wordpress files of er wijzigingen zijn.

[Blokker_1999]

Niet, jij kunt niet bepalen wat die miljoenen andere apparaten op het internet doen. Je doet nu al het enige wat jij zelf kunt doen. Het verkeer blokkeren op het moment dat je het voor de eerste keer ziet binnenkomen.

De volgende stap moet dan al zijn dat je naar een DDoS mitigatie platform gaat kijken dat jouw specifieke use case kan verwerken en tegenhouden.

[Oogje]

Dat klinkt een beetje als de AI scraper van meta, die is echt fokkin irritant en een bizarre slurper van data. Je moet ff kijken welke useragent er allemaal op die GETs zit.

[CodeCaster]

Kun je in Cloudflare niet gewoon een rule instellen?

[Sagitherus]

Al kun je kijken naar een tweede type ban, die say ... een maand lang is. Dit type get request ziet er niet direct uit als een scraper, maar eerder een ddos door alle select queries die er bij de vraagteken plakken.


Ik dans nog heel erg op Cloudflare en met een mogelijk tweede loadbalancer die de cpu load of webverkeer dekt.

[Onbekend]

Bestaat het pad /product/extern wel? Ik herken het namelijk niet direct.

Zo niet, dan zou je dit in de config van Nginx kunnen toevoegen:
location = /product/extern {
return 444;
}

[Conrado]

Dank voor alle reacties. Even kort wat antwoorden:

• Er komt een hele reeks user agents voorbij, ik denk ook allemaal nep
• Ik geloof ook niet in een scraper, want er komen alleen dit soort ?select queries, die nergens op mijn site voorkomen. De sitestructuur staat gewoon in een sitemap.xml. Het is een WP-omgeving dus je ziet ook regelmatig de bekende WP scrapers zich melden. Dat is geen probleem.
• Ook ik heb al aan Cloudlfare gedacht, maar je moet op Query kunnen filteren. Dat heb ik nog niet ontdekt. Als alternatief kom ik veel scripts tegen om vanuit fail2ban de firewall van cloudflare met rejects te vullen. Echter in mijn CPU load is de firewall niet het probleem, wen fail2ban zelf.
• Ja, de paden bestaan, maar de ?select query niet.

[Juup]

Vreemd dat fail2ban een hoge load geeft.
Hoe heb je die geconfigureerd? Met welke database back-end?

Jouw firewall (en niet fil2ban) moet alles tegenhouden. En dan 1x per zoveel tijd een nieuw ip-adres toevoegen aan de firewall etc.

[Sagitherus]

De query wekt nogal een insteek van sql injection af, zou je je database na kunnen lopen naast het controleren van file hashes?

[Conrado]

Juup schreef op woensdag 8 juli 2026 @ 15:56:
Jouw firewall (en niet fil2ban) moet alles tegenhouden. En dan 1x per zoveel tijd een nieuw ip-adres toevoegen aan de firewall etc.

Dat doet 't ook prima, maar de GET's komen met de tientallen per seconde binnen. Het is voor f2b alle hens aan dek.

[Conrado]

Sagitherus schreef op woensdag 8 juli 2026 @ 16:09:
De query wekt nogal een insteek van sql injection af, zou je je database na kunnen lopen naast het controleren van file hashes?

Hoe pak ik dat het beste aan..?

[njitter]

Voor Wordpress heb je ook gewoon firewall plugins. Zelf gebruik ik Wordfence.

[418O2]

njitter schreef op woensdag 8 juli 2026 @ 16:20:
Voor Wordpress heb je ook gewoon firewall plugins. Zelf gebruik ik Wordfence.

Dan is WordPress alleen al "aan het werk" met de request en het kost vast ook wel wat performance. Zulke zaken vang je idealiter eerder af

[Conrado]

Dat is ook mijn ervaring. In principe genereren deze GET's in WP standaard een 404. Echter WP gaat plat bij zoveel request per seconde.
Sowieso - ik kom van Joomla - vind ik dat in vergelijk WP veel resources nodig heeft. Het heeft wat moeite gekost om de site echt soepel te laten lopen.

[418O2]

Conrado schreef op woensdag 8 juli 2026 @ 16:32:
Dat is ook mijn ervaring. In principe genereren deze GET's in WP standaard een 404. Echter WP gaat plat bij zoveel request per seconde.
Sowieso - ik kom van Joomla - vind ik dat in vergelijk WP veel resources nodig heeft. Het heeft wat moeite gekost om de site echt soepel te laten lopen.

WordPress is inderdaad niet echt zuinig met resources. Je moet echt aan de slag met caching om het acceptabel te krijgen

[Conrado]

Ja, ik heb Supercache em de NGINX fastcache actief, dat werkt prima.

[CodeCaster]

Sagitherus schreef op woensdag 8 juli 2026 @ 16:09:
De query wekt nogal een insteek van sql injection af, zou je je database na kunnen lopen naast het controleren van file hashes?

TS heeft het over een consistent patroon met ID's bestaand uit groepen van drie letters, gescheiden door een streepje. Niks SQL injection aan. Daarnaast, hoe "loop je je database na"?

@Conrado je noemt dat het jullie nieuwe site is. Worden deze requests op domeinnaam gedaan, of op IP? In het eerste geval: had de oude site iets draaien op het geraakte endpoint, en kun je achterhalen wie dat zou aanroepen en vragen of ze stoppen? Zoals anderen noemen: misschien valt er uit de User-Agent wat te achterhalen. In het tweede geval: heb je misschien een VPS gekregen die eerder een ander soort site hostte op dat IP, en zo ja, vraag en IP-wissel of nieuw publiek IP aan?

En ik blijf bij mijn Cloudflare-opmerking van eerder: ik zou het daar blokkeren. Kan prima op deel van de URL.

[ Voor 64% gewijzigd door CodeCaster op 08-07-2026 23:10 ]

[Conrado]

Ze komen op domeinnaam binnen dus via Cloudflare. Direct access - om Cloudflare heen - is sowieso geblokt.

Maar @CodeCaster gaf het beste antwoord: Gebruik een rule in Cloudflare. Ik zat bij Cloudflare te veel met fail2ban in m'n hoofd. Je kunt echter op een query - ?select - filteren en daarop een block zetten. Zodoende hou je de rommel gewoon buiten.
Met één rule werd mijn log stil, muis stil

De CPU is nog wel aan het werk om alle Reject regels op te schonen. Ik snap dat ik die kan wissen, maar het is wel mooi om te zien hoe dat met f2b werkt. Nog 6000 bans te gaan. Dankzij dit gedoe ben ik wel overtuigd dat f2b ècht werkt. Het kan dus ook grote volumes aan.

Iedereen bedankt voor het meedenken!