Jim Dory writes:
[S]ince I've failed to get any suggestions to work[,] I think I need to move off this older Centos server.
Keeping the server upgraded is always a good idea, but I don't think that is going to help, and it's likely to bring a host of new issues. To slightly misquote from Zork, "you will find yourself in a twisty maze of little passages, all alike." And unlike the situation now, they won't be relevant to solving your spamming problem, just annoying glitches because of the upgrade. Postpone that in favor of locking out the spammers first, IMHO, YMMV.
I will still play around with the captcha solution and see if I was missing anything.. but can't get past a "We hit a bug" when enabled.
I would like to figure why this isn't working for you.
I tried firewalld, but locked myself out of the web interface and not real sure how to configure that to work. Could do some more research on it.
You say elsewhere that you know which IP addresses are currently causing the problem. I'm with Dmitri, just use iptables (or whatever native packet filter is available if it's so old it doesn't have iptables). I assume you just want them to go away period, right? For iptables, just su or sudo and
/usr/sbin/iptables -A INPUT -p tcp -j DROP -s 999.888.777.666/32does the trick for the various bots that were hammering on my Django site.[1][2] You just replace the fake IP address with a malicious address, and if you identify a subnet full of them you can replace the /32 with /24 (my rule is "> 2 from a /24") or even as wide as /16 ("> 5", but I look up the net in whois first to figure out how many).[3] Dmitri is also spot on about using fail2ban and its weakness against somebody with access to even a small botnet.
Another thought I had (from googling) is to use an .htaccess file. Curious if that would work?
It could help, but it suffers from the problem that it tells the miscreants your site is still alive (see also footnote [1]). You could also password all the cgi-bins that are dangerous (eg, subscribe). If they aren't targeting you personally, you can put the password in the listinfo page. If they *are* targeting you personally, they'll social engineer the password out of you, so it won't work.
Footnotes: [1] Use "-j DROP" not "-j REJECT" because the former just ignores those IPs so they won't necessarily realize they've been filtered, while the latter tells the source that you are still alive, you just hate them, which is not what you want if they have it in for you personally.
[2] If you want to check if they go away or something like that you can also log these attempts by duplicating the iptables command but using "-j LOG" instead of "-j DROP" and placing it before the corresponding DROP command. There's probably a better way to do this but it worked for me. (I stopped logging after a while because I never checked the logs.)
[3] You probably want to do this with a file-based approach: iptables-save to get any current rules, add the new rules, then iptables-apply to implement everything at once. Then your site appears to have just dropped off the net to those IPs.