A General Honeypot Tutorial
Well, here it is... my first crack at a tutorial. Thought it was about time I gave back to the AO community.
It's a general honeypot tutorial which has been a work in progress for while, so I apologize if the info is a bit dated. As mentioned, I was going to submit it to 2600 in hopes of it being printed, but I felt it was better suited for AO instead. Didn't find any other honeypot tuts through a quick search, so if this has already been covered, sorry.
Feedback is always appreciated...
A General Honeypot Tutorial
Originally, this was written as a repsonse to an article in 2600 that I saw and didn't think did justice to honeypots. Upon closer inspection, I decided that, judging by the way it was written, it was more suitable for the AntiOnline crowd. I'll try and grace 2600 with a different article. Most of my information for this little tutorial came from a book entitled, "Honeypots: Tracking Hackers" by Lance Spitzner. Those interested in the honeypot field should check it out as it is an excellent, excellent book filled with a wealth of information. It's also a great place to start out from.
What exactly is a honeypot you ask?? According to Spitzner,
it is "a security resource whose value lies in being probed, attacked or
compromised (p. 40)." In other words, it's a machine you want to be attacked so
you may look over the logs, or any other data generated by the attack, in an attempt to learn exactly how the attacker got in and what techniques he/she may have used. Now, there are many different kinds and classifications of honeypots, but
they all have at least one common trait. Honeypots have no production value so no
communication should be taking place with them. Therefore, anything that does
go their way, should be questioned. Most likely, it's a scan, probe or attack
of some sort. It may also be possible to install a packet sniffer on the physical honeypot machine in order to see the actual keystrokes of the attacker. If it is, then not only would you know that something is happening, you'd know exactly what. I'm not totally sure on that though.
Honeypots are grouped by the amount of interaction they allow the attacker to
have, either low, high, or medium. Low interaction honeypots are generally
port listeners which occasionally emulate, but do not provide, actual services. Usually, there is little risk, both to other networks and the network on which the honeypot
resides since there is nothing for the attacker to truely
interact with, just a script pretending to be an actual service.
High-interaction honeypots tend to offer actual operating systems for the
attacker to interact with. As you can see, the amount of risk high-interaction
honeypots produces is great, so they are most usually in some sort of controlled
environment. Usually, this environment is behind a firewall which allows attackers to compromise a
honeypot sitting behind it, but does not allow the attacker to
attack other machines from the honeypot (Spitzner p. 82). Medium-interaction
honeypots fall into a grey area between its low and high interaction
counterparts in that they are home-made and not some off-the-net/out-of-the-box
pre-made solution. Medium-interaction honeypots can range from a simple port
listener created with netcat listening on a particular port to a complete Red Hat 9.0 machine just sitting on
a network somewhere waiting to be attacked. Basically, these types of
honeypots are built and completely customized by those who will be administering them.
An example of a low-interaction honeypot is one called Back Officer Friendly
(BOF). Originally written to listen for Back Orifice attempts, BOF would listen
on port 31337 and pretend to be a machine infected with the BO trojan. As time
passed, capabilites to listen on other ports, like FTP, telnet, and SMTP, were added. As of this writing, BOF is currently capible of listening on seven ports. Honeypot software called ManTrap is an example of a high-interaction honeypot and runs on Solaris machines. ManTrap runs on top of the operating system and creates up to four exact, yet seperate, copies of the operating system with each copy being unaware of the others. Each copy acts as a cage, which contains the attacker and records all of his/her actions. Records of the events are sent to an administration GUI where the logs of all the cages/copies can be viewed.
But what can a honeypot do for me, you ask? Think of this. Firewalls have the
have the wonderful ability to create upwards of gigabytes of data per day,
containing entries of both hostile and non-hostile activity. Honeypots, since
they have no production value, should not get any traffic at all. The traffic
they do get, not only is significantly less, but is also automatically
questionable. Say a Linux honeypot mimicing a webserver was compromised. You
have the log entry generated by the honeypot, along with the offending IP. Now you can reference the date and time of that event with the firewall to significantly narrow your search of the event in the firewall's log. Once you know what it looks like in the
firewall, you can then look for other potential attacks against your actual
webservers from the same offending IP. You then can also see what kind of other traffic is coming from that offending IP to your network. Same ideas holds true for desktop/workstation machines, and other machines of value, as well. Obviously though, the honeypot must mimic the production machine either exactly, or as close as possible in order to look like an actual machine of value.
However, the most valuable purpose a honeypot has is research. Honeypots are
currently used to learn the tricks and the trades of the black-hat "hacker".
They also can catch previously unknown, day-zero, exploits in the wild and
discover vulnerabilites that they exploit. In January 2002, a ManTrap honeypot running on Solaris discovered a previously unknown exploit in use targeting the dtspcd service.
More recent than that, in April 2003, an exploit against Samba was discovered
by a machine that was "essentially a honeypot (Lemos)." While some people are figuring out ways to break into systems and developing tools to do so, others are figuring out how the first group got in, and are developing tools to aide them in this process. Honeypots happen to be one of them.
As wonderful as honeypots may seem to some, a huge legal and privacy debate
rages on. It isn't quite clear where honeypots fall in terms of
legality in the United States. Our legal system here in the U.S. is based on
precedent, and since honeypots have only recently begun to gain popularity,
there currently is no precdent that I know of. Entrapment is also a concern
among some, but since entrapment involves getting someone to committ a crime
they otherwwise would not have, and crackers are most likely out looking to
break into something anyway, an entrapment defense might not work. However, I'm
no lawyer (thank god!!), so talk with someone who is before deploying one.
On the other hand, honeypots spark an intense privacy debate as well.
Here, honeypots may also fall under various other laws like the Fourth Amendment
of the U.S. Constitution, The Wiretap Act, The Pen/Trap Statue, and the Electronic
Communications Privacy Act (Spitzner p. 372 - 376). A major concern among some
is that attackers, once they break in to a honeypot, may not know that they are
being monitored. Apparently, they would then go chat with their buddies and others, on IRC or whatnot, thinking they have secure communications. Suggestions have been made to add disclaimers on log-in screens that basically say "On this system, you'll be monitored and by logging in you agree to let yourself be monitored" so that attackers may have a
chance to know that they're being monitored. But like I said earlier, for you security professionals out there, consult a laywer before deploying a honeypot on your organization's network. It could save you a mess of legal headaches later on.
Honeypots are available to install on a wide variety of operating systems, including Windows, and the various Linux and Unix flavors. They are quickly gaining popularity in many organizations and I am sure that we will see them again in the near future. Soon, deceiving a potential attacker will be just as important as detecting and preventing one. Like anything though, in order for them to operate with maximum efficency, they must
be carefully maintained and administered.
** Works Cited **
Lemos, Robert. "Honeypots Get Stickier for Hackers". CNET News.com
http://news.cnet.com/2100-1009-996574.html. April 11, 2003
Spitzner, Lance. "Honeypots: Tracking Hackers" Addison-Wesley. 2003.