Linux Firewalls - Michael Rash [136]
Note
Because the data transmission capabilities of port knocking are so limited, it is not feasible to use asymmetric encryption algorithms to encrypt port-knocking sequences. Even simply encrypting 10 bytes of information with GnuPG and the Elgamal cipher with a 2048-bit key would result in several hundred bytes of encrypted information.
Knock Sequences and Port Scans
As discussed in Chapter 3, a port scan involves a series of connections to multiple ports on a target system within a short period of time. When examined on the wire, a port-knock sequence clearly fits this definition, even though the goals of a port scan versus a knock sequence are quite different. The trouble is that any intrusion detection system that is watching for port scans cannot differentiate between the two types of activities, and it generates an alarm for both. These alarms may bring unwelcome attention to the person using port knocking to authenticate to a remote service.
Note
I am aware of someone (let's call him Bob) who was asked to resign his position with his employer because port scans were prohibited by the company security policy. In an effort to enhance his security, Bob repeatedly scanned his home system to make sure that services were not accessible, but the local IDS caught the activity. The IDS alert would have sounded if Bob had been using a port-knocking system. Of course, this is an extreme example, but it underscores the point that there is no reason to call unnecessary attention to oneself.
Knock Sequence Busting with Spoofed Packets
Because port knocking encodes information only within packet headers (as opposed to relying on encrypted application layer data), it is easy for an attacker to forge packets to look like they are part of a legitimate knock sequence. If an attacker spoofs a duplicate packet into a port-knocking sequence as it is en route over a network, the knock server cannot tell that this additional packet is not part of a real sequence from a port-knocking client; the result is that the client does not appear to know a valid knock sequence. This is a Denial of Service (DoS) attack against the knock server, because an attacker can force the server to not give access to legitimate port-knocking clients. DoS attacks can be complex affairs (such as the coordinated flooding of traffic to a single IP address from a network of zombie machines), but they can also be exceedingly simple to perpetrate; the DoS against a port-knocking server with a single packet is trivially easy to perform—it can be spoofed from anywhere!
To illustrate this attack, suppose that the following port-knock sequence has been agreed upon by the port-knocking client and server to open TCP port 22 for 30 seconds (all packets are TCP SYN packets): 1001, 2004, 5005, 1001, 1000. Now, suppose that the IP address 123.4.3.2 begins sending the knock sequence to the knock server running at IP address 231.1.2.3, with a half-second delay between each packet. If an attacker can monitor this sequence as it is being sent over the network, the following usage of the hping command will make it appear as though the port-knocking client actually sends the sequence "1001, 2004, 5005, 5005, 1001, 1000" (note the duplicate packet to port 5005):
[root@attacker ~]# hping -S -p 5005 -c 1 -a 123.4.3.2 231.1.2.3
HPING 231.1.2.3 (eth0 231.1.2.3): S set, 40 headers + 0 data bytes
--- 231.1.2.3 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Hence, the port-knocking server has no choice but to discard the knock sequence as being invalid, because it appears to originate from the real client's IP