Note: The commands and utilities in this article have been tested on a Debian Cloud Server. They are not guaranteed to function correctly on other distributions. However, the General Package Installation Guidelines article may assist in “porting” this article to another distro.
Introduction
If you’ve read the article on firewalls, you know that an ideal firewall permits only the desired traffic, and absolutely nothing else. A port knocking daemon can compliment a firewall by permitting only what traffic is wanted, when it is wanted. Port knocking works by setting a combination, or sequence, of ports that must be “knocked” before a given port or set of ports will be opened. Let’s use an example set of firewall rules:
- ALLOW: DestPort=22
- ALLOW: DestPort=80
- DENY: ALL
From these pseudo-rules, we can see that this Cloud Server is running SSH and HTTP daemons. Our web server, of course, needs to always be available, so port knocking wouldn’t be helpful there. But what about SSH? In most cases (certainly not all), SSH will only need to be available to a few specific users. Perhaps those users have dynamic IP’s, so we weren’t able to lock port 22 down with static firewall rules. This is where port knocking really shines.
knockd
Let’s test this out by installing knockd on a Debian system…
apt-get install knockd
The configuration file, /etc/knockd.conf, looks like this:
[options] UseSyslog [openSSH] sequence = 7000,8000,9000 seq_timeout = 5 command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn [closeSSH] sequence = 9000,8000,7000 seq_timeout = 5 command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn
It turns out that this works perfectly for our situation. (Though, for security reasons, we would need to change the sequence.) You can see that, to open port 22 to a given IP address, we must knock at 7000/8000/9000 from that IP address. To close it, we reverse the sequence. knockd works well with iptables, but can also be used with other firewalls. You could even use it with other commands — for example, you could have knockd send you an e-mail whenever the sequence is entered.
Once we’ve got our sequence and firewall rules set, we can start knockd…
knockd &
… and ensure it starts at boot by editing /etc/default/knockd:
################################################ # # knockd's default file, for generic sys config # ################################################ # control if we start knockd at init or not # 1 = start # anything else = don't start # # PLEASE EDIT /etc/knockd.conf BEFORE ENABLING START_KNOCKD=0 # <-- Change this to 1 # command line options #KNOCKD_OPTS="-i eth1"
knock
As you may have already realized, in order to unlock this sequence, we need a client to do so! Fortunately, knockd comes with a client of its own called knock. Once we’ve installed knock on our local machine, we can run:
knock 1.2.3.4 7000 8000 9000
This should unlock our Cloud Server so we can access it normally via SSH — but only from our current IP. knock also supports UDP packets, which may be specified using the “-u” switch. To close the port:
knock 1.2.3.4 9000 8000 7000
And that’s it!
Downsides
Unlike firewalls, port knocking is far from a universally-needed security feature. Aside from the issue of requiring an extra “knocking” client, it is also a form of security by obscurity. Knock sequences are like passwords; they should never be made public, and if they ever are, should be changed. However, unlike a password for, say, SSH, knock sequences cannot be easily encrypted. (Though there are theoretical implementations which could do this.) Port knocking can never be used with a publicly-available service, and is easily detected on private services. However, for situations like the one given in our example, a port-knocking daemon can be an excellent compliment to a well-designed firewall
Views: 129