John G. Levine

HoneyStat: Local Worm Detection Using Honeypots

Worm detection systems have traditionally used global strategies and focused on scan rates. The noise associated with this approach requires statistical techniques and large data sets (e.g., 220 monitored machines) to yield timely alerts and avoid false positives. Worm detection techniques for smaller local networks have not been fully explored.

The use of Honeynets to detect exploited systems across large enterprise networks

Computer networks connected to the Internet continue to be compromised and exploited by hackers. This is in spite of the fact that many networks run some type of security mechanism at their connection to the Internet. Large enterprise networks, such as the network for a major university, are very inviting targets to hackers who are looking to exploit networks. Large enterprise networks may consist of many machines running numerous operating systems. These networks normally have enormous storage capabilities and high speed/high bandwidth connections to the Internet. Due to the requirements for academic freedom, system administrators are restricted in what requirements they can place on users on these networks. The high bandwidth usages on these networks make it very difficult to identify malicious traffic within the enterprise network. We propose that a Honeynet can be used to assist the system administrator in identifying malicious traffic on the enterprise network. By its very nature, a Honeynet has no production value and should not be generating or receiving any traffic. Thus, any traffic to or from the Honeynet is suspicious in nature. Traffic from the enterprise network to a machine on the Honeynet may indicate a compromised enterprise system.

Wireless intrusion detection and response

A prototype implementation of a wireless intrusion detection and active response system is described. An off the shelf wireless access point was modified by downloading a new Linux operating system with nonstandard wireless access point functionality in order to implement a wireless intrusion detection system that has the ability to actively respond to identified threats. An overview of the characteristics and functionality required in a wireless intrusion detection system is presented along with a review and comparison of existing wireless intrusion detection systems and functionalities. Implemented functionality and capabilities of our prototyped system are presented along with conclusions as to what is necessary to implement a more desirable and capable wireless intrusion detection system.

Intrusion detection testing and benchmarking methodologies

The ad-hoc methodology that is prevalent in todays testing and evaluation of network intrusion detection algorithms and systems makes it difficult to compare different algorithms and approaches. After conducting a survey of the literature on the methods and techniques being used, it can be seen that a new approach that incorporates an open source testing methodology and environment would benefit the information assurance community. After summarizing the literature and presenting several example test and evaluation environments that have been used in the past, we propose a new open source evaluation environment and methodology for use by researchers and developers of new intrusion detection and denial of service detection and prevention algorithms and methodologies.

Using honeynets to protect large enterprise networks

Network administrators use several methods to protect their network. Installing a honeynet within large enterprise networks provides an additional security tool. Honeynets complement the use of firewalls and IDS and help overcome some of the shortcomings inherent in those systems. In addition, honeynets can also serve as platforms for conducting computer security research and education.

A methodology to detect and characterize Kernel level rootkit exploits involving redirection of the system call table

There is no standardized methodology at present to characterize rootkits that compromise the security of computer systems. The ability to characterize rootkits will provide system administrators with information so that they can take the best possible recovery actions and may also help to detect additional instances and prevent the further installation of the rootkit allowing the security community to react faster to new rootkit exploits. There are limited capabilities at present to detect rootkits, but in most cases these capabilities only indicate that a system is infected without identifying the specific rootkit. We propose a mathematical framework for classifying rootkit exploits as existing, modifications to existing, or entirely new. An indepth analysis of a particular type of kernel rootkit is conducted in order to develop a characterization. As a result of this characterization and analysis, we propose some new methods to detect this particular class of rootkit exploit.

Re-establishing trust in compromised systems: Recovering from rootkits that trojan the system call table

We introduce the notion of re-establishing trust in compromised systems, specifically looking at recovering from kernel-level rootkits. An attacker that has compromised a system will often install a set of tools, known as a rootkit, which will break trust in the system as well as serve the attacker with other functionalities. One type of rootkit is a kernel-level rootkit, which will patch running kernel code with untrusted kernel code. Specifically, current kernel-level rootkits replace trusted system calls with trojaned system calls. Our approach to recover from these type of rootkits is to extract the system call table from a known-good kernel image and reinstall the system call table into the running kernel. Building on our approach to current generation rootkits, we discuss future generation rootkits and address how to recover from them.

A Methodology to Characterize Kernel Level Rootkit Exploits that Overwrite the System Call Table

A cracker who gains access to a computer system will normally install some method, for use at a later time that allows the cracker to come back onto the system with root privilege. One method that a cracker may use is the installation of a rootkit on the compromised system. A kernel level rootkit will modify the underlying kernel of the installed operating system. The kernel controls everything that happens on a computer. We are developing a standardized methodology to characterize rootkits. The ability to characterize rootkits will provide system administrators, researchers, and security personnel with the information necessary in order to take the best possible recovery actions. This may also help to detect and fingerprint additional instances and prevent further security instances involving rootkits. We propose new methods for characterizing kernel level rootkits. These methods may also be used in the detection of kernel rootkits.

An investigation of a compromised host on a honeynet being used to increase the security of a large enterprise network

The growth of network intrusions on large enterprise networks continues to increase, creating an epidemic of compromised hosts. The deployment of firewalls and intrusion detection systems has not slowed the growth of intrusions to an acceptable rate. Investigating the compromise of a production machine is both difficult and time-consuming due to the mixing of attack and production traffic, while similar investigations of compromised machines on honeynets are much less complex since there is no real production traffic. We discuss why these investigations are easier on a honeynet and how honeynets may be used to make investigations of compromised production machines faster and recovery easier. We include a description of an attack and the analysis that was conducted.

Application of a methodology to characterize rootkits retrieved from honeynets

Techniques and methods currently exist to detect if a certain type of rootkit has exploited a computer systems. However, these current techniques and methods can only indicate that a system has been exploited by a rootkit. We are currently developing a methodology to indicate if a rootkit is previously known or if it is a modified or entirely new rootkit. We present in this paper an application of our methodology against a previously unseen rootkit that was collected from the Georgia Tech Honeynet. We conduct our analysis process against this rootkit and are able to identify specific characteristics for subsequent detections of this rootkit. This ability will provide system administrators, researchers, and security personnel with the information necessary in order to take the best possible recovery actions. This may also help to detect and fingerprint additional instances and prevent further security instances involving rootkits.