Download Lab 7

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 up
an IRC channel, share the secrets of his dark brotherhood, etc. – but this is alright. A low
2