Linux Firewalls - Michael Rash [137]
Figure 12-2. An attacker spoofing a duplicate packet into a port-knocking sequence, causing a DoS
* * *
[71] 3 Martin Krzywinski, "Port Knocking: Network Authentication Across Closed Ports," SysAdmin 12 (2003): 12–17.
[72] 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.
[73] 5 If the port-knocking server or any libraries it depends on (such as libpcap) are vulnerable, then an attacker may still be able to compromise a system that has deployed a port-knocking scheme. However, finding such a system is not as easy as just using Nmap to scan for vulnerable services that happily volunteer their own existence.
Single Packet Authorization
Port knocking has shown us how to maximize the use of a packet filter to enforce a default-drop stance against all attempts to communicate with a protected service.[74] However, as shown earlier in this chapter, port knocking is not a panacea, and it has significant architectural limitations. In this section, we'll explore an alternative to port knocking that retains its benefits while avoiding its shortcomings.
Single Packet Authorization (SPA) combines a default-drop packet filter with a passively monitoring packet sniffer in a manner similar to port-knocking implementations. However, instead of transferring authentication data within packet header fields, SPA leverages payload data to prove possession of authentication credentials. This works because the MTU size of most networks is on the order of several hundred bytes (for example, the Ethernet MTU is 1514 bytes, including the Ethernet header), so only a single packet is required in order to communicate identity to an SPA server.
Because port knocking and SPA share the concepts of a default-drop packet filter and a passively monitoring device, the diagram in Figure 12-3 is quite similar to Figure 12-1, which illustrates port knocking. However, this time, only a single packet is needed to transmit the authentication information to the SPA server, so there is only a single line from the (spoofed) SPA source address to the iptables system; a sequence of packets is not necessary before the real SSH session can begin. We will soon see that this is an important innovation beyond port-knocking schemes.
Figure 12-3. An SPA network
Addressing Limitations of Port Knocking
A brief summary of the problems posed by port-knocking protocols is as follows:
It is difficult to stop replay attacks from attackers who can monitor port-knocking sequences.
The lack of effective data transmission limits the types of information and even the cryptosystems that may be used to encrypt sequence data.
Any intermediate IDS may set off alarm bells when a port-knock sequence is being sent over the network.
Sequence-busting attacks are trivial to perform, because packet headers are not hard to duplicate and spoof.
By using payload data in SPA, we can overcome each of these deficiencies:
SPA solves the replay problem by including random data within every SPA packet. Each SPA packet is built according to a well-defined cleartext packet format (the specific format used by fwknop is discussed in Chapter 13). This format includes space for the random data, and once the packet is constructed, it is encrypted. Including random data ensures that no two SPA packets are identical—even those that make the same access request to the SPA server. By storing the MD5 sum of each successfully decrypted SPA packet on the server side, we can repeatedly send the same access request, knowing that no two SPA packets will have the same MD5 sum. Replay attacks are thus easily thwarted by comparing the MD5 sum of any new SPA packets with those of the previously monitored packets.
SPA solves the data transmission problem by using the payload portion