I can see from the failed attempts that are trying to curl the kiss a dog cryptojacking software, so they aren't simply probing my server - they are trying to cause harm.
Preferably legal. Making them lose money would be great too!
Rather than simply blocking them, whenever I detected a card tester, I started sending them random results that mimic real-world results. About 98% of the time, I sent a false "card failed" error, with varying reasons for the failure. And about 2% of the time I sent false "donation successful" messages.
It went on like that for weeks. I was giving them complete garbage data that they seemed to be accepting, so I assume I was completely wasting their time and effort, and possibly getting them in hot water with the shady clients who buy the lists of "working" cards.
I finally got sick of the ongoing DDoS and started replying to them with SQL injections, like:
> '; DROP TABLE users; --
> '; DROP TABLE user; --
> '; DROP TABLE credit_card; --
...and so on. My thinking was that they might not be sanitizing the inputs on their end, replies from a CC processor would be an unexpected vector for SQL injections.
The card testing stopped just after that, either because the change tipped them off, or because I managed to guess one of their table names and caused hilarious destruction of data.
To some extent yes, give them a status 200 for anything they send at you, especially for your default catch-all domain/IP/virtual-host. In NGinx this looks like
error_page 404 500 501 502 503 504 =200 /some_generic_message.html;
Add headers and content to the generic message file that has links to URL's like WordPress, wp_login.php, wp-story.php, js/file-uploader, nf_tracking.php, about.php, wp-reset.php and others. To minimize writes on your disk, set custom logs for your default virtual-host/IP/domains to either write into a tmpfs ram disk or to /dev/null once you get bored watching them. If writing to tmpfs be sure to set up a more frequent log rotation and less retention. Be sure to also set the HTTP keepalive time very low so they are not wasting your resources. No need to tarpit them, most of the code used by these bots will time out after a few seconds.
[Edit] I should add, these are not hackers you are messing with. They are just parasitical script-kiddies that prey on the weak, most often using their batches of WordPress hosts as jump-off points and watering hole phishing sites to scam the elderly out of their life savings.
Making them lose money would be great too!
That's much harder. Most of the IP's you see do not belong to the attacker. The attacker is likely using a set of Command and Control C&C nodes that control a swath of end-user PC's and Wordpress servers infected with malware. Anything you do will cost them nothing but it might slow their threads down a little. The only way to make them lose money would be to find who is controlling the C&C nodes, gather evidence and have law enforcement take them down. To do this one would have to break the law by hacking into the compromised host and see what C&C nodes it is dialing home to, then hack into those hosts and see who is connecting to them. They could be using Tor but most people are lazy enough to not do this.
https://en.wikipedia.org/wiki/Zip_bomb
There's more you can do when they actually parse documents. XML + XSLT can overflow some systems. Even just a deep html document tree can use up resources.
I clicked the above link and had to chase a growing population of 10+ popups.
Hilarious.
p.s. I do have a popup/JS blocker, but disabled it last night to test something else.
iptables --append INPUT --source 1.1.1.1,1.1.1.0/24 --protocol tcp --dport smtp --match hashlimit --hashlimit-name HASHES_FOR_PROBABLE_SPAMMER_THROTTLING --hashlimit-mode srcip --hashlimit-above 3/minute --hashlimit-burst 1 --jump DROPat which point you can report it to the host/attack it/whatever.