Introduction: The Vulnerability of the Open Port

In the modern enterprise infrastructure landscape, Secure Shell (SSH) is the bedrock of remote administration. However, relying on standard SSH configurations introduces a persistent security risk: visibility. Even when protected by strong cryptographic keys and non-standard ports, an open port is an invitation to malicious actors. Automated bots and sophisticated scanners continuously traverse the IPv4 and IPv6 address spaces, looking for open ports to target with brute-force attacks, zero-day exploits, and denial-of-service (DoS) attempts.

Traditionally, security teams have relied on IP whitelisting or Virtual Private Networks (VPNs) to restrict access. Yet, these solutions introduce operational overhead and single points of failure. What if you could make your SSH port completely invisible to the outside world, responding only to authorized users while dropping all other traffic by default? This is the core promise of Single Packet Authorization (SPA), implemented via the open-source utility fwknop (FireWall Knock Operator).

The Evolution of Stealth: Port Knocking vs. Single Packet Authorization

To understand the elegance of Single Packet Authorization, it is essential to contrast it with its predecessor: legacy port knocking. Traditional port knocking requires a client to send a specific sequence of connection attempts to closed ports (e.g., TCP SYN packets to ports 1000, 2000, and 3000 in sequence). A daemon listening on the firewall detects this exact sequence and temporarily opens the desired port (like Port 22) for the client's IP address.

While innovative, legacy port knocking suffers from several critical vulnerabilities:

Replay Attacks: An attacker monitoring network traffic can capture the sequence of connection attempts and replay them to open the port.
Protocol Overhead and Speed: Sending multiple packets takes time and can be disrupted by network latency or out-of-order packet delivery.
Traffic Visibility: The distinct sequence of packets across multiple ports can be easily flagged by simple intrusion detection systems (IDS).

Single Packet Authorization (SPA) solves these flaws by condensing the authorization request into a single, heavily encrypted packet. This packet is sent via UDP or ICMP, payload-encoded, and immediately processed by the firewall architecture without completing a traditional network handshake.

How fwknop and SPA Work Under the Hood

The fwknop utility leverages the packet capture library (libpcap) to passive-sniff incoming network traffic. Because it sniffs traffic before the host operating system's firewall processes it, the firewall can be configured to DROP all incoming connections to Port 22 by default. To an external port scanner, the server appears entirely dead or non-existent.

The standard architectural workflow of an SPA connection follows these distinct phases:

Packet Generation: The client-side fwknop utility generates an encrypted payload containing a random 16-byte salt, the client's current IP address, a timestamp, the client software version, and the requested access rule (e.g., access to TCP port 22).
Encryption: This payload is encrypted using either Symmetric encryption (Rijndael/AES) or Asymmetric encryption (GnuPG public/private keys), combined with an HMAC (Hash-based Message Authentication Code) to guarantee data integrity.
Transmission: The client sends this single data payload via a single UDP packet (typically to port 62201) to the destination server.
Passive Analysis: On the server, the fwknopd daemon detects the incoming packet via libpcap. It decrypts the payload, validates the timestamp (to prevent replay attacks), verifies the HMAC, and extracts the client's IP address.
Dynamic Firewall Modification: If validation succeeds, fwknopd executes a local command to temporarily inject an iptables or nftables rule, permitting the client's specific IP address to access Port 22 for a restricted window (e.g., 30 seconds).
Establishment and Tear-down: The user successfully initiates their SSH session. Once the initial window expires, fwknopd removes the firewall rule. Active connections remain undisturbed, but no new connections can be initiated without sending a new SPA packet.

Note: Because the server never replies to unauthorized SPA packets or port scans, it remains completely invisible to the network. There is no open port to attack, no banner to grab, and no cryptographic handshake to exploit.

Step-by-Step Deployment Guide

Implementing fwknop requires configuration on both the target server and the client machine. Below is a structured guide assuming an Enterprise Linux or Ubuntu LTS environment.

Step 1: Installing fwknop

First, update your package repositories and install the daemon on the server, and the client application on your local machine.

On the server:

sudo apt-get update
sudo apt-get install fwknop-server

On the client:

sudo apt-get install fwknop-client

Step 2: Configuring the Server Daemon

The server configuration relies on two primary files: /etc/fwknop/fwknopd.conf (global settings) and /etc/fwknop/access.conf (access rules and keys).

Open /etc/fwknop/fwknopd.conf and ensure the daemon is listening on the correct network interface:

PCAP_INTF    eth0;

Next, define the access controls in /etc/fwknop/access.conf. We will generate strong keys for authentication and integrity checking:

SOURCE          ANY
REQUIRE_SOURCE_ADDRESS  Y
KEY_BASE64      [Generated_Symmetric_Key]
HMAC_KEY_BASE64 [Generated_HMAC_Key]
FORCE_NAT_PORTS 22

Step 3: Configuring the Firewall

With fwknopd ready, you must configure your firewall to drop all unsolicited SSH connections. Execute the following rules to establish a default-drop policy for port 22, while allowing established connections to persist:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j DROP

Step 4: Client Execution and Testing

On your local workstation, save your access configuration keys into the local runtime environment. To knock and open the port, execute the client command:

fwknop -A tcp/22 -D server_ip_address --named-config server_profile

Upon sending the packet, you will have a temporary window to establish your secure SSH session:

ssh user@server_ip_address

Business Benefits of SPA Implementation

Integrating Single Packet Authorization into your enterprise infrastructure security model yields immediate strategic advantages:

Zero Attack Surface: Automated reconnaissance networks and opportunistic hackers cannot target services they cannot discover. Eliminating public-facing listening ports radically reduces your digital footprint.
Mitigation of Zero-Day Vulnerabilities: Even if a critical vulnerability is discovered within the OpenSSH daemon itself, attackers cannot exploit it because they cannot route packets to the daemon without being authenticated first at the firewall layer.
Compliance and Logging: SPA provides clean, centralized audit logs of authentication attempts before an application-level login even occurs, facilitating adherence to rigorous regulatory standards such as PCI-DSS and ISO 27001.

Conclusion

Relying solely on traditional perimeter defenses leaves enterprise infrastructure vulnerable to highly sophisticated network discovery tactics. By decoupling network authorization from application session establishment, Single Packet Authorization via fwknop shifts the paradigm from visible defenses to absolute stealth. Implementing SPA ensures that your critical infrastructure components remain hidden from plain sight, maintaining security, operational integrity, and peace of mind.

Securing SSH with Single Packet Authorization (SPA) Using fwknop: Stealthing Port 22 from Scanners