4 ms·

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

by mrkurt 5y ago

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.

Nextgrid 5y ago
Are you doing this because of resource usage? 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.
- mrkurt 5y ago
  We're primarily trying to prevent fraudulent payments combined with expensive VMs. Throttling CPU to almost nothing on high risk accounts sounds delightfully irritating. 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.
  - Nextgrid 5y ago
    I wonder if you could return bogus but plausible results to port scans? Either whitelist a set of safe ports such as HTTP(S?) so that if they try to "curl google.com" to confirm whether everything is OK they get a good response but silently drop everything else causing their scan to return negative on all ports.
  - New_California 5y ago
    How do you know the payment was fraudulent? Is there any possibility it can affect honest users?
sdenton4 5y ago
Yeah, in the end you wind up with a small set of persistent adversaries who have been tweaking their abuse alongside your fixes, and a hopefully much higher wall for new abusers to scale. 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.
- OneTimePetes 5y ago
  I wonder though, would it not be easier, to identify the watchers and shadowban those. Just present bisected realities to spam watching groups and identify those who trigger a reaction.
ljm 5y ago
I remember an old mailing list discussion on sourcehut, because sourcehut provides a build service that you can use for automation. 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.
- Qub3d 5y ago
  > The decision from sircmpwn was, at the end, to charge money for the service. 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.
  - shakna 5y ago
    > I'm sure they've built very sophisticated filtering tools, but imagine someone slips through the cracks and gets a cryptominer working. 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-attack-through-pull-request-2lmc https://dev.to/thibaultduponchelle/the-github-action-mining-... [1] https://www.bleepingcomputer.com/news/security/github-actions-being-actively-abused-to-mine-cryptocurrency-on-github-servers/ https://www.bleepingcomputer.com/news/security/github-action...
New_California 5y ago
Is there any possibility user is unaware she is "abusive"? 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".

by mrkurt 5y ago

Nextgrid 5y ago

Are you doing this because of resource usage? 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.

mrkurt 5y ago
We're primarily trying to prevent fraudulent payments combined with expensive VMs. Throttling CPU to almost nothing on high risk accounts sounds delightfully irritating. 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.
- Nextgrid 5y ago
  I wonder if you could return bogus but plausible results to port scans? Either whitelist a set of safe ports such as HTTP(S?) so that if they try to "curl google.com" to confirm whether everything is OK they get a good response but silently drop everything else causing their scan to return negative on all ports.
- New_California 5y ago
  How do you know the payment was fraudulent? Is there any possibility it can affect honest users?

sdenton4 5y ago

Yeah, in the end you wind up with a small set of persistent adversaries who have been tweaking their abuse alongside your fixes, and a hopefully much higher wall for new abusers to scale. 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.

OneTimePetes 5y ago
I wonder though, would it not be easier, to identify the watchers and shadowban those. Just present bisected realities to spam watching groups and identify those who trigger a reaction.

ljm 5y ago

I remember an old mailing list discussion on sourcehut, because sourcehut provides a build service that you can use for automation. 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.

Qub3d 5y ago
> The decision from sircmpwn was, at the end, to charge money for the service. 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.
- shakna 5y ago
  > I'm sure they've built very sophisticated filtering tools, but imagine someone slips through the cracks and gets a cryptominer working. 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-attack-through-pull-request-2lmc https://dev.to/thibaultduponchelle/the-github-action-mining-... [1] https://www.bleepingcomputer.com/news/security/github-actions-being-actively-abused-to-mine-cryptocurrency-on-github-servers/ https://www.bleepingcomputer.com/news/security/github-action...

New_California 5y ago

Is there any possibility user is unaware she is "abusive"? 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".