On Jun 01, 2009, Sebastien J. wrote: > Hi Patrick, > > It is true that this is one of the primary remaining issues with SPA. The > server receiving the packet only sees the public IP of the client. At the > moment there isn't a solution to this, as IPv4 doesn't provide any kind of > authentication at the network level. Once the server has verified the SPA > packet, it can only open the necessary port to <public IP>. It can't > distinguish <host1>@<publicIP> from <host2>@<publicIP>. But generally this > problem permeates into computer security as a whole. The MITM attacker almost > always has supreme power by having the luxury of manipulating traffic until > it suits him. > > The purpose of SPA is simply to add another layer of security. In 99% of > cases you won't have a malicious attacker in a MITM position who is watching > all traffic. Remember that defeating SPA only brings you back to square one: > authenticating/attacking the original service. For a MITM attacker to take > advantage of his situation, if SPA were protecting port 22 of a server for > example, he would have to wait for a valid SPA packet to fly by, open a > connection to the server, and send an exploit and/or login with a valid > username/pass. He definitely won't have enough time for a dictionary or brute > force attack of any kind.
Just a quick note on this - I completely agree that the NAT issue still remains as a bit of a problem for both SPA and port knocking, but there is one strategy that fwknop offers to mitigate this to some degree: port randomization. The typical case where a NAT gives the same access to an attacker as a legitimate fwknop client involves two things I think - the ability of the attacker to sniff traffic (in order to see the SPA packet and the destination IP it is going to) and seeing which service is being accessed (say, SSH). But, the SPA packet can be sent over a random port, and it can request that the service itself is accessible over a randomly assigned port as well (by using iptables NAT rules on the fwknopd server side). So, this would force the attacker to watch a lot more traffic in order to see what's happening because the SPA packet might travel over, say, port 10103, and then the SSH connection itself might be made over port 40134. Also, there is no necessary link between the destination IP in the SPA packet (which is open for all to see) and the IP where a service will be accessed. If the SPA packet is sent over the Tor network, or if the fwknopd server is in a position to monitor an SPA packet that is in route to an unrelated IP, then an attacker on the same network as the client will not be able to link this communication with the IP where a service is accessed. Although if all communications can be watched there is a brief window where the attacker can access the service directly just as the legitimate client does. Still, these factors make it harder for the attacker to know where and how this access will be made so it forces them to do more work. Here is a blog post that discusses a few of these issues: http://www.cipherdyne.org/blog/2008/06/single-packet-authorization-with-port-randomization.html Even with all of this, I think Sebastien's point about defeating SPA only brings you back to square one of authenticating/attacking the original service is the most important. SPA is additive. Thanks, --Mike > I haven't researched it much yet, but IPv6 may be able to bring some > developments in this area as it offers native authentication. I'd be happy to > find a better solution before then ;) > > Sincerely, > Sebastien > > > On Monday, June 01, 2009, at 04:41PM, "patrick koping" > <[email protected]> wrote: > > > >Hello! > > > >I recently got around to try out fwknop and I must say it's really sweet! > > > >One question popped up though: > > > >I can't figure out what one would gain in security against a MITM attack > >using the resolving of ones public IP, > >if one would be located behind a NAT'ing router? Somewhere in the > >documentation, there was a note > >about an attacker being on the same private net, but what kind of > >configuration would > >protect against that (except the obvious with using encrypted communication > >as usual). > > > >As I am testing now, having two servers behind the same NAT firewall, one of > >them sends the SPA packet and both > >of them can connect openVPN to the receiving openVPN server. Now this is ok > >because I want them to be able > >to connect, but as I see it, it defeats the whole purpose of fwknop, as I > >can't trust the NAT'ed net. > > > > > >Regards > >Patrick > > > >_________________________________________________________________ > >Vi vet vem du passar ihop med! Klicka här för att få veta! > >http://dejting.se.msn.com/channel/index.aspx?trackingid=1002952 > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Fwknop-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Fwknop-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
