Endpoint Protection

This is the third installment in an ongoing series of articles looking at honeypots. In the first two papers, we discussed the OpenSource honeypot Honeyd, how it works, and a deployment in the wild. In this paper we will look at a different honeypot, the commercially supported solution Specter.

Similar to Honeyd, Specter's primary value is detection. However, that is where the similarities end, these two honeypots are different as night and day. Many of Honeyd's strength's are Specter's weaknesses, just as many of Honeyd's weaknesses are Specter's strengths. This is why these two honeypots make for such an excellent comparison. Keep in mind that, as true with most honeypots, neither is better then the other, it all depends on what you are looking for.

What is Specter?

Specter is a commercially supported product, developed and sold by the Swiss company Netsec. While SecurityFocus generally does not focus on commercial products, Specter is one of the few honeypot solutions of any kind for Windows environments. Specter is designed for commercial organizations, both small and large enterprise environments. As you will see later, it's extremely easy to use: multiple honeypots can be remotely managed, and it has extensive alerting mechanisms. Designed for Windows, it will run on NT, Win2000, and XP. This paper is based on Specter version 6.0. Specter is what I classify a low-interaction, production honeypot. Honeypots that are low interaction emulate services: they limit the amount of interaction the bad guy has with the honeypot. This interaction is limited to how sophisticated the services being emulated are. Unlike high-interaction honeypots, there is no true operating system for the bad guys to access. The advantage with low-interaction honeypots is that they are easier to deploy (as you will soon see), and have reduced risk. One of the risks of honeypots in general is that attackers can take over the system and use it to attack other computers. Low-interaction honeypots reduce this risk, as they limit what attackers can and cannot do with the honeypot. The disadvantage with such honeypots is they cannot gather extensive amount of information (such as IRC chats, emails, toolkits, etc). However, that is not the intended purpose of Specter. This is a production honeypot: its purpose is to secure your organization by detecting unauthorized activity, not gathering intelligence on attackers.

How Does Specter Work?

Like all honeypots, Specter operates on the principle that it serves no practical applications; therefore any Internet-based activity taking place on it is unauthorized. Anytime there is any interaction with the honeypot, this is by definition most likely malicious activity. This makes it extremely effective for detection, especially on internal networks. It will quickly tell if you a bad guy has penetrated your perimeter defenses, or if you have an employee or vendor looking where they shouldn't. Specter works by listening on specific TCP services. When an attacker interacts with one of these services, Specter captures all of their activity, logs the behavior, and generates an alert. Specter currently does not have the capability to detect ICMP, UDP, or any non-standard IP traffic. Specter is not an appliance. Instead, it is simply a piece of software you install on a computer, similar to any other application, such as Microsoft Office or Winamp. Specter monitors the IP assigned to the computer. Unlike some other honeypots, Specter cannot monitor unused IP space. This limits the number of IPs you can monitor with it.

Currently Specter can monitor a total of 14 TCP ports. Of these 14 monitored ports, 7 are what Specter calls traps, the other 7 are what Specter calls services. Traps are nothing more then port listeners: when a connection is made, the attempt is terminated, and then logged. Services are more advanced; they actually interact with the attacker, emulating the application. The level of emulation depends on each service. For example, the HTTP service emulates a simple Web server with default static Web pages. The FTP server allows an attacker to log in and execute some basic FTP commands. The 7 traps and 7 services are listed in the table below.

Specter has a variety of options that extend the capabilities of the seven services it listens on (you cannot effect the capabilities of the seven traps, as they do nothing more then record, then terminate connections). The first of these capabilities is operating system emulation. Specter can emulate up to thirteen different operating systems. This capability can be extremely useful, particularly as you can have the honeypot mirror the operating systems you are using in your organization. If you have mainly Window systems deployed in your network, then you can have your honeypot emulate a Windows computer. If you have Solaris, Linux, or OS X, then you simply select the appropriate operating system. By having the honeypot mirror the same systems and applications you deploy internally, they will blend with your real production systems, improving their detection capabilities.

Specter does this by changing the behavior of the services based on the operating system you select. For example, if you select the honeypot to be a Windows computer, then the services behave as a Windows computer would. The HTTP service will behave as an IIS Web server; the FTP login banner will say this is a Windows computer. If you select a Linux honeypot, then the HTTP service will behave as an Apache Web server, and login banner will say this is a wu-ftpd FTP server. The same goes for other services, such as Telnet or SMTP. Keep in mind that you want to select the appropriate services for the appropriate operating system. Most Unix systems are not infected with Netbus or Sub-7, as such if you are emulating a Linux system you may not want to run these services. Similarily, if you are emulating a Windows honeypot, you may not want to run Unix-based services, such as SSH or Finger.

There is one limitation with operating system emulation: it does not emulate at the IP stack. This means if you are emulating a Solaris system, your honeypot will still have a Windows IP stack (specifically, whichever Windows OS you used for the honeypot). An attacker can use an active fingerprinting tool (such as the infamous Nmap to determine that even though you are running what appears to be an Apache and a Solaris FTP server, you have a Windows IP stack. This discrepancy can give away your honeypot. This is not a problem if the system you are emulating is the same system that you have the Specter software installed on (such as a Specter installation on WinXP emulating a WinXP server).

This limitation may not be as large a problem as it seems. First, many attackers do not take the time or the effort to analyze a target in such depth. Second, keep in mind the purpose of the honeypot is to detect unauthorized activity. If an attacker scans the honeypot, analyzing emulated services and the IP stack, by then it is too late: the honeypot has done its job and detected the attacker. If you require a more advance solution that can do IP stack emulation, you may want to consider solutions such as Honeyd or Honeynets.

You can also change the "personality" of the seven services. For example, you can select "open", which causes the service to act as an insecure system. The FTP server acts as an open anonymous server, allowing you to download a fake password file. Or the SMTP service can act as an open relay (which is excellent for catching spammers looking for mail relays). You can select "secure", so that the honeypot acts as a hardened system. The same services that pretended to be secure under "open" will act as a hardened box under "secure". The same FTP service will no longer allow anonymous logins, and the SMTP service will no longer allow mail relay. One of my favorites is the personality setting "aggressive". This means that when the service identifies someone doing something they shouldn't be (such as anonymous FTP login), the service will terminate the connection and then issue a warning to the attacker that their activity has been detected and the organization has been notified. This is excellent for scaring off attackers.

Keep in mind that these are emulated services, not the real thing. As such, they are limited in their capabilities. You have some options in configuring the behavior. For example, you can add some of your own customized Web pages for the HTTP service, or add accounts for the emulated POP service. However, the services do not provide true functionality. For example, the Telnet service provides a login and password prompt, but the attacker is never given an actual shell to log into.

One of the most unique features of Specter is "intelligence gathering". When an attacker probes the honeypot, Specter optionally returns the favor by actively querying the attacking system and gaining information from it. This can potentially be useful, as there may be information that can be obtained at the time of the attack. Options include the ability to scan, finger, or traceroute the remote system. You have to be careful about using such options though. While they can prove useful in getting information on the attacker, they can also alert the attacker to the honeypot's existence, or accidentally harm another system.

Installing, Configuring and Deploying

Without a doubt, the greatest feature of Specter is its ease of use. My grandmother could install and configure this honeypot in about 15 minutes flat. This is one of the easiest honeypots I have ever worked with. Installation is simple: it uses a standard Windows installer that does all the work for you. To configure the honeypot, you simply start the Specter program, which gives you a single GUI to configure all the options. You then point-and-click the options you want, and then run the honeypot. In the upper right-hand corner of the GUI is a status bar, telling you if the honeypot is running, and all the services it is listening on. A full explanation of the GUI is beyond the scope of this paper, so I'll let you just check it out (you can figure out how it works in about thirty seconds). You can see a snapshot of the GUI below. To make configuring even simpler, next to every option is a "?" button. To understand what the option does, you simply click on the question button, which explains to you what the option is, how it works, and its value. No digging around complex help menus. Perfect for the impatient geek who wants to get this up and running in five minutes flat.

Figure 1: Snapshot of the Specter GUI
CLICK ON IMAGE TO ENLARGE

There are several options you will want to configure for deployment purposes. The first is alerting. One of Specter's strongest features is its built-in remote alerting capability. I feel this is critical. The sooner a honeypot informs you that unauthorized activity is happening, the greater value it has. One of the worst things you can have happen is have your honeypot detect an attacker on your internal network on a Friday night, but to not receive the alert until you come in Monday morning. By default, Specter logs all activity to its own database system (nothing more than simple ASCII files of each attack). Each attack is first listed in the alert box in the upper right-hand corner of the GUI. Each attack is then analyzed in greater detail using Log Analyzer. This gives you the option of listing all the attacks or querying specific ones, based on time, service, or IP address.

In addition, you can have Specter log to a remote syslog server using syslogd, or the local Event Log. For real time alerts, Specter will send detailed alerts to an email address, or shortened alerts good for cell phones or pagers. The short alerts are good for informing you that something bad is happening. The detailed alerts not only tell you that something bad is happening, but exactly what it is, giving you enough information to react appropriately. For example, below are two alerts for the same activity: someone scanning for and logging into anonymous FTP servers. In the short alert, we see someone is probing the FTP service. In the long alert, we see they are logging into anonymous FTP servers and attempting to capture password files (naughty hacker).

 Date: Mon, 31 Mar 2003 15:07:24 -0600 From: SPECTER on OUTPOST  To: lance@honeynet.org Subject: FTP connection (hacker.honeypots.com) - Attempt 1/2 (FTP/Total) FTP connection from 192.168.1.1 (hacker.honeypots.com) (FTP attempts: 1, Total attempts: 2) on Mon Mar 31 15:07:46 2003 

 Date: Mon, 31 Mar 2003 15:08:07 -0600 From: SPECTER on OUTPOST-01 To: lance@honeynet.org Subject: FTP connection (hacker.honeypots.com) - Attempt 1/2  (FTP/Total) FTP connection Host  : 192.168.1.1  (hacker.honeypots.com) Login : anonymous Pass  : evilattacker@hello.com Time  : Mon Mar 31 15:07:46 2003 Log: Client connecting: 192.168.1.1 Client tries anonymous Login --->331 Guest login ok, send your complete e-mail address as password. Client sent PASS 'evilattacker@hello.com' --->230 User anonymous logged in. Client sent SYST --->215 UNIX Type: L8 (Linux) Client changed type to I --->200 Type set to I.  Client set port to 50739, IP to 192.168.1.1 --->200 PORT command successful. Client wants to fransfer file passwd --->501 File not found.  Client closed connection --->221 Goodbye. Closing connection with 192.168.1.1   

Specter has another feature that is pretty cool: a "heartbeat" option for alerting, which means that the honeypot will send you emails at intervals you configure. This is good for honeypots that are deployed on quiet networks. The heartbeat reminds you the honeypot is still deployed and active. The last step before deploying is locking down the system itself. As a honeypot, Specter minimizes risk by emulating services. These emulated services contain the activity of attackers. However, Specter does nothing to secure the host system itself. If you install Specter on an insecure Windows installation (such as with file shares open, or an easy to guess Administrator password) then the honeypot can be compromised and used to harm other systems. When deploying Specter, you have to ensure you use common best practices to secure the system itself (including installing and maintaing the latest security patches).

When it comes time to deploying, you must keep in mind what you are using the honeypot for. For detection, Specter works best on internal networks. If you deploy Specter on your external or perimeter networks, it will tell you what you already know: the bad guys are pounding on your organization. Specter is most valuable detecting unauthorized activity on your internal, or trusted networks. Specter also comes with a GUI for remote administration. This separate program runs on any Windows system. It is then used to connect to your Specter honeypots. The remote administration GUI looks almost exactly the same as actual honeypot itself, the only difference is you cannot remotely analyze alerts or attacks - that has to be done locally on the honeypot. If you enable remote administration (it is disabled by default), be sure to select a different port to listen on. The last thing you want is the management port to become a fingerprint for your Specter deployment.

For all of its strengths, Specter's greatest weakness is probably its limitation to detect activity on only 14 TCP ports. Attackers may be active on other ports or even other IP protocols. As such, when using Specter, I recommend using other technologies to increase your honeypot's capabilities. I also recommend also running the Windows version of Snort on your honeypot when using Specter. This does two things for you. First, it captures more detailed information on all the attacks. Not only can you use Snort to identify and alert on attacks, but you can also use it to capture every packet and its full payload to a binary log file. This information may prove critical in analyzing an attack or unauthorized activity at a later date. The second thing Snort offers is that it can capture (and log) activity on other IP protocols and ports that Specter is not listening on. This increases its detection capabilities. In order to capture the maximium amount of information using Snort, I recommend the Snort configuration files used by the Honeynet Project. You can learn more at their Honeynet Tools section.

Conclusion

The purpose of this paper has been to offer an overview of the commercial Windows-based honeypot, Specter. Specter is an extremely easy to use honeypot, with a variety of feature that monitors up to 14 TCP ports. Now that this series has looked at a couple of different honeypots solutions, the next article will take a step back and analyze their value for detection.

To learn more about honeypots in general, please visit the author's Web site, www.tracking-hackers.com.

To read the next installment to this article, click here.