- firewall-based method for user authentication
- closed ports are used to transmit information
- firewall logs detect knock sequences
- knock sequences can be encrypted
The most secure system is a system which does not permit any connections from any external system. Such a system, though protected, is impractical - nobody can connect, independent of their trust status. This essentially describes a computer that is not networked. These kinds of computers are not a lot of fun.
To discriminate between trusted and untrusted users - something that firewalls cannot natively do - an authentication method called port knocking is used. The following is an example of how port knocking can be used to completely secure a system against most attacks, achieving a high level of security while maintaining flexibility.
Step 1 : Ports are closed
First, all ports on a system are closed, while connections to some number of these closed ports are logged. This is shown in Figure 1. You can see that the port for ssh (tcp/22) is closed, as are ports for other applications. The ssh/mail/web/pop services are running. In this state, no remote host is able to connect.
Figure 1 | An isolated system. All ports are closed, including ports associated with running services. Although services are running remote hosts cannot establish connections because all attempts to connect are explicitly blocked by the firewall.
Port knocking is not well suited for protecting public services such as web and mail. The reason for this is that establish a connection to protected services is predicated on the knowledge of a secret port knock. Connections to public services can come from anywhere and anyone and it is counterproductive to use port knocking to protect these ports. For this reason, the description of port knocking in this section will use ssh (tcp/22) as the example port. It is best to delegate public services such as web and mail to bastion servers in a firewall's DMZ zone (a distinct network lying between the internet and a fully protected intranet).
Figure 2 shows an example of a secure system protected with port knocking. This figure illustrates that remote hosts cannot connect to the ssh (tcp/22) port, because connections to the port are actively blocked for all IP addresses, which are assumed to be untrusted.
Figure 2 | An isolated system whose ssh (tcp/22) port is protected by port knocking. All ports are closed, including ssh (tcp/22), although the ssh service is running. Other closed ports are logged for connection attempts - these ports will participate in the knocking process.
Step 2 : Trusted User Knocks on Closed Ports
Next, a trusted user from a blocked IP address initiates connections, in a particular order, to some of the logged ports in sequence. This port knock sequence is a secret known only to trusted users. In this way, the trusted user can make his or her IP address change status from untrusted to trusted. This is shown in Figure 3. The knocking phase is analogous to blindly knocking on invisible doors. The user cannot detect that ports are being monitored for secret knocks and - more importantly - neither can anyone else.
Figure 3 | A trusted user at a blocked remote location connects to closed ports in a prescribed sequence.
Step 3 : Firewall Rules are Modified to Permit Trusted User to Connect
Once the firewall detects a well-formatted and acceptable knock sequence, a rule is automatically inserted into the firewall to allow connections to the ssh (tcp/22) port from the trusted user's IP address. Now, this user can connect, as shown in Figure 4. The port was opened only to the IP address encoded in the port knock. Other IP addresses remain blocked.
Figure 4 | Firewall rules are modified upon receipt of a valid port knock sequence, thereby allowing the trusted user to connect.
Closing Ports and Extensibility
Once the user has finished the session, another port knock sequence can be used to similarly manipulate the firewall rules and close the port. By implementing
into the port knock sequence and embedding the client's IP address in the sequence the system can be made extremely resistant to intrusion. Because authentication is done using a knock sequence and mediated by the firewall, by appropriately designing the form, content and encryption of the sequence it is possible to
- open and close arbitrary ports from any IP address for specific amounts of time
- open ports to IP addresses other than that of the host performing the port knock
- minimize the success of replay attacks by using a port knock sequence to prevent a range of IP addresses from originating subsequent knocks
- use one-time pads to encrypt the sequence making the system unbreakable
Is port knocking stealthy?
It is possible to detect the presence of an active network service. Even if you don't have a correct username and password, as long as connections are allowed from your IP, you can simply attempt to make a connection to the service to see if it's running. Here is an example: I can detect that the host
mail.hotmail.com is running a mail service by connecting to the smtp (tcp/25) port. The text in bold is what I typed.
> telnet mail.hotmail.com 25
Connected to mc5.law1.hotmail.com (126.96.36.199).
Escape character is '^]'.
220 mc5-f36.law1.hotmail.com Microsoft ESMTP MAIL Service,
Version: 5.0.2195.5600 ready at Mon, 21 Apr 2003 13:23:23 -0700
250-mc5-f36.law1.hotmail.com (02.02.00.0007) Hello [188.8.131.52]
221 mc5-f36.law1.hotmail.com Service closing transmission channel
Connection closed by foreign host.
In one short connection I know that the host is running the Microsoft ESMTP Mail Server and I know the version of this service, 5.0.2195.5600. I greeted the service using the EHLO (HELO is also supported) command, and learned a few more things. If I were an espresso-sipping malfeasant, I could now ask my buddies whether they know of any way to exploit or "inconvenience" this particular version of Microsoft's Mail Service.
Getting back to port knocking... individuals who do not know the proper port sequence cannot connect to the secured port because, by the way the port knocking mechanism is designed, the port is closed. Furthermore, it's not possible for anyone to (a) determine whether a service at this secured port is running (b) determine whether the host is listening for knocks or (c) successfully use port probes to find out the knock sequence. Knowledge that port knocks were being listened for would be of little use because the identity of the ports used in port knocking is unknown. Even if the identity of the ports could be discovered, a curious user would be faced with the task of guessing the sequence by trial and error. Such brute-force attempts are easily spotted by intrusion detection systems, such as snort, and the offending IP address can be quickly blocked.
Without being able to determine the sequence by probing, intercepting the sequence by listening to network traffic is another method that can be employed. If you are knocking on your server and someone monitors your connection attempts they could duplicate your knock and gain access. This vulnerability can be addressed by (a) incorporating the IP to be allowed in in the knock sequence and (b) encrypting the knock sequence. If this is done, even if the sequence is intercepted and executed by a third-party there would be no harm since the encrypted IP address has not been altered. In order for the IP address to be modified, the knock sequence would have to be decrypted, using knowledge about the method of encryption - very unlikely. Maximum protection can be achieved by using one time pads for encryption of the knocks.
In the unlikely event that someone gains knowledge of a knock sequence and gains access to an open port, they are still faced with getting past the authentication required by the listening application. Port knocking is an additional security layer and does not replace existing application security. It provides a stealthy way to carry out network authentication in complete privacy. If encrypted knocks are used, an additional level of protection is achieved, hardening any network host's services against attacks.