Zero Trust: Single Packet Authorization | Passive authorization
Not everything in Software-Defined Perimeter (SDP) is new
Even though we are looking at disruptive technology to replace the virtual private network and offer secure segmentation. One thing to keep in mind with zero trust and software-defined perimeter (SDP) is that it’s not based on entirely new protocols. So we have reversed the idea of how TCP connects. Started with an authentication first then connect approach, but traditional networking and protocols still play a large part.
We still use encryption to ensure that only the receiver can read the data we are sending. We can, however, use encryption without authentication which validates the sender. However to stand any sort of chance in today’s world the two of them should go hand in hand. Attackers can circumvent many firewalls and secure infrastructure. As a result, message authenticity is a must for zero trust and without an authentication process, a bad actor could change, for example, the ciphertext without the reviewer ever knowing.
A key aspect of zero trust networks is to authenticate and authorize network traffic: i.e the flows between the requesting resource and the intended service. Simply securing communications between two endpoints is not enough. Security pros must ensure that each individual flow is authorized. This can be done by implementing a combination of security technologies such as Single Packet Authorization (SPA), Mutual Transport Layer Security (MTLS), Internet Key Exchange (IKE), and IP security (IPsec).
IPsec can use a unique security association (SA) per application in which only authorized flows are allowed to construct security policies. While IPsec is considered to operate at Layer 3 or 4 in the open systems interconnection (OSI) model, application-level authorization can be carried out with X.509 or an access token. There is also an enhanced version of TLS known as mutually authenticated TLS (MTLS) used to validate both ends of the connection. The most common TLS configuration is the validation which ensures that the client is connected to a trusted entity. But the authentication doesn’t happen the other way round so that the remote entity is communicating with a trusted client. This is the job of mutual TLS. As I said, mutual TLS goes one step further and authenticates the client.
The pre-authentication stage
You can’t attack what you cannot see. The mode that allows pre-authentication is Single Packet Authorization. UDP is the preferred base for pre-authentication because UDP packets by default do not receive a response. However, TCP and even ICMP can be used with the SPA.
Single Packet Authorization is a next-generation passive authentication technology, beyond what we previously had with port knocking which uses closed ports to carry out the identification of trusted users. SPA is a step up from port knocking. The typical port knocking scenario is for a port knocking server to configure a packet filter to block all access to a service, for example, the SSH service, until a specific port knock sequence is sent by a port knocking client. For example, the server could require the client to send TCP SYN packets to the following ports in order: 23400 1001 2003 65501.
If the server monitors this knock sequence, the packet filter reconfigures to allow a connection from the originating IP address. However, port knocking has its limitations which SPA addresses, SPA retains all of the benefits of port knocking but fixes the limitations.
What is Single Packet Authorization (SPA)
SPA was invented well over 10 years ago and was commonly used for superuser SSH access to servers where it mitigates attacks by unauthorized users. The SPA process happens before the TLS connection, mitigating any attacks targeted at the TLS ports.
As already mentioned SDP didn’t invent new protocols, it was more of a binding together of existing protocols. SPA used in the world of SDP was based on RFC 4226 HMAC-based One-Time Password “HOTP”. It is another layer of security and is not a replacement for the security technologies mentioned at the start of the post.
The first step in an attack is reconnaissance whereby an attacker is on the prowl to locate a target. This stage is easy to do and can be automated with tools such as Nmap. However, SPA ( and port knocking ) employs a default-drop stance that provides service only to those IP addresses that can prove their identity via a passive mechanism. No TCP/IP stack access is required to authenticate remote IP addresses. Therefore, Nmap cannot even tell that a server is running when protected with SPA, and whether the attacker has a zero-day exploit is irrelevant.
The idea around SPA is that a single packet is sent: based on that packet an authentication process is carried out. A key point to note is that there is nothing listening on the service itself so you have no open ports. For the SPA service to operate, there is not anything specifically listening. When the client sends a SPA packet, the packet will be rejected, but a second service identifies the SPA packet in the IP stack and then authenticates it.
If the SPA packet is successfully authenticated, the server will open a port in the server’s firewall which could be based on Linux iptables so that the client can establish a secure and encrypted connection with the intended service.
A simple SPA process flow
The SDP gateway protects assets and this component could be containerized and listens for SPA packets. In the case of an open-source version of SDP, this could be fwknop, which is a popular open-source SPA implementation.
When a client wants to connect to for example a web server, it sends a SPA packet. When the requested service receives the SPA packet, it will open the door once the credentials are verified. However, the service still does not respond to the request.
When the fwknop services receive a valid SPA packet, the contents of the packet will be decrypted for further inspection. Following the inspection, it will reveal the protocol and port numbers that the sender is requesting access to. The SDP gateway adds a rule to the firewall so that a mutual TLS connection to the intended service can be established. Once this mutual TLS connection is established, the SDP gateway removes the firewall rules and the service is invisible to the outside world.
Fwknop uses this information to open up firewall rules to allow the sender to communicate with that service on those ports. The firewall will only be opened up for a period of time which can be configurable by the administrator. Any attempts to connect to the service must know the SPA packet, and even if the packet can be recreated, the sequence number of the packet needs to be established prior to the connection. This is next to impossible to do considering the sequence numbers are randomly generated.
Once the firewall rules are removed, let’s say after 1 minute, the initial MTLS session will not be affected as it is already established. However, any other sessions requesting access to the service on those ports will be blocked. This permits only the sender of the IP address to be tightly coupled with the requested destination ports. It’s also possible for the sender to include a source port, enhancing security even further.
What can SPA offer
Let’s face it, robust security is hard to achieve. We all know that you can never be 100% secure. Just have a look at OpenSSH. OpenSSH was developed by some of the most security-conscious developers, and yet it occasionally contains exploitable vulnerabilities.
Even when you look at some of the attacks on TLS. We have already discussed the DigiNotar forgery in a previous post on zero trust networking but one that caused a major issue was the THC-SSL-DOS attack where a single host could take down a server by taking advantage of asymmetry performance required by the TLS protocol. Single Packet Authorization (SPA) overcomes many existing attacks and combined with the enhancements of MTLS with pinned certificates creates a robust security model. SPA defeats many a DDoS attack as only a limited amount of server performance is required for it to operate.
SPA provides the following security benefits to the SPA-protected asset:
- SPA blackens the gateway and protected assets that sit behind the gateway. The gateway does not respond to any connection attempts until they have provided an authentic SPA. Essentially, all network resources are dark until security controls are passed.
- SPA also mitigates DDoS attacks on TLS. More than likely, TLS is publicly reachable on the internet running the HTTPS protocol that is highly susceptible to DDoS. SPA mitigates these types of attacks because it allows the SDP gateway to discard the TLS DoS attempt before entering the TLS handshake. As a result, there will be no exhaustion from targeting the TLS port.
- SPA assists with attack detection. The first packet to an SDP gateway must be a SPA packet. If a gateway receives any other type of packet, it should be viewed and treated as an attack. Therefore, the SPA enables the SDP to identify an attack based on a single malicious packet.
For a general overview of zero trust concepts and projects such as software-defined perimeter, you can check out my course on ZERO TRUST NETWORKING: THE BIG PICTURE. If you would like more specifics on Single Packet Authorization (SPA) and how it relates to Software-Defined Perimeter (SDP), please see my other Zero Trust course on SOFTWARE-DEFINED-PERIMETER (SDP)