Wireless Honeypots Created by: Sponsored by: Final Documentation Volume 2 Product and Process Documentation April 25, 2005
Product and Process Documentation Introduction A honeypot is a node on a network whose purpose is to provide an environment designed to entice intruders. Once the intruder has been enticed and hacks into the honeypot, all of his or her actions are logged at kernel level. These logs are incapable of being altered by the intruder and they are a useful tool for analyzing the intruder s hacking techniques. They may also indicate the intruder s interests in the honeypot system and thus be a basis for improving security in other nodes on the network. Product Objectives The biggest objective for this product was to create a stand-alone wireless honeypot. This kind of product does not exist on the market today and it is part of an extremely cutting-edge technology. The product also needed to be portable and platform independent, so to meet these requirements our team re-mastered Linux and made it available on a bootable live mini-cd. To meet the wireless capabilities of the honeypot, an ordinary computer had to be turned into a wireless access point. In addition to this, the honeypot environment had to be enticing and authentic enough to capture the intruder s attention, but at the same time it had to limit the intruder s capabilities of launching attacks from the honeypot onto the network or compromising the honeypot itself. Multiple scripts were written in order to re-create a real environment but with very limited capabilities. Finally to be able to use the honeypot as a research tool as well as a deterrent, all activity on the honeypot, meaning all key-strokes, is logged. Product Process First and Second Draft Designs The first idea for creating the wireless honeypot was to use a wireless router with 4 computers to turn then into the honeypot. The plan was to modify the firmware on the router, creating a false file system, and using three other computers to become the honeypot system. One of the computers would run the freeware honeyd honeypot, another would do all the logging, the third would be the (IDS) Intrusion Detection System and the fourth would be a gateway to the internet. Shortly after some reanalysis, it was found that only 3 computers would be necessary because the router would be enough to be a gateway to the internet. The way these components would interact would be to allow only one was traffic from the router to the honeypot. Logging would also only be one way, all activity from the honeypot would be logged, but there would be no access from the honeypot to the logger or from the router to the logger. Also, the IDS would act as a logger and detection system to monitor for intruders on any of the 3 computers. After spending numerous weeks on this design it was thrown out for a couple of reasons, one of the reasons being the size of the physical honeypot since it required 3 computers and a router. The second reason was the inability to modify the router firmware as it is a read-only file system, resulting in an ineffective system. Figure 1 on the next page shows an example of the second draft design. TheHive-FDR-vol2 Page 1 of 5 4/24/2005
Production Network INTRUDER Internet Router (handles authentication) Logging Server HONEYPOT IDS (Snort) Figure 1: Second Draft Design Third Draft Design After more extensive research and brainstorming a third and final solution was developed. Instead of using many different computers as components in a honeypot system, it became more logical to create the stand-alone wireless honeypot in a customized operating system and bootable from a live mini-cd. This honeypot would have the honeyd freeware, logging capabilities, arpd and dhcp, HostAP and NIC all in the same operating system. Please refer to Figure 2 for a structural representation of the third draft design. Having found the honeyd software as the basis for the honeypot, the next step was to decide on an operating system to host its environment. Several operating systems were tried, each was ineffective for some reason, Knoppix STD was too large and required to many files to be removed to scale it down enough, DSL Linux was not good either because it did not run well on the computers that were used. Eventually Feather Linux was settled on and it was stripped of all unnecessary functions, files, executables, etc. It was scaled down to the bare minimum. The next step was to write scripts for the honeypot to control the intruder s actions by limiting their ability to move around in the file system or to create/destroy any files. Scripts for SSH, telnet, pop3, and HTTP were written and each script was mapped to the respective port number. Thus when the intruder attempts to log into the telnet port or the HTTP port, the respective scripts will be run on those ports instead of the actual applications. Please see Figure 3 for a flowchart of the intruder s movements through the honeypot and the different scripts that could be accessed. TheHive-FDR-vol2 Page 2 of 5 4/24/2005
DHCP Honeyd HostAP + Wireless NIC Sebek/syslogd Flash Drive OS Applications Hardware Figure 2: Third Draft Design TheHive-FDR-vol2 Page 3 of 5 4/24/2005
Intruder port scan of Honeyd IP Honeyd logs scan Runs script associated with port Port Path SSH/Telnet (Port 22, 23) POP (Port 110) HTTP (Port 80) Run authentication script Run POP3 emulation script Log commands Show spoofed webpage Log commands Authentication Authorized Denied Log attempted user names and passwords Read commands from attacker Self shutdown OR Intruder stops browsing Figure 3: Flow Chart TheHive-FDR-vol2 Page 4 of 5 4/24/2005
To create the wireless capabilities a Network Interface Card (NIC) was used in connection with HostAP to spoof wireless network traffic. HostAP is a freeware application that sends out beacon frames which imitate packets on a real network, thus transforming out NIC into an access point where an intruder may think he is on an actual network. In addition, DHCP spoofs IP addresses which also helps to make the wireless access point look more authentic, but also allows the intruder to believe its authenticity since it will allocate an IP address for the intruder to connect into when he or she request a connection to the honeypot network. Through these applications the honeypot becomes a wireless honeypot. With the aid of Sebek and Syslogd, logging is available on the honeypot. The logging is set up at the user and kernel levels and all logs are stored on an external flash drive. The drive is mounted, the logs are saved and backed up on the flash drive, and then the drive is demounted. It is practically impossible for the intruder to detect the mounting and demounting of the flash drive, thus it is the safest way to store the logs without allowing them to be compromised. Conclusion To create the product, the design went through a few extensive design stages. With each new implementation, the design became more accurate, simple, and precise. All of the above listed components combine to create the product, a wireless honeypot. Without one of these components, the honeypot would either be useless or it could be easily compromised, thus all need to be present and work together to create the final product. TheHive-FDR-vol2 Page 5 of 5 4/24/2005