1 ECE 4112 Internetwork Security Lab 7: Honeypots and Network Monitoring and Forensics Group Number: _______________ Member Names: _________________________ _________________________ Date Assigned: February 24, 2009 Date Due: March 3, 2008 Last Edited: October 29, 2007 Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions and be sure you turn in ALL materials listed in the Turn-in Checklist ON or BEFORE the Date Due. Goal: To understand the concept of a Honeypot and how it can prove useful to administrators and network professionals when correctly implemented inside their network topology. Also covered in the lab is he concept of Forensics, which is a way of looking at data you’ve collected in order to find out what sort of exploit was run on your machine. Summary: In this lab you will first set up a couple of different honeypots, one on Windows and then one on Linux, to monitor network traffic and look for anything suspicious. You will also use snort to log data and as an Intrusion Detection System. On the forensics side you will examine a few files of captured data from real attacks and see if you can find out what was going on. Finally you will look at a forensic tool and see some of its uses. Background and Theory: Honeypot What is a honeypot? A honeypot is a system whose value lies in being probed, attacked, or otherwise taken advantage of by a blackhat. This idea may sound somewhat counterintuitive at first; why would we want to give one of our valuable systems over to the other side? [1] The answer to this question depends on what we are trying to accomplish. Spitzner classifies honeypot solutions into two broad categories: production and research. For research purposes, we simply want to collect as much information on our attackers as possible. Production systems are generally used as an added layer of network security. The value of any network security device can be quickly disseminated when one considers the three keys to network security: prevention, detection, and response.2 Consider “The Burglar Alarm Analogy:” Deadbolting your front door is a way to prevent thieves from entering. A security alarm can detect that thieves got past the deadbolt indicating that the preventative measures were not successful. With any luck, your system dials the police who then respond by showing up at your house with guns blazing. [1] A honeypot is the electronic equivalent of an unlocked door, so we can’t expect it to add much to the protection layer. It is in the detection of unwanted intruders that a honeypot adds the most value. There is one important reason for this. A honeypot, by definition, should have no legitimate traffic. Consider how much information an IDS system has to sift through, or how many packets are seen by your router or firewall in one day. Entirely too much to sit and watch go by on the wire. If you’re hacked, it will be nearly impossible to find the source of the attack with these more conventional network security devices. A honeypot, on the other hand, will collect very little information over the course of a day, but it’s likely that all of that information has some sort of value to a network administrator. Later in the lab you will see how versatile a honeypot can be in collecting data, whether one is just looking for source and destination ports of scans on their network or want to capture the keystrokes and tools of an attacker for further analysis. [1] The value added by a honeypot to the response layer of network security (which can be significant) is beyond the scope of this lab. There are numerous whitepapers available on the Internet for those who find themselves interested in the subject. [1] Appropriate websites are listed at the end of this lab. It’s fairly easy to see how a production honeypot might help a company who has been the victim of past attacks, and how a research honeypot might help the security community to analyze the tools and tactics of the blackhat community. What remains to be seen, however, is what sets the two categories apart in terms of the construction, functionality, and topology of the honeypot systems we’d like to deploy. [1] Traditionally, production honeypots are thought of as simpler and more intuitive than research honeypots, and rightly so. Most network administrators care less about the tactics employed by a hacker and more about the immediate security concerns of their network. A primary goal of a production honeypot, then, is to provide an alert that something might be amiss [1]. This affords system administrators the freedom to select from several commercially available (and sometimes free) honeypot solutions. Examples of such solutions that are currently available include BackOfficerFriendly, Specter, and honeyd. Spitzner classifies these three tools as “low-interaction” honeypots [1]. When we define a honeypot as low interaction, we are referring to how much operability we plan to leave on the victim box for an attacker to play with. Consider the BackOfficerFriendly program, which we will be installing and running for the first exercise in the lab. BackOfficerFriendly can simulate only six services, gathering very little information beyond the source IP and source port that attempted to connect to the ports associated with these services. An attacker cannot break into this system, download his tools, set up3 an IRC channel, share the secrets of his dark brotherhood, etc. – but this is alright. A low interaction honeypot like BackOfficerFriendly will still provide an administrator an indication of trouble on his network, and often this is all that’s necessary. Research honeypots, on the other hand, are often homemade solutions that can track an attacker’s actions down to the keystroke. Network security professionals and educational institutions often employ research honeypots in the hopes of seeing a hacker in action. A honeypot that is to be used for research will often contain a fully