Intrusion detection honeypots are just plain cool. They’re incredibly simple to run and give you extremely accurate alerts about intruders in your systems.

A honeypot can be as simple as a fake server inside your network that alerts if anyone connects to it. There’s no reason to intentionally connect to this bogus server, so any attempts are probably an attacker already inside your network.

Unfortunately, that’s about as far as most people get with them. It’s a shame that so often honeypots get written off as just a novelty—no more than a neat trick to catch pentesters. Most people miss the point behind honeypots.

In fact, honeypots just scrape the surface of a really powerful detection tactic—the “this should never happen” alert.

Mapping out the usage patterns

Before you can write a “this should never happen” alert, you first need know what actually does happen in your system. This boils down to threat modelling: how do real users interact with your system and how could attackers abuse it?

There are many ways to do threat modelling but here we’re going to think about usage patterns: the different things users can do and how likely they are to do them. Taking the example of an SSH server, you might end up with something like this:

Along the x-axis we’ve put the various interactions someone might have with the server. On the y-axis there’s how often we expect to see that behaviour. It’s a bit of a stretch to draw this as a line graph—there’s no real relation between adjacent points—but it’s a useful mental picture.

But, let’s keep things even simpler and focus on how three specific features get used:

  • Public-key auth. All of our users should be logging in with SSH keys. On the other hand, if an attacker is able to steal an SSH key they’re also likely to use it.
  • Password auth. We don’t expect a real user to try passwords—none of them have password authentication enabled. But, an attacker will probably try some default or phished passwords.
  • Port-forwarding. Both our real users and attackers are likely to use this.

If you’re tasked with detecting malicious use of this SSH server, where do you start?

Your instinct might be to start with alerting on events that could actually cause damage. Logging in with a stolen SSH key, or using port-forwarding to spread laterally both get an attacker closer to their goals. Makes sense you’d want to detect this.

But, trying to build good alerts is going to be tough—these are the things our real users are most likely to do too.

Detecting just the bad SSH logins without flagging lots of real user logins is going to be tough. Here be machine learning dragons!

Why not start with alerting on failed password authentication attempts instead? Failed password attempts are fairly harmless, so it’s natural to ignore them, but there’s a lot going in their favour:

  • You don’t need to care about false positives—real users should always be using an SSH key.
  • An attacker is pretty likely to try using a default or phished password to login.
  • It’s dead simple to alert on. We don’t even have to look at the details of the log event, just its existence is cause for alarm.

The fact that a real user should never cause a failed password login event is exactly why its useful. Anyone that fails a password login is probably an intruder bumbling around not realising that everyone uses SSH keys.

I think this is the first tactic to learn from honeypots:

🍯
It’s hard to spot an attacker in a sea of real users. Instead, detect the things that only an attacker would do.

Honeypots manipulate usage patterns

Alerting on failed password authentications is useful but isn’t perfect. If an attacker stays within the normal behaviour of our users, they’ll never hit one of our “this should never happen” tripwires.

Unfortunately, we’re limited by the usage pattern of our real users, and it doesn’t look like there’s any more natural “this should never happen” opportunities in our SSH server.

This is where we could deploy a honeypot. Rather than opportunistically looking for “this should never happen” situations in actual systems, honeypots just create their own. They let us conjure systems that real users never use but where an attacker is likely to go poking around.

The usage patterns for a honeypot SSH server. Expected malicious usage is unchanged but expected legitimate usage is now almost non-existent.

We can alert on almost any activity from an SSH honeypot. Because the honeypot serves no use, we never expect a real user to login, and certainly don’t expect any port-forwarding. Apart from an occasional health-check, any events we see coming out of this server are worth investigating.

But, on it’s own, a system without any user activity isn’t interesting—it’s easy to deploy a useless server that no one ever interacts with. A honeypot’s trick is to be useless while still making an attacker think it’s a useful. The more important it seems, the more likely an attacker wants to go explore it.

By using deception, the honeypot has a completely different malicious usage pattern from its expected usage pattern. This difference gives us maximum opportunity to write “this should never happen” alerts.

This then is the other tactic to learn from honeypots:

🍯
Usage patterns are flexible—by employing deception, you can shape them to create opportunities for high quality alerts.

So… just deploy honeypots everywhere then?

While you could start deploying honeypots all over your network, actually I think straight-up honeypots are a bit of a novelty. Instead, it’s the honeypot tactics that are far more useful than honeypots themselves. Create a situation that should never legitimately happen and then alert if it does.

Why just deploy a honeypot SSH server when you could apply honeypot tactics to all your real SSH servers too?

Further reading