SPA: A Security Protocol

Single Packet Authorization (SPA) is a security protocol allowing users to access a secure network without entering a password or other credentials. Instead, it is an authentication protocol that uses a single packet—an encrypted packet of data—to convey a user’s identity and request access. This packet can be sent over any network protocol, such as TCP, UDP, or SCTP, and is typically sent as an additional layer of authentication beyond the network and application layers.

SPA works by having the user’s system send a single packet of encrypted data to the authentication server. The authentication server then uses a unique algorithm to decode the packet containing the user’s identity and request for access. If the authentication is successful, the server will send a response packet that grants access to the user.

SPA is a secure and efficient way to authenticate and authorize users. It eliminates the need for multiple authentication methods and sensitive data storage. SPA is also more secure than traditional authentication methods, as the encryption used in SPA is often more secure than passwords or other credentials.

Additionally, since the packet sent is encrypted, it cannot be intercepted and decoded, making it an even more secure form of authentication.

The Mechanics of SPA:

SPA operates by employing a shared secret between the client and server. When a client wishes to access a service, it generates a packet containing a specific data sequence, including a timestamp, payload, and cryptographic hash. The server, equipped with the shared secret, checks the received packet against its calculations. The server grants access to the requested service if the packet is authentic.

Implementing SPA:

Implementing SPA requires deploying specialized software or hardware components that support the single packet authorization protocol. Several open-source and commercial solutions are available, making it feasible for organizations of all sizes to adopt this innovative security technique.

Back to Basics: Zero Trust

Five fundamental assertions make up a zero-trust network:

• Networks are always assumed to be hostile.
• The network is always at risk from external and internal threats.
• To determine trust in a network, locality alone is not sufficient.
• A network flow, device, or user must be authenticated and authorized.
• Policies must be dynamic and derived from as many data sources as possible to be effective.

Different networks are divided into firewall-protected zones in a traditional network security architecture. Each zone is permitted to access network resources based on its level of trust. This model provides a solid defense in depth. In DMZs, traffic can be tightly monitored and controlled over riskier resources, like those facing the public internet.

Perimeter Defense

a) Perimeter defenses protecting your network are less secure than you might think. Hosts behind the firewall have no protection, so when a host in the “trusted” zone is breached, which is just a matter of time, access to your data center can be breached. The zero-trust movement strives to solve the inherent problems of placing our faith in the network.

b) Instead, it is possible to secure network communication and access so effectively that the physical security of the transport layer can be reasonably disregarded.

c) Typically, we examine the remote system’s IP address and ask for a password. Unfortunately, these strategies alone are insufficient for a zero-trust network, where attackers can communicate from any IP and insert themselves between themselves and a trusted remote host.

d) Therefore, utilizing strong authentication on every flow in a zero-trust network is vital. The most widely accepted method is a standard named X.509.

A key aspect of zero-trust network ZTN and zero-trust principles is authenticating and authorizing 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 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; only authorized flows can 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.

Mutually authenticated TLS (MTLS)

Mutually authenticated TLS (Transport Layer Security) is a system of cryptographic protocols used to establish secure communications over the Internet. It guarantees that the client and the server are who they claim to be, ensuring secure communications between them. This authentication is accomplished through digital certificates and public-private key pairs.

Mutually authenticated TLS is also essential for preventing man-in-the-middle attacks, where a malicious actor can intercept and modify traffic between the client and server. Without mutually authenticated TLS, an attacker could masquerade as the server and thus gain access to sensitive data.

Setting Up MTLS

To set up mutually authenticated TLS, the client and server must have digital certificates. The server certificate is used to authenticate the server to the client, while the client certificate is used to authenticate the client to the server. Both certificates are signed by the Certificate Authority (CA) and can be stored in the server and client’s browsers. The client and server then exchange the certificates to authenticate each other.

The client and server can securely communicate once the certificates have been exchanged and verified. Mutually authenticated TLS also provides encryption and integrity checks, ensuring the data is not tampered with in transit.

Enhanced Version of TLS

This enhanced version of TLS, known as mutually authenticated TLS (MTLS), is used to validate both ends of the connection. The most common TLS configuration is the validation, which ensures the client is connected to a trusted entity. However, the authentication doesn’t happen the other way around, so the remote entity communicates 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 identify trusted users. SPA is a step up from port knocking.

Port-Knocking Scenario

The typical port-knocking scenario involves a port-knocking server configuring a packet filter to block all access to a service, such as the SSH service until a port-knocking client sends a specific port-knocking sequence. For instance, 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 rules.

SPA & Port Knocking

As a next-generation Port Knocking (PK), SPA overcomes many limitations PK exhibits while retaining its core benefits. However, PK has several limitations, including difficulty protecting against replay attacks, the inability to reliably support asymmetric ciphers and HMAC schemes, and the fact that it is trivially easy to mount a DoS attack by spoofing an additional packet into a PK sequence while it is traversing the network (thereby convincing the PK server that the client does not know the proper sequence).

SPA solves all of these shortcomings. As part of SPA, services are hidden behind a default-drop firewall policy, SPA data is passively acquired (usually via libpcap), and standard cryptographic operations are implemented for SPA packet authentication and encryption/decryption.

Firewall Knock Operator

Fwknop (short for the “Firewall Knock Operator”) is a single-packet authorization system designed to be a secure and straightforward way to open up services on a host running an iptables- or ipfw-based firewall. It is a free, open-source application that uses the Single Packet Authorization (SPA) protocol to provide secure access to a network.

Fwknop sends a single SPA packet to the firewall containing an encrypted message with authorization information. The message is then decrypted and compared against a set of rules on the firewall. If the message matches the rules, the firewall will open access to the service specified in the packet.

No need to manually configure the firewall each time

Fwknop is an ideal solution for users who need to access services on a remote host without manually configuring the firewall each time. It is also a great way to add an extra layer of security to already open services.

To achieve strong concealment, fwknop implements the SPA authorization scheme. SPA requires only a single packet encrypted, non-replayable, and authenticated via an HMAC to communicate desired access to a service hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to connect to services such as SSH to make exploiting vulnerabilities (both 0-day and unpatched code) more difficult. Because there are no open ports, any service SPA hides cannot be scanned with, for example, NMAP.

Supported Firewalls:

The fwknop project supports four firewalls: Support iptables, firewall, PF, and ipfw across Linux, OpenBSD, FreeBSD, and Mac OS X. We also support custom scripts so that fwknop can be made to help other infrastructure, such as upset or nftables.

Example use case: SSHD protection

Users of Single Packet Authorization (SPA) or its less secure cousin, Port Knocking (PK), usually access SSHD running on the same system as the SPA/PK software. A SPA daemon temporarily permits access to a passively authenticated SPA client through a firewall configured to drop all incoming SSH connections. This is considered the primary SPA usage.

In addition to this primary use, fwknop also makes robust use of NAT (for iptables/firewalld firewalls). A firewall is usually deployed on a single host and acts as a gateway between networks. Firewalls that use NAT (at least for IPv4 communications) commonly provide Internet access to internal networks on RFC 1918 address space and access to internal services by external hosts.

Since fwknop integrates with NAT, users on the external Internet can access internal services through the firewall using SPA. Additionally, it allows fwknop to support cloud computing environments such as Amazon’s AWS, although it has many applications on traditional networks.

Single Packet Authorization and Single Packet Authentication

Single Packet Authorization (SPA) uses proven cryptographic techniques to make internet-facing servers invisible to unauthorized users. Only devices seeded with the cryptographic secret can generate a valid SPA packet and establish a network connection. This is how it reduces the attack surface and becomes invisible to hostile reconnaissance.

SPA Single Packet Authorization was invented over ten 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 attacks targeted at the TLS ports.

As mentioned, SDP didn’t invent new protocols; it was more binding existing protocols. SPA used in 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.

Surveillance: The first step

The first step in an attack is reconnaissance, whereby an attacker is on the prowl to locate a target. This stage is easy 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 tell that a server is running when protected with SPA, and whether the attacker has a zero-day exploit is irrelevant.

Process: Single Packet Authentication

The idea around SPA and Single Packet Authentication is that a single packet is sent, and based on that packet, an authentication process is carried out. The critical point is that nothing is listening on the service, so you have no open ports. For the SPA service to operate, there is nothing explicitly listening.

When the client sends an SPA packet, it will be rejected, but a second service identifies it in the IP stack and authenticates it. If the SPA packet is successfully authenticated, the server will open a port in the 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 Single Packet Authentication process flow

The SDP network gateway protects assets, and this component could be containerized and listened to for SPA packets. In the case of an open-source version of SDP, this could be fwknop, which is a widespread open-source SPA implementation. When a client wants to connect to 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 has not responded to the request.

When the fwknop services receive a valid SPA packet, the contents are decrypted for further inspection. The inspection reveals the protocol and port numbers to which the sender requests access. Next, the SDP gateway adds a rule to the firewall to establish a mutual TLS connection to the intended service. Once this mutual TLS connection is established, the SDP gateway removes the firewall rules, making the service invisible to the outside world.

Fwknop uses this information to open firewall rules, allowing the sender to communicate with that service on those ports. The firewall will only be opened for some time and can be configured by the administrator. Any attempts to connect to the service must know the SPA packet, and even if the packet can be recreated, the packet’s sequence number needs to be established before the connection. This is next to impossible, 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, 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 Single Packet Authorization 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. Some of the most security-conscious developers developed OpenSSH, yet it occasionally contains exploitable vulnerabilities.

Even when you look at some attacks on TLS, we have already discussed the DigiNotar forgery in a previous post on zero-trust networking. Still, one that caused a significant issue was the THC-SSL-DOS attack, where a single host could take down a server by taking advantage of the 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 addition; SPA defeats many a DDoS attack as only a limited amount of server performance is required to operate.

SPA provides the following security benefits to the SPA-protected asset:

• • SPA blackens the gateway and protects assets that sit behind the gateway. The gateway does not respond to connection attempts until it provides an authentic SPA. Essentially, all network resources are dark until security controls are passed.
  • SPA also mitigates DDoS attacks on TLS. TLS is likely publicly reachable online, and running the HTTPS protocol is highly susceptible to DDoS. SPA mitigates these attacks by allowing 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 malicious packet.