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.
- 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 188.8.131.52
Here are some commands for a Cisco router:
- Router_A(config)#access-list 1 deny 184.108.40.206 0.0.0.0
- Router_A(config)#access-list 1 deny 220.127.116.11 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=18.104.22.168,22.214.171.124,126.96.36.199,188.8.131.52
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="184.108.40.206" subnetMask="255.255.255.0" allowed="false" />
<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" 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" />
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.