Implement Port-Knocking Security with knockd
The idea behind port knocking is to close all ports and monitor attempts to connect to them. Whenever a very specific sequence of attempts (a knock sequence) is recognized, and only in that case, the system can be configured to perform some specific action, like opening a given port, so the outsider can get in. The knock sequence can be as complex as you like—for example, a simple list (like trying TCP port 7005, then TCP port 7006 and finally, TCP port 7007) to a collection of use-only-once sequences, which once used, will not be allowed again. This is the equivalent of “one-time pads”, a cryptography method that, when used correctly, provides perfect secrecy.
Before setting this up, let me explain why it's a good safety measure. There are 65,535 possible ports, but after discarding the already-used ones (see the list of assigned ports in Resources), suppose you are left with “only” 50,000 available ports. If attackers have to guess a sequence of five different ports, there are roughly 312,000,000,000,000,000,000,000 possible combinations they should try. Obviously, brute-force methods won't help! Of course, you shouldn't assume that blind luck is the only possible attack, and that's why port knocking ought not be the only security measure you use, but just another extra layer for attackers to go through (Figure 2).
On the machine you are protecting, install the knockd dæmon, which will be in charge of monitoring the knock attempts. This package is available for all distributions. For example, in Ubuntu, run sudo apt-get install knockd, and in OpenSUSE, run sudo zypper install knockd or use YaST. Now you need to specify your knocking rules by editing the /etc/knockd.conf file and start the dæmon running. An example configuration is shown in Listing 2. Note: the given iptables commands are appropriate for an OpenSUSE distribution running the standard firewall, with eth0 in the external zone; with other distributions and setups, you will need to determine what command to use.
Listing 2. A simple /etc/knockd.conf file, which requires successive knocks on ports 7005, 7007 and 7006 in order to enable secure shell (SSH) access.
[opencloseSSH] sequence = 7005,7006,7007 seq_timeout = 15 tcpflags = syn start_command = /usr/sbin/iptables -s %IP% -I input_ext 1 ↪-p tcp --dport ssh -j ACCEPT cmd_timeout = 30 stop_command = /usr/sbin/iptables -s %IP% -D input_ext ↪-p tcp --dport ssh -j ACCEPT
You probably can surmise that this looks for a sequence of three knocks—7005, 7006 and 7007 (not very safe, but just an example)—and then opens or closes the SSH port. This example allows a maximum timeout for entering the knock sequence (15 seconds) and a login window (30 seconds) during which the port will be opened. Now, let's test it out.
First, you can see that without running knockd, an attempt to log in from the remote machine just fails:
$ ssh your.site.url -o ConnectTimeout=10 ssh: connect to host your.site.url port 22: Connection timed out
Next, let's start the knockd server. Usually, you would run it as root via knockd -d or /etc/init.d/knockd start; however, for the moment, so you can see what happens, let's run it in debug mode with knock -D:
# knockd -D config: new section: 'opencloseSSH' config: opencloseSSH: sequence: 7005:tcp,7006:tcp,7007:tcp config: opencloseSSH: seq_timeout: 15 config: tcp flag: SYN config: opencloseSSH: start_command: /usr/sbin/iptables -s %IP% -I input_ext 1 -p tcp --dport ssh -j ACCEPT config: opencloseSSH: cmd_timeout: 30 config: opencloseSSH: stop_command: /usr/sbin/iptables -s %IP% -D input_ext -p tcp --dport ssh -j ACCEPT ethernet interface detected Local IP: 192.168.1.10
Now, let's go back to the remote machine. You can see that an ssh attempt still fails, but after three knock commands, you can get in:
$ ssh your.site.url -o ConnectTimeout=10 ssh: connect to host your.site.url port 22: Connection timed out $ knock your.site.url 7005 $ knock your.site.url 7006 $ knock your.site.url 7007 $ ssh your.site.url -o ConnectTimeout=10 Password: Last login: Sat Oct 3 14:58:45 2009 from 192.168.1.100 ...
Looking at the console on the server, you can see the knocks coming in:
2009-09-03 15:29:47: tcp: 220.127.116.11:33036 -> 192.168.1.10:7005 74 bytes 2009-09-03 15:29:50: tcp: 18.104.22.168:53783 -> 192.168.1.10:7006 74 bytes 2009-09-03 15:29:51: tcp: 22.214.171.124:40300 -> 192.168.1.10:7007 74 bytes
If the remote sequence of knocks had been wrong, there would have been no visible results and the SSH port would have remained closed, with no one the wiser.