Rat-a-tat-tat

In this article, I'll run through the installation of the aforementioned knockd on Debian and Ubuntu. Barring the procedure behind the package install, I would hope that the config would also play nicely with other members of the Linux family, too.

On Debian, use:

apt-get install knockd

Once the small, circa 200KB package is downloaded and installed, the first thing you might notice is the response from the installation script as it comes to an end:

* knockd disabled: not starting. To enable it edit /etc/default/knockd

You'll be glad to know that this is not an error, but a precaution. Because you don't want to be locked out of your remote servers before you're even given a chance to configure the package, knockd thoughtfully installs and doesn't fire itself up until you are ready to proceed carefully. For example, you might want to run a second SSH instance on a different port while you test, make sure that an engineer is handy onsite within the data center, or spawn a failsafe Telnet server just in case you're locked out during testing.

The useful README file, which can be found in /usr/share/doc/knockd/README, runs through a brief description of how knockd works with a firewall, looks at the simplicity of the client-side knock sequence, and explains how popular packages such as hping, sendip, and packit are all capable of initiating a connection sequence.

In the README, you will see added information about at least two other implementations of port knocking software called Pasmal [2] and Doorman [3]. The subtitle on the Doorman website – Silent Running – is apt, in that a server can run completely silently, in the sense that all TCP ports are invisible and closed.

Harking back to ye olde days of secret societies, which required a secret knock before the door would be opened, your server suddenly appears like an ephemeral apparition, intriguingly, only to you.

Who's That Knocking?

As you might expect, I next inspect the file mentioned at the end of the install, /etc/default/knockd. Figure 1 demonstrates the simplicity of the file. As you can see, /etc/default/knockd only enables and disables the daemon and changes which interfaces the daemon will listen on; the highest level of config for knockd, you might say.

Figure 1: The /etc/default/knockd file postinstallation with the daemon disabled by default for safety reasons.

Following the sensible Linux standard, the global configuration file is in the root of the /etc directory; as the output in Figure 1 shows, you're now pointed toward a file called /etc/knockd.conf (Figure 2). From this file, you'll set about putting this sophisticated package to good use.

Figure 2: The default configuration within the main config file.

What immediately strikes me when looking at this file is that, as packages go, it's definitely very light on the config and entirely unintimidating. That suits me just fine: In my book, simplicity is by far the most intelligent approach to dealing with complexity.

Not Today, Thanks

The next task is to incorporate the trusty TCP Wrappers into the [openSSH] and [closeSSH] sections. This can be achieved in a number of ways once TCP Wrappers is verified as being installed.

Back in the day, it was a case of downloading a tarball and building the file from source with a complex, multiply wrapping command line. Thankfully, however, tcpd, the daemon responsible for wrapping inbound traffic (with useful logging and access control granularity) installs from package managers with ease these days. If for some reason you're not seeing the man page, you can install it with:

apt-get install tcpd

Incidentally, if you're thinking of using TCP Wrappers with other programs, you can easily check whether they have been compiled with support by running:

ldd /usr/local/filename | grep libwrap

In theory, if your software can indeed speak to TCP Wrappers without further ado, you should see some output.