Honeypots with sensors on production systems

Individual sources report that more than 286 million new, positively identified malware instances were registered in 2010 alone, not counting unreported cases (i.e., malware that cannot be detected by current security tools). In many cases, these huge numbers of “new” malicious programs (Figure 1) are not necessarily malware with any new functionality; instead, they are often the result of polymorphic or metamorphic code that regularly generates slightly modified variants of a malicious program with virtually identical functionality. The objective of this procedure is to modify the structure of the malware so that it is no longer recognized by classic, signature-based detection tools.

Figure 1: The number of malicious programs on the Internet has exploded in recent years. (From AV-TEST Institute [1], which registered more than 55,000 malicious programs every day.)

Although regular updates of signature databases used in virus scanners and intrusion detection systems are essential, uniquely assigning all newly discovered malware to a signature would take an average of 38 new signatures per minute. This number makes it clear that a signature-based approach alone is not sufficient to ensure reliable detection of all current malware.

New Methods

To detect the propagation of this kind of malware on monitored networks, other detection methods, such as honeypots, are required as well. These resources are capable of identifying unknown attacks without the help of signatures, assuming they target one of the simulated vulnerabilities. Because honeypots can only identify direct attacks on their own resources, comprehensive network monitoring using only honeypots is hardly practicable. To increase the honeypot’s visibility, you could add more honeypots to a network, or assign additional IP addresses to individual honeypots. In both cases, however, additional resources are required, and in many cases, resources are limited or involve some kind of financial overhead.

A larger number of honeypots on the network not only increases the resource requirements, it adds complexity to network monitoring, because information from various resources must be evaluated and correlated. Furthermore, the administrative overhead increases because honeypots need to be updated at regular intervals to detect malicious code that uses new attack vectors. In addition to this overhead, honeypots can also be an additional security risk for other systems on the network. For example, it is conceivable that a honeypot might contain a vulnerability and be infected as a result. Using the infected honeypot as a platform, further attacks can be launched against production systems on the network.

Whether or not an attack can be registered by a honeypot ultimately depends on whether it is possible for a remote attacker to identify and avoid it. This is the case in particular with technically savvy individuals, whose attacks might be impossible to detect by honeypots in certain circumstances. For example, if the attacker has information about the network infrastructure or the addresses of interesting systems, the honeypot will have little, if any, chance of discovering the attack. However, if the attacker has no detailed information about the target network, systems within the network are tracked down in the typical way with active scanning and checked for potentially vulnerable services, which could put the honeypot in center stage.

On the downside, because ordinary, low-interaction honeypots in particular often provide a characteristic set of simulated services, they can be identified as honeypots, and the attacks on them can be dropped. To address this problem, individual honeypots can be actively adopted to match existing production systems; however, this again involves additional time and effort and restricts the visibility of the honeypots.

HoneypotMe

Nevertheless, to achieve comprehensive network monitoring on the basis of honeypots, the approach used by HoneypotMe is based on flexibly outsourcing honeypot sensors to the production systems. The use of only individual ports as a honeypot, instead of dedicating all of the system’s resources, makes this possible. In fact, many production systems provide only a small number of services accessible to malicious code or available for individual attackers to exploit over the network.

If a network service is not available on a production system, no interaction with the corresponding port should be found during regular network operations. If an attempt to initiate this interaction nevertheless occurs (e.g., by a malicious program), the TCP stack on the attacked system will automatically reject the attempt to connect – if it is not blocked previously by appropriately restrictive firewall rules. In both cases, however, the failure of the connection attempt means that no further information on the interaction is generated, even if that information would be quite easy to attain. If, instead, a honeypot were to accept the connection and evaluate it, it would be possible to detect directly an attempted infection. Thus, it seems logical to leverage these unused ports as honeypots on production systems, rather than dedicating resources exclusively for use as honeypots.

Risk-Free Pass

An evaluation of incoming connections for closed ports on the production systems being used as various dedicated honeypots would, however, mean increased security risks, additional resource requirements, and administrative overhead in the form of updates, for example. The use of honeypot software on the production systems also would add to the security risk of the affected systems. An attacker might be able to exploit vulnerabilities in the honeypot software to access the production system. To avoid this, and at the same time allow for centralized evaluation of unwanted connections, HoneypotMe uses a dedicated analysis component. Unwanted connections are transparently forwarded by HoneypotMe from the production systems to the analysis component, where they are logged and analyzed in detail (Figure 2).

