DDoS attacks sound like something out of one of those cheese-ball 1980s “hackers break into somebody’s computer and ignite a world war three” movies — you know, the ones that feature 400 baud modems and TRS-80s with cassette drives — but “distributed denial of service” (DDoS) attacks are very real, and are a growing problem.
ServInt, like everybody else in the hosting industry, has seen an uptick in DDoS activities on its network over the last couple of years. And while DDoS hasn’t been a major problem for us, it’s something we’re working hard to stay ahead of — which is what brought it to my attention, and what got me to make the effort to understand DDoS attacks better.
What is a DDoS attack?
A DDoS attack occurs when hackers gain control of multiple computers (that’s what makes these attacks “distributed”) and force them to make some form of system resource-dependent request of a target computer or website. The volume at which these requests are made quickly overwhelms the computer that is being targeted, and eventually the site or computer ceases functioning.
This is not the place — and I am certainly not the author — to go into the specifics of how this all works. Here’s an article that does a good job summarizing the different kinds of DDoS attacks.
What’s more important to you and me is: how can all this affect ServInt customers, and what measures does ServInt take to address the problem?
Who gets hit by DDoS attacks?
Media reports make it seem like only major corporate or government sites are impacted by DDoS attacks. In fact, DDoS activity can affect anybody. To understand how and why, we need to break down the difference between DDoS “targets” and “victims.”
Remember how I said that DDoS attacks start with bad guys hijacking other people’s computers to carry out their plans? That’s the first category of DDoS “victim.” In hosting terms, this could mean that a web server gets hacked, and is told to send hundreds of thousands of website requests to an IP address given by the hackers. (Note that at a reputable host like ServInt, the only way this is likely to happen is if you don’t follow proper server security procedures.)
In this scenario, the owner of that server is a victim of the DDoS attack, but not its “target.” The target is, of course, the site the server has been directed to request over and over. More on targets later.
Another possible victim, in a hosting scenario? All the other hosting customers on that VPS, since the “get” requests for the target site could quickly overwhelm the server’s ability to send legitimate requests out to the internet.
The collateral damage of DDoS attacks gets potentially worse, depending on the size of the attack. As we work our way upstream from the hijacked server, there’s a chance the DDoS attack could clog the network connection for the entire rack of servers in which it resides — and perhaps go as far as slowing down the internet connection for the entire data center.
If we turn our focus to the target side of the attack, all of the above applies as well — all the requests hitting the target server, from potentially many thousands of computers, usually cause the same kind of collateral damage to other users on the network or hosting platform.
Now, imagine all that damage, to all those businesses, and multiply it by a factor of — well, who knows? The impact of a DDoS attack is entirely contingent on how many computers have been hijacked, and what orders they’ve been given. In a recent case, a coordinated attack totaling about 400Gbps hit a target in Europe, causing DDoS mitigation experts to declare that the internet itself was shaken by the magnitude of the event.
Now, before you tuck your laptop under your arm and head for your lead-lined bunker, let me first say that attacks of this magnitude are extremely rare — and (more importantly) that ServInt has processes in place that can cut most DDoS attacks off at the knees before they affect you. Here’s what we do.
How to protect innocent bystanders from DDoS “collateral damage”
As I mentioned earlier, most DDoS attacks have only one target, but many victims. Our primary goal is to protect these innocent victims, and we do it in two ways: by helping victims clean up after a DDoS “hijacking” has been spotted, and by removing DDoS targets from our network at the first sign of an attack. The former policy helps ameliorate the direct and indirect impact of server hijacking, and the latter obviously brings all the effects of such an attack to a halt.
Kicking DDoS targets off our network may sound pretty draconian, but in almost all cases, these people fall into the “no surprise they’ve been targeted” category. Most often, they’re being targeted for “revenge DDoS” attacks because they’ve engaged in spamming, or distributing malware, and so forth. In fact, it’s not unusual for the bad actors on our servers to reveal themselves as a result of being targeted for this kind of vigilante “justice.” If DDoS targets don’t turn out to be bad actors themselves, they’re most often people who know they have a target on their back, and who know they are eventually going to ruin the online lives of all their server neighbors. Usually, when we inform a DDoS target that they’re being taken off our network, they react with little surprise, and we often discover they left their previous host for exactly the same reason. To them, we say: good riddance.
To our customers who are resource hijacking victims, we say, Help us help you. After we work together to close the security breach that allowed your server to be taken over, you must make sure it stays closed. I’ve written before on the topic of server “hygiene,” and this kind of thing proves once again that keeping your apps up to date and your passwords clean is critically important.
One final, very important word of advice: if you have reason to believe your server has been hijacked or targeted by a DDoS attack, open a ticket with our MST immediately, so we can help. The primary symptom of DDoS is a measurable slowdown in your site’s performance. Of course, there are many reasons why one’s site can slow down, so before contacting the MST, it’s important that you check your bandwidth graphs to see if anything unusual is going on. Here’s the path to get to your graphs:
Portal -> My Servers -> (read “How to Read and Interpret Traffic Graphs”!) -> click on “Manage” in the list of your servers on the right -> click on “Bandwidth Graphs/Stats” in the “Managing Server” box
A quick glance at your bandwidth graphs should show you whether your traffic pattern has deviated from normal. If anything looks fishy to you, open a ticket. The MST will take it from there.
Photo by Bob van Aubel