Single Packet Authorization

PortGuard

3.2 Service Protection in Cloud Environments

Scenario: Internal services (e.g., databases, web servers) in AWS, Azure, and other cloud platforms need to be accessed through the public network, but the ports need to be avoided from being directly exposed.

Implementation: PortGuard integrates with NAT to allow external clients to access internal services in the RFC 1918 address space through SPA.

Advantages: Supports complex network topologies, suitable for hybrid cloud and multi-tenant environments.

Example: Run fwknopd on AWS EC2 instances, dynamically open the MySQL port (3306) for authorized users to access.

3.3 Defend Against Port Scanning and Brute Force

Scenario: Servers face port scanning (e.g., Nmap) or brute force attacks, and need to hide service ports to reduce the attack surface.

Implementation: PortGuard maintains the default drop firewall policy, only opening ports after receiving valid SPA data packets.

Advantages: Even if there are unpatched vulnerabilities, attackers cannot discover service ports.

Example: Prevent SSH brute force, fwknop only opens ports after verifying HMAC.

3.4 Support Multiple Service Protection

Scenario: Enterprises need to protect multiple services (e.g., SSH, RDP, VPN, database) but do not want all ports to be open all the time.

Implementation: fwknop supports defining multiple services and ports in access.conf, and the client can specify the target protocol and port.

Advantages: Flexible rule configuration, support custom timeout and port open strategies.

Example: Configure fwknop to protect both SSH (tcp/22) and OpenVPN (udp/1194).

3.5 Embedded or IoT Device Security

Scenario: IoT devices or embedded systems need remote management, but the device resources are limited and vulnerable to attacks.

Implementation: Run lightweight fwknopd or tnokd on resource-constrained devices, control access through SPA or TOTP.

Advantages: Low resource consumption, suitable for small devices.

Example: Protect the Web service running on Raspberry Pi.

3.6 Third-Party Device Integration

Scenario: Need to integrate with devices that do not support native fwknop (e.g., Cisco routers), control firewall rules.

Implementation: The command open/close cycle (command open/close cycle) feature of fwknop allows executing custom scripts to dynamically modify the ACL of third-party devices.

Advantages: Extensible, support non-standard firewall devices.

Example: Run fwknopd on Linux servers, update the ACL of Cisco routers through SSH.

3.7 Technical Details

• fwknop supports defining timeout (CMD_CYCLE_TIMER), port open automatically closed, reducing exposure time.
• Can be combined with VPN (e.g., WireGuard, OpenVPN) to build a secure private network.
• Supports X-Forwarded-For header parsing, suitable for SPA in HTTP environment.

4.2 Prevent Port Scanning

Mechanism: PortGuard uses the default drop firewall policy, and the service port is invisible when not authorized, so Nmap and other tools cannot detect it.

Security: Significantly reduces the attack surface, even if there are zero-day vulnerabilities, attackers cannot locate the service port.

Limitations: If the knock data packet is sniffed (traditional port knocking is more susceptible to this), attackers may attempt replay (SPA has solved this problem through HMAC).

4.3 Resist Brute Force

Mechanism: SPA data packets need to be correctly encrypted and HMAC authenticated, brute force is almost impossible (data packets with failed HMAC are discarded directly).

Security: Compared to traditional port knocking, SPA's single-packet design and encryption mechanism significantly improve the ability to resist brute force.

Limitations: Configuration errors (e.g., weak keys or disabled HMAC) may reduce security.