Using Honeypots to enhance Log Analysis

If you are faced with the task of finding network probes and attacks in an endless stream of IDS, firewall, netflow and application events, then using one or more honeypots to help find low-and-slow probes, stealthy attacks and internal abusers may be for you. This blog entry will discuss several different types of honeypot types, monitoring techniques, and how this can be implemented with the Tenable Security Center and Log Correlation Engine.

Honeypot "Simulators"

There are several specific applications that can be run on one or more systems to simulate multiple operating systems, servers and even networks. Examples of these include:

• honeyd
• nepenthese
• iDefense Multipot
• La Brea (as in the tarpit)

Each of these applications can simulate various technologies on your local network. They can be placed within DMZs, can be configured to make use of unused addresses space on your network or can be deployed as targets for internal intruders to stumble over.

The Log Correlation Engine can parse logs from each of these applications, plus a few commercial ones not listed here. The advantage of interacting with the raw logs from these devices is that each often has very detailed analysis of what occurs. For example, the Mulitpot from iDefense will actually interact with some worms and probes and report when new payloads for worms have been downloaded.

Live Sacrificial Honeypots

If simulating a target with an application isn't real enough for you, consider running copies of your operational systems, but designate them as your "honeypot". These could be real servers or additional virtual servers such as another running VMWare image.

If you specifically deploy these secondary systems, then monitoring them with the Security Center and Log Correlation Engine can be easily accomplished. The actual servers can be added to an Asset List named "Honeypot". Using that as a filter, all IDS events or logs can easily be analyzed. Discovering who is probing your honeypots from the outside or inside can be very enlightening.

Within the Log Correlation Engine, you can also configure certain types of alerts with the TASL scripting language to recognize when:

• internal systems connect to the Honeypot asset
• the honeypot systems actively reach out to the network, perhaps indicating a compromise or infection
• external systems scan both the Honeypot and then continue to scan other systems

When working with live honeypots, you should be conscious of how they "look" compared to the rest of your network. The Security Center can be used to measure the typical types of vulnerabilities and applications on your network. With this knowledge, you can keep your honeypot configured the same as the local network to "blend in" or can make it a more attractive target for an attacker, depending on your goals.

It should be noted that if you are running systems specifically to be broken into or be compromised, this may indeed be a liability for your organization. For example, consider what happens if an external attacker compromises a honeypot and then does a lot of damage to a third party. If this is your type of environment, you should consider running a simulated honeypot like we've discussed about above or perhaps identifying live systems that are operational, but seldom used such as disaster recovery or fail-over servers.

Honeypot "Services" and Firewalls

Running a separate application to simulate a honeypot or running stand-alone systems may not be necessary to capture evidence of intruders. If your network already has active applications, consider presenting additional services to either the outside world or local networks.

For example, consider a Windows IIS web server that does not usually run SSH on port 22. Using a third party application that opens a port on 22 and just listens for connections is interesting. Tools like Multipot can be configured to listen on various ports like this. If you are confident in the security of the extra application, you could simply run it and then use the Log Correlation Engine to monitor the logs and alert whenever there is a connection.

This concept can be extended to firewalls as well. Consider a network that has a firewall policy to log a "deny" event for any network request that isn't already allowed to a server. Looking in these "deny" logs can find all sorts of external and internal probes for ports which should not be probed. The Log Correlation Engine can be used to alert for "deny" firewall events from places like a DMZ or to filter for internal probes to a DMZ. This can help identify abuse, low and slow probes or determined attackers.

Lastly, if you have a firewall that supports port forwarding, you can present many different external IP addresses and services to the outside world. Consider a network that may have multiple real IP addresses on the "outside", but is using port forwarding to serve a single web server. Instead of running multiple web servers, using multiple port forward rules to make it seem like you have more web servers could help act like a honeypot. The logs from the firewall, NIDS or monitoring log for these additional IP addresses can be processed by the Log Correlation Engine for analysis as well.

Honeypot Users

If your application can log events about specific users, then you may want to consider adding specific accounts that should "never" be used. These accounts shouldn't be any different from other accounts already on your application. For example, don't add an account with a bad password or administrator privileges to "hope" that a remote intruder will exploit this.

Once this has been configured, consider how you would like to alert for the user activity. The Log Correlation Engine has many TASL scripts which look at user activity. If your application log is proprietary, you'll need to write custom PRM parsing rules and then modify an existing TASL script to alert when the user of interest is used.

The Honeypot that wasn't There

Another concept that is very easy to implement is to look for chunks of address space on your network that are not in use. With the Security Center, scanning with multiple Nessus scanners, or monitoring with the Passive Vulnerability Scanner, this is very easy to accomplish. These networks and IP addresses can be placed into a "dead space" type of Asset List. Once this is accomplished, you can either perform manual queries into the logs of your firewalls, netflow or NIDS and look for internal or external systems attempting to access these ranges. If you were so inclined, you can modify existing TASL scripts to alert when connections to these networks or asset list occurs.

Support In Tenable Products

Tenable customers interested in implementing these concepts should consider the following:

• The Security Center can be used to create Asset Lists to represent one or more honeypots
• There are existing PRM rules for honeyd, nepenthese, La Brae and Mulitpot
• The honeypot.tasl script can look for combinations of specific destination IP address and ports
• Asset based alerting scripts such as asset_webserver.tasl can be modified for your "honeypot" assets
• TASL scripts that parse user activity logs such as new_user.tasl can be modified to look for honeypot user accounts