SDN: Where Everything is a Honeypot

Beware the honeypot army!

HP Networking introduced one of their SDN App Store partners to the Tech Field Day crowd at the ONUG spring conference a few weeks ago. If you don't know about ONUG, but you're interested in real-world SDN options and operator experience free of vendor lies, you should probably check out the upcoming fall ONUG conference.¹ 

GuardiCore's Active Honeypot SDN offering really captured my imagination in ways that other SDN demonstrations have failed to do.

The objective is to detect/ensnare an intruder who has already compromised an asset in your datacenter and is now attempting to move on from there. Honeypots are one way of doing this, but the likelihood of an attacker finding the honeypot, rather than a real server with real vulnerabilities is pretty low in a large data center. How can we improve the odds?

The solution assumes that during normal operations, clients know where servers are and don't waste time attempting to connect to services which don't exist. An attacker, on the other hand, will be looking to find vulnerable services, and will probably attempt lots of connections to services that don't exist.

Because the attacker doesn't know where she's going to find the next service to exploit, her attempts will generate lots of TCP segments with the RST (go away!) bit set, something we don't expect² from normal application traffic.

So, lots of RST segments will be flowing toward the attacker from (potentially) all over the network. GuardiCore inserts forwarding rules into physical and/or virtual switches to intercept RST segments and redirect them to a GuardiCore analyzer. Both the interception and the analysis can be widely distributed, possibly into every hypervisor, so that the RST segments might never even hit the real network. This means we can implement the solution on a legacy DC network or on a network full of physical servers (with OpenFlow capable switches).

When the GuardiCore engine receives an RST segment it's got 3 options:

1. Do nothing. The RST will never be delivered to the attacker, making it look like a filtered port on the server.
2. Put the RST back onto the wire for delivery to the attacker. She'll never know anything funny happened in this case.
3. Do magic things I'll describe below.

GuardiCore knows where your honeypots are, and what "services" each is offering. When it concludes that one of your systems appears to be compromised because it is scanning for vulnerable services, three things happen:

1. A NAT rule is inserted into the network near the attacker. The rule rewrites packets belonging to the attempted flow between the attacker and a real system (the one which generated the RST) into a flow between the attacker and a honeypot offering the service the attacker is seeking.
2. A SYN packet is delivered to the honeypot on the attacker's behalf.
3. The honeypot responds to the attacker with SYN/ACK. The NAT rule makes the packet appear to have come from the system which the attacker attempted to contact. The attacker thinks she's found a system to attack.

This is really nifty. The attacker is identified by collecting RST segments from everywhere (a great idea), and then is contained by transforming any/every IP address which the attacker might attempt to connect into a honeypot.

Rather than waiting for the attacker to stumble onto the honeypot, GuardiCore makes sure that the honeypot finds the attacker.

Clever stuff.

---

1 Full disclosure: I think ONUG is great, but one of my pals is a bigwig there, so believe nothing I say about it. ^↩
2 Unfortunately badly coded applications with sloppy socket handling generate lots of RSTs too. There's no question that GuardiCore will find these, but I imagine they've got some filtering logic to ignore these cases.^↩