Hacking: Fight Back
Beat Hackers At Their Own Game With A Hackerbasher Site
At a Glance:
- Prevent automated attacks from reaching legitimate Web domains
- Automatically divert attacks into a dead end
- Get a single log that shows all attack traffic
On any given morning, a look through my production Web server's logs will show that my server farm is under a barrage of attacks. Hackers and crackers with automated IP port scanners can swamp a Web site with bogus requests and failed logons.
The sheer volume of this traffic can reduce response times and overload service request logs. Failed logon attempts (sometimes several hundred in a minute) can obliterate legitimate security reporting in the event viewer. Even if the hacker never gains access to anything, your Web site suffers. I use several procedures to minimize the attack surface. But even after hardening the server and putting it behind a firewall, it is still vulnerable to attacks on port 80.
In this article, I will present an easily implemented strategy that uses HTTP 1.1 host headers to divert port 80 attacks away from unsecured public Web sites into a dead end where they can't do damage. My site, called Hackerbasher, stops the automated attack and records the details about the attack along with the IP address used by the attacker. Hackerbasher doesn't require any special software and its only cost is the time it takes to set it up on your server. You also get the added benefit of being able to monitor port 80 attacks in a single log file. See the sidebar "Setting Up Your Hackerbasher
" for more information.
As you can see in Figure 1, the Hackerbasher log contains evidence of a typical automated attack. Several sites on the server are being attacked several times per second by the hacker at xx.xxx.71.170. The hacker is trying to find cmd.exe along several different paths by requesting that it execute with the command line /c+dir+c:\. Such an attack typically lasts only a few seconds. If the command fails, the hacker automation increments the IP address and sends the request to the next unlucky server. If the command succeeds on any of the IP addresses in the server, the hacker will be at the "C:\" prompt, ready to damage or destroy the server, steal valuable information, or whatever he or she wants. My firewall doesn't keep out this kind of attack.
Many of these attackers appear to be crackers—thrillseekers who simply want to break into something. Crackers usually sniff around for the obvious stuff such as unsecured databases and leftover developer sample files. Obviously, some attackers are on a mission to get in and do damage.
So how do we track down these people? One way is to use a honeypot: an information system resource intended to receive unauthorized or illicit use. The Honeynet Project
was set up so that the good guys can watch and analyze what hackers do. The Honeynet Project reports that the average life expectancy of a honeypot on the Internet is 72 hours. The shortest known manual compromise time was 15 minutes, but a worm got the job done in 15 seconds.
My solution is like a honeypot in that Hackerbasher has no production value. It is set squarely in the path of automated IP:80 attacks and, through its logs, it lets me study what the hackers are trying to do.
Figure 1 A Hackerbasher Log
Hackerbasher consists of one locked empty directory containing absolutely nothing—no home page, no virtual connections, no apps, and no server extensions.
How It Works
I got the idea for Hackerbasher one morning back in 2002 while I was wading through endless IIS logs tracking a worm. I noticed that the hackers weren't attacking the sites by their domain names but by their IP addresses. I was sure there was an automated tool out there systematically trolling through my IP pool looking for something listening on port 80. So, I thought, why not route all the IP:80 requests to a dead end in cyberspace? I then used host headers to do exactly that and called it Hackerbasher.
Legitimate users don't normally go to a Web site by typing an IP address, but automated tools do. Humans use the domain name. The log files from Hackerbasher for the past two years prove this. The only nonhacker traffic to Hackerbasher has been the occasional request for an invalid URL or an unresponsive domain. I'll explain why Hackerbasher gets these requests later.
On all my servers that are running Microsoft® Windows®, Hackerbasher is secured with Windows NT® Challenge/Response authentication, or NTLM. It's not Kerberos, but it works on older servers, including those that are not running Active Directory®, so it's the lowest common denominator. Every request to this site is presented with the Windows Integrated Authentication challenge. The automated attack fails to authenticate and the server returns a 401 error, effectively ending the attack (see the sc-status column in Figures 1 and 2). The Hackerbasher logs show that attacks launched against IP:80 don't expect to have to try passwords, so the automated attack software increments the IP address and tries again, as you can see in Figure 2. The hacker at IP address xx.xxx.119.16 attacks yy.yyy.yyy.21, 22, 23, up to 29 from 6:31:36 until 6:31:47. That's 17 attacks in 9 seconds! When the IP address increments beyond the IP addresses in my server, someone else will be under attack.
Figure 2 Hackerbasher IIS Log from Failed Attacks
Even if someone were to provide valid logon credentials to the Hackerbasher site—even if they are a sysadmin for the domain—they will get an "HTTP Error 403—Forbidden" message after they pass the Challenge/Response authentication because there is no home page.
I mapped all the root IP:80 addresses to Hackerbasher and set up host headers for all my other domains. The hackers can "bash" against the site as long as they like, but all they get from my server is a 401 (Unauthorized, Access Denied) failure message, shown in the sc-status column in Figure 1. Meanwhile, my customers' sites purr along without this traffic threatening their sites and filling their logs.
Putting this security procedure in place cost nothing except the time it took to make sure all my sites had their host headers in order. For years I have used host headers to get the most out of my limited pool of IP addresses so setting this up wasn't much work. All I had to do was collect the root IPs, assign them to Hackerbasher, and make sure my customers' host headers were in order.
Figure 3 Host Header Definitions and IP Mapping in the MMC
Most of my sites have at least two host headers defined, one with the "www" and one without, for example www.testersparadise.com and testersparadise.com. Some Web sites have multiple domain names pointing to them and multiple extensions; .com, .org, and so on. Notice in Figure 3 that there is no identity defined that has an IP address without a host header name.
A Single Log File
The log excerpt you saw in Figure 1
shows only one type of attack, but one that is being used against many IP:80 addresses on this server. (Reading your logs is always important, as you'll read in the sidebar "Hardening Your Web Server
.") You don't usually get a single log file that shows how the hacker attack is moving through the IP addresses on a server. Normally the record of the attacks would be spread across multiple IIS site logs; an administrator would have to look through each one to piece together this information. This approach separates the legitimate users who failed to log onto a host header domain (recorded in the log from that domain) from the crackers and hackers. It also adds a layer of security to my hosted sites by diverting the bogus traffic to a site that can give them what they deserve: an authentication prompt that will never let them in.
In the course of a normal day, there will be several different types of attacks going on all at the same time. Before I put the Hackerbasher solution in place and collected all this information into one log, it was impossible to gauge the size and the seriousness of this type of attack, since the details were buried in several IIS site logs.
Figure 4 shows a series of failed logon attempts in the Windows Event Viewer. These failures are mostly hackers attempting to get into e-commerce, intranet, disaster recovery, and similar secured sites. They are usually my first clue that a serious assault may be underway against some secured resource, like a database or an e-store.
Figure 4 Failed Logons from an Automated Attack
If you only have one secured Web site running in a server when you see a series of security failures like this, you can check the IIS log and determine if it is under attack and what the attackers are trying to do. You can also determine if the attack is being directed at some other resource, such as an FTP server or an SMTP server. If you are running a hosting service with lots of secured sites, however, the evidence can be spread across too many site logs to track down.
It really frustrated me that I couldn't get an accurate idea of how many attacks were going on and what type they were without spending days going through hundreds of logs. For example, I could see the logon failures in my event log, but I couldn't close the loop between a particular logon failure in the event log and a specific failed server request among all the secured virtual servers running on the computer. Figure 2 shows the Hackerbasher IIS log for this same time period. Notice that every request was sc-status 401 (Access Denied). I still can't do a precise correlation with IIS 5.0, but at least with Hackerbasher in place, I can see what's going on across all the IP addresses in the box. If my event logs don't match my Hackerbasher log, it's time to start looking for attacks on legitimate secured sites.
Hackerbasher has proven to be a goldmine in several ways. In Figures 1 and 2, each attack is failing, as you can see in the sc-status column. All these IP addresses are secured by Integrated Windows authentication. The hacker tool simply quits attacking a particular IP address when it receives a 401 from the server. No matter what other defenses are in place, the hack is failing because it cannot pass a logon request.
On an average day, Hackerbasher is subjected to thousands of attacks from IP addresses all over the world. I had no idea just how many attacks were going on per day until I set up Hackerbasher and routed all of the IP attacks to it. Over the past 24 months, Hackerbasher has successfully captured several different types of attempted hacks in its log files, alerting me to new types of attacks as soon as they appear. These are attacks that could succeed against an unsecured public site, underscoring the importance of having your server patches in place when a new attack finds it.
How Host Headers Work
In IIS 3.0, a machine could be assigned multiple static IP addresses, and it could have a virtual Web server running on port 80 of each IP address, and that's all. Each Web site with a domain name had to have a dedicated IP address.
Domain Name Servers look up the IP address associated with a domain name. DNS assumes port 80 for all domain names, so a Web domain defined with a port other than 80 would not appear in any DNS entry. With HTTP 1.0, this meant that each IP address in the server was dedicated to a single domain.
Host headers were added in HTTP 1.1. IIS 4.0 and later support the HTTP 1.1 host header definition. Host headers mean there are three parts to a Web server's identifty in the Web server: the IP address, the port number, and the host header. Using host headers, you can specify the address the old way, using the IP address and port number, or you can assign a host header to an IP address that will use port 80. Several virtual servers (Web sites on the same machine) can share two of the three parts, but the third part must be unique to the particular virtual server.
Host headers allow me to put several hundred small domains on one IIS server using only a handful of IP addresses. Even customers who have their own dedicated IP addresses use multiple host headers.
Several different servers can run on the same machine with the same IP address. For example, the HTTP and FTP servers often share an IP address for a specific domain, but they must each have a dedicated port on the IP address that they can communicate through. Since FTP servers listen on port 21 by default, the IP address would then be 184.108.40.206:80 for the HTTP server and 220.127.116.11:21 for the FTP server. These servers can listen on any port defined for them, but most domains rely on DNS for domain name resolution and since DNS uses port 80, they will also.
Having multiple Web sites defined on a single IP address, with each one listening on a different port, is called IP overloading. This is useful when you own only one IP address. It is also used to obfuscate the location of some sites (like the server administrative site), and allows the server to programmatically redirect traffic to a Web-based application on the server. A user accessing a site defined in this way must specify the full IP address followed by a colon and the port number.
The host header is the domain name that is requested by the user in the location field of their browser. Starting in HTTP 1.1, the browser puts the domain name portion of the URL into the Host Header Definition part of the HTTP request header. Using host headers, I can define multiple domain names for the same site (see Figure 3).
Behind the Scenes
By default, an HTTP server will listen on all unassigned IP addresses on the server using port 80. If you don't define any specific IP address, your server will be available on all the IP addresses on the server; this is a very poor security practice but it is commonly used for SMTP and FTP servers. The server that has an IP address assigned with port 80 and no host header is the primary, or root, server for that address on that port. When a request is received from a browser, the server tries to route the request to its intended site (virtual server) using the IP address, the port, and the host header name. If the host referenced in the host header is unavailable or doesn't exist, or if the page requested does not exist, the request is routed to the primary Web server of that IP:80 address. Hackerbasher is my primary Web server for all of the IP addresses on port 80. Figure 5 shows the host header mappings for Hackerbasher. Just as there are no site identities without a host header on the Web site, Hackerbasher is the only Web site with no host headers defined. Hackerbasher receives all the requests for missing pages and defunct or nonfunctioning domains. This is often my first notification that a customer's Web site is unresponsive, and it is also handy to be able to let my customers know when they have missing pages.
Figure 5 Host Header Mappings for Hackerbasher
If the request comes from an HTTP 1.0 browser, hacker tool, or port scanner, and it does not contain a host header, the primary server (Hackerbasher) responds with an authentication challenge. Someone who expected to see testerparadise.com on the banner of the page might get a response from Hackerbasher instead.
A legitimate request from an HTTP 1.0 client will be routed to Hackerbasher because the browser request will contain only the IP address, not the host header name. Even back in 2003, though, my site logs showed that less than one percent of legitimate client traffic was using HTTP 1.0. So far, I haven't had a single user complain that they couldn't get to a Web site, and my customers are pleased to have the hacker attacks diverted away from their sites.
Marnie Hutcheson is president of Ideva, a firm that specializes in Web application design, development, and hosting. She has published a variety of technical papers and books on various computing topics. You can reach her at email@example.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited
With Hackerbasher, a hacker will have to attack a production Web site through its domain name. Unfortunately, a small proportion of hacks I've seen do attack sites via their domain names. One example of this is the mysterious Microsoft-WebDAV-MiniRedir/5.1.2600 client which appears as the cs(User-Agent) in both automated attacks and in suspicious requests in production server logs that appear to be driven manually. The original signature is associated with an unchecked buffer issue (see Microsoft Knowledge Base article 815021
). This client sends requests to the server using WebDAV methods.