Someone has been attempting to DDoS us for weeks and we do nothing

This reads as extremely self-congratulatory. A &quot;billion requests per month&quot; is only a few hundred requests per second, which is both trivial and not a &quot;DDOS.&quot; Also, their site is behind a CDN (Cloudflare), so I&#x27;m <i>extra</i> confused on how they think they did something notable from a performance perspective here.<p>For example, there&#x27;s no reasonable world where that 200 MB blob is <i>not</i> cached and served over CDN. I can&#x27;t imagine someone would be <i>so proud</i> that their application server <i>isn&#x27;t</i> reading 200 MB from disk and copying those bytes to the client on every download; it&#x27;s just so obviously poor design.

4 TB per month isn&#x27;t really a DDoS attack, no? 4 TB per hour might qualify as a DDoS, but 4 TB per month is just 1.5 MB &#x2F; second. 6 million requests per months are just 2 requests per second. I&#x27;d say the fact they run a monolith service isn&#x27;t really relevant at this scale, especially as I assume Cloudflare handles most of the requests through caching them at the CDN level.

This is just a static marketing site for a desktop app. They don’t even have a discussion forum — feedback is handled by GitHub issues. Bragging about how simple their deployment is for a static marketing site and how it’s able to handle a static file being downloaded <i>millions of times a day</i> is super weird. And Cloudflare is doing all the mitigation work here (if that’s even needed for such a puny amount of traffic), not them.<p>If I were to be hit by such an &quot;attack&quot; myself I probably wouldn&#x27;t even notice until Cloudflare sends me that monthly &quot;X TB of data transferred, something close to 100% bandwidth saved&quot; email.<p>I like the app btw, can recommend.

I&#x27;d hardly call that a DDoS attack: from the description given, the extra 8TB-or-so of monthly traffic seems to fall under &quot;annoyingly pointless abuse of services&quot;...<p>As long as such abuse doesn&#x27;t cause monetary or resource exhaustion concerns, it&#x27;s quite OK to ignore it, but stories like &quot;whelp, turns out that 80% of the capacity of our auto-scaling fleet is not doing anything useful&quot; are depressingly common enough to at least <i>keep an eye on things</i>.<p>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.<p>It&#x27;s also a lot harder than it sounds! I can&#x27;t count the number of times I&#x27;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.<p>Spending <i>way</i> too much time on going down successive rabbit holes is a great way not to get any <i>real</i> work done -- a great reason to outsource, or, if that&#x27;s too much work as well or just too expensive, indeed just ignore the abuse, annoying though it is...

That&#x27;s not a noteworthy &quot;attack&quot;; that could be a single runaway bash script on someone&#x27;s machine. 50MM requests per month &quot;from the UK&quot; averages out to under 20 requests per second. I would expect a single Go server to handle 250 times that request volume before optimizing much.<p>Their advice isn&#x27;t bad per se, but their numbers are not a testament to it. I expect for my Go HTTP API services to handle 5k requests per second on a small to medium VPS when there is some DB activity and some JSON formatting without doing any optimizations. This is based on deploying dozens of similar services while working at a place that got multiple billions of requests per day, spiking to over 500k rps.

It’s great that this isn’t hurting them but it leaves out a lot that makes me a bit nervous about this being taken as advice.<p>They’re advocating deploying a binary as preferable to using docker, fair enough, but what about the host running the binary? One of the reasons for using containers is to wrap your security hardening into your deployment so that anytime you <i>do</i> need to scale out you have confidence your security settings are identical across nodes.<p>On that, the monolith talked about here can be hosted on a single VPS, again that’s great (and cheap!), but if it crashes or the hardware fails for any reason that’s potentially substantial downtime.<p>The other worry I’d have is that tying everything into the monolith means losing any defence in depth in the application stack - if someone does breach your app through the frontend then they’ll be able to get right through to the backend data-store. This is one of the main reasons people put their data store behind an internal web service (so that you can security group it off in a private network away from the front-end to limit the attack surface to actions they would only have been able to perform through a web browser anyway).

Pet peeve of mine. “Billion requests per month” is about 370 rps. Which can be likely handled by a single well configured server. Certainly less than 10 servers. A single rogue bash script could cause that much traffic

I might be out of touch with reality, but billions of requests per month sounds like peanuts. Is that considered a big ddos attack?

Nice one :-)<p>“… =&gt; Thus, we build a monolith service for each app, which is easy to deploy and maintain. No Docker, no Kubernetes, no dependencies, no runtime environment - just a binary file that can be deployed on any newly created VPS. …”

Was hoping for something more swole dog worthy when reading the headline. Even though I agree with much of the advice, being behind Cloudflare is definetly not nothing.<p>Depending on the distribution of the traffic they might have survived well on VPS&#x27;s without Cloudflare anyways, doesn&#x27;t seem that large. Would be interesting to see more detailed stats of rps and how much (if any) Cloudflare stopped before they got it.<p>Russian layer7 ddos&#x27;es that I know of targeting Swedish companies have been large enough that major providers run into capacity problems and fall over (including Verizon, Azure Frontdoor, Cloudflare, GCP&#x27;s Load balancer). This strategy would absolutely not work against those volumes.

