Strengths and Weaknesses

Port Knocking is a complex technique that is mainly targeted to critical systems that need very high levels of security. For this reason, any system that implements Port Knocking needs to consider a number of issues in order to prevent any kind of attack and guarantee that ports are opened only to authorized users.

This document will present the situations that an ideal port knocking system should handle and how Aldaba behaves in those situations.

Data Sniffing and Packet Replay

An attacker may have the ability to intercept network traffic that is being sent by a client or being received by the server. That same attacker may be able to replay the intercepted packets unmodified or altering them before transmission. Aldaba addresses this problem in two different ways:

1. The knocking information is sent encrypted using symmetric encryption algorithms with a key that is known by both ends. If the information was sent in plain text an attacker could easily intercept it and change it for his own benefit.

2. The IP that the port will be opened to is encoded in the knocking information. Otherwise it would have to be extracted from the IP header. In that case an attacker could easily replace the original source IP address with his own, then replay the captured packets and get a port to be opened for him.

NATed clients

If a client is connected to a NAT-configured network all the information that it sends to the Internet will not have its own IP address but the Gateway/Router external IP. If client's local IP was included in the knocking information, the remote port would be opened for a wrong IP address (probably a non-routable address) and the client would not be able to connect to the opened port. Aldaba addresses this issue letting the user specify which IP should be included in the knocking information. Aldaba also has mechanisms to resolve the external IP automatically.

Packet arrival order.

In small local area networks, packets usually arrive in the same order that they were sent. The Internet behaves differently and in many cases packets arrive to their destination unordered (Bennet et al, 1999). Once they reach their destination, the system's TCP/IP stack is usually the one in charge of reordering the packets and delivering them to the appropriate application as they were originally sent. This works when applications use sockets to listen on specific ports because when packets arrive they first flow through the TCP/IP stack and then they are passed to them. In this case the situation changes. Instead of using sockets Aldaba Server listens on a network interface and gets the packets before they reach the stack. This means that the application must be able to handle unordered packets by itself.

With SPA, this is not a problem as authentication is achieved with a single UDP packet. For Port Knocking Aldaba addresses this issue implementing a data structure that associates sequence port numbers to specific chunks of information so whenever a packet that is targeted to one of the knocking sequence ports is received, the information that it transports is extracted and placed in the correct position as opposed to the queue model that some other port knocking implementations use.

It should be noted that Aldaba can handle packets that are delivered out of order but it requires that packets are generated in the correct order, that is, the knocking sequence must be identical in both ends. If a client uses the sequence “1,4,8,16” and the server uses “1,4,16,8”, the authentication will fail.

Association between authentication and subsequent connections.

Once a valid knock is received, a port is opened for a specific IP address. However, in certain cases an attacker may be able to use the client's IP address and therefore establish a connection to the opened port before the legitimate client does. This is the case of NAT networks where the client and the attacker may share a public IP address.

An ideal port knocking system should provide a mechanism to verify that the client that establishes the connection to the opened port is really the same one that initiated the knock. deGraaf et al (2004) discuss some techniques based on the negotiation of Initial Sequence Numbers for the TCP packets that establish subsequent connections but unfortunately they are difficult to implement as they involve kernel-space operations or TCP/IP stack modification.

At the moment of writing this document no port knocking implementation provides a reliable way of associating knocks and following connections.

Firewall Rules Poisoning

The client needs to send an IP address and a port number to the server . If that information is sent as binary numbers instead of using ASCII characters, any combination of 32 bits represents a valid IP address and any combination of 16 bits represents a valid TCP/UDP port. A typical scenario that uses this configuration would be a port knocking system that transmits 6 bytes of information to the listening server, encoded as follows:

[ IP Address (4 bytes) ] [ Port No (2 bytes) ]

Although that information is usually sent encrypted, if an attacker knows the ports that form the knocking sequence, he would be able to forge his own packets filling them with random data and sending them to the correct ports. Those packets would arrive to the listening server and would be decrypted obtaining 48 bits of garbage. However that information would still represent valid IP addresses and port numbers so, sending multiple knocks, an attacker could poison the system firewall, randomly opening multiple ports to different IP addresses. This would result in a denial of service as the server's firewall tables would become unmanageable.

Any decent port knocking system should provide a mechanism to ensure that the received information represents a valid knock. Aldaba addresses this issue including a message authentication code along with the authorization information. This lets the server check if the data has been altered during transmission, generated randomly, etc. It is very unlikely that random garbage decryption produces data that is validated by the included authentication code. This way, only authorized clients in possession of appropriate cryptographic keys can generate valid authentication messages.

Interoperability with existing devices and protocols

Any application that generates its own packets should be very careful in the crafting process. Modern protocols require valid checksums, specific values, particular byte orders, etc. If packets do not conform to the standards, firewalls, routers and other types of network devices may discard them before they reach their destination host.

Aldaba creates packets that are fully compliant with the TCP/IP standards described in RFCs 793, 791 and 768 so packet dropping is unlikely unless packets travel through highly congested networks.

However, although packets meet the standards, the stealthiness of the system could be compromised by tools that implement covert channel detection (Kruptos 2005). A lot of research has been done on this matter and multiple detection techniques have been developed. Be aware that some skilled attackers may detect that you are using Port Knocking.

Multiple knocking attempts at the same time

