Gethsemani said:
tippy2k2 said:
How?
No seriously, how?
Because if you know of a way, let all those big companies know because you're going to be a billionaire. It's stupidly easy to do but unless I'm mistaken (rare but not impossible), it's virtually impossible to actually defend against BECAUSE it's so stupidly easy to do.
It is not impossible, just so expensive as to be prohibitive. What you'd need is several thousand percents of server overcapacity that could deal with sudden spikes in traffic. It can be done, but the company would be pouring lots of money into preventing a problem that's a minor nuisance at best.
Exactly. I fully disagree it's in any way "impossible" as people in this thread seem to suggest. It may be hard and worth little in the long run, but certainly not impossible. There are a multitude of ways to prevent DDoS from hurting the servers and a successful approach will blend more than one. I'm not an expert on this - far from it, really, however I can at least give an overview even if I lack the specifics.
First off, DDoS attack is "merely" a DoS attack coming from multiple locations. But let's start from the basics:
Given that you have an automated system that offers something to people, Denial of service (DoS) attacks aim to deprive your system of some resource, so it cannot work or it cannot work correctly (it's slow or inaccurate). There are a variety of ways to do it but they broadly fall into a couple of categories:
Overwhelming resource capacity
It's a quick and dirty attack - normally a service can only handle so much things. You make it unavailable to process stuff by doing requests. It's roughly to IRL staying at a checkout and not allowing other shoppers to use it, thus denying the shop money from transactions.
In general, that overload based DoS can be further subdivided into two more or less distinct things:
Traffic based overload
If the system is online, just keep issuing requests. Eventually the bandwith will be saturated, enough so no new requests can be made. This is an attack on the
network infrastructure. How exactly plays out will differ - examples:
- it may simply overload the ISP's channel to your server which is outside of your infrastructure;
- it may also get through but cause your switches and routers to (figuratively) catch fire and take them out of commission;
- it may just be that there is a hard limit somewhere on how many requests can be open at any one time and thus once you reach, say, 1000 requests, you cannot accept more.
At any rate, it's trying to stop or at least further traffic coming through.
Load based
It could be that your network infrastructure can handle a lot of traffic but your application does not behave well. This is an attack on the
processing capacity however that is defined. Examples are:
- if you have "heavy" requests that, say, take 10 seconds to come back, then just keep issuing those and eventually the server will have to wait to process anything new
- even relatively normal requests may start taking more and more CPU time if there is hundreds, or thousands of them coming in
- even if normally a response comes back quickly, each might consume a lot of memory, so if there are multiple being processed at any one time, then the rest of the system may be starved for resources
So, simply put - if there are one or more components that don't take huge stress well, they may cripple your system.
"Exploits"
This is more of a catch-all but you could deny service in other ways. It will include some prior knowledge, though, so it's (more or less) an attack
targeted at a vulnerability. The variations can be many, but very few examples:
- if you're able to log users out mid usage, that will make them stop using the system (duh) until they log in again. But if they get logged out multiple times in a row, they may just not bother any more or something.
- it may be possible to divert traffic from one site to elsewhere thus taking all (or most) of the users away
- it may be possible to just block something from being used
Anyway, these are more precision-based.
Now, about Distributed Denial of Service (DDoS) - it's very similar to the above, only it comes from multiple places. It's mostly the former category of trying to overwhelm the system until it gives out. It is rarely concerned with exactly how to do this - given enough stress, either the infrastructure will fail or the system itself, although sometimes a DDoS may try to target one or the other. It's effective because it's cheap...the only thing you need is hundreds, or thousands, or hundreds of thousands of machines to work at it at once. On the other hand, the machines need not be really that beefy themselves unlike if you try to do it with only one computer. So, your choices are basically:
1. A bunch of people. If you just persuade enough people to participate, it's not that hard to DDoS something.
2. A bunch of machines - if you happen to have a lot of computers you control, then you could just coordinate those. Say, if you administer or otherwise have access to a network of computers.
3. A bunch of
infected machines - it's ore of a variation of the above but it bears a separate mention. Instead of
having computers of your own, you have access to a lot of infected ones that you can tell to do stuff. These are referred to as "zombies" and compose a botnet (also: a zombie network). It's the same principle, though, however more illegal.
So with this out of the way -
how do you protect against a DDoS? Few choices, as I said, and a successful approach will use more than one:
- overprovision. Very simple, very basic - if you expect 100 people at any one time, try to aim for 5000. Just a random numbers there, of course, but you get what I mean. You can overprovision various resources and you may need more than one. Most notably, you want to overprovision the bandwith, because most of the rest is in your hands, but if traffic simply can't get through to you, you can't do much.
- elastic scaling - add or remove resources as needed/not needed. A lot of CPU cycles being used? Get a couple of more and when then stop them when they aren't longer needed. The system eating through your 60 gig of memory? Just add another 120. Running out of space? Slot a bunch more HDDs. And so on and so forth. This can be virtual or physical scaling but it'd be similar either way. Cloud hosting can help a lot but it's also virtualisation in general. Alternatively, you could just have spare desktops to swap around into extra server hardware.
- load balancing - it's easy to overwhelm one server, but what if there are 10? Or 20? Or 100? If one goes down, you just restart it and let the rest handle requests in the mean time.
- CDN hosting - use a dedicated network to host some of your resources. This takes a load off your system(s) and shares it elsewhere.
- application level hardening - done on the software-side to prevent overloads. Could involve caching to prevent expensive requests to be repeatedly serviced, or maybe even just prevent very expensive requests.
- system architecture efficiency - software-side again - optimising the system to be able to handle huge loads without falling into pieces. It would depend a lot on the system in question but, say, requests could be batched instead of doing them one by one, to make more efficient use of threading, requests can also be sequenced instead of fired off immediately and so on and so forth.
- black network magic - I must admit, that's probably what I know the least of but it's also what sounds the most interesting. It involves filtering traffic at the network level and just discarding garbage. Attempted overload requests tend to actually be fairly easy to recognise. Makes sense - you want to spend as little time possible crafting them, so you can spend as much time possible sending them. Hence they will look alike and you can fairly easily tell them apart from legitimate traffic. It does involve network engineering I'm simply not familiar with but I know it's possible. I believe some smarter routers can even start to auto-filter if they start requesting what looks like a flood of requests. This is a perimeter defence designed to keep garbage traffic away from the core of your system. The trick is to make sure the recognition/discard is both good and efficient enough, otherwise you may start discarding legitimate traffic or maybe the router will fall victim to the DDoS.
- taking out sources - easier said than done, but if you nip the problem at the bud, it...well, stops being a problem. If you can stop a botnet, then it's probably worth doing so.
There are probably a lot more I am missing but these will be the more obvious ways to start off.
Stopping DDoS is certainly not "impossible". That's not to say it's
easy but not some sort of insurmountable problem. As games aren't critical systems, the protection is simply not done or not done as well, as it has it's costs. At the end of the day, chances are that you'd lose, what a day or two of playtime at most? A problem, sure, but is it
really that much of a problem? From the business perspective - no, it's not. People have already bought the game, so why should the company care. Now, compare this to a bank - if there are a day or two of no transactions, then things are going to be
incredibly bad. Every minute bank servers are down, it costs the bank A LOT of money. There are tales of estimated costs for bank systems where a couple of hours of downtime may bankrupt the bank.
But that's still not as bad as some OT failures. While there are systems out there that, when they are down, costs their companies a lot of money (and games aren't part of those systems), there are
other systems that, when they go down, they cost
lives. Imagine if a nuclear powerplant's monitoring system decides to misbehave and report normal readings instead of "CRITICAL! DANGER!". Imagine if a seismic monitoring system that tries to predict volcano eruptions[footnote]and some of those system manage to warn barely in advance for an emergency evacuation[/footnote] gives out? Imagine if an oil rig starts pumping all the oil into the sea. All of these are controlled by computer systems and all of them may potentially fail. In fact, it's actually scary how vulnerable those are - for some we're talking about software from the 70s running on hardware from the 60s. At any rate - these types of systems are even more critical to safeguard.
I know it sounds like "starving children in Africa defence" but I want to offer a sense of perspective here. A game experiencing some downtime? Hardly anything to worry about for whoever is in charge of them. It would be in their interest to keep the game available
overall at least in the short to medium term, but, say, two solid days of downtime are still not that bad. Even a week of servers not working over the course of a year is still 98% uptime.
