Remix.run Logo
close04 7 hours ago

> then your host taking your website down and then you having to run circles around their support staff to bring back the website up again

These are very different situations. With a DDoS the disruption ends when the attack ends, and your site should become available without any intervention. Your host taking down your site is a whole different matter, you have to take action to have this fixed, waiting around won't cut it.

throwaway150 7 hours ago | parent | next [-]

> These are very different situations.

It is obvious those two are very different situations. I'm not sure I understand your point. Yeah, nobody will be bothered by a short 15 minute DDoS attack. I prolly wouldn't even notice it unless I'm actively checking the logs. Sure, nobody is going to be bothered by that. But what if someone's DDoSing persistently with a purpose? Maybe they're just pissed at you.

My point is... a sustained DDoS attack will just make your host drop you. So one situation directly leads to another and you are forced to deal with both situations, like it or not.

blueflow 5 hours ago | parent | next [-]

> a sustained DDoS attack will just make your host drop you

I'd love to see someone suing the host for damages. The contract binds them as much as it binds you.

Sounds like a good way to have your next gaming rig financed.

giancarlostoro 3 hours ago | parent [-]

I'm pretty sure in every webhost terms of service I've ever read they leave language in to kick you out if you are degrading the service for others. Turns out a prolonged DDoS attack is degrading the service for others. The bigger cloud providers are drastically less likely to drop you but now you're paying a premium on hosting.

NewJazz 6 hours ago | parent | prev | next [-]

DDoS attacks are frequently shorting than 15 minutes. We've seen plenty of attacks last less than a minute.

close04 6 hours ago | parent | prev [-]

> It is obvious those two are very different situations. I'm not sure I understand point.

Your host taking down the site and forgetting to bring it back up after a DDoS attack isn't a common thing with any host, unless it's the kind that does this routinely even without a DDoS. And then you should look long and hard at your choice of hosting.

Either you suffer from a DDoS attack and come back when it's over, or you have a host that occasionally brings your site down and fails to bring it up until you chase them. But one does not follow the other without a lot of twisting.

whartung 6 hours ago | parent | prev [-]

Not may area, so forgive me.

How does taking the site down stop the DDOS attack?

Isn't the host network still being bombarded by garbage packets, even if there isn't anything there listening?

Or is routing the destination IP to /dev/null enough to blunt the attack?

I know there are different kinds of attacks (e.g. some that are content based, impacting the individual server), but I thought most of them were just "legit" requests storming through the door that the server can't keep up with.

Having the site taken down after the fact, as a "risk to infrastructure" that the host can't afford, that's a different issue.

grayhatter 5 hours ago | parent [-]

Forgiveness not necessary, these are good questions.

Internet packets have to travel through many routers between the source and the attack and the server they're attacking, at each step the routers usually get smaller. the smaller routers are less able to withstand the amount of traffic destined for one server, which means they can't route traffic to all the other servers that are not under attack. a common strategy is to drop the traffic at a much farther away server, thus protecting the smaller routers, thus protecting all the other servers.

The host Network would definitely still be affected by the DDOS, which is why the strategy is often to "blackhole" the traffic farther away from the individual server racks.

I see people say route traffic to /dev/null All the time, but I personally try to reserve that for the individual servers or the nearest router, just to avoid your exact confusion.

depending on how well designed, any specific network is the "hug of death" which has taken down many sites would also degrade the performance of the peers next to that server. Which is why many ISP are quick to block the traffic farther away. To protect not you but their other customers.

To be fair (pedantic), if it's part of a DDOS, it's not a legit request. Depending on the capabilities of the attackers, they will either choose obviously invalid requests because those take longer to process or exclusively valid requests which take longer to process. it is generally speaking much easier to send valid well-formed requests because that's what most libraries exist to do. you're often writing custom code if you want to send an invalid request because that is a bug in other cases.

A good example of an invalid request is setting up TLS transmitting a partial packet and then closing the connection (or leaving the TCP open), This one can be particularly expensive and much harder to detect.

> How does taking the site down stop the DDOS attack?

When people say take the site down, in this context, they often mean one of two things, either changing the DNS configuration to point to a different IP address (or none at all), or "null routing" traffic to the under attack IP, at an edge router, edge in this case meanthing their upstream ISP or other network peer. (farther from the victim server) I object to both uses because the specificity is important. When I say take down the server, I almost always mean quit [nginx] or power off the box.

whartung 5 hours ago | parent [-]

Ok, thanks.

I was thinking more things being done to the actual machine the site was hosted on.