In 2003, a brilliant concept called port knocking3 was introduced to the security community by Martin Krzywinski in an article in SysAdmin magazine. Port knocking is the communication of authentication data across closed ports which allows a service (such as SSHD) to be protected behind a packet filter configured in a default-drop stance. Any would-be client that wishes to make a connection to a protected service through the default-drop packet filter must first prove possession of a valid port-knock sequence. If a client produces a correct knock sequence (e.g., by connecting to each constituent port of the sequence in the proper order), then the packet filter is temporarily reconfigured to allow the IP address that sent the sequence to connect to a protected service for a short period of time.
Typically, port-knocking systems either monitor firewall logs or use a raw packet capture mechanism (such as libpcap) in order to collect knock sequences from port-knocking clients. We will see later that iptables log messages are well suited to supply the necessary port knock sequence data. We will also see that while port knocking is an important technology with a compelling innovation (i.e., the protection of a service behind a default-drop packet filter), a related technology called SPA provides the same benefits as port knocking but eliminates many of its limitations. But first, we need some background on port knocking.
Port knocking quickly became a success and nearly 30 known implementations of port-knocking schemes sprung up around the security landscape, each of these implementations offering a slightly different twist on the concept of port knocking. For example, cd00r and portkey use TCP SYN packets to communicate port-knock sequences, while Tumbler uses packet payloads to send hashed authentication data. (For more examples of port-knocking schemes, see http://www.portknocking.org.) We'll see later that nothing prohibits the use of packet payloads (instead of just packet headers) to send authentication data—concealing a service behind a default-drop packet filter can still be accomplished in such implementations.
A port-knocking sequence may be either a shared, non-encrypted set of ports or a set of ports that is encrypted with a symmetric cipher such as Rijndael4 (details of these schemes can be found in "Shared Port-Knocking Sequences" on page 218 and "Encrypted Port-Knocking Sequences" on page 221).
Figure 12-1 illustrates a network diagram in which a port-knocking client is used to generate a port-knocking sequence against a Linux system that is running an iptables firewall and a port-knocking server. Because port knocking never requires bidirectional communication (such as the three-way handshake required to set up a TCP connection), port-knocking sequences can be spoofed from a fake IP address. This allows port-knocking sequences to
3 Martin Krzywinski, "Port Knocking: Network Authentication Across Closed Ports," SysAdmin 12 (2003): 12-17.
4 "A set of encrypted ports" means that the port sequence defines a series of byte values and this series itself is used as input to the encryption algorithm. The result is a new set of byte values which correspond to new port numbers. This will become more clear later in the chapter.
originate from an arbitrary IP address, but the actual source IP address from which a connection to a protected service will be accepted by the knock server is encoded within the sequence itself. For instance, you can spoof a sequence so that it appears to originate from the source IP address 22.214.171.124 and is sent to a knock server running on the IP address 126.96.36.199. However, the real source IP address from which you will be making a connection is, say, 188.8.131.52. By encoding the 184.108.40.206 address within the sequence, the knock server grants access to your real IP address instead of the spoofed source IP address, 220.127.116.11. Including the real source IP address within a port-knocking sequence is only really useful if the sequence is encrypted, since a malicious third party would not be able to intercept the spoofed sequence and easily be able to tell where the real connection will come from. Although it is not made explicit in Figure 12-1, the understanding is that the client system generates the port-knocking sequence before attempting to make the SSH connection to the iptables system.
Figure 12-1: A port-knocking network
Was this article helpful?