My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Should I setup a Honeypot? [SANSFIRE]

Published: 2014-06-30. Last Updated: 2014-06-30 15:28:48 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

During last weeks ISC handler panel at SANSFIRE, we had a lot more questions then we could answer. So I am trying to post some of these questions here over the next few days/weeks and please, chime in and give your answers as well. The questions will use the tag "SANSFIRE" and will also be labeled as such in the subject.

The first question we got: "How would one justify to management that setting up honeypots on the network is a good idea?"

The goal of having a honeypot is to learn more about your attackers. A honeypot will only see malicious traffic, making it easy to spot attacks. you can use data from successful attacks against a honeypot to derive indicators of compromise that are then used to detect similar attacks against business systems. Without the honeypot, it would be very difficult to spot these attacks due to all the other traffic a business system sees.

First of all, if you do setup a honeypot, make sure you do so correctly. The last thing you would like to have happen is to have the honeypot pose a risk to your network. Overall, there are a number of different kinds of honeypot. You could setup a "full interaction" honeypot. This is usually a vulnerable host complete with operating system and respective software. These full interaction honeypots do need a lot of care and supervision. They can easily be turned against you. If you decide to set one up: Don't make it too vulnerable. Configure it similar to your production system. The goal is not to find "any" attacker, but attackers that matter.

As an alternative to a full interaction honeypot, you may want to consider a medium-interaction honeypot. These honeypots simulate vulnerable services. They are a lot easier to maintain and generally safer. One such honeypot we discussed in the past is kippo, which simulates a vulnerable ssh server. The problem with these honeypots is that they are easily spotted by a sophisticated attacker. But they do allow you do collect malware attackers upload (so you can search for it on other systems).

Lastly, and in my opinion one of the most useful honeypots, are what some people call "honeytokens". Instead of dedicating a machine to the task of being a honeypot, you add little trap doors to existing applications. 2-3 such trap doors can do a good job identifying attackers who go the extra mile and do some manual work, vs. just running nmap/nessus and similar tools against your site.

Anybody here has a success story how data collected from a honeypot became useful?

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

2 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

Once upon a time, at a previous job, I ran LaBrea on a handful of IPs (authored by one of the handlers, as I recall), and though it's not a honeypot, as such, it did prove useful as an early-warning system. I don't recall it's name now but I'd stumbled across a bit of perl CGI that would turn the LaBrea logs into daily/weekly bar-charts showing what ports were the most active during which times in recent hours/days. Basically, if I saw a spike in activity for a particular port (a port someone was portscanning for), I'd find out what services used that port and sure 'nuff within a week or two there'd usually be some patch announced for that service fixing some security hole. If we had any systems with that service, I'd watch them a bit more closely for a while.

File it under "there is never enough intel". So, as long as you can keep your honeypot from being turned against your network (or someone else's), it will very likely provide at least some useful intel, even if it's nothing more than "what's being attacked this week". :-)
Keep it simple at first. Start off on your internal network. Scatter some cheapo Linux systems around on critical subnets and set iptables rules so that if anything touches them at all, syslog sends an alert to a monitoring server. They should not respond to pings, have DNS entries, or anything at all.

You'll have to set a few ignore rules for normal ping-the-world monitoring servers but that's it. If nothing is supposed to connect to them, nothing should. And if anything attempts to, even with a single ping, it needs investigated.

On just about every internal pen test, these are the boxes that pick up the attackers and well before the fancy IDS stuff. And usually a day or more sooner. Make sure you have some on the same subnet as your DNS servers/DHCP servers/domain controllers and you'll catch them every time as they try to slowly explore the network.

The only real drawback is that the Windows admins will usually ping an IP to see if it's in use. No response = free to use in their mind. The correct way is to log into the switch and check the ARP table.

Diary Archives