Stop an ongoing DoS attack

Many server managers say that effectively stopping a DoS attack is impossible. This is only half true.

Under a DoS siege the majority of the server administrators will try to create a null route for each offensive IP, IP block or even whole subnets. This is done as an effort to keep the service online for legitimate clients, but deny service for the offenders. This is very time consuming operation as the IPs are faked so null routing almost always is impossible.

So what other methods are available?

I can tell you my experience only, and that is extremely simple. First, I start to look for the port the attackers chose. Usually and unfortunately this port is almost always port 80 aka HTTP. If the server became completely unusable and the number of connections is unbelievably high, then one simple step: shut down the ethernet card which handles the public network. No one will be able to use the server until you re-enable the ethernet card so this is a very cruel option in many’s mind. But why? If no one can access the server because the DOS attack, why is bad if I shut down the ethernet card?
And why do I shut down completely the traffic? This is again my own experience: the offender thinks that the mission was accomplished and simply gives up. I had only once situation when re-enabling the ethernet card after a few hours brought the offender back too, one occasion from a few dozen. So in my humble opinion it’s still better to have a few hours of silence than having a few hours of stress caused by the efforts of blocking the unwanted traffic.
On the other hand if the server didn’t deny the service yet, you may try to null route the offenders. It’s an extremely time consuming operation and if the IPs are faked… well. You can’t really null route. But if you desperately want to keep the server up and running, you may try it. Be prepared for great stress, have your coffee machine prepared too, and if you smoke, a few packs of cigs in the nearby is also required.

Another option I heard about is a bit more interesting. But it involves DNS administration so you should be familiar with it before start it.
Let’s take the following situation: you have www.example.com functioning on the 192.168.0.1 IP. When you observe that your IP is under attack and your website functioning under the example.com domain became slow, you move your domain name under another IP on another server, the offenders will still attack the old IP but they cause no trouble since that IP is out of service.
This is very beautiful in theory, but in real world may function or not. Usually doesn’t, since while the update in your DNS travels through the whole world, your website may be already on its knees.

What can be done to just not experience DoS attacks?

To be prepared for the attack. There will be always black hat hackers and hacker kids in suburban basements who has nothing better to do but try to offend websites or whole servers, so our only option is to be prepared. Better said, the datacenters.
DoS attacks can be recognized quite easily, there is a listening system installed on every major internet backbone too. What they can do is to early recognize that something is happening and start to block the malicious traffic while is born.
Choose your provider wisely. If you want a good hosting solution go with well known web hosts like GoDaddy or MediaTemple. If you need servers, choose well known data centers like RackSpace or Softlayer. They are all prepared for DoS attacks and can help you in no time.

If you go with a server, a must have is a good hardware (!) firewall, which can distinguish the good traffic from the bad one, then block the unwanted. This kind of firewalls, stateful firewalls are manufactured by Cisco for example. They do a hell’a good job.
Other than that, you can only beg for mercy. Nothing else. Every system is vulnerable to these attacks at any time, it’s not just you. The only difference is how much the servers can survive without being killed.

Related posts brought to you by Yet Another Related Posts Plugin.