Single Packet Authorization#
Author: Michael Rash
Translator: BlueDog
Abstract#
Single Packet Authorization fills the gap in port knocking.
The complexity of countless software, protocols, and their intricate interdependencies has created a massive system where ensuring any specific attribute of the system—especially security—becomes extremely difficult. Even software specifically designed to enhance security can be found to have potential vulnerabilities under the scrutiny of knowledgeable experts. Vulnerabilities have been found in everything from firewalls to implementations of the SSH protocol. For example, OpenSSH, developed by some of the most security-conscious developers in the world, occasionally includes remotely exploitable vulnerabilities. This is an important fact to note, as it demonstrates the difficulty of achieving security and the need for a defense-in-depth approach. This article explores the concept of Single Packet Authorization (SPA) as a next-generation passive authentication technology that goes beyond port knocking.
When an attacker attempts to exploit vulnerabilities in server software (rather than client software), the first step is reconnaissance, where the attacker needs to find a target. Nmap has excelled at automating this process, making it easy to build a list of potentially vulnerable systems. If you happen to have a zero-day vulnerability in the server software you are running, you definitely do not want to be on this target list! Both port knocking and Single Packet Authorization techniques use packet filters configured to drop packets by default and only provide service to IP addresses that can prove their identity through a passive mechanism. This passive verification of the remote IP address is done without requiring access to the TCP/IP stack. With this kind of protection, Nmap is unable to even determine if the server is running, and even with a zero-day vulnerability, attackers are powerless.
This article is the first part of a two-part series on Single Packet Authorization, laying the theoretical groundwork for SPA and explaining why it is the next-generation passive authentication technology that goes beyond port knocking. The next chapter will provide practical guidance on how to use fwknop to provide Single Packet Authorization protection for SSH daemons.
Introduction to Port Knocking#
Port knocking is an early technique that uses the port field in TCP and UDP packet headers to convey information. Typically, these protocols are used to encapsulate application layer data, but port knocking encodes information as a sequence of packets sent to various ports, using the port number itself as the data field. These packets are often monitored through firewall logs or packet capture mechanisms such as libpcap. In the typical scenario, there is a port knocking client and a port knocking server. In this case (and for the rest of this article, unless otherwise noted), the terms client and server refer to the software components that send and monitor the packets, respectively. The client is responsible for generating the port sequence, and the server is responsible for passively receiving the sequence and reconfiguring the packet filter to allow connections to the protected service.
A typical port knocking scenario involves configuring the port knocking server to block all access to a service (such as SSH) until the port knocking client sends a specific port knocking sequence. For example, the server may require the client to send TCP SYN packets to the following ports in the specified order:
- 23400
- 1001
- 2003
- 65501
If the server is monitoring this knocking sequence, it will reconfigure the packet filter to allow SSH connections from the IP address that sent the sequence. Leveraging the connection tracking mechanism provided by packet filters (such as the conntrack system in Netfilter), even if the initial rules created by the knocking server are deleted after a timeout, the SSH session can still remain established. Port knocking sequences can be encrypted, and many implementations are listed at http://www.portknocking.org. For a graphical representation of port knocking operations, see Figure 1.
Figure 1. Port Knocking Operations
Limitations of Port Knocking#
Port knocking can effectively limit access to services, but what are its limitations? First, encrypted knocking sequences inevitably introduce information transfer, and the amount of information is dependent on the encryption algorithm. For symmetric encryption algorithms, the encrypted data size is at least equal to the block size (e.g., the Rijndael symmetric block cipher used in the Advanced Encryption Standard has a block size of 128 bits). For asymmetric encryption algorithms, the encrypted data size is even larger.
For example, the original ElGamal algorithm used in GnuPG doubles the length of the plaintext when encrypting data. Even though GnuPG employs compression techniques (which can sometimes result in ciphertext shorter than the original plaintext), GnuPG keys are typically large, resulting in ciphertext even for short messages reaching hundreds of bytes.
This is particularly important in the context of port knocking. Since TCP and UDP headers provide only a 16-bit width port field, each packet in a port knocking sequence can carry only two bytes of information (assuming that other fields in the packet header do not participate in carrying data, even if they do, the payload is still much smaller than the data payload). Therefore, for block ciphers, the cipher sequence needs to contain at least B/(2*8) packets, where B is the block size in bits. Given the prevalent speed and reliability of current networks, this is not a problem in itself. The real problem lies in out-of-order delivery.
Out-of-order delivery poses difficulties for decryption, and since there is no concept of a "connection" in the TCP sense between the port knocking client and the server, the server cannot reorder out-of-order packets. Packets may take different routes, and some routes may be slower, so the client must introduce a human mechanism to minimize the possibility of out-of-order arrival: time. Introducing a time interval (e.g., half a second) between each packet in the knocking sequence typically ensures that the packets arrive at the server in order. Now, for a 128-bit block size, the corresponding port knocking sequence would be 128/(2*8) = 8 packets. With the consideration of a half-second delay, it would take four seconds just to transmit the sequence. For larger messages (e.g., messages generated by asymmetric ciphers), such a data transfer rate is unacceptable.
The limitation of data transfer capacity also brings another limitation to port knocking schemes. It is difficult to effectively defend against replay attacks. Anyone who can monitor the knocking sequence sent by the client to the server is free to replay that sequence against the server in an attempt to gain the same access privileges. If the sequence is passed through a NAT device, and the server's packet filtering rules allow source IPs that are external NAT addresses, this becomes a particularly serious problem. For example, if the port knocking client is on an RFC 1918 subnet like 10.10.1.0/24, and the port knocking server is on a remote network accessible only through the public network, then the server must allow access from the NAT IP. As a result, anyone on the same subnet who can replay the sequence can gain the same access privileges. Additionally, as long as the rule exists, anyone on the same subnet has the same access privileges, and once the rule is instantiated to accept connections from NAT addresses (which is also the case with SPA), sequence replay is not required.
In an attempt to address the replay problem, various modifications have been made to traditional port knocking, such as introducing time windows, using S/Key-style hash iterations, or simply changing the encryption key after each use. However, these methods require the port knocking client and server to maintain some state, and their scalability is not very good when multiple users are involved.
Another limitation of port knocking is that a malicious third party can easily disrupt the knocking sequence by disguising an additional packet as the port sequence sent by the client over the wire. The attacker simply sets the source address of the packet to be the same as the source address of the legitimate client and chooses a port number that matches the last packet sent by the client. This additional packet disrupts the knocking sequence, so the server does not allow any further access by the legitimate client. While the likelihood of someone actually doing this is relatively low (they still need to be able to monitor the packets sent by the client), the main problem is that such an attack is very easy to execute. It only takes one packet, and the attacker doesn't even need to be on the same link as the original packet's data path.
Finally, any intrusion detection system (IDS) that can monitor traffic between the client and server can easily detect the knocking sequence as a port scan. This is especially true for encrypted knocking sequences, which are often longer than simple shared sequences. For an IDS, port knocking looks like a series of probes against various ports from a single IP address within a relatively short period of time, which fits the definition of a port scan.
Single Packet Authorization#
Given the above, port knocking provides many security benefits, but there are serious limitations that need to be addressed. Single Packet Authorization is a relatively new protocol that retains all the benefits of port knocking but fixes the limitations discussed above. The first publicly available implementation of SPA was released in May 2005 as part of software called fwknop (http://www.cipherdyne.org/fwknop). Originally created in 2004, fwknop was the first port knocking implementation to combine passive OS fingerprinting and port knocking (which made it possible to perform operations like "only accept knocking sequences from Linux-2.4 systems"), but the SPA method is now the most popular (and default) authentication method provided by fwknop. It should be noted that fwknop provides both authentication and authorization services, but this article does not include a comprehensive discussion of the differences between the two.
Single Packet Authorization requires a similar architecture to port knocking. Both have client and server components, where the server controls the packet filter configured to drop packets by default, and the server passively monitors the packets. However, the similarity in architecture between port knocking and SPA is limited to this.
Single Packet Authorization moves the data transfer to the application layer where it belongs. This means that SPA can send data in each packet up to the minimum MTU value (1500 bytes on Ethernet networks), while port knocking can only carry two bytes of data in each packet. This far exceeds the data transfer rate possible with port knocking and opens up a wealth of possibilities for accessing such a large amount of packet data. The rest of this article discusses the fwknop implementation of Single Packet Authorization.
fwknop defines the following packet format at the application layer:
- 16 bytes of random data
- Client username
- Client timestamp
- fwknop version
- Mode (access mode/command mode)
- Access (or command string)
- MD5 checksum
Many fields in the SPA packet format have variable lengths but are separated by a ":" character (the fields are base64 encoded, so the embedded colons do not break this syntax). After constructing the above packet format, the entire packet is encrypted using one of two encryption algorithms: Rijndael symmetric block cipher with a 128-bit shared key or the ElGamal asymmetric algorithm with up to 2048-bit public/private key pairs generated by GnuPG. The fwknop client defaults to sending SPA packets over UDP port 62201, but this can be easily changed via the command line; see the --Server-port parameter. (fwknop offers many configuration options—see the resources for links to documentation and man pages.) For a graphical representation of SPA operations, see Figure 2.
Figure 2. SPA Operations
The 16 bytes of random data address one of the highest-priority limitations in port collision—replay attacks. Each SPA packet adds 16 bytes of random data before encryption, and after decryption, the fwknop server caches the MD5 checksum of the entire packet. The random data ensures that each SPA packet is different (even if the same access command is sent), so the MD5 checksum of each packet is also different. If the MD5 checksum of a new packet matches a previous packet, the fwknop server takes no action and writes a warning message to syslog. Therefore, intercepted SPA packets cannot be replayed on the network to bypass the packet filter that drops packets by default.
fwknop includes the client username and timestamp in the packet, and the fwknop server uses the username to maintain different authorization levels for remote users. fwknop can be installed on a multi-user system, where each user can be authorized to connect to different services through the remote fwknop server. The fwknop version field is used to maintain backward compatibility. New versions can add or remove fields, but by using the version number, the fwknop server can be compatible with old client builds that construct SPA packets in a specific way. The mode field tells the fwknop server whether the client is requesting access to a service or executing a command (the next field uses specific access control instructions or commands). For example, to access TCP port 22, the access field would contain the string ",tcp/22", where is any IP address the client chooses to include in the packet. Finally, the MD5 checksum field contains the MD5 checksum of the unencrypted packet sent by the client before transmission. The server uses this field to verify message integrity after decryption.
The data transfer of SPA packets addresses the replay problem and the extremely low data transfer rate in port knocking schemes. The other two limitations in port knocking can also be addressed. First, the single-packet nature of the SPA protocol means that a malicious third party cannot disrupt the authentication scheme simply by deceiving the packet to the same port monitored by the SPA packet. Finally, since the SPA protocol only requires one packet, it does not appear as a port scan to any intermediate IDS. Any IDS can only see a seemingly meaningless block of data that appears to be randomly sent to some IP address.
Conclusion#
Single Packet Authorization provides similar security benefits to port knocking in protecting services that use packet filters configured to drop packets by default. When scanning for such protected target services in this way, it is impossible to detect that such services are listening, making it more difficult to exploit zero-day vulnerabilities. SPA offers clever solutions to many of the limitations of port knocking. These solutions allow SPA to address replay attacks, achieve data transfer rates that support the use of asymmetric encryption, thwart simple deception attacks, and evade reconnaissance by intrusion detection systems monitoring network port scans.
See next month's LJ for the second part of this article, which will provide a detailed demonstration of how to use SPA with fwknop.
References#
- Krzywinski, M. 2003. "Port Knocking: Network Authentication Across Closed Ports." SysAdmin Magazine 12:12-17.
- ElGamal Encryption: http://en.wikipedia.org/wiki/ElGamal_encryption
- At the time of writing this article, the only other SPA implementation I know of is one available at http://www.unspecific.com/spa.
- Another implementation called Tumbler (http://tumbler.sourceforge.net) uses a single packet, but it uses a hashed payload instead of an encrypted payload, resulting in a completely different architecture.
- fwknop documentation and man pages: http://www.cipherdyne.org/fwknop/docs