Remote access security with single-packet port knocking
Who's There?
If you are looking for an extra layer of remote access security, try single-packet port knocking.
Public key cryptography means that the traffic is secured and that if you verify keys correctly, it isn't vulnerable to man-in-the-middle attacks. Exploits are occasionally found, but they are quickly fixed. However, your system could still be vulnerable to brute-force attacks. If you have only a small number of user accounts, if your usernames are unusual, and if your passwords are carefully crafted, this might not be an issue. But if you have multiple users on a system, it becomes harder to ensure that all passwords really are secure. One solution is to run a password-guessing system such as John the Ripper [1], which can discover a poor password before anyone with nefarious intentions has time to exploit it.
Also, you can create firewall rules that establish a maximum number of connection attempts from the same IP address, either indefinitely or for the next few minutes. (The latter option is preferable to avoid problems for real users, who do occasionally mistype their password several times.)
Another alternative is port knocking. In a traditional port-knocking configuration, all ports on the server are closed by default. To the outsider, the network seems inaccessible. A remote user who wants access attempts to initiate a series of connections to a specific sequence of (closed) ports. These connections are not successful, but they are logged by the server. After the appropriate sequence of connection attempts ("knocks"), a daemon running on the server edits the firewall rules to allow a connection from the IP address that has originated the "knock" sequence. The user can then log in normally.
The SSH port is thus opened only in certain circumstances (when a user has demonstrated that they're legitimate), rather than being open all the time. A password is usually required for login once the port is opened, providing an additional layer of security.
Port knocking has a few benefits:
- It's hidden – an outsider cannot detect whether a firewall is listening for port knocking (which is the most important feature). Even if a cracker has access to an SSH exploit, they can't get at the SSH server to try it out.
- It's very flexible – you can set up whatever rules you want.
- It's foolproof – if you cannot rely on your users to create secure passwords, you are vulnerable to brute-force attacks, as well as to any holes in your SSH implementation.
However, traditional port knocking also has some disadvantages. First, a client program needs to do the knocking. Depending on your users' tolerance for such things – and your own ability to manage the remote client configuration – this could be problematic. Also, it might not be possible to run such a program from some locations (e.g., from a library or network cafe). If the server side of the process goes wrong, no one (including you!) will be able to connect to the machine.
Port knocking also increases network traffic, although if the port-knocking configuration reduces the overall traffic because of scanning and brute-force attempts, this reduction could more than balance out the increased traffic for the knocking process. Another problem is that traditional port knocking isn't exactly unbeatable: It might be possible for an attacker to monitor traffic and detect the knocking sequence.
Single-Packet Authorization
A more recent version of the same basic idea – running a server that appears closed until the proper "secret knock" is detected – is Single-Packet Authorization (SPA). In contrast to traditional port knocking, which requires a sequence of several knocks, SPA requires, as its name suggests, only a single encrypted packet to communicate all the information necessary.
An SSH session can occur only after a valid encrypted packet is detected, and as with port knocking, if you are looking at the firewall/server from outside. you can't tell that sshd (or any other service) is listening.
The major advantage of SPA is that its packets are not replayable, whereas with traditional port knocking, it is possible – at least in theory – for an attacker who discovers the sequence to replay it. In addition, SPA is faster and harder to detect because it requires only a single packet.
Fwknop
The best tool for implementing SPA is fwknop, available at the CipherDyne website [2], which is operated by the security researcher Michael Rash. Even though fwknop can also perform traditional port knocking, its authors strongly recommend that you use SPA solution instead.
Installation
To start, you'll need to install the libpcap-dev package (on Debian), or whichever package your distro uses to provide the PCAP development libraries. Then, download the most up-to-date fwknop tarball [3]. To unzip and install the software, enter:
$ tar zxf fwknop-1.9.1.tar.gz $ cd fwknop-1.9.1 $ ./install.pl
During the install process, select server for the local execution mode, then pcap for the data acquisition method. Choose your network interface when asked (probably eth0), and set the access alert email address you want to use (this is the address that will receive an alert when the server is accessed or when access is turned off again). You probably want to choose yes for fwknop to run at boot time.
To ensure that fwknop will run correctly on your system, run the test suite after install: test/fwknop_test.pl from the fwknop install directory.
Now you need to complete the configuration by editing the file /etc/fwknop/access.conf, but you shouldn't need to edit the config settings in /etc/fwknop/fwknop.conf: All the access rules are set in access.conf. The sample access.conf file allows SSH access for 30 seconds after the specified key is sent successfully, which is a reasonable default. The only line you actually need to edit is the one that begins with KEY – alter the key to a password of your choice.
Before starting fwknop, you need to set up your iptables config so that existing connections and loopback are allowed but all other connections are dropped. Be very careful when setting up iptables rules. It is entirely possible to lock yourself out of your server if you get things wrong.
If you already have iptables running, type iptables -F to flush all the rules; then. set rules for the INPUT chain as follows,
iptables -A INPUT -d 1.2.3.4 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -P INPUT DROP
and replace 1.2.3.4 with the IP address of your server.
This configuration accepts packets from established connections (first line) and from loopback connections (second line), but it drops all other packets (third line). The OUTPUT and FORWARD chains are not affected – this code just changes the rules about which inbound packets are accepted. Now start fwknop with /etc/init.d/fwknop start.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
-
Hacker Successfully Runs Linux on a CPU from the Early ‘70s
From the office of "Look what I can do," Dmitry Grinberg was able to get Linux running on a processor that was created in 1971.
-
OSI and LPI Form Strategic Alliance
With a goal of strengthening Linux and open source communities, this new alliance aims to nurture the growth of more highly skilled professionals.
-
Fedora 41 Beta Available with Some Interesting Additions
If you're a Fedora fan, you'll be excited to hear the beta version of the latest release is now available for testing and includes plenty of updates.
-
AlmaLinux Unveils New Hardware Certification Process
The AlmaLinux Hardware Certification Program run by the Certification Special Interest Group (SIG) aims to ensure seamless compatibility between AlmaLinux and a wide range of hardware configurations.
-
Wind River Introduces eLxr Pro Linux Solution
eLxr Pro offers an end-to-end Linux solution backed by expert commercial support.
-
Juno Tab 3 Launches with Ubuntu 24.04
Anyone looking for a full-blown Linux tablet need look no further. Juno has released the Tab 3.
-
New KDE Slimbook Plasma Available for Preorder
Powered by an AMD Ryzen CPU, the latest KDE Slimbook laptop is powerful enough for local AI tasks.
-
Rhino Linux Announces Latest "Quick Update"
If you prefer your Linux distribution to be of the rolling type, Rhino Linux delivers a beautiful and reliable experience.