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.