Figure 2: Analysis of an attack is removed from the system being attacked.

Transparent Tunnel

Response messages are sent back to the attacked system via the tunnel, and the victim then forwards them to the attacking system. The advantage of tunneled connections over a proxy is the analysis component receives information on both the attacking and the attacked system. Moreover, all metadata contained in the connection data is kept – in particular, the packet headers. On the basis of the information contained in the headers, additional information about the attacking system can be derived.

A major challenge is choosing which ports to forward from the production systems to the analysis component. Depending on the respective systems, you can specify the ports on which no regular interaction is expected; however, it is generally accepted that this principle cannot be applied to arbitrary ports. For example, it is unlikely that port 1439 for the Microsoft SQL database servers will be used for production purposes on Linux systems. Each and every interaction with this port could thus be generically viewed as a malevolent interaction, in line with the classic honeypot concept. Depending on the application running on the production system, or depending on the operating system, the production ports used on the monitored systems can differ. Furthermore, the number of productive ports would vary over the observation period.

Flexible Port Selection

These factors necessitate individual and flexible routing of ports depending on the individual hosts to avoid interfering with production operations on the network, and to support comprehensive monitoring of the unused ports. If you were to forward all connection attempts targeted at a previously defined set of ports to the analysis component, you could only cover ports that were not used by any of the production systems. Ports used only by a subset of all systems could not be taken into account.

To allow for flexible forwarding of connection attempts to closed ports on individual systems, these connections can be dynamically forwarded to the analysis component directly by the affected systems. For this to happen, HoneypotMe checks incoming packets with the SYN flag set to discover whether an attempt is being made to open a TCP connection to a closed port. HoneypotMe achieves this by checking for incoming SYN packages to see whether a corresponding receiver socket is bound to the requested port. When a connection attempt is detected, HoneypotMe automatically forwards the SYN package through the tunnel to the analysis component. This can now open a TCP connection and create a corresponding response package with SYN/ACK flags, which it tunnels back to the attacker.

Any further communication will, of course, take place between the attacker and the analysis component, so that the connection does not need to be accepted on the target server itself. During this process, automatically generated RST packets on the targeted server are dynamically blocked under Linux using libipq . To prevent the analysis component opening further connections through the tunnel to the network to be monitored, HoneypotMe discards any TCP SYN packages received through the tunnel. It also ensures that all TCP packages to be forwarded use the correct sender IP address.

Influence of HoneypotMe on Attack Scenarios

The use of HoneypotMe on production systems reveals further characteristics, in addition to possibly detecting attempted attacks on closed ports. If the closed ports on a system are used as a honeypot, an attacker using Nmap cannot distinguish whether the services offered by the target system are genuine, existing services, or simulated by the honeypot. The set of services visible to the attacker on the target system is equal to the total set of the services offered by the server and the analysis system (Figures 3 and 4).

Figure 3: Visible ports of an ordinary Linux web server as revealed by nmap.

Figure 4: Visible ports (abridged) on a Linux web server with active HoneypotMe as revealed by nmap.

As a result, systems with HoneypotMe appear similar in an active scan of the network because a similar scope of services is offered. Approaches that develop dynamic honeypots pursue the objective of adapting honeypots to match production systems; however, to make it more difficult to distinguish between the two, HoneypotMe makes the production systems look like honeypots. In contrast to dynamic honeypot approaches, HoneypotMe itself does not need to check other systems actively because it does not need to respond to changes to the system configuration on the network.

Additionally, using HoneypotMe improves the security of your production systems by forwarding unused ports directly. An attacker might overlook a genuinely vulnerable service and instead attack a service on the honeypot. Self-propagating malware (e.g., Phatbot, Agobot, or Spybot) uses attacks on various services to infect new systems. If a malicious program interrupts the attack after the first successful infection attempt on a simulated service, the genuinely vulnerable services might not be attacked. In this case, an infection of the production systems might be prevented through the simulation of individual services. On the other hand, it is possible for simulated services to be detected by individual attackers, and the attacker might then switch to another service as a result. In this case, the manual attack might be successful, but it would still be detected because of the previous attack on a simulated service.

Honeypot Disguise

However, if an attacker detects an atypical combination of available services on the target system, they might assume that they are looking at simulated services or a honeypot. If the attacker is unable to distinguish simulated from real services, they might just give up. This in turn increases the security of the systems because the attacker does not gain access to them. On the downside, it reduces the amount of information about the respective attack because only the scan of the individual simulated services is registered.

