We shadow ban abusive users on Fly.io and it works great. Everything seems to work right up until they try to connect to a deployed app.
It took me a while to realize that ramping up the frustration level is, itself, a helpful deterrent.
It took me a while to realize that ramping up the frustration level is, itself, a helpful deterrent.
The decision from sircmpwn was, at the end, to charge money for the service. Charging money and KnowYourCustomer will kill most exploits dead.
In this sense, this is turning the frustration level to 11. You can use the service to a certain extent, without frustration, but if you want to get serious then you're going to have to jump through some hoops.
Dedicated people will still find a way through, but you've cut off 95% of the flow and killed the low-effort attempts. Now, you can focus on the serious shit.
The risk of having their payment identifier/address banned from services before significant use makes it very risky for them to use such a thing even if tiny micropayments a worth it to the spammer.
It certainly could have other problems with people getting banned from such a system for things other than: spam and other use detrimental to the service provider. There is also the issue of how the initial buy in fee is distributed.
But a high buy in for a system that many online service providers use would very strongly discourage use detrimental to the services providers (I think; this is only for discussion, as this is posted by someone with little knowledge on this. Micropayment systems have been talked about a lot, but I don't remember high buy-in mentioned).
Edit: Forgot to mention that the idea of this is that service providers can offer their services at lower cost because the risk to them from a account/address with a high buy in is lower than from an account/address with no buy in.
Frankly, I'm shocked the other major free providers (GitHub/Lab) haven't done this by default. GitHub's current default is free for public branches, and a small fee for private.
I could see a flipped setup working: by default a very small fee (1-5 cents per x number of batches) that most companies wouldn't notice, and a path for FOSS projects to apply for credits.
I can't find the direct link, but I remember someone on HN pointing out that because CI tools are turing complete, GitHub actions is the cheapest serverless cloud product in the world right now -- you just need to figure out how to game the system.
I'm sure they've built very sophisticated filtering tools, but imagine someone slips through the cracks and gets a cryptominer working. Get that action registered in enough projects (by, say embedding it in an Actions library or generator tool) and that could be significant.
It's been done, multiple times. Here's a handful (96) of documented cases which are somewhat recent. [0][1]
It seems to be surprisingly easy to abuse the process, and GitHub are continually playing catch up.
[0] https://dev.to/thibaultduponchelle/the-github-action-mining-...
[1] https://www.bleepingcomputer.com/news/security/github-action...
If possible, it can help to hold back new systems and release a bunch of orthogonal anti abuse systems at once. Then the attackers need to find multiple tweaks instead of just evading one new system.
Just present bisected realities to spam watching groups and identify those who trigger a reaction.
If resources are free then you could even actually deploy their app and either whitelist it for their own IP or only allow very few requests before taking it down.
This would be even more frustrating and could ruin whatever they plan to do with their abusive app in the first place. Let's say they deploy their malware/phishing page, test it a couple of times (possibly from a different IP) and it works. They then start spamming the malicious link and waste decent amounts of time/money/processing power, not realizing that the link was dead after the first 10 hits.
We also get the less resource intensive, but still harmful abusive apps that port scan the internet. Those are relatively easy to detect. We generally don't want to be a source of port scans so we shut them off pretty quickly.
For example, I quickly searched the ToS for port scanning and didn't find it banned, yet you admit to intentionally frustrate such users.
I am not Fly.io customer at this time but I do port-scan my own services as a realtime security check.
As otherwise great service, you may open yourself for very angry user reviews if the tactic is "frustrate the user".