You Can Hide So SOA Won’t Run

As stated in my previous blog entry, one of the best ways to secure SOA services is to hide them behind a port knocking firewall. Port knocking makes your system appear as if it offers no services at all. Any cracker who comes a-knocking’ will either conclude that nobody is home, or that your administrators are smart enough to make access so difficult it’s not worth the trouble to try to break in.

There is an even better way to hide your SOA services so they appear invisible to anyone except legitimate clients. It’s a variation on port knocking called Single Packet Authorization. As a variant, Single Packet Authorization shares one of the best features of port knocking. It allows you to configure your servers to appear as if it offers no services, hence, nothing to be cracked. It only makes services visible to legitimate clients after they prove that they are authorized to access them.

Single Packet Authorization is pretty simple in concept. A legitimate client—say, your SOA client software—wraps up key authorization information into a single encrypted message. The client sends the message to your protected server. The server appears to reject the message. Behind the scenes, however, it decrypts the message, verifies that it is legitimate and then opens up access to the client for a short period of time (perhaps 30 seconds). Your client establishes a connection to the SOA services and proceeds to do its work. The connection will persist so that your SOA components continue to work even after the 30- second window closes.

Here are a couple reasons why single packet authorization is superior to port knocking alone. As you may recall, port knocking works like a combination lock. When a cracker tries to dial any given number on the combination lock, it will fail, and your server will continue to appear as if it doesn’t even have any services to protect. But when a legitimate client dials in the right combination, your server will open up SOA access to that client, and to that client only.

While the likelihood of anyone cracking the combination is negligible, it is nevertheless possible. The good news is that crackers won’t do it by chance. They have better odds of winning the lottery. But a highly skilled and persistent cracker with the right equipment in the right location on the network might be able to guess that you are using port knocking and then “look over your shoulder” to discover the sequence as you dial in the combination. Unlike port knocking alone, single packet authorization is nearly impossible to crack, even if you have the best sniffer connected to an ideal location in the network.

For example, suppose a cracker recognizes that you are using single packet authorization, and then sniffs out a copy of your client’s authorization message. The message doesn’t contain anything the cracker can understand. All the data is encrypted and looks like random garbage.

Ah, the clever cracker thinks, now that he has a copy of the authorization key, all he has to do is resend the same message from his own machine, thus gaining access to the same service, right? Wrong. Single Packet Authorization has a built-in anti-Deja Vu feature. Among other things, the message contains an encrypted time-stamp. If a cracker resends the same message, the server will recognize it as an authorization attempt that it has already seen. It will reject the duplicate message and deny entry to the cracker.

Single packet authorization has other advantages over port knocking alone, but I’ll leave that for the techno-geeks in your organization to discover. In particular, they should read about something called fwknop, which is the central utility [PDF] for single packet authorization.

Just like port knocking, single packet authorization is not a replacement for traditional authorization procedures. If you protect your services by user name/password combinations, you should continue to do so. Port knocking and single packet authorization are an extra level of protection meant to prevent unauthorized clients from discovering that you provide SOA services.