Tài liệu Risk Management The Big Picture – Part V doc

5 - 1
Information Risk Management - SANS
©2001
1
Risk Management
The Big Picture – Part V
Honeynets and Honeypots
Welcome, let’s take a minute and revisit what we have learned so far. We started out with an
example attack and then focused on one tool that would have given a lot of bang for the buck, a
firewall. If you reflect back carefully on the firewalls and ways to avoid firewalls then you realize
we introduced the concepts of threats and countermeasures. We covered the history of the threat as
far back as 1995 to the most recent type of attacks. Then we began to explore detection, covering
sensors and logging for both host and network-based platforms. Along the way you were introduced
to a number of commands and tools. Have you started working with those? Do you now have
TCPdump, Windump, or Ethereal running on your system? SANS Security Essentials teaches a lot
of theory and teaches you about a lot of things, but that is not the focus of the course. The course is
designed to equip you to face the threat and we cannot achieve that if you do not put the lessons into
practice. You are going to need these tools as we progress to networking, so if not, perhaps it would
be better to go do that, and begin this lesson later.
This segment of risk management, the big picture will deal with honeypots. They are critical to find
and analyze new attacks.
5 - 2
Information Risk Management - SANS
©2001
2
Honeypots
• What are they?
• Why you might need a honeypot
• Example honeypots:
–DTK
–Honeynet

There are a number of technologies that can be used for a honeypot and everyone has a strong
opinion about their approach. Obviously the more sophisticated attackers are only going to be fooled
by an operating system that exactly mirrors what they expect and this includes when they
“compromise” it, the system must fail correctly.
The only honeypot that will work at that level of fidelity is an operating system itself; this is the
approach Lance uses. This is a very advanced and dangerous technique, since the system can easily
be used to attack others. To make his system work, he relies on multiple layers of monitoring and has
modified the syslog facility to do a lot of logging, but not in a way attackers will notice. He has also
modified the operating system shell to log commands to the syslog facility and then monitors
everything with a Snort IDS. Still, when he published his work, the attackers figured out they had
been had and laid waste to the system. This is evidence a few more safety measures would be a good
thing!
5 - 3
Information Risk Management - SANS
©2001
3
Honeypots (2)
• What are they?
– A host trap - they run real services on
a sacrificial computer or simulated
instrumented services, (or fake a core
dump)
– A network trap – the intruder thinks
they found a vulnerable organization
Are there safer alternatives? We will talk about DTK in some depth.
5 - 4
Information Risk Management - SANS
©2001
4
What are They?

• A decoy - if a machine becomes
“hot”, change the IP address and
name and put in a honeypot
• DNS, Mail, Web servers make great
honeypots on their unused ports
Attackers will not succeed in being able to crack it to attack other systems. Of course, smap is not
sendmail and just changing the banner from “smap” to “sendmail” will not fool the wise attacker.
The higher the fidelity of the honeypot, the greater the risk.
Where do you put a honeypot? How do you make it effective? Well to be sure, every IP address gets
attacked - ask any cable modem user. However, there are things you can do to optimize
performance. Perhaps the most effective honeypots are machines that have become “hot”. In such a
case, it is a good idea to move that machine to a new name and IP address, (think “witness protection
program”), and deploy a honeypot on that system’s address.
Domain name servers, mail servers and web servers’ non-service ports make a great place to put
honeypot code.
5 - 5
Information Risk Management - SANS
©2001
5
Why you Need a Honeypot
143
Firewall
The firewall, properly configured, stops this
attack. That’s good. But, you can’t learn anything
about the attack, (if it is TCP), and that might be
bad.
Firewalls impact network traffic. In the slide above, the packet is addressed to TCP port 143, the
IMAP service. If the site does not allow IMAP through the firewall, then there will never be a
SYN/ACK response, the TCP three-way handshake will not complete, and we never know the
attacker’s precise technique or intentions.

If we place a honeypot outside the firewall or allow the traffic through the firewall to the honeypot
on an isolated network, we can collect information as to what the attacker is trying to do.
5 - 6
Information Risk Management - SANS
©2001
6
TCP Three-way Handshake
• A -- SYN Æ B
• A ÅSYN/ACK -- B
• A -- ACK Æ B
No valuable content gets sent until the handshake
is complete. Filtering routers and firewalls block on
at least the SYN packet, ergo no content.
Can you name a situation where you might really
want to know the content of the TCP conversation?
In this slide we see the steps that are required to complete a TCP connection. Take a minute and
think about the question on the bottom of the slide. Many times we just want to block the traffic and
not even think about it. However there might be situations where you would really want to see what
the traffic is. They include:
• The example we discussed when an actual userid or login and password is being used. In this case
we want to know the attacker’s intentions and how much they know.
• When we see a particular system is the focus of lots of probes. This can happen for a number of
reasons. We had a researcher give out the name and IP address of a research system when I worked
for the Navy, and for the next three years probes came from all over the world trying to find this
system. I moved it and put a honeypot in its place.
• When we think a new attack or technique is being used. This would allow us to gain information
about what is being done.