To prevent a manual attacker identifying simulated services because you have the same set of services available on different systems, you can vary the services simulated on the different systems. To do so, you can configure different services for different host systems centrally on the analysis component. Now, a manual attacker can no longer distinguish simulated services on the basis of different systems having a similar subset of services. This tactic increases the probability that an attack on a simulated service will be carried out and that more attack details can be registered on top of the intrusion detection results. In contrast to a dynamic honeypot approach, the appearance of the honeypot is not adapted to match that of the production systems; instead, the appearance of the production systems varies.

HoneypotMe in Action

The Fraunhofer Institute for Communication, Information Processing, and Ergonomics (FKIE) develops and operates various honeypots for automatic detection of malware on the Internet in collaboration with the Institute of Computer Science 4 at the University of Bonn, Germany. Detection of malicious code by honeypots reveals that the extent to which malicious programs propagate through various networks can differ widely. At the same time, honeypots often detect propagating malware within their own networks with a higher probability (Figure 5).

Figure 5: Proportion of all registered attacks from Germany with existing sensors.

The reason for this is that malicious programs often do not search the Internet randomly for vulnerable systems but prefer to attack systems on their own subnets. To achieve as differentiated an overview of current malware as possible, it is necessary to operate honeypots on different networks. Although the two institutes have IP addresses on different networks, they are used by production systems and are therefore not available for deploying dedicated honeypots. However, because the live systems usually only serve up a few ports for production use, it is possible, using HoneypotMe, to forward the free ports to existing honeypots for analysis.

To increase the visibility of the existing honeypots, HoneypotMe was deployed over a period of one month on four regular production systems at the University of Bonn, each of which was directly accessible from the Internet. Evaluation of the registered attacks has shown that the frequently forwarded ports belong to services typically used by malware to infect new systems (Figure 6).

Figure 6: Registered attacks on various ports of production systems at the University of Bonn courtesy of HoneypotMe.

All told, some 3,448 of 25,149 connection requests were successfully processed and analyzed with the use of honeypots. In the case of other connection attempts, the ports were either just tested, or the requested service was not supported by the honeypots. In the case of successful connections, it was possible to log detailed information about the attempt, whereas in other cases, only the attack itself was registered.

Analysis

In further analysis, a total of 8,855 attacks from the within the network of the University of Bonn were detected. This high number of attacks results largely because each attempt to connect to a closed port is considered to be a separate attack. Thus, a single port scan already leads to a high number of attacks. Port scans from three different IP addresses within the university network were registered, each of which was launched in parallel against all four monitored systems. The number of connection attempts per port scan on a monitored system with HoneypotMe was between 11 and 1,180. This example shows that it is possible, using HoneypotMe without additional resources, to register and evaluate attacks on production systems. The likelihood of registering an attack from the University of Bonn network was thus higher than with sensors on other networks.

Conclusions

With the use of HoneypotMe, it is possible to expand the limited visibility of classical honeypots on a wide range of systems, so that larger networks can be monitored completely with honeypots. This approach reveals detailed information about attacks on networks and allows for appropriate countermeasures. Additionally, the use of HoneypotMe directly increases the safety of the monitored systems because it is impossible for the attacker to distinguish genuine ports from ports on the analysis component. Attackers can thus be distracted from genuine vulnerabilities because the vulnerable services simulated by the honeypot on the HoneypotMe system are also shown as available.

In contrast to honeypots on dedicated resources, however, HoneypotMe can only detect attacks that are not carried out against services that are genuinely available. Thus, it is possible that individually targeted attacks will not be detected by HoneypotMe. However, if a network comprises heterogeneous systems with different services, it is likely that attacks on arbitrary ports will be logged sooner or later.

The advantage of the approach presented here in particular is that no additional resources are needed for the use of HoneypotMe. Installing and running the sensors doesn’t require any background knowledge. The use of sensors does not entail any additional security risk for the systems because data packets are only tunneled, without the need to establish or analyze a connection. The individual sensors do not require any updates to detect new attacks because analysis is carried out on the external analysis component.

The analysis component does not need to reside on the networks where the sensors are deployed: You could run the analysis component on a specially hardened network or outsource the task completely to a third party. The analysis component used by the sensors can also be replaced, so that analysis components can be customized for the required application.

Info
[1] AV-TEST Institute