Why do they need an app server at all? The website, to my initial glance, seems to be a brochure for the desktop product. Surely static pages and static assets would be even more resilient against a ddos since it&#x27;s just bog standard webserver streaming out the static resources. Mount a memory based fs and conventional disk latency concerns become mitigated, too.

A bit ingenious to say we do nothing when you have CloudFlare in front of your servers. Cloudflare by itself can automatically detect and handle DDoS without explicitly activating the Under Attack mode.<p>Also Java jar files give you the same benefit.

You should try to protect yourself from it using cloudflare or something like that. here is one site which you can use to test your protection <a href="https:&#x2F;&#x2F;topstresser.net&#x2F;#pricing" rel="nofollow">https:&#x2F;&#x2F;topstresser.net&#x2F;#pricing</a>

I guess this is an ad, so I&#x27;ll bite: Why is the mac download button featured so centrally, while there appear also to be downloads for other platforms, too? It&#x27;s not like that&#x27;s a usual default.

Literally laughed when they&#x27;re talking about language choices for a billion requests per month.<p>I&#x27;ve got nodejs lambda code that is doing 388B&#x2F;month and only at this point have we even considered changing the language for performance because the cost savings have a net positive ROI.<p>It took 5 years to get to this point.

The architecture of the app didn&#x27;t seem related to the &quot;DDoS&quot; attack they&#x27;re describing. If it&#x27;s only their setup file being downloaded, I imagine their backend isn&#x27;t even touched, doubly so if they&#x27;re using cloudflare for caching.

It feels like they didn&#x27;t learn the root lesson - move your 200MB setup file to a subdomain. You shouldn&#x27;t host large assets like this on the same domain as your marketing&#x2F;app site even if there is a CDN fronting it because an attacker can simply add a random query string to bust through the CDN cache and cause the cache miss to hit your box. The subdomain should be hosted on a different box and fronted possibly with a different CDN provider so that any large scale attack doesn&#x27;t affect your marketing&#x2F;app site (either due to your CDN provider or upstream network provider temporarily black holing you).

Bragging about this has to rank up there as the worst idea in the world. If your hole argument is taunting would be attackers with your wallet - saying you&#x27;re more overprovisioned than the traffic they can send, you&#x27;re just threatening them with a good time. At another time in my life I&#x27;d take this post as an invitation, even, specially because the numbers shared are super low.<p>I&#x27;ve had 3 situations where my place of work was under DoS attack, in the 3 cases I managed to identify an email address and reached out asking why they are doing it, and if they want to talk about our backend. In 1 case, the &quot;attack&quot; was a broken script by someone learning how to program, the other two were real attacks and one of them just immediately stopped once they knew we knew who they were, the other actually wanted to chat and we emailed back and forward a bit.<p>99.99% of the time a DoS is someone who is bored. Talking to them tends to work.<p>Edit: there&#x27;s some questions about the situations so I&#x27;ll expand:<p>- The first was not a real attack, and they were doing the network calls through their authenticated API key. This was early days of a YC startup so of course there was no rate limiting in place. In this case I exchanged 2 or 3 emails and after they sent me their python script I sent them back a patch and they finished their scraping without bringing us down. Never heard from them again<p>- The second was at a different company, we were getting targeted to distribute email spam, because at the time we&#x27;d allow people to invite their colleagues as members of their account, and some people associated with casinos based out of Macau automated a way to spam their casinos by putting the URL in the name of the account, which went out in the email notification. I contacted one of the admin emails of one of the casinos I found and they stopped and disappeared. In this case we also locked all their accounts and prevented further logins + emailed them to reach out to support if they thought it was a mistake.<p>- The third one was more difficult, they weren&#x27;t using any account, so all we had was network. At some point on the second day though they changed how they were sending some of the calls, and by mistake or not leaked their Telegram username. I installed telegram and talked to them, they trolled me a little bit, but stopped very quickly and didn&#x27;t start it again. This one was very amusing to people in my company because I had told them this approach would work but a few of the big wigs didn&#x27;t want me to do it (they didnt have any reason other than &quot;obviously won&#x27;t work to just talk&quot;). I just did it anyway.<p>To be clear, you shouldn&#x27;t reach out with some threats or how you&#x27;re so good that you found them. My approach is of genuine curiosity, and my literal first message to the telegram person was:<p>&quot;Hello, how is it going? I work at &lt;companyname&gt; and we&#x27;re seeing a load of requests originating from your user here on telegram. Does this make any sense to you or do you think I might have the wrong person?&quot;<p>That&#x27;s it!

&gt; our setup file is approximately 200MB<p>&gt; we keep things as minimal as possible<p>Wonder what&#x27;s in that file that makes it need to be that large...

Doesn&#x27;t look like a real DDos attack to me with the traffic numbers (of course, No true Scotsman).<p>4TB&#x2F;200mb = 5000.

A nice thing about modern cloud providers is their expensive bandwidth so a new vector of attack is simply downloading large files that they host. (except cloudflare)

Those numbers in the screenshot from Cloudflare represents requests to Cloudflare, not requests to the origin. It includes cache hits.

This is so cute. The webpage could be fully static, served from a raspberry as it is hiding behind a CDN anyway and the DDOS is not even trying.<p>Anyhow, doing the same with a high traffic application would be a very very different animal, specially when the app has 100k+ active daily users and is doing actual stuff. The advice is not bad, but it sounds so silly. From experience every time a commercial web application was build as a monolith it became very hard or even unmaintainable in a few years, specially when 15+ Teams are constantly contribution. So pick the right hammer for the problem you have, but pretending a simple marketing webpage + payment&#x2F;subscription is a good example for architecture is just a bit much.

&gt; we’ve simplified the deployment process as much as possible. We don’t use Docker, Kubernetes, or any containers, or need to setup the enviroment.<p>This sounds like a dream, both in the sense that it&#x27;s wonderful, and that I&#x27;m not quite sure I believe it.

I like this a lot: Why? Because the attacks are directed to someone who isn&#x27;t bothered and wastes their own resources. I&#x27;ve been a Table Plus user for near a decade now and enjoy the simple but highly compatible software they provide.

Reminds me of Nietchze’s Genealogy of Morals quote: I’m strong enough to allow that.

This content was very useful to me, as I am running a small service for a few clients that I worry might be taken down by a DDoS. The main takeaway seems to be &quot;use a CDN&quot;, but if you are running a more complex service, why can&#x27;t the attackers hit endpoints that aren&#x27;t CDN-cached? Is the strategy in this case simply to refuse the request very early in the process, to ensure the service doesn&#x27;t waste much time processing it?

Downloading a setup file is not the way to bring down a site. My experience in the HDD era was that people laugh at you when you do a lot of requests like that but call the FBI on you (at least here in the States) if you insert a lot of random users into their database. (Each of those requires a transaction and each of <i>those</i> requires waiting for the disc to spin around unless they had a nice battery-backed write cache)

Public boasting as a mitigation strategy, that&#x27;s got to be a new one.<p>Not entirely sure it&#x27;s a wise approach given the deeply asymmetric infrastructure costs of DDoS attacks, especially if the attacker has access to a botnet.<p>[EDIT]:<p>in other words, there is a non-zero probability that the attacker, piqued by the boasting, might be able at the flick of a switch to increase the intensity of the attack by a factor 1M.

&gt; When using binaries, you can let Linux Systemctl handle the process<p>“Systemctl” instead of “systemd” ? Hm, do I detect reticence to publicly admit the undeniable, vast superiority of systemd by confusingly using the name of the utility?

This is the dumbest thing I&#x27;ve read on HN today.<p>&quot;We do nothing..because we can.&quot;<p>This speaks volumes about your attitude towards security as a business. If I was your enterprise client I wouldn&#x27;t really be happy reading this.

It&#x27;s going to a point where that directly find out the person behind it is cheaper than fix the bug. People nowadays don&#x27;t pay respect to the hard working people anymore

Yeah Goroutines are great. Then add something like WebRTC to your project that realistically tops out at 10000 listeners, and people wonder why Twitter Spaces is so buggy...

THATS not a DDos attack! when i were a lad...

People has broken CI&#x2F;CD so we do meme. Not sure if 6M&#x2F;m is a lot. Looks like not that much.

A post like this seems kind of dangerous. Just asking someone to fire their cannon at you! Beware.

This is the first time hear the word &quot;Monolith&quot;<p>What is it and how can one learn about it.

Almost sounds like a buggy update process of their app that they shipped.

Similar problem and similar-ish product 0]; we get DDoSsed a lot and I don’t know why. We had to put Cloudflare botfight to stop it. That works very well, but what do you do if CF doesn’t exist?<p>0] <a href="https:&#x2F;&#x2F;flexlists.com" rel="nofollow">https:&#x2F;&#x2F;flexlists.com</a>

Is there any way to know who&#x27;s behind a DDoS attack?

off topic but you guys have done solid SEO. You query anything related to SQL&#x2F;syntax and tableplus will be in front of you.

What does “heete” mean?

It is like computer viruses.<p>DDoS attacks do benefit some specific corps, for instance cloudflare.<p>What&#x27;s very important is to build DDoS resistant infrastructure without them, to rid of the incentive to shadow-hire hackers to DDoS and force some infrastructures to move there and pay them.<p>There is too much suspicion in the digital world nowdays. Like current crypto is not mainly for shaddy ops and mafia? Really?

not really that interesting of a post. billions of requests per month is like low hundreds of requests per second. billion is a big number but so is a month when it comes to request throughput. all the grandstanding about monolith... for something that serves 2-3 requests per second, and is a static marketing site... this is so overblown.

Why is billions of request per month so exciting to the authors? That’s only ~100 QPS, which a single-core application should be able to handle easily.<p>Wake me up when you have hundreds of millions of QPS of DOS load.