Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Forum server under attack
May 1 2026 – forum server is under attack from bot traffic.
I have blocked a number of IP ranges as a sledgehammer approach until I have some more time later tonight.
The forum will be slower than usual until I have resolved it properly.
Thank you for your patience. I will update this thread later.
Please excuse any terseness, I have been awake since 0430 today fixing CopyFail and the ongoing cPanel-related exploits that are causing chaos.
We are not affected by cPanel (I do not use it anywhere but some of my clients insist on it), and we are patched against CopyFail.
Offline
Re: Forum server under attack
I’ve enabled the Cloudflare Brown Alert© interstitial check box for a short time. Don’t hate me.
The server is overloaded with bot traffic, and I can look at this properly in about 4-6 hours.
Last edited by gaekwad (2026-05-01 16:39:54)
Offline
Re: Forum server under attack
Whatever steps are required until it passes is good for me. Thank you for being on this. And look after yourself.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Forum server under attack
Bloke wrote #343234:
Whatever steps are required until it passes is good for me. Thank you for being on this. And look after yourself.
Copy that! Thank you!
TXP Builders – finely-crafted code, design and txp
Offline
Re: Forum server under attack
We’re back. Cloudflare checkbox thingy disabled for now.
This is typical usage for *.textpattern.com (including the forum):
…and this is where we were at before I put the checkbox thingy on:
About 20× usual traffic. Bot traffic was hitting /viewtopic.php= queries like a mad thing, each request hit a PHP-FPM thread, and we were red-line’d for about an hour.
Queries were obfuscated SQL commands:
[01/May/2026:16:26:33 +0000] "GET /viewtopic.php?id=28621+WHERE+9199%3D9199EXTRACTVALUE%283248%2CCONCAT%280x7e%2C%28SELECT%2F%2A%2A%2F%28ELT%283248%3D3248%2C1%29%29%29%2C0x7e%29%29--+-&p=31 HTTP/2.0"
[01/May/2026:16:26:34 +0000] "GET /viewtopic.php?id=28621+WHERE+3761%3D3761EXTRACTVALUE%281569%2C%2F%2A%2150000CONCAT%2A%2F%280x7e%2C%28%2F%2A%2150000SELECT%2A%2F%28ELT%281569%3D1569%2C1%29%29%29%2C0x7e%29%29--+-&p=31 HTTP/2.0"…and there were ~30 requests per second before I put up the Cloudflare checkbox. Prior to this, Nginx didn’t crash or error out, PHP-FPM didn’t snap, and the only visible impact was a soupy response time from forum navigation.
Lessons have been learned for the next server rebuild iteration (later this year when I have sorted some snags), but overall our oldest server held up pretty well. I’ll share more of these lessons / changes when they’re implemented.
Final thing: I enabled IP logging in the Nginx logging for a short time to spot any patterns in the chaos. This command chews through the log and sorts the number of requests per IPv4 address, then groups by IPv4 similarity, and makes it much easier to spot problematic CIDR blocks:
sed -e 's/\([0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+\).*$/\1/' -e t -e d ./nginx.access.log | sort | uniq -c | sort…which spits out this (anonymised, excerpted) data:
2 xxx.yyy.190.102
1 xxx.yyy.190.103
1 xxx.yyy.190.107
3 xxx.yyy.190.110
2 xxx.yyy.190.111
1 xxx.yyy.190.115
2 xxx.yyy.190.119
1 xxx.yyy.190.129
1 xxx.yyy.190.13
2 xxx.yyy.190.131
1 xxx.yyy.190.177
14 xxx.yyy.190.2
1 xxx.yyy.190.203
9 xxx.yyy.190.205
2 xxx.yyy.190.220
1 xxx.yyy.190.233
1 xxx.yyy.190.248
9 xxx.yyy.190.3
1 xxx.yyy.190.42
1 xxx.yyy.190.52
1 xxx.yyy.190.62
3 xxx.yyy.190.66
7 xxx.yyy.190.67
678 xxx.yyy.190.70
784 xxx.yyy.190.71
2 xxx.yyy.190.89
1 xxx.yyy.190.96
1187 xxx.yyy.253.106
320 xxx.yyy.253.107
2 xxx.yyy.253.110
7 xxx.yyy.253.111
1 xxx.yyy.253.151
1 xxx.yyy.253.25
1 xxx.yyy.253.45
1 xxx.yyy.253.51
1 xxx.yyy.253.57
2 xxx.yyy.253.58
3 xxx.yyy.253.59
1 xxx.yyy.253.60
14 xxx.yyy.253.74
4 xxx.yyy.253.75
1 xxx.yyy.253.78
2 xxx.yyy.253.79
1 xxx.yyy.253.82
11 xxx.yyy.253.88
1 xxx.yyy.253.91
1 xxx.yyy.253.96From there, the offenders can be picked out and banned. The Nginx rate limiting appear to be firing correctly, but the ban time was too short and the blocked IPs switched to other nodes. This has been addressed.
Last edited by gaekwad (2026-05-01 21:38:34)
Offline