A General Honeypot Tutorial

[alphabetarian]

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...

alpha


----------------------------
A General Honeypot Tutorial

by: alpha
alpha_betarian@yahoo.com

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.
------------------

[saintakaagni]

nice one i read only some i will tell you comment after reading it fully

[reuben911]

nice tut. ........but i think someone needs to learn how to write some paragraph forms or double space lines!!


it was hard to read!

[Soda_Popinsky]

Thats because you need to read it with wordpad or another rich text compatible viewer.

BTW good tut, I recommend Honeypots by Lance Spitzner for further reading.

edit: just realized you included Honeypots by Lance Spitzner in your works cited. Nonetheless, still good to read for more in depth research.

[alphabetarian]

Sorry 'bout that folks... didn't realize the wacky formatting when I posted it. Note to self: when writing tuts, stick with the same editor.

Anywho, I pasted it into the main body of the original thread and kept the original attachment on there. But if you're reading this, chances are, you already figured that out. :-) Hopefully it's a bit easier to read now.

alpha

[TheTempest]

Hey,

According to DMCA arn't honeypots illegal? Isn't that why the main site was moved outta the US?

[alphabetarian]

I haven't heard anything lately about the exact legality of honeypots, so I couldn't tell you for sure. The whole article spawned from an indpendent study course I did on honeypots last year, in which I used Honeyd, by Neils Provos. At the time, he was a Ph.D student at the Univ. of Michigan and the state gov't passed some DMCA-in-nature law where software that hid it's original source was illegal. Honeyd, through the help of arpd, would take over unused IPs on a subnet and pretend to have actual machines sitting behind those unused IPs. I think that's what caused him problems, so he had it moved of shore for a little bit, but I'm not sure what's going on with it now. Aside from that, that's the only DMCA-ish problem I've ever heard of regarding honeypots. But granted, I've been bad and haven't looked into them in a while.

So, long story short, I'm not sure. I'll google it and report back...

alpha

[qod]

i like the tutorial, although i would like to see some tutorial that goes deap and not just repeat what was said in some other articles. How does it work, what are there pros/cons, why should i use them, how to set them up, etc...

[minasbeede]

Originally posted here by alphabetarian
I haven't heard anything lately about the exact legality of honeypots, so I couldn't tell you for sure. The whole article spawned from an indpendent study course I did on honeypots last year, in which I used Honeyd, by Neils Provos. At the time, he was a Ph.D student at the Univ. of Michigan and the state gov't passed some DMCA-in-nature law where software that hid it's original source was illegal. Honeyd, through the help of arpd, would take over unused IPs on a subnet and pretend to have actual machines sitting behind those unused IPs. I think that's what caused him problems, so he had it moved of shore for a little bit, but I'm not sure what's going on with it now. Aside from that, that's the only DMCA-ish problem I've ever heard of regarding honeypots. But granted, I've been bad and haven't looked into them in a while.

So, long story short, I'm not sure. I'll google it and report back...

alpha

I tihnk the notion about the possible bad legal ramifications of honeypots came from just one guy (federal employee, a lawyer), whose name I don't recall. His proposed scenario was that an abuser would use a honeypot to commit abuse that damaged someone else and that the operator of the honeypot would be liable. He didn't say how that was worse than the potential liability of the operator of a vulnerable system that got abused nor did he say how it was that a honeypot (which if effective would not allow abuse, even though it might look to the abuser as though it did) would be abused. I sort of suspected at the time that he was deliberately trying to make people fearful of honeypots. If so, it worked.

Note, too, that honeypots don't have to be general: they can be for specific abuse on specific ports (such as Jackpot, or the Bubblegum proxypot.) Those would be much harder to abuse. If the abuse is a spammer then he's simply trying, in a bulk fashion, to find systems he can abuse to send spam. He's not being sophisitcated or spending a long time checking out the system, he's just looking for what looks like it an be abused. (As an aside, it's really fun to fool somene who thinks he's fooling you.)

I have seen Jackpot relay email that it shouldn't, so I eventually configured mine (I no longer run it) to deliver nothing. For an open relay honeypot (which is what Jackpot is) the real power can come from relaying the test messages the abuser-spammer scatter-sends throughout the internet. He knows from the ones that get delivered which IP addresses are the open relays. I've seen many ways of indicating the tested IP address in the message, both in plaintext (xxx.xxx.xxx.xxx) and encoded in some way, for example in the Message-ID, in decimal ASCII. Sometimes they wer edouble-encoded, but not in any way pareticular hard to decipher. Probably the spammer woul djust collect all the test messages he received and use a search program to pick off a unique string (like "Message-ID") and then decode the IP addresses using a simple program.