For the sake of argument, let's say you have an SOA server component for your custom client software that uses port 4000. Port knocking can close off port 4000 (and every other port) to anyone who doesn't know the "secret method" for opening it. Any cracker who scans your server for open ports will never discover that you have an SOA service available on that port. All ports will appear unresponsive, which makes your server appear to offer no services at all.

Ironically, your client gains access to port 4000 in a way similar to the way crackers discover existing open ports. As described above, port scanners step through all available ports sequentially, knocking on each one to see if there's an answer. By default, a port knocking-enabled firewall never answers on any port. The secret to unlocking any given port is in the non-sequential order your client uses to check for open ports.

For example, your client software might check ports 22, 8000, 45, 1056, in that order. Each time, there will be no answer. But the server will recognize that your device —running the legitimate client software—knocked on just the right ports in the right order, like the key to a combination lock. Having gotten the right combination, the firewall will open port 4000 to the authenticated device and only to that device. Port 4000 will continue to look closed and unused to the rest of the world.

This isn't meant to be a replacement for the next level of authentication. It simply adds another level of security to make your services harder to discover and crack. The effect is (with apologies to Paul McCartney), when "Somebody's knocking on the port, someone's ringing the bell," they'll probably go away if it looks like nobody is home. The Portknocking.org site has information on port knocking implementations, and existing port knocking client software is available.

Next time, I'll look at an even better way to lock down your network to keep your SOA components safe and undiscovered by crackers.