Systems that have more than one user need to be able to handle multiple knocking attempts at the same time. If the system is not designed correctly two clients sending different knocks at the same time could interfere with each other thus resulting in a denial of service for both of them.

Any port knocking implementation should be able to associate a knock with the originating IP address. This is usually quite easy to implement so most port knocking systems do it. The real problem is that an attacker may be able to detect the start of a knocking sequence, forge his own packets with random information spoofing the client's IP address and send that information to the knocking server right in the middle of a legitimate knock. This causes the server to process incorrect information and therefore discard the knock, resulting in a denial of service for the client.

Aldaba does not have this problem if the authentication protocol is SPA because only one packet is involved in the process. However, Port Knocking is vulnerable to this attack. Currently Aldaba does not have any solution for it so unfortunately there is a chance that a client suffers a Denial Of Service Attack if an attacker is able to guess the knocking sequence and detect the start of a knocking attempt made by the client.

At the time of writing this document no other Port Knocking implementation that sends more than one packet per knock offers a solution to this problem.

In most cases, the best option is to use SPA authentication. It offers the same functionality but has a lot less problems than Port Knocking.

Memory exhaustion.

As Keong (2004) describes, any port knocking implementation that listens for incoming packets can generate an additional load in the server due to the processing being performed by the knocking server whenever the machine is port-scanned.

Additionally, every time the start of a knocking attempt is detected, new data structures are created to handle them.

Aldaba keeps a record of all the knocking attempts that have not been completed yet. Every time that the start of a knock is detected, a new record entry is generated. If an attacker knows the ports that form the knocking sequence, he may be able to create multiple packets with different source IP addresses and send them to the server. The knocking server will think that multiple clients are trying to send a knock and therefore a node will be created for each different IP. If the attacker sends enough false knocks, the system could eventually ran out of memory and could easily crash the server.

Doyle's implementation (Doyle 2004) solves this problem by adding a timestamp to every node and periodically checking the list, deleting the nodes that were created too long ago to belong to an active knocking attempt.

Aldaba is designed to handle this problem using Doyle's solution. This is quite effective but should be implemented carefully, paying special attention to the amount of time the server should wait before checking the list and the maximum time-to-live for the nodes. A very short time-to-live may discard legitimate knocking attempts before they are completed while a longer one may not be sufficient to prevent memory exhaustion in case of attackers that have high bandwidths.

The perfect solution would be to have an algorithm that considers the frequency in which different knocks are being received and dynamically sets the appropriate timeouts and checking frequencies. At the moment Aldaba includes a basic algorithm that uses hard-coded values to determine how often should the list be checked and for how long should knocking attempts be valid. However, this should be improved in future versions of the program.

Regarding the additional processing overhead, Aldaba tries to reduce this extra load by telling the kernel to only deliver the packets that are targeted to the specific ports that form the knocking sequence. This reduces dramatically the amount of information that the knocking server has to process.

Cryptographic keys protection

Any application that handles passwords, encryption keys or any other kind of sensitive information should be able to protect that data from being discovered by others. Port knocking clients should be able to be used on untrusted computers, leaving no trace.

Aldaba has a little issue when the encryption key is supplied as a command line argument. In this case, the key will probably be logged somewhere, as most UNIX systems keep a list of the commands that were executed recently. For this reason, there is a chance that malicious attackers obtain the encryption key if they are able to get access to the client computer. (for example, in multiuser environments that have the shell history file readable by other users of the same group).

However, if the encryption key is supplied interactively, there should be no need to worry. Aldaba implements mechanisms to safely wipe sensitive information after the program has finished. This is achieved by overwriting user-supplied information many times so recovery is just not possible. This works in theory but I haven't proven it correct. Maybe people with resources like the guys at the NSA are able to recover encryption keys if they have physical access to your RAM modules and the media that stores your swap space...

Root privileges

In many cases Aldaba requires root privileges to function properly. While this should not be a problem for the server it reduces the number of machines that could be used as clients.

The reason why root privileges are required is mainly because Aldaba uses raw sockets to create custom IP packets. This is needed to be able to create the covert channel to transmit the knocking information to the server. However, the SPA technique does not require administrator privileges.

References

Bennet, JCR, Partridge, C and Shectman, N.(1999). Packet Reordering is Not Pathological Network Behavior. ACM Transactions on Networking, vol. 7, no. 6, december 1999. 789-798

deGraaf, R, Aycock, J, and Jacobson M (2004). Improved Port Knocking with Strong Authentication [online]. Department of Computer Science, University of Calgary. <http://www.acsac.org/2005/papers/156.pdf>

Doyle, M. (2004) University of Arkansas Department of Physics. Implementing a Port Knocking System in C.[online] University of Arkansas. <http://portknocking.sourceforge[...]System%20in%20C.pdf>

Keong TC (2004). Remote Server Management Using Dynamic Port Knocking and Forwarding [online]. Special Interest Group in Security and Information Integrity. <http://www.security.org.sg/code/sig2portknock.pdf>

Kruptos (2005). Potential Covert Channel Manipulation Detector (based on the IPv4ID) [online]. Covert Channels and Steganography in Computer Networks research at the Distributed Systems and Networks Research Group at the University of St Andrews.
<http://kruptos.cs.st-andrews.ac.uk/Software/tabid/274/Default.aspx>.