NAT and Single Packet Authorization
23 April, 2015
People who use Single Packet Authorization (SPA) or its security-challenged cousin Port Knocking (PK) usually access SSHD running on the same system where the SPA/PK software is deployed. That is, a firewall running on a host has a default-drop policy against all incoming SSH connections so that SSHD cannot be scanned, but a SPA daemon reconfigures the firewall to temporarily grant access to a passively authenticated SPA client:
This works
well enough,
but both port knocking and SPA work in conjunction with a firewall, and "important" firewalls
are usually gateways between networks as opposed to just being deployed on standalone hosts.
Further, Network Address Translation (NAT) is commonly used on such firewalls (at least
for IPv4 communications) to provide Internet access to internal networks that are on
RFC 1918 address space, and also to allow external hosts access to services hosted on
internal systems.
The prevalence of NAT suggests that SPA should integrate strongly with it. Properly done, this would extend the notion of SPA beyond just supporting the basic feature of granting access to a local service. To drive this point home, and to see what a NAT-enabled vision for SPA would look like, consider the following two scenarios:
- A user out on the Internet wants to leverage SPA to access an SSH daemon that
is running on a system behind a firewall.
One option is to just use SPA to access SSHD on the firewall first, and then
initiate a new SSH connection to the desired internal host from the firewall itself.
However, this is clunky and unnecessary. The SPA system should just integrate with
the NAT features of the firewall to translate a SPA-authenticated incoming SSH
connection through to the internal host and bypass the firewall SSH daemon
altogether:
- A local user population is behind a firewall that is configured to block all access
by default from the internal network out to the Internet. Any user can acquire an IP on
the local network via DHCP, but gaining access to the Internet is only possible after
authenticating to the SPA daemon running on the firewall. So, instead of gaining
access to a specific service on a single IP via SPA, the local users leverage SPA
to gain access to every service on every external IP. In effect,
the firewall in this configuration does not trust the local user population, and Internet
access is only granted for users that can authenticate via SPA. I.e., only those users
who have valid SPA encryption and HMAC keys can access the Internet:
Both of the above scenarios are supported with fwknop-2.6.6, which has been released today. So far, to my knowledge, fwknop is the only SPA/PK implementation with any built-in NAT support. The first scenario of gaining access to an internal service through the firewall has been supported by fwknop for a long time, but the second is new for 2.6.6. The idea for using SPA to gain access to the Internet instead of just for a specific service was proposed by "spartan1833" to the fwknop mailing list, and is a powerful extension of SPA into the world of NAT - in this case, SNAT in iptables parlance.
Before diving into the technical specifics, below is a video demonstration of the NAT capabilities of fwknop being used within Amazon's AWS cloud. This shows fwknop using NAT to turn a VPC host into a new gateway within Amazon's own border controls for the purposes of accessing SSH and RDP running on other internal VPC hosts. So, this illustrates the first scenario above. In addition, the video shows the usage of SPA ghost services to NAT both SSH and RDP connections through port 80 instead of their respective default ports. This shows yet another twist that strong NAT integration makes possible in the SPA world.
Now, let's see a practical example. This is for the second scenario above where a system with the fwknop client installed is on a network behind a default-drop firewall running the fwknop daemon, and the new SNAT capabilities are used to grant access to the Internet.
First, we fire up fwknopd on the firewall after showing the access.conf and fwknopd.conf files (note that some lines have been abbreviated for space):
[firewall]# cat /etc/fwknop/access.conf SOURCE ANY KEY_BASE64 wzNP62oPPgEc+k...XDPQLHPuNbYUTPP+QrErNDmg= HMAC_KEY_BASE64 d6F/uWTZmjqYor...eT7K0G5B2W9CDn6pAqqg6Oek= FW_ACCESS_TIMEOUT 1000 FORCE_SNAT 123.1.2.3 DISABLE_DNAT Y FORWARD_ALL Y [firewall]# cat /etc/fwknop/fwknopd.conf ENABLE_IPT_FORWARDING Y; ENABLE_IPT_SNAT Y; [firewall]# fwknopd -i eth0 -f Starting fwknopd Added jump rule from chain: FORWARD to chain: FWKNOP_FORWARD Added jump rule from chain: POSTROUTING to chain: FWKNOP_POSTROUTING iptables 'comment' match is available Sniffing interface: eth3 PCAP filter is: 'udp port 62201' Starting fwknopd main event loop.With the fwknopd daemon up and running on the firewall/SPA gateway system, we now run the client to gain access to the Internet after showing the "[internet]" stanza in the ~/.fwknoprc file:
[spaclient]$ cat ~/.fwknoprc [internet] KEY_BASE64 wzNP62oPPgEc+k...XDPQLHPuNbYUTPP+QrErNDmg= HMAC_KEY_BASE64 d6F/uWTZmjqYor...eT7K0G5B2W9CDn6pAqqg6Oek= ACCESS tcp/22 ### ignored by FORWARD_ALL SPA_SERVER 192.168.10.1 USE_HMAC Y ALLOW_IP source [spaclient]$ nc -v google.com 80 ### nothing comes back here because the SPA packet hasn't been sent yet ### and therefore everything is blocked (except for DNS in this case) [spaclient]$ fwknop -n internet [spaclient]$ nc -v google.com 80 Connection to google.com 80 port [tcp/http] succeeded!Back on the server, below are the rules that are added to grant Internet access to the spaclient system. Note that all ports/protocols are accepted for forwarding through the firewall, and an SNAT rule has been applied to the spaclient source IP of 192.168.10.55:
(stanza #1) SPA Packet from IP: 192.168.10.55 received with access source match Added FORWARD ALL rule to FWKNOP_FORWARD for 192.168.10.55 -> 0.0.0.0/0 */*, expires at 1429387561 Added SNAT ALL rule to FWKNOP_POSTROUTING for 192.168.10.55 -> 0.0.0.0/0 */*, expires at 1429387561Conclusion
Most users think of port knocking and Single Packet Authorization as a means to passively gain access to a service like SSHD running on the same system as the PK/SPA software itself. This notion can be greatly extended through strong integration with NAT features in a firewall. If the SPA daemon integrates with SNAT and DNAT (in the iptables world), then both internal services can be accessed from outside the firewall, and Internet access can be gated by SPA too. The latest release of fwknop supports both of these scenarios, and please email me or send me a message on Twitter @michaelrash if you have any questions or comments.
