Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : 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 SPA and basic SSH access 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 1. 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 SPA and DNAT SSH access to internal host 2. 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 SPA and SNAT to external hosts A quick note on the network diagrams above - each red line represents a connection that is only possible to establish after a proper SPA packet is sent. 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 1429387561 Conclusion 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.






Les derniers articles du site "cipherdyne.org System and Network Security" :

- Single Packet Authorization and Third Party Devices
- Software Release fwknop-2.6.7
- Android Fwknop2 Client and OpenWRT
- New Android Single Packet Authorization Client Fwknop2
- NAT and Single Packet Authorization
- Single Packet Authorization Threat Modeling
- RAM Disks and Saving Your SSD From AFL Fuzzing
- Integrating fwknop with the 'American Fuzzy Lop' Fuzzer
- Software Release fwknop-2.6.4
- Code Coverage Challenges For Open Source Projects

---

S'abonner au fil RSS global de la revue de presse

---