Securing Infrastructure: Hiding SSH Ports Completely Using Single Packet Authorization (SPA) and OpenBSD Authpf

Introduction to Stealth Infrastructure

In modern enterprise cybersecurity, perimeter defense relies heavily on minimizing the attack surface. Traditional Secure Shell (SSH) deployments, even when secured with public-key authentication and non-standard ports, remain vulnerable to reconnaissance, zero-day exploits, and persistent brute-force scanning. Every open port is an invitation for malicious actors to probe for weaknesses.

To achieve true stealth, organizations are increasingly turning to Single Packet Authorization (SPA). Unlike traditional port knocking, which requires a sequence of TCP connections and is susceptible to replay attacks, SPA uses a single, cryptographically secure packet to temporarily open a firewall rule. When combined with OpenBSD's robust authpf (Authenticating Gateway User Shell) subsystem and the native pf (Packet Filter), administrators can construct a highly secure gateway where the SSH daemon remains completely invisible to unauthorized entities. This guide explores the architectural concepts and provides a comprehensive implementation path for securing enterprise gateways using OpenBSD.

Understanding the Core Components

Before diving into configuration, it is essential to understand how these technologies interact to create a dynamic, zero-trust network boundary.

What is Single Packet Authorization (SPA)?

SPA represents an evolution in network knocking mechanisms. A client wishing to connect to a protected service sends a single UDP packet containing an encrypted, authenticated payload. This payload typically includes timestamps, client IP addresses, and cryptographic signatures. The server-side daemon listens passively via packet capture, decodes the payload, validates its authenticity, and modifies firewall rules on the fly to allow access from the client's IP address. To an external scanner, the port appears closed or filtered at all times.

The Role of OpenBSD Authpf

OpenBSD's authpf is a specialized user shell designed to change firewall rules upon successful user authentication. When a user connects to an authpf gateway via SSH, the system authenticates the credentials and executes the authpf shell. This process automatically inserts customized packet filtering rules into a dedicated pf anchor, mapping specifically to the user's current external IP address. Once the session terminates, the rules are instantly destroyed, closing the window of vulnerability. By nesting SPA in front of authpf, we achieve two layers of cryptographic isolation.

Architectural Overview and Prerequisites

The architecture consists of a hardened OpenBSD gateway routing or proxying connections to internal systems, or simply protecting its own management interface. The following prerequisites must be met before proceeding:

A functional installation of OpenBSD (version 7.0 or later recommended).
Administrative privileges (root access) on the gateway.
An active network configuration utilizing the Packet Filter (pf) firewall.
An SPA daemon installed on the server; for this guide, we will utilize fwknop (Firewall Knock Operator), which supports native pf integration.

Step-by-Step Implementation Guide

Step 1: Configuring the Packet Filter (pf.conf)

The foundation of this setup lies within /etc/pf.conf. We must ensure that all incoming SSH requests are blocked by default, while defining the placeholder anchor where authpf will dynamically inject rules.

Crucial Note: Misconfiguring pf.conf can cause immediate loss of remote management access. Always maintain an out-of-band console session (such as serial console or IPMI) during initial setup.

Edit your /etc/pf.conf to incorporate the following structure:

# Interfaces
ext_if = "vio0"

# Default policies
set skip on lo0
block all

# Define the authpf anchor
anchor "authpf/*"

# Allow essential outgoing traffic
pass out on $ext_if proto tcp to any keep state
pass out on $ext_if proto udp to any keep state

# Allow SPA (fwknop) packets passively
pass in on $ext_if proto udp from any to any port 62201 keep state

Reload the firewall configurations to apply the baseline security structure:

# pfctl -f /etc/pf.conf

Step 2: Implementing and Configuring fwknopd

Install the Firewall Knock Operator daemon via OpenBSD packages:

# pkg_add fwknopd

Next, configure the daemon behavior in /etc/fwknop/fwknopd.conf. Ensure the daemon points to the correct network interface and is configured to talk directly to pf via the appropriate anchor structures:

PCAP_INTF                vio0;
ENABLE_PF_ANCHOR         Y;
PF_ANCHOR_NAME           authpf/fwknop;

Define your cryptographic access parameters in /etc/fwknop/access.conf. This file maps client keys to specific firewall operations:

SOURCE                   ANY
REQUIRE_SOURCE_ADDRESS   Y
KEY_BASE64               [Insert_Base64_Shared_Key]
HMAC_KEY_BASE64          [Insert_Base64_HMAC_Key]
FORWARD_ACCESS           tcp/22

Enable and start the daemon using the system resource controller:

# rcctl enable fwknopd
# rcctl start fwknopd

Step 3: Setting Up Authpf Subsystem

With SPA successfully screening incoming requests, we now configure authpf to handle user-level dynamic permissions. Create the global configuration file at /etc/authpf/authpf.conf. This file can remain empty but must exist for the subsystem to initialize properly.

Next, define the specific rules that authpf will append to the anchor upon successful validation. Create /etc/authpf/authpf.rules:

ext_if = "vio0"
pass in on $ext_if proto tcp from $user_ip to any port 22 keep state

Create a dedicated system user whose shell is explicitly routed through authpf:

# useradd -m -s /usr/sbin/authpf gatekeeper
# passwd gatekeeper

Verifying the Security Workflow

To establish a connection, the client workflow operates as follows:

The Reconnaissance Phase: A standard port scan against the OpenBSD gateway reveals port 22 as completely filtered or closed. No banner grabbing is possible.
The SPA Trigger: The client executes the fwknop client utility, sending an encrypted payload to UDP port 62201.
Firewall Modification: The server-side fwknopd processes the packet, verifies the HMAC, decrypts the contents, and appends a temporary rule allowing the client's IP to communicate with port 22.
User Authentication: The client establishes an SSH connection using the gatekeeper account. Upon successful public-key authentication, authpf initializes and locks the session open.

Conclusion and Operational Considerations

By nesting Single Packet Authorization with OpenBSD's native authpf, organizations achieve a highly resilient security posture. Even if an attacker discovers a vulnerability within the OpenSSH daemon, they cannot exploit it because they cannot route packets to the daemon without the appropriate SPA cryptographic keys. This layered approach implements a true zero-trust perimeter, making it an exceptional pattern for critical corporate infrastructure and remote management nodes. Maintain strict key rotation schedules for your SPA keys to ensure long-term operational integrity.