How to Stop a Denial of Service (DoS) Attack
At this point, you should have a list of IP addresses for the attacking machines.
If not, please read the previous section.
Ideally, you want to stop the Denial of Service (DoS) attack at the network layer by configuring one or more routers.
Sometimes this is possible, sometimes not. You can also stop the attack by using IT Administration techniques.
I will show you techniques from both camps in this section; try to implement as many of them as you are able, but don't worry
(too much) if
you are unable to do all of them.
Most IT organizations and ISPs have both IT Administrators and Network Administrators
(often, these two groups don't communicate much). Later on, when we contact the other
victims of the attack, you will want to keep this in mind. If the Network Administrator can't or won't help you, you will want to
ask for the help of an IT Administrator, and vice versa. If you happen to be both the IT Administrator and the Network Administrator
for your website, then I recommend that you try to do all of the following techniques.
How to block the attack from your website
- Blocking the Attack with Packet Filters on the Router(s)
This is by far the best method, and if you can do this, you are pretty much done, except that its still a good idea to contact the other ISPs who are victims of this attack.
Most ISPs have a bunch of routers. For best results, do this on the "border" router(s) (the ones at the border between your network and the outside world) or, to reduce load,
do this on the router closest to the machine under attack.
Here are some external articles you might find useful:
Most of these articles concern Cisco routers. If you (or your ISP) are not using a Cisco router, your router will certainly have similar commands.
e.g. here is a command for a Pix firewall: shun 184.108.40.206
Here are some commands for a Cisco router:
- Router_A(config)#access-list 1 deny 220.127.116.11 0.0.0.0
- Router_A(config)#access-list 1 deny 18.104.22.168 0.0.0.0
- Router_A(config)#access-list 1 permit any
If your attacker is more technically advanced than mine was, you might want to check out Cisco's
Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks.
Blocking the attack by configuring Windows Firewall.
If you are unable to block the hacker traffic via routers as described above, then this is probably your best alternative.
Here is an article which shows you how to setup Windows Firewall with Advanced Security using a graphical interface.
Personally, I prefer to use a cmd prompt, and create a script which looks like this:
netsh advfirewall firewall delete rule name="disallow Hacker IP"
# ignore wrapping, this should all be on one line
netsh advfirewall firewall add rule name="disallow Hacker IP" action=block enable=yes profile=any
localip=any protocol=any dir=in remoteip=22.214.171.124,126.96.36.199,188.8.131.52,184.108.40.206
Note: If your development machine is _not_ a Windows 2008 Server R2 machine, then you may need to change some parameters here
to run, as the netsh command
parameters apparently vary between Windows versions.
There are a couple of advantages to using a script:
- If you are deploying to a platform like Azure, you can implement this is a
startup script, so it gets deployed to every web role instance that is running your web server code (I'll show you how to do this later).
- Using netstat, and a scripting environment like PowerShell, you
can create a script which automatically blocks IP addresses when a hacker attack is detected (I'll eventually post this in an upcoming PowerShell scripts section).
Here is a good article on Wikipedia which tells you how to setup Null routes on
Linux, Solaris, BSD, Junos, Cisco, and Windows. Note that on Windows, you want to set the "null route" destination as an unused IP address (in their case 192.168.32.254 and
not 127.0.0.1, which doesn't work on all Windows Operation Systems. In this method, you are giving your computer a bad route to the hacker's IP address,
so your computer is unable to communicate with the hacked machine, and vice versa.
Blocking the attack by configuring the webserver.
Azure support person Ming Xu sent me this great link with a bunch of useful IIS settings which can be used to thwart
more sophisticated DDos attacks. In particular, you might want to check out enableHeaderChecking, executionTimeout, maxQueryStringLength, maxRequestLength, and maxUrlLength (and thanks to Paco for giving an updated link and settings suggestions!).
Here is a good article on the subject from Microsoft.
This method will quickly mitigate the attack, but not completely stop it. It is a good first step if you can't block the attack at the router as described above, but you
will still want to implement some of the steps below. This method will tell IIS (your webserver) to stop servicing requests from these hacked IP addresses.
However, these hacked machines will still be able to open (unused) network connections to your machine; you can still see these
connections using netstat; you will see many
connections which are not "ESTABLISHED", but the attacker will have to use many, many more machines to attack your site in order to cause a Denial of Service,
so this method may work well for you in the short run.
Here is an excerpt from my web.config file
which tells IIS that it shouldn't accept web connections from the IP addresses
of the hacked machines:
<add ipAddress="220.127.116.11" subnetMask="255.255.255.0" allowed="false" />
<add ipAddress="18.104.22.168" subnetMask="255.255.255.0" allowed="false" />
<add ipAddress="22.214.171.124" subnetMask="255.255.255.0" allowed="false" />
<add ipAddress="126.96.36.199" allowed="false" />
<add ipAddress="188.8.131.52" allowed="false" />
<add ipAddress="184.108.40.206" allowed="false" />
<add ipAddress="220.127.116.11" allowed="false" />
<add ipAddress="18.104.22.168" allowed="false" />
<add ipAddress="22.214.171.124" allowed="false" />
<add ipAddress="126.96.36.199" allowed="false" />
<add ipAddress="188.8.131.52" allowed="false" />
As described in the Microsoft article, you may need to install "IP and Domain Restrictions" on IIS.
If the ISP who is hosting your website doesn't support this (mine didn't seem to), then you might consider
moving to Azure as I describe later. Also, if you add this code to your web.config, and your development machine doesn't have the
IIS "Domain and IP Restrictions" installed, you may see a Visual Studio warning about this, but you can ignore it.
How the other victims can stop the attack and also track the hacker
Network: As described above, the ISP can block the attacker using packet filters on their routers. Many network administrators also have
monitoring software, often based on SNMP (e.g. The Multi Traffic Grapher (MRTG)) which can alert them to sudden traffic
abnormalities one would expect from a Distributed Denial of Service Attack.
They can also use these programs to confirm that an attack is taking place
(often, when you report these attacks, they won't believe you at first.)
As described in Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks,
network administrators and system administrators can also use programs like tcpdump or
snoop to anaylze network traffic.
Here is a gigantic list of network monitoring tools.
On a Windows machine, you can check to see which users are logged into a machine using commands described in this article.
On a Unix machines, you can use the "w", "who", or "users" (Linux) command to find out which users are logged in, and what programs they are running.
Administrators can use these commands to find out which user is running the
attack. The user account may belong to the hacker, or the account may
belong to a legitimate user who has had his or her account hijacked by the
On a Windows machine, you can check to see which processes are running and which users are running them.
Be sure to check the "Show Processes from All Users" button at the bottom of the
Task Manager screen.
On Unix machines, you can use the "ps" (ps -alx, ps -au | more, ps -u
[username]) command to find out which processes are running. In my case, the
ISPs could have run the ps command to see who is running ApacheBench (the
executable is called "ab").
You can setup logging on a cisco router by following the instructions in this article.
On Windows systems, you can use Windows Event Viewer; here is a
YouTube video on using Windows Event Viewer.
When you look at the logs in Event Viewer, you will want to look at the Application, System, and Security logs. If the security logs are empty, you may need
to enable Security logs. Here is an article which tells you
how to read Unix logs.
Searching for malware: In my case, I could tell from my web logs that the attacker was using ApacheBench (ab) to attack my site. The ISPs I contacted
could have used some of these following commands to find out where "ab" was installed. From a Windows command prompt, you can run commands like this to find the files:
# if you have other drives, you can replace "c:" with their drive letters here
dir ab.* /s /p
Here is an article that describes how to use the Unix find command.
Log files can be useful both in tracking down and stopping the attack. If several ISPs cooperate, it may also be possible to find out who the hacker really is using these logs.
If you are still considering pursuing legal actions against the attacker, you will certainly want to keep these for your records; logs often get automatically
deleted after a period of time.
Next: Contacting the other Victims of the Distributed Denial of Service (DDos) Attack
Previous: How to get Email Addresses for the other Victims of a Hacker
Back to Table of Contents