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

1. 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:

   • Basics of setting up Access Lists
   • Configuring IP Access Lists
   • Wikipedia article on Standard ACLs

   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 216.36.50.65

   Here are some commands for a Cisco router:

   • Router_A(config)#access-list 1 deny 216.36.50.65 0.0.0.0
   • Router_A(config)#access-list 1 deny 69.163.239.247 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.

2. 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=67.219.58.161,69.163.239.247,174.122.60.235,216.36.57.157
   
           

   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:

   1. 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).
   2. 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).
   
   
   
3. Null Routes 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.
   
   
4. 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:

           <system.webServer>
     <system.webServer>
        <modules runAllManagedModulesForAllRequests="true"/>
   
   
       <security>
   
         <ipSecurity allowUnlisted="true">
           <add ipAddress="85.17.199.0" subnetMask="255.255.255.0" allowed="false" />
           <add ipAddress="200.98.197.0" subnetMask="255.255.255.0" allowed="false" />
           <add ipAddress="69.163.239.0" subnetMask="255.255.255.0" allowed="false" />
           <add ipAddress="85.17.199.93" allowed="false" />
           <add ipAddress="216.36.50.65" allowed="false" />
   
           <add ipAddress="216.36.49.48" allowed="false" />
           <add ipAddress="216.36.53.144" allowed="false" />
           <add ipAddress="174.122.60.235" allowed="false" />
   
           <add ipAddress="69.163.239.247" allowed="false" />
           <add ipAddress="67.219.58.161" allowed="false" />
   
           <add ipAddress="216.36.57.157" allowed="false" />
           
         </ipSecurity>
       </security>
   
     </system.webServer>
           

   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

1. 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.
   
   
2. Monitoring users: 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 attacker.
   
   
3. Monitoring Processes: 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").
   
   
4. Checking logs: 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.
   
   
5. 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
   c:
   cd \
   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.