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 DDoS bot traffic.
May 7 2026 – forum server is under attack from DDoS 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.
Last edited by gaekwad (2026-06-23 14:51:27)
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
Re: Forum server under attack
There’s a new wave of bot traffic ongoing.
Cloudflare checkbox thingy re-enabled until I can sort a more permanent fix.
Thanks for your understanding and patience.
Offline
Re: Forum server under attack
Pete, I’d suggest you try the Hiawatha webserver. Not only is it secure, fast, and very lightweight with a simple configuration syntax, but it also includes all the necessary measures to protect HTTP connection from intruders — no more headaches, and no need for any firewall rules for HTTP.
Offline
Re: Forum server under attack
Offline
Re: Forum server under attack
Credit where it’s due, the source compile was very straightforward:
$ sudo ./hiawatha -v
Hiawatha v12.2, copyright (c) by Hugo Leisink <hugo@leisink.net>…and it appears to talk directly to PHP-FPM, which makes it a doddle to attach to an existing server without reinventing the wheel. I like this!
Given the last few weeks of madness with various vulnerabilities and patching until the early hours, this could be a fun weekend project to take some of the stress away. Thanks for the reminder, Vienuolis!
Offline
Re: Forum server under attack
The website moved from www.hiawatha-webserver.org to the author’s hiawatha.leisink.net (all the structure and internal links remain the same). I have corrected the links, yet my #236 is still pending for approval (Status: Open in GitHub).
Offline