CHAPTER 3

Port Knocking and SPA ( Single Packet authorization )

3. 1 What is Port Knocking?

Port Knocking [5] is a technique that allows a client to remotely open a port on a distant machine. This can be achieved in many ways but in general a client sends a specific sequence of connection attempts to a listening server. The server detects this sequence and opens one of its ports so the client machine can connect to it. This prevents attackers from scanning your network for open ports or attacking network services with 0-day exploits because the protected ports will appear to be closed. The following diagrams show the basics of Port Knocking.

When it comes down to it, port knockings primary aim is to provide an extra layer of protection through the use of authentication with the added benefit of concealment. As described earlier, networks were originally designed to work seamlessly, and thus we find ourselves relying on a structure which offers no authentication before one machine can connect to another. Port Knocking attempts to fill the void by adding (not replacing) a layer of security, which can be used to authenticate users before they are given access. From a security standpoint it should be obvious that there is no good reason for the average unskilled attacker to be able to detect SSH running on port 22 of a server. If only authorized users are allowed to use the SSH service, then it should make sense that only authorized users should be allowed to connect toit in the first place. Port Knocking allows administrators to keep the (potentially vulnerable) service hidden from the public, whilst making it available to authorized users, without the risk of making the machine vulnerable should the port knocking mechanism fail.

3.1 Basic Working of Port Knocking

In order to analyse port knocking as a security mechanism, it is essential to outline its basic workings. The crucial element of port knocking relies on a completely closed firewall which is set to DROP all packets that arrive. This means that all received packets should be dropped and no response sent out (as opposed to the REJECT/DENY state which drops packets and sends a ICMP PORT UNREACHABLE back to the client). The significant difference is that one gives away the presence of a listening host, whereas the other remains absolutely silent and so makes it impossible to determine whether or not a machine exists at that address.At this pointwe have a completely silent, inaccessible machine. This is relatively secure, yet also relatively useless. The next step is to find a way to connect to the server or perform some kind of action on it. A port knocking daemon sits on the server and watches packets as they are dropped, waiting for a sequence of packets arriving at a predetermined set of ports in order. The client who wishes to connect to the server sends SYN packets (the first packet in a TCP connection) to the predetermined ports in order, for example: ports 100, 110, 120, 130. The server will receive these packets and drop them silently, however, the port knocking daemon will see these incoming packets and recognize the valid knock on the ports. Once the proper ports have been knocked on, the daemon can execute any predetermined action, for example: open port 22 (SSH) for the IP that knocked. The user who knocked can then connect to the protected machine, and if set up properly, can knock on ports 200, 190, 180, 170 in order to close port 22. Most good implementations, however, simply close the port automatically after a given amount of time has elapsed. The significant features we can see so far are:

1.Concealment: the servers firewall is set to DROP all packets and so a scanning or probing attacker will have no clues as to whether or not the server exists, let alone what services it is running.

2. Service Protection: services running on the host (such as SSH) are protected from attacks on unpatched vulnerabilities. This feature serves as a useful stop-gap and gives administrators time to patch their vulnerable systems. One important aspect of this port knocking feature is the fact that it can actually protect against 0day attacks, which are considered extremely difficult to defend against. Even if an attacker possesses an exploit for a vulnerable version of a

servicerunning on the protected server, they have no way to mount an attack and deliver that exploit, asall ports on the server are closed to the attacker.

3. User Authentication: by watching the incoming traffic for a predetermined knock, which essentially acts as a secret key known only to the users trusted to use the protected server, the port knocking daemon is able to authenticate the user at the other end before allowing them toconnect to any (potentially vulnerable) services.

3.2 Basic Working Of Single Packet Authorization Single Packet Authorization (SPA) and port knocking have the same aim but significantly different delivery mechanisms. In SPA the knock, which is called an Authorization Packet (AP), is encoded within a single packet. This can provide certain advantages not found in traditional port knocking schemes, such as eliminating the problem of out-of-order packet delivery. In traditional port knocking, if a knock sequence arrives out of order, which can easily happen asthe server is not sending back any acknowledgements, then the port knocking daemon will not recognize e the knock and thus access will not be allowed SPA simplifies the process by encoding all of the necessary information into a single packet, typically UDP or ICMP. The information encoded in these packets can be as simple as a timestamp (for replay protection), client IP address, and password combination, for example:

Timestamp: 200608062127 (21:27 6th August 2006) Client IP: 192.168.1.1001 Password: secretpassword

In this very simple example, the server would be configured for a single user and would execute a single command, for example to open SSH port 22 for the client IP for 5 minutes. The server would also be set up to keep a record of the last valid authorization packet it received, in order to prevent an attacker from replaying an old AP . The resulting AP that is sent to the server is usually constructed by feeding the fields above into a hash function.In this case the resulting hash, using MD5, would be: MD5 (200608062127:192.168.1.100:secretpassword) = 9c6f2af8e1a0f841467f0a1de39f53c8

This hash would then be packed into a UDP packet and sent off to the server. Upon receiving the packet, the SPA daemon would recalculate the hash by hashing the password (which it knows), the current date and time (accurate in minutes), and the IP address of the client that knocked (which can be found in the IP header of the UDP packet). If the resulting hash is the same as theone received, then port 22 would be opened for the client IP. If the hashes do not match, or the received hash had already been received previously (ie. The hash is a replay of an old hash), then no action is performed.

3.3 Port Knocking - A Firewall Authentication Scheme Most current-day network services require some form of user authentication before a connection can be made. Services such as SSH1 and FTP both require a username and password when a connection is opened. Alternatively, SSH has the option of only allowing cryptographic keys to be used in the authentication process, denying the use of username and password combinations. So in essence, SSH and FTP are layers which exist to protect the system and authenticate users before some kind of access is granted. The problem with networked services is that they are potentially vulnerable to attack, for example, by exploiting bugs in their code, or to simple dictionary attacks. For these reasons, port knocking allows the services to be hidden from theworld, until a valid authenticated user attempts to connect. Figure below depicts how a system running SSH could be protected using a port knocking layer. Remember that in this conguration, the rewall is set to drop all trac silently until a port is opened by the port knocking daemon.

Figure 3.2: Port Knocking as an additional layer in the Defense in Depth

. One major concern about port knocking is the question of what would happen if the mechanism failed. This turns out to be quite a simple scenario to assess, due to the fact that port knocking operates with a completely closed rewall. Figure 3.3 depicts a situation where the port knocking daemon fails safely. The rewall remains closed, meaning that nobody can connect to any services. Admittedly this results in a classic Denial of Service (DoS), but the system remains secure which may be the preferred result in certain environments.

Figure 3.3: Port Knocking Fails Safely - all ports are closed.

The other way that port knocking can fail, depicted in Figure 3.4, is the fail open. This situation can happen, for example, if a user knocks to open a port, and the port knocking daemon fails and thus the port is not closed automatically as it should be. Here the rewall is left in an open state, thus allowing connections to the SSH daemon on port 22. This state may result in a DoS for any additional users who wish to connect, and in most cases does not result in an overly open system, as most port knocking implementations only open the port to the IP of the client that knocked. However, a less complex implementation could open ports fully (i.e. to any IP), and although this means that the port knocking mechanism has been circumvented, from an attackers perspective, he would still have to either authenticate to the underlying service or attempt to exploit it - the attacker is essentially back to square one, just as he would have been had port

knocking not been employed in the rst place! More importantly, compromise of the port knocking mechanism does not result in the penetration of the underlying system.

Figure 3.4: Port Knocking Fails Open - attacker must authenticate to underlying service.

CHAPTER 4

Port Knocking and SPA Implementations

These are the basics of Port Knocking and SPA.In our project we have made comparative study of three diffrerent SPA implementations namely 1. Fwknop 2. AldabaPortknocking 3. SIG^2 Port Knocking

4.1.Fwknop
Firewall Knock Operator (fwknop) is the SPA implementation by Michael Rash. Fwknop (also programmed in Perl) used to be a port knocking implementation, but with the appearance of the single packet authorization concept, its primary mode of operation is now SPA over UDP (although TCP and ICMP are also supported). From the couple of SPA implementations that were tested, fwknop denitely seems to be the most exible in terms of how the system can be set up. Fwknop, as with most SPA implementations, sets up a knock string which is then packed into a UDP packet, utilising the payload available, and sent o to the server. In SPA the knock is called an authorization packet. In fwknop, the authorization packet consists of ve pieces of data: Random data: 3765661773077220 (16 bytes of random data) Username: admin (local username) Timestamp: 1155665551 (local timestamp) Version: 0.9.7 (fwknop version) Action: 1 (access or command mode) Access: 10.0.0.1,tcp/22 (desired access or command) MD5 sum: qZayT4TNoK1pCOI66Wr0oA The MD5 is calculated over all of the elds in order to allow the server to check whether the authorization data was received correctly. The Username, Access and MD5 sum elds are Base64 encoded. These strings are then concatenated together, delimited by colons (:), to form the plaintext authorization data:

3765661773077220:YWRtaW4=:1155665551:0.9.7:1:MTAuMC4wLjEsdGNwLzIy:qZayT4TN oK1pCOI66Wr0oA The resulting string is encrypted using Rijndael, in Cipher Block Chaining (CBC) mode, with a block size of 128-bits and a key length of 256-bits.By encrypting the authorization string, that contains a hash of the data, the plaintext becomes integrity-protected, and thus an attacker would be unable to modify the plaintext (through ciphertext manipulation) without those modications being detected. The cryptographic key in fwknops default conguration,however, is derived from a user-entered passphrase (8-16 characters in length4) through a series of MD5 hashes5, meaning that there are only approximately 9516 (100-bits) possible keys (there are 95 printable ASCII characters, and a maximum of 16 characters per password), far less than the full 256-bits of a Rijndael key. The encrypted authorization data is then packed into a UDP packet and sent o to the specied server. On the server, the fwknop daemon (fwknopd) watches on UDP port 62201 (by using libpcap to sni the wire) for inbound authorization packets. When a packet is received fwknopd attempts to decrypt it, parse the decrypted data by nding the colon (:) delimiters, and checks that the MD5 hash of the elds matches the MD5 hash included in the packet. . As stated in Section 4.2.3, detecting SPA packets is more dicult than detecting port knocks as SPA packets are less obvious than long and loud port knocks, and contain seemingly random data which can potentially blend in with normal network trac. In the case of fwknop, however, there are some indicators which could be programmed into an IDS to ag that fwknop may be in use on the network. Fwknop packets go to port 62201 by default, so a rule could be dened to watch for trac to that port, although this would easily be circumvented by changing to a custom port. Alternatively, an IDScan attempt to track fwknop packets by checking the data length of the UDP packets. An fwknop packet encrypted using Rijndael will be anywhere between 80 and 160 bytes in length. A packet encrypted using GPG will be anywhere between 500 and 1600 bytes in length [6]. Although a quick test of such a rule on any machine, running several common applications, reveals that about 15 packets meet the above requirements every 10 seconds. Obviously this rule would generate far too many false positives. Thus, the only way to successfully track for fwknop packets would be to track packets of the lengths mentioned above, going to UDP port 62201 of a machine..

6.2.1 Important features offwknop

Fwknop has following features

Security
From an entity authentication perspective, fwknop is basically an implementation of ISO/IEC 9798-2 mechanism 1, a one-pass method for providing unilateral authentication using timestamps and encryption, which has been applied to the concept of rewall authentication (although fwknop does not follow the actual standard). This provides eective authentication of the client requesting authorization to the server, and helps protect against replay, although the timestamp used in fwknop is not actually checked against the clock on the server. Both the timestamp and the random data elds are used as fresh values or randomisers which help ensure that each authorization packet will yield a unique MD5 sum which can be logged to check for replays. However, in this lack of timestamp checking exists a possibility for a man in the middle attack where the attacker intercepts and blocks an authorization packet from the client. Due to the fact that the packet never reaches the server, its MD5 hash will not be logged, and the timestamp will not be checked for freshness at the time of delivery. Although a replay of this intercepted packet at a later date will only open the requested port for the IP included in the packet (probably the clients IP at the time), this can still be used to the attackers advantage should he have the ability to connect from the same location as the client, or masquerade as the client on the network. These issues of block and replay attacks can be reduced by implementing a window of acceptance against which the timestamp is checked before any action is performed. The window of acceptance can be set to compensate for standard clock drift, although a client with incorrect time may experience a denial of service as the clients timestamp will not match the valid time on the server when the timestamp is checked. By checking the timestamp and making sure that its within the window of acceptance, the server is able to reject any potential replays that are outside the accepted timeframe. Fwknop does not include the identity of the server in the authorization packet, which means that two servers with an identical setup (same users and keys), are vulnerable to replay attacks of each others authorization packets especially if timestamps are not checked. An attacker could simply intercept a valid authorization packet on route to one of the servers, and immediately (or at a later date, if no timestamp check is implemented) replay it to the second server.

Anonymity
Fwknop has recently gained the ability to send authorization packets over thTor onion network [18, 49]. Although using this feature requires the daemon to run an actual listening TCP socket for the client to connect to12, this mechanism loses the design goal of concealment, but gaining the anonymity oered by the Tor network. The Tor network functions by sending encrypted packets over a random path through several servers (onion routers). The key element is that no individual router knows the complete path through the onion network (the network of onion

routers) from the client to the server (see Figure 6.1). This makes it impossible to track exactly where a packet is coming from, and thus trac analysis becomes a much more dicult task. It would also be possible to make use of Tors hidden service feature to conceal which server a client is sending authorization packets to. As it is no longer possible to track the origin of packets, and all trac must routed over the Tor network, an attacker who used to be in a MITM position can no longer carry out any of his attacks against the client nor the server.

6.3 Aldaba Port Knocking and SPA suite

Aldaba Knocking is anan open source client/server tool that implements a complete Port Knocking and Single Packet Authorization system for GNU/Linux. Aldaba allows a client to manipulate firewall rules remotely by sending a specific sequence of packets with encoded information to a listening server. In general terms Aldaba Client needs to send to the server an IP address, a port number and an action to take (open or close). That information needs to be transferred securely so eavesdropping does not give attackers any useful

information and needs to be transferred stealthily so it does not become obvious to anyone that the system is running a port knocking server. Aldaba provides that functionality by using encryption and TCP/IP-based covert channels. Additionally, instead of relying on the accuracy and availability of firewall logs, Aldaba server captures all the packets that flow though a network directly from a network interface and processes them in real time, in order to find a pattern that matches a pre-defined knock. Once a valid knock is received, a customizable script is executed and the specified port is opened or closed.

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. Following are the situations that an ideal port knocking system should handle and how Aldaba behaves in those situations.

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.

4.4 SIG^2 Port Knocking

Port knocking is a technique [9] that can be used to hide services that are running on a hardened server. This is achieved by not opening the service port until a correct sequence of "knock" packets are received by the server. There are currently many implementations of port knocking and most of them require the client to send a fixed pre-defined sequence of port knocks to the server. The problem with this approach is that once the adversary got knowledge of the knock sequence, it would be trivial for him to replay the sequence in order to gain access to the service port. In this paper, we present the implementation of a port knocking technique that does not require the obscurity of the port-knock sequence. Our approach does not require the clients to send a fixed pre-defined sequence of port knocks to the server. Instead, the port knocking sequence is dynamic and is determined only when the client needs the server to open a connection port. In certain cases, a server may need to run additional services to support tasks like remote administration. For example, SSHD may need to be enabled on a web server to allow uploading of new webpages. However, it may not be desirable to enable additional services on the web

server, since these services may be subjected to attacks. Further, any vulnerabilities in these services may be exploited by the adversary to gain unauthorized access to the server. The port-knocking technique can be used in this situation as a means of dynamically enabling or disabling the additional services as required. For example, if the Administrator needs to upload a new webpage via SCP, he would send a pre-defined sequence of port knocks to the server. Upon receiving the port knocks, the server would open the SSHD port to allow the Administrator to connect. After uploading the files, the Administrator may need to send another sequence of port knocks to close the port. This is depicted in the diagram below.

Figure 1 - Opening a "hidden" port by port knocking

Several implementations of port knocking exist for both Linux and Windows. Such implementation typically requires the port knock sequence to be fixed and pre-defined. This approach has the following issues. 1. If the adversary got hold of the port knock sequence by packet sniffing, he would be able to replay the sequence to the server and cause the "hidden" port to be opened. 2. If multiple users need to access the "hidden" port/service, the port-knock sequence must be made known to all of them. This is a problem if there are many users and when one of

the users becomes untrusted, a new port knock sequence would need to be distributed to the remaining users. 3. The service port to be opened is fixed. In the above example, a correctly received knock sequence will cause the server to open port 22 (SSHD). During the period of time the port is open, that particular service will be susceptible to attacks.

Working of SIG^2 Port Knocking

Our implementation of port knocking is designed to overcome the issues mentioned above. In particular, we do not require the port knock sequence to be fixed and pre-defined. We also randomize the "hidden" port, so that each correctly received knock sequence will cause to server to open a random port for the client. In other words, the SSH service can be accessed via a different port each time. This significantly reduces the possibility of the adversary finding and attacking the SSH service. The following sequence of steps gives a high-level overview of how our implementation works. 1. Port-knock client generates a random port-knock sequence, encrypts it using the user's password hash, and sends it to the server in a single MD5 HMAC protected UDP packet. This packet shall be called P1. The client uses this packet to declare to the server the portknock sequence it will send in step 3. 2. Server decrypts the request packet, validates the MD5 HMAC and waits for the client to send the knock sequence. 3. Client sends the agreed port-knock sequence to the server. 4. Client sends an encrypted and MD5 HMAC protected UDP packet to the server to check the status of the port-knock. This packet shall be called P2. 5. After receiving the correct port-knock packets and packet P2, the server will reply with packet P3. Packet (P3) is encrypted with the user's password hash and contains the server assigned port. 6. After receiving P3, the client can connect to the server via the assigned port. 7. The server will only allow connections to the assigned port by the client who requested the port-knock (identified by IP address). Connections from other IP's will be closed immediately. The server will perform port-forwarding to forward the incoming connection to a predefined IP and PORT.

The following diagram depicts this.

Figure 2 - Our Dynamic Port-Knocking Implementation