Hiding open ports with shimmer

For humans, by humans

Every article on LWN.net is written for humans, by humans. If you've enjoyed this article and want to see more like it, your subscription goes a long way to keeping the slop at bay. We are offering a free one-month trial subscription (no credit card required) to get you started.

Open TCP or UDP ports on an internet-facing host can be worrisome to an administrator, they almost feel like an invitation to an attacker. If an unknown or unpatched vulnerability is running behind the port, the host could be compromised. Admins have come up with some reasonable ways to deflect the simplest of these attacks: changing the well-known port or port knocking. The new shimmer project provides a twist, by using cryptographic techniques to choose the port to open.

The basic idea is that one port (within a chosen range) will be open to real traffic of the service that the admin wants to hide – ssh or a private web server for example. The number of that port will be able to be calculated by both client and server using a secret that they share. A client that connects to the proper port gets forwarded to the real service. In addition to the proper port, 15 other ports are opened and connected to a blacklist service. Any connection made to those ports will result in the source IP address being banned for 15 minutes. The server redoes the calculation each minute, coming up with a new set of 16 ports – one good and 15 bad.

In order to calculate the port number, the shared secret (key) is combined with the time (to the nearest minute), and the name of the service, then hashed using SHA-256. The hash is used as an AES key to encrypt the numbers 0 through 15. Those values are mapped into the port range and serve as the 16 port numbers for that minute. In order to handle small clock variations between client and server, the server actually keeps each set of 16 open for three minutes – adding the set for the minutes before and after the current one.

While this seems like it provides a great deal of security to hide an open port behind, in reality it is more showy than useful. As with simple port knocking, or changing the well-known port number, it is vulnerable to an attacker that can monitor traffic to the server and observe successful connections. Shimmer leaves three ports wide open at any given time with 45 ports that will cause an IP to get blacklisted. Depending on the size of the port range chosen, the odds aren't that bad of randomly guessing the right port. Someone with few thousand IP addresses to use probably won't have any difficulty.

Much like the other techniques, shimmer will likely deflect all but the most determined of attackers, but is unlikely to provide much in the way of a barrier against those. It sounds attractive and uses cryptographic terms and techniques which may make it seem more secure than it really is. Using it without understanding this could lead to a false sense of security.

To me, shimmer and port knocking both seem ridiculous. In the case of shimmer, from what I
understand, you're essentially using a shared secret to create somewhere between 4 and 16 bits
of data (= "the port number"), and sending that to the server as your unencrypted
"authentication". If you want to secure a service, why not just add a real authentication
step? Make a TCP connection, authenticate yourself using the shared key, and then be granted
access. No flashy tricks...

The argument is that using Shimmer reduces the exposure of any bugs in, say, OpenSSH's
authentication code.
But given that OpenSSH uses privilege separation during the authentication phase, and that
using Shimmer adds more code to the application stack, it's possible (probable?) that Shimmer
could increase susceptibility and exposure to attack. Just because Shimmer doesn't exchange
messages over the network doesn't mean its immune to bug exploitation.
It may prove in this case that "less is more" is a more apposite cliche than "defense in
depth".
As for the argument that Shimmer is just obsfuscation, I agree. At best it adds only a few
bits of potential entropy to the access key. As regards better passwords or public/private
keys it hardly compares favorably.
On OpenBSD I just use PF rate-limiting to keep the bots from filling my logs. It's the only
use I have for a packet filter (or traditional "firewall"). Most anything else just adds
additional work for no appreciable gain.

So if I'm an attacker, I just forge lots of different requests from different source IP
addresses (on a network I can still view). The server may "block" some, but that won't block
ME.

I guess shimmer requires a valid TCP handshake before blocking the other 
party. Anything else would be foolish, as you stated.

Didn't anyone see the Denial of service that shimmer could cause?
If a hacker wants to keep someone from using the system (like an administrator), he can just
send forged IP packets to cause the blocker to kick in.

This really just sounds like a (poor) variation on Single Packet Authentication:
http://lwn.net/Articles/224540/

How about a scheme where you would include the source IP into the crypto calculation and
derive a port knocking order which would then open the service port to the source IP?
AFAICS this would beat someone listening in (unless he can connect from the same source
address) and would make a distributed brute force attack more difficult (If you manage to
force the service open, you still have to connect within the time window from the successfull
source ip).

That sounds like a better scheme, yes. Port knocking is less vulnerable to brute-forcing, but
an eavesdropper would be able to just replay the port knocks. Making the port combination a
function of the source IP would secure it somewhat (not entirely -- you still have to
communicate the formula used to derive it!)

Or better yet one could use a solution like SSL-Explorer.