|
|
There are other kinds of honeypot solutions or closely related mechanisms related to learning more about malware. We briefly introduce them now and point out differences from the previous approaches.
David Zimmer from iDefense published a tool called Multipot, which is available at http://labs.idefense.com/files/labs/releases/previews/multipot/index.html Multipot is designed to run on Windows system and thus a solution you can use if you do not have a machine running Linux.
Multipot is an emulation-based honeypot designed to capture malicious code that spreads through various exploits across the Internet. It is similar to nepenthes and also emulates the vulnerable parts of network services. In addition, it also emulates popular backdoors from Remote Access Trojans (RATs). Zimmer provides five examples of use cases for Multipot on the project's website:
ISPs to monitor their networks
Corporate security personnel to be warned of infections
Security researchers to build statistics of Internet health and exploitation
Virus researchers to collect new samples of malware in the wild
Hobbyists and students to learn more about Internet security
As you can see, this is basically the same as for nepenthes. The project site also contains more information on how to extend Multipot and references on how to configure the tool.
HoneyBOT is a Windows-based low-interaction honeypot solution. Its basic idea is very similar to the one from nepenthes and honeytrap: It emulates vulnerabilities in network services. HoneyBOT works by opening many UDP and TCP listening sockets on the honeypot machine and then emulates vulnerabilities on these ports.
You can download HoneyBOT version 0.1.2 at http://www.atomicsoftwaresolutions.com/HoneyBOT_012.exe. The tool requires at minimum Windows 2000 as the operating system, and the machine should have at least 128MB RAM. The installation itself is very easy: Just download the link, double click on the file, and follow the on-screen instructions. It is safe to accept the defaults. Further instructions to install HoneyBOT are available via a user guide that can be downloaded at http://www.atomicsoftwaresolutions.com/HoneyBOTUserGuide.pdf.
We suggest that you install HoneyBOT on a dedicated computer with no valuable information or resources required of it. This is useful because there are no guarantees that HoneyBOT is free of vulnerabilities. And since attackers interact with your honeypot, they could potentially compromise the system. Thus, you should also place the machine running the honeypot on a dedicated network with additional protections. (We have said this many times).
Billy Goat is a worm detection system developed by several researchers from IBM. Its most important feature is its reliability in terms of accuracy, resiliency, and rapidity in detection and identification of worms without false positives. The focus of the tool lies in automated detection of infected machines within a given network. It is limited to detecting known worms and designed to be free of false positives. The key factor of the tool is that it exploits the propagation strategy of worms. To find new targets, a worm has to scan for other machines — for example, by random scanning or sweeping of a given network range. This leads to the fact that a worm will often hit an unused IP address, and this is where Billy Goat comes in. The tool listens on unused IP addresses and offers emulated services that include those commonly exploited by worms, similar to what nepenthes does or what you can achieve with the help of honeyd. Each emulated service offers enough interaction to detect what kind of exploit was attempted, and all collected information is sent to a central repository for data analysis. A more complete overview of Billy Goat 2.0 is available in the paper by James Riordan et al. [112].
Today, many solutions exist to observe malicious traffic on a large-scale basis, in other words, on the whole Internet. However, they often involve in monitoring a very large number of unused IP address spaces to look for malicious activities. Several names have been used to describe this technique, such as network telescopes [6,56], blackholes [10,85], darknets [16], or Internet Motion Sensor (IMS) [2]. All of these projects have the same approach: They use a large piece of globally announced IPv4 address space and passively monitor all incoming traffic. For example, the network telescope run by the University of California, San Diego, uses 224 IP addresses. This is 1/256 of all IPv4 addresses. The telescope contains almost no legitimate hosts, so inbound traffic to nonexistent machines is always anomalous in some way (the principle of honeynets is also used in this context). By analyzing all packets, they can infer information about attackers. Since the network telescope contains approximately 1/256 of all IPv4 addresses, it receives roughly 1 out of every 256 packets sent by an Internet worm with an unbiased random number generator. Thus, the monitoring of unexpected traffic yields a view of certain remote network events. This can, for example, be used to study the threats posed by denial of service attacks [56]. The main drawback is the pure passive approach: By not responding to the packets, it is not possible to learn more about full attacks or the associated malware binaries. For this we need, normally, a (limited) interaction and response mechanism as implemented by nepenthes and honeytrap.
Another approach in this area is to passively measure live networks by centralizing and analyzing firewall logs or IDS alerts [40,110]. The Internet Storm Center (ISC) / DShield.org [40,41] is a well-known project in this area. In this project, the collected data is simple packet filter information from different sources around the world, and no "high-level" data is included. Reports are published on a daily basis, and they include information about attack patterns and take a closer look at unusual events. A report combines 8 to 20 million records per day with 200,000 to 400,000 source and 300,000 to 450,000 target IP addresses per day. The results are nevertheless only simple queries like "Most Attacked Port." Moreover, the data contains no detailed information about the source who has collected the packet. So a comparison of different attacks is not easy.
Coarse-grained interface counters and more fine-grained flow analysis tools such as NetFlow/cflow offer another readily available source of information. A flow is defined as IP traffic with the same source IP, destination IP, source port, and destination port, since this quadruple can describe the IP traffic between two devices on the Internet. A router that is capable of flows will only output a flow record when it determines that the flow is finished — for example, either by explicit connection shutdown or timeout. The flows are stored in a central database and can be analyzed from a high-level point of view. With this aggregation of data, it is often possible to draw conclusions about unusual events within a network.
Finally, another comparable approach to learning more about malicious network traffic is eCSIRT.net. In the context of this project, several European Computer Security Incident Response Teams (CSIRTs) set up a network of IDS sensors across Europe. This network collected data about attacks in a central database for further analysis and helped in vulnerability assessment. After the project ended, some teams decided to continue the then-established sensor network across Europe, which has provided information about network attacks since September 2003.
|
|