Download Lab 7

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 operational
operating system running certain services and vulnerabilities. Generally, this type of
honeypot is much more difficult to configure and requires more time for upkeep. Also,
research honeypots that utilize fully operational operating systems can be dangerous – a
skilled attacker is as likely to route successive attacks through our honeypot as any other
system that he might compromise [1].
We can see that there are tradeoffs between production and research machines.
These tradeoffs can generally be summed up as follows: the more functionality we build
into a honeypot, the more useful data we can collect. The more data that we collect, the
more likely it is that our honeypot might be used for nefarious purposes. Administrators
must be careful when placing a honeypot onto their network. A careful survey of
network topology and configuration options on the honeypot itself is imperative. Placing
a vulnerable machine in a production network could lead to understandably disastrous
results [1].
What can we do when we want to collect a lot of information on a hacker, but are
concerned that he might use our honeypot as a platform from which to launch further
attacks? Used in conjunction with a firewall and/or router, research honeypots can be
made considerably safer. To illustrate this as well as some other points that have already
been discussed, consider the following configuration [1]:
INTERNET
Firewall
Web server
Sniffer
Honeypot A
Management
Firewall
Log server
INTERNAL
NETWORK
Honeypot B
3