Linux Firewalls - Michael Rash [135]
Note
The output of the enc_knock.pl script in Listing 12-2 would need to be sent over the network in order to function as a real port-knocking sequence; the script here just serves to illustrate how encrypted port-knocking sequences are generated. The enc_knock.pl script is available at http://www.cipherdyne.org/linuxfirewalls.
Architectural Limitations of Port Knocking
Although port knocking can provide an additional layer of protection for network services that may contain undiscovered security bugs, some of the characteristics of the port-knocking architecture make it somewhat brittle and not scalable to enterprise-class deployments. These limitations stem from the usage of packet headers as the data transmission mechanism, as opposed to using application layer payloads. As we shall soon see, SPA (discussed in "Single Packet Authorization" on page 226) addresses many of the limitations of traditional port-knocking implementations.
The Sequence Replay Problem
In today's world of security threats, we should assume that all traffic is monitored by an unknown third party as it travels across a network. Doggedly adhering to this viewpoint provides ample motivation to make sure that sensitive information (such as credit card numbers) is only transferred over the network in encrypted form.
In the case of port knocking, no packet has application layer data associated with it, so there would appear to be little reason to intercept a port-knocking sequence.
However, the goal of port knocking is to transmit just enough information over the network to allow the recipient to deduce that a packet filter should be temporarily reconfigured, granting access to an IP address that has proven its identity via the knock sequence. If an attacker can intercept a port-knocking sequence as it is transmitted over the network, then it is easy for the attacker to send an identical knock sequence to the same target at a later time. This is called a replay attack, because the attacker is replaying the knock sequence against the target in an attempt to gain the same access as the legitimate port-knocking client. Because port knocking just uses packet headers, it is difficult to build enough variation into port knock sequences to stop replay attacks.
Some port-knocking implementations use successive iterations of a hashing function (similar to S/Key authentication, defined in RFC 1760) to stop replay attacks, but these methods require that both client and server store some state information. Alternatively, we could simply change the shared port-knock sequence or the decryption password for each encrypted sequence once access has been granted, but this is tedious and certainly does not scale well for lots of users. (We'll see in "Single Packet Authorization" on page 226 that there is a much more elegant way to thwart replay attacks.)
Minimal Data Transmission Rate
Because the port fields in the TCP and UDP headers are 16 bits wide, if we assume that a port-knocking implementation uses only the destination port number of each packet in the knock sequence, only two bytes of information can be transferred per packet. In addition, because there is no guaranteed in-order delivery and packet retransmission mechanism for port knocking as in TCP (port knocking is strictly unidirectional), we can't blast a complete port-knocking sequence onto the network without adding a time delay between each successive packet. We need the time delay to maintain the correct ordering on the port-knocking sequence because packets may arrive along different routing paths—some of which may be slower than others.
Although there is no optimal time delay that works for all networks (and indeed, if a member of the port-knocking sequence is lost, the entire sequence has be retransmitted), a half-second delay is a good starting point.
Hence, for a port-knocking sequence that is encrypted with a symmetric cipher that has a 128-bit block size (the minimum block size for the Rijndael cipher as mentioned earlier in this chapter), we get a minimum length