3 ms·

I'd hardly call that a DDoS attack: from the description given, the extra 8TB-or-so of monthly traffic seems to fall under "annoyingly pointless abuse of servic

I'd hardly call that a DDoS attack: from the description given, the extra 8TB-or-so of monthly traffic seems to fall under "annoyingly pointless abuse of services"... As long as such abuse doesn't cause monetary or resource exhaustion concerns, it's quite OK to ignore it, but stories like "whelp, turns out that 80% of the capacity of our auto-scaling fleet is not doing anything useful" are depressingly common enough to at least keep an eye on things. My annoyance with this kind of abuse revolves mostly around logging: a majority of logs just showing the same set of hosts displaying the same pointless behavior over and over again. Again, not a huge issue if your log storage is cheap and plentiful (as it should be), but having some kind of way to automatically classify certain traffic as abusive and suppress routine handling of that is definitely a good idea. It's also a lot harder than it sounds! I can't count the number of times I've added classification logic to my inbound SMTP server that should pick up on outright, silly abuse (of which there is a lot when dealing with email), only to have it triggered by some borderline-valid scenario as well. Spending way too much time on going down successive rabbit holes is a great way not to get any real work done -- a great reason to outsource, or, if that's too much work as well or just too expensive, indeed just ignore the abuse, annoying though it is...

Borg3 3y ago
Yes!! Great idea.. Keep ignoring them. So they feel more encouraged to do more fishy things. That attitude made todays internet pretty much swamp.
- PreInternet01 3y ago
  The TL;DR of my comment is "I personally enjoy implementing automated solutions to relatively-low-volume abuse, but as long as it doesn't cause you any capacity concerns, I fully understand ignoring it, since it's hard" Using that as a reason to assign me responsibility for the state of the internet seems... slight hyperbole?
  - Borg3 3y ago
    It wasnt directed at you as person, but as an idea. Not sure if you ever did abuse report, but they are mostly ignored. Thats the problem. Everyone just waves the hand like, it doesnt make capacity issues, we can ignore it. Sure, until its too late. Maybe I am overly paranoid, but seems that old russian maxima is reasonable: Fight when they coming for cent, because when they will come to take dollar it will be too late.
    - PreInternet01 3y ago
      So, funny story, a major reason why abuse reporting became pointless (unless done at the right level, i.e. when there is a direct and significant business relationship between the parties involved) is... abuse of the abuse reporting process! Sometime around the dawn of this millennium, for example, 'consumer firewalls' at just about every OSI layer became a thing, and a lot of these had the great feature where they would automatically email WHOIS contacts for domains and IP blocks (plus all of their upstreams, for good measure) every time something bad happened, like receiving a single UDP packet on port 139. Stuff like that, predictably, put a bit of a dent in the availability of useful technical contact information, and as much as I would like to go back to the "I have the beeper number of the guy who runs the national backbone" Internet, I'm afraid that Cloudflare is the best we can do these days, sorry. Back to the topic at hand: "fight" on the 2024 Internet means refusing service to abusive parties as much as possible. That responsibility is best outsourced (see 'Cloudflare' above...), and a hard undertaking if you want to do it yourself without causing collateral damage (which, yes, Cloudflare also does, but at least you get someone to point at!). Expecting to somehow get in touch (or worse, 'get even') with the myriad of bulletproof hosters (who simply don't care), admins of bug-ridden/misconfigured systems (who often don't even understand the issue) and assorted detritus is unproductive. And, as with any "the ideal amount of fraud is nonzero" discussion, that can be a hard pill to swallow, but a necessary one nonetheless.
      - Borg3 3y ago
        Huh, interesting story. Can you point to some sources about that? What FW software vendors did it? I never heard about such dumb feature. Really. If I have rule that DROPs traffic, I do NOT care anymore whats really going on (unless its DoS).
smarx007 3y ago
> As long as such abuse doesn't cause monetary [...] concerns 8TB egress on AWS is $595 (taking into account 1TB free egress/mo), while 8TB egress on Hetzner starts at less than $10/mo. With DigitalOcean you'd pay $30 overage for 3TB on top of 5TB included in the s-4vcpu-8gb-intel, for example. 3TB overage is $15 with Linode. I think the article has a point.
- PreInternet01 3y ago
  The article (the point of which is: 'just ignore this', which is sort-of the opposite of the conclusion you seem to have gotten to) specifically mentions that their egress is free via Cloudflare. But, sure, if you have public-facing services on AWS that have the ability to send large amounts of data on demand, absolutely make sure that you limit access to those! (E.g. using a unique download token that is only available from a separate rate-limited and valid-source-checking service).
  - smarx007 3y ago
    What I was trying to say is that the article describes an architecture that takes cloud billing abuse attacks into account (they point out specifically that R2 is preferred to S3 due to egress cost structure) and this design is what partially allows them to ignore the light attack. Most of the cloud architecture posts on HN either focus on how k8s/%your favourite new tool% is good for scale or detrimental to keeping complexity under control. And I think it's valuable for startups to consider cloud billing abuse attacks in addition to horizontal scaling concerns and complexity, which is what I referred to when I said the article has a point. As you wrote, rate limiting and extra checks could get the job done in a scalable deployment, so there is more than one way to keep cloud bill from an attack.

Borg3 3y ago

Yes!! Great idea.. Keep ignoring them. So they feel more encouraged to do more fishy things. That attitude made todays internet pretty much swamp.

PreInternet01 3y ago
The TL;DR of my comment is "I personally enjoy implementing automated solutions to relatively-low-volume abuse, but as long as it doesn't cause you any capacity concerns, I fully understand ignoring it, since it's hard" Using that as a reason to assign me responsibility for the state of the internet seems... slight hyperbole?
- Borg3 3y ago
  It wasnt directed at you as person, but as an idea. Not sure if you ever did abuse report, but they are mostly ignored. Thats the problem. Everyone just waves the hand like, it doesnt make capacity issues, we can ignore it. Sure, until its too late. Maybe I am overly paranoid, but seems that old russian maxima is reasonable: Fight when they coming for cent, because when they will come to take dollar it will be too late.
  - PreInternet01 3y ago
    So, funny story, a major reason why abuse reporting became pointless (unless done at the right level, i.e. when there is a direct and significant business relationship between the parties involved) is... abuse of the abuse reporting process! Sometime around the dawn of this millennium, for example, 'consumer firewalls' at just about every OSI layer became a thing, and a lot of these had the great feature where they would automatically email WHOIS contacts for domains and IP blocks (plus all of their upstreams, for good measure) every time something bad happened, like receiving a single UDP packet on port 139. Stuff like that, predictably, put a bit of a dent in the availability of useful technical contact information, and as much as I would like to go back to the "I have the beeper number of the guy who runs the national backbone" Internet, I'm afraid that Cloudflare is the best we can do these days, sorry. Back to the topic at hand: "fight" on the 2024 Internet means refusing service to abusive parties as much as possible. That responsibility is best outsourced (see 'Cloudflare' above...), and a hard undertaking if you want to do it yourself without causing collateral damage (which, yes, Cloudflare also does, but at least you get someone to point at!). Expecting to somehow get in touch (or worse, 'get even') with the myriad of bulletproof hosters (who simply don't care), admins of bug-ridden/misconfigured systems (who often don't even understand the issue) and assorted detritus is unproductive. And, as with any "the ideal amount of fraud is nonzero" discussion, that can be a hard pill to swallow, but a necessary one nonetheless.
    - Borg3 3y ago
      Huh, interesting story. Can you point to some sources about that? What FW software vendors did it? I never heard about such dumb feature. Really. If I have rule that DROPs traffic, I do NOT care anymore whats really going on (unless its DoS).

smarx007 3y ago

> As long as such abuse doesn't cause monetary [...] concerns 8TB egress on AWS is $595 (taking into account 1TB free egress/mo), while 8TB egress on Hetzner starts at less than $10/mo. With DigitalOcean you'd pay $30 overage for 3TB on top of 5TB included in the s-4vcpu-8gb-intel, for example. 3TB overage is $15 with Linode. I think the article has a point.

PreInternet01 3y ago
The article (the point of which is: 'just ignore this', which is sort-of the opposite of the conclusion you seem to have gotten to) specifically mentions that their egress is free via Cloudflare. But, sure, if you have public-facing services on AWS that have the ability to send large amounts of data on demand, absolutely make sure that you limit access to those! (E.g. using a unique download token that is only available from a separate rate-limited and valid-source-checking service).
- smarx007 3y ago
  What I was trying to say is that the article describes an architecture that takes cloud billing abuse attacks into account (they point out specifically that R2 is preferred to S3 due to egress cost structure) and this design is what partially allows them to ignore the light attack. Most of the cloud architecture posts on HN either focus on how k8s/%your favourite new tool% is good for scale or detrimental to keeping complexity under control. And I think it's valuable for startups to consider cloud billing abuse attacks in addition to horizontal scaling concerns and complexity, which is what I referred to when I said the article has a point. As you wrote, rate limiting and extra checks could get the job done in a scalable deployment, so there is more than one way to keep cloud bill from an attack.