| |
Build A Honeypot
Lance
Spitzner
This article is a follow up to the "Know
Your Enemy" series. Many people from the Internet
community asked me how I was able to track black-hats in
the act of probing for and compromising a system. This
paper discusses just that. Here I describe how I built,
implemented, and monitored a honeypot network designed
specifically to learn how black-hats work.
What is a Honeypot?
For me, a honeypot is a system designed to teach how
black-hats probe for and exploit a system. By learning their
tools and methods, you can then better protect your network
and systems. I do not use honeypots to capture the bad
guy. I want to learn how they work without them knowing they
are being watched. For me, a well designed honeypot
means the black-hat never knew he was being tracked.
There are a variety of different approaches on how you can do
this. Mine is only one of many.
Before I continue, I would like to post a disclaimer.
First, no honeypot can catch/capture all the bad guys out
there. There are too many ways to spoof/hide your
actions. Instead of going into detail on how this is
possible, I highly recommend you check out Insertion,
Evasion, and Denial of Service: Eluding Network Intrusion
Detection or fragrouter. Second, keep in mind
that you are playing with fire. Someone far more
advanced then you may compromise your honeypot, leaving you
open to attack. Third, throughout this paper I use the
term black-hat. I define a black-hat as anyone who
is attempting un-authorized access to a system. This
could be an 15 year old kid from Seattle, or a 45 year old
company employee in accounting. Also, I refer to our
black-hat as a he, however we have no idea what the true
gender of the black-hat is.
Where to Begin?
There are a variety of different approaches to building a
honeypot. Mine was based on simplicity. Build a
standard box that I wanted to learn how the black-hat
community was compromising. In this case it was Linux,
but you can just as easily use Solaris, NT, or any other
operating system. Don't do anything special to this
system, build it as you would any other. Then put the
system on the Internet and wait. Sooner or later someone
will find the system and attack it. The system is built
to be attacked and compromised, someone will gain root on that
system, that is the goal. However, while they are
gaining root (or Admin), you are tracking their every move.
This approach is different from other concepts.
Network Associates has built a commercial product called
CyberCop Sting, Designed to run on NT, this product can
emulate variety of different systems at the same time,
including Linux, Solaris, Cisco IOS, and NT. Fred Cohen
has developed the deception toolkit, which are a variety of
tools intended to make it appear to attackers as if a system
has a large number of widely known vulnerabilities. One
of my favorites is NFR's BackOfficer Friendly, which emulates
a Back Orifice server. All of these have their
advantages. However, my goal was to build a honeypot
that mirrored my production systems, so I could better
understand what vulnerabilities and threats existed for my
production network. Also, the fewer modifications I make
to the honeypot, the less chance the black-hat will find
something "fishy" on the box. I do not want the
black-hat to ever learn that he was on a honeypot.
The Plan
My plan was simple. Build a box I wanted to learn
about, put it on the network, and then wait. However,
there were several problems to this. First, how do I
track the black-hats moves.? Second, how do I alert
myself when the system is probed or compromised? Last,
how do I stop the black-hat from compromising other
systems? The solution to this was simple, put the
honeypot on its own network behind a firewall. This
solves a variety of problems.
- First, most firewalls log all traffic going through
it. This becomes the first layer of tracking the
black-hat's moves. By reviewing the firewall logs, we
can begin to determine how black-hats probe our honeypot and
what they are looking for.
- Second, most firewalls have some alerting
capability. You can build simple alerts whenever
someone probes your network. Since no one should
be connecting to your honeypot, any packets sent to it are
most likely black-hats probing the system. If there is
any traffic coming FROM the honeypot out to the Internet,
then the honeypot was most likely compromised.
- Third, the firewall can control what traffic comes in
and what traffic goes out. In this case, the firewall
lets everything from the Internet in, but only limited
traffic out. This way the black-hats can find, probe,
and exploit our honeypot, but they cannot compromise other
systems.
The goal is to have our honeypot behind a
controlled system. Most firewalls will do, as long as it
can both control and log traffic going through it.
Tracking Their Moves
Now, the real trick becomes how to track their moves
without them knowing it. First, you do not want to
depend on a single source of information. Something can
go wrong, things can be erased, etc. I prefer to track
in layers. That way, if something does go wrong, you have
additional sources of information. Also, you can compare
different sources to paint a better picture.
Personally, I do not like to log information on the
honeypot itself. There are two reasons for this.
First, the fewer modification you make to the honeypot, the
better. The more changes you make, the better the chance
a black-hat will discover something is up. The second
reason is you can easily lose the information. Don't
forget, sooner or later the black-hat will have root on the
honeypot. Several times I have had data altered, or in
one case, the entire hard drive wiped clean. Our goal is
to track the enemies moves, but log all the data on a system
they cannot access. As we discussed above, our first
layer of tracking is the firewall logs. Besides this, I
track the black-hat's moves several other ways.
A second layer I use is the system logs on the
honeypot. System logs provide valuable data, as they
tell us what the kernel and user processes are doing.
However, the first thing a black-hat normally does is wipe the
system logs and replace syslogd. So, the challenge
becomes logging syslog activity to another server, but without
the black-hat knowing it. I do this by first building a
dedicated syslog server, normally on a different network
separated by the firewall. Then I recompile syslogd on
the honeypot to read a different configuration file, such as
/var/tmp/.conf. This way the black-hat does not realize
where the real configuration file is. This is simply done by
changing the entry "/etc/syslog.conf" in the source code to
whatever file you want. We then setup our new
configuration file to log both locally and to the remote log
server . Make sure you maintain a standard copy of the
configuration file, /etc/syslog.conf, which points to all
local logging. Even though this configuration file is
now useless, this will throw off the black-hat from realizing
the true destination of our remote logging. Now, you
will capture all system logs up to and including when the
system is compromised. This will help tell us how the
system was probed and compromised. It is also very
interesting comparing these true system logs to the logs a
black-hat has "cleaned" on a compromised system. This is
the only time where I make a modification on the honeypot.
The only problem with
using a remote syslog server is it can be detected with a
sniffer. Normally, black-hats either kill or replace
syslogd when they gain root. If so, they can no
longer sniff the syslog packets, since there are no longer any
packets sent. However, if the black-hat does not modify
nor kill the syslogd dameon, then they could sniff the packets
sent. For the truly devious, you could send your syslogd
traffic using a different protocol, such as IPX, which are
normally not sniffed. Your level of paranoia may
vary. There are also several alternatives
you can use to standard syslogd. CORE-SDI has ssyslog,
which implements a
cryptographic protocol called PEO-1 that allows the remote
auditing of system logs. For you NT users, they also have a
Windows version, called slogger.
There is also syslog-ng,
developed by BalaBit Software, which is similiar in use to
ssyslog, but uses SHA1 instead. All versions are free and open
source.
My third layer of tracking (the firewall is the first,
syslogd hack is the second) is to use a sniffer. I run a
sniffer on the firewall that sniffs any traffic going to or
from the honeypot. Since the honeypot is isolated by the
firewall, you know all traffic goes through the
firewall. The advantage of a sniffer is it picks up all
keystrokes and screen captures, to include STDIN, STDOUT, and
STDERR. This way you see exactly what the black-hat is
seeing. Also, all the information is stored on the
firewall, safely protected from the black-hat (I hope :). A
disadvantage is the black-hat can hide his moves with
encryption, such as ssh. However, if you are not running
any such services on your honeypot, the blackhat may not use
them. Also, a sniffer can be spoofed by advanced users, as
discussed by the paper linked above.
In the past, I have used sniffit, a commonly used
black-hat tool used to sniff passwords. It does this by
sniffing the first 300 bytes of every packet. By
configuring sniffit to capture the full payload of every
packet, you can capture all the keystrokes in most sessions.
However, I am now a die hard fan of snort,.
Written by Marty Roesch, it is far more robust and
configurable then sniffit, and can capture packets in tcpdump
and snort format. It also has builtin
IDS functionality, I highly recommend it.
Another idea I am playing with is running proxy servers on the
firewall. That way specific traffic that runs through
the firewall is proxied, allowing for more control and
logging. I'm trying it out now with just a http proxy
server on the firewall.
Finally, I run tripwire on the honeypot (there is also a NT
version). Tripwire tells us what binaries have been
altered on a compromised system (such as a new account added
to /etc/passwd or a trojaned binary). I do this by
running tripwire from a floppy, then storing the tripwire
database to a floppy. You do NOT want any tripwire
information stored locally on the system. By storing it
on removable media, you can guarantee the integrity of the
data. As an added precaution, I recommend compiling
tripwire as statically linked. This way you are not
using libraries that may be compromised on the honeypot.
For the truly paranoid, boot off a floppy such as tomsrtbt,
then run tripwire. This protects against trojaned kernel
modules. Tripwire is an excellent way to determine if
you system has been compromised. Also, it is an
excellent forensic tool that helps identify what modifications
the black-hat has made.
You may find these layers as redundant. But remember,
no single layer of information can capture all the
traffic. Also, different sources give you different
information. For example, most systems cannot detect
stealth scans, however, many firewalls can. If your
firewall logs your honeypot being scanned, but there is
nothing in the system logs, then you were most likely scanned
by a "stealth" scanner, such as nmap. Also, we are not
perfect. Often while tweaking one service, you munge
another. You could accidentally kill system logging or
the sniffer. By having other layers of information, you
still can put a picture together of what happened. If you
develop any of your own methods of tracking, I highly
recommend you implement them. The more layers you have,
the better off you are. If you have any methods
you would like to recommend, I would love to hear from.
Additional methods can include hacking the system shell or
kernel to log keystrokes, but to be dead honest, I haven't
developed the skills yet to do that.
The Sting
Remember, our goal is to learn about the black-hat,
without him ever knowing he was had. To gain a better
understanding of this strategy, I highly recommend you watch
one of my favorite movies, The Sting. We want to attract
the black-hats, monitor them, let them gain root, and then
eventually kick them off the system, all without them getting
supicious. To attract black-hats, I like to name my
honeypot enticing names, such as ns1.example.com (name
server), mail.example.com (mail server), or
intranet.example.com (internal web server). These are
often primary targets for black-hats. Once we have
enticed them, use the methods discussed above to track their
actions.
Once the black-hat gains root, the question becomes, now
what? Normally, I continue to monitor the black-hat for
several days, to learn what he is up to. However, you
have to be careful, eventually the black-hat will catch on
that he is on a honeypot. If he does, bad things can
happen. What I like to do is once I learn everything I
can, I kick the black-hat off, normally by rebooting the
box. I do this with the shutdown command, sending a
message to all logged on users (the black-hat), stating the
system is going down for routine maintenance. I then
take the system off-line, remove the backdoors the black-hat
made, and bring the system back online. Or, you can
reinstall, building a new system. I recommend you fix
the vulnerability that was used to gain access last time, so
you can learn about new exploits/vulnerabilities.
The other issue is limiting the black-hat, we do not
want him launching attacks from our own system. I do
this by using the firewall. Remember, all traffic to and
from the honeypot must go through the firewall. I use a
rulebase that allows anything from the Internet to reach our
firewall, but only limited traffic outbound (basically, the
exact opposite of what a firewall is designed to do).
The trick is, allowing enough outbound traffic so a black-hat
does not get supicious, but we still have to limit their
capabilities. If you block everything outbound, the
black-hat will know right away that something is up. If
you allow everything outbound, the black-hat can blatantly
scan the Internet from your system. You now become
liable for his actions, so we have to find a balance.
Normally the first thing a black-hat does following
access is to download their tool set. If they can't
reach the Internet, they are going to cover their tracks and
leave your system. What has worked for me is to allow
all traffic inbound, and allow FTP, ICMP, and DNS (UDP)
outbound. Normally, this is enough for the black-hat
without them getting supiscious right away, but denies them
utilizing most of their tools outbound. Your
mileage may vary.
Thats it. All that is let left is to wait for the
black-hat to strike (kind of like fishing). Ensure you
have a good alerting mechanism, so you know as soon as
possible when your system is being probed or has been
compromised. You want to get as much information as soon
as possible. You do not want the black-hat to catch on
before you know he is there, bad karma may be coming your
way. Good luck!
Conclusion
Honeypots are an extremely powerful tool that allows you to
learn about the black-hat community. Correctly
implemented, they give you an inside window on how the
black-hat community works. There are a variety of
different approaches to building and implementing a honeypot,
mine is only one of many. My goal is to build a simple
system that mirrors the production network. then sit back and
wait. The key to tracking the enemy is layers.
Do not depend on a single layer of information, as it
can be altered or lost. By comparing different layers of
information, you can also gain a better understanding of what
the black-hat was doing. Happy hunting :)
Author's bio
Lance Spitzner
enjoys learning by blowing up his Unix systems at home. Before
this, he was an Officer in the Rapid Deployment Force, where
he blew up things of a different nature. You can reach him at
lspitz@ksni.net .
|
