There are 21,680 unique IPs that have attempted the DOS POST attack on my server since I noticed it last week.

The trickle is just about a thousand different hosts, for a few thousand different hits each day. Peanuts compared to the other traffic on the site. Small enough now to require familiarity with the log entry to pick them out as the logs scroll by when the server's a little busy.

I did mange to "stop" the attack by another mechanism: I force SSL on the site in question. This means that the server ignores the POST request and sends a redirection to the client. In this case, since it's not a legitimate use, the redirection is ignored. I'm not going to let that be the only mechanism of protection, especially since the redirection message is bigger than the error response (up to 310 bytes from 78), but it's nice to know it'll offer some small protection to the Apache server by not allowing the slow overflowing of POST data. Note I did leave the POST deny rule on the HTTP port, but the HTTPS redirect seems to be winning in some internal Apache priority.

I've got a one-line script that will rip through a day's log and add unique IP addresses to my firewall rule, so it's now a non-issue. Further, even if they decided to try a DOS attack using one of the other servers it won't work because all of those bot machines are blocked by the firewall. It saddens me a little bit as those are now IP addresses that can't see the things on the server. Currently cutting off traffic is not a big deal, but who knows who might like to see a review of Fido or something? I mean, this blog is not that interesting, but it's one of a handful served by the server.

More interesting is that even after blocking all of those IPs, and 15 countries (wherein there are likely to be some overlap), the attack still spreads. I suppose it's possible that there are bots who are just now getting the message. There may be bots who are changing IPs periodically.

Either way, it speaks of the determination of the bots. For whatever reason the attack started, it persists. It's been only a handful of days, so maybe this is normal bot latency. Or maybe the message queue for the bots has that many tries in it. I do know if I turn off the IP filtering that a flood of requests come in (I've tried it).

This whole problem also gives me a little IPv6 fear. My IPv6 has 18-bazillion addresses (a real number). Additionally, automatically my IPv6 addresses are changed throughout the day; right now my main workstation has six different addresses, some or all of which are different than earlier today. This is part of the obscurity security offered by IPv6, and it will mean firewall hell. Either a bazillion IP addresses will be entered or entire /48 or /64 networks will need to be blocked. That's what I have, is a /64, but with the effort of checking a box on a form with my tunnel provider (as my ISP doesn't yet do IPv6) I can have a /48. My provider doesn't care; they've got bazillions (still a real number) of networks they can hand out. I digress.

It occurs to me that it might need to be the case that when an IPv6 attack becomes reality that the general rule is to block out /64 networks instead of individual IPs. This is unfriendly because it means that a bazillion users on each network (I extend with all kinds of kidding) wouldn't be able to reach the server.