3 ms·

Curious. What brand/model of router did you use? My suspicion is that the manufacturer might be being "helpful" by bundling aspects of NAT configuration into it

Curious. What brand/model of router did you use? My suspicion is that the manufacturer might be being "helpful" by bundling aspects of NAT configuration into its firewall configuration screen—so by disabling the firewall, you've also reconfigured the pseudo-firewall packet dropping behaviour of a typical NAT implementation. Regardless as I have repeatedly said, this isn't sufficient to invalidate my claim. To recap, here's claim I made which you are attempting to dispute: "NAT does provide some security, it’s just uncertain, unreliable..." and "...it sometimes makes inbound more difficult under certain circumstances. It’s not real security. But it’s also not nothing." and "however weak it may be, in the real world where normal people live, NAT is the first line of defence against inbound attacks for most personal computers" Your counterpoint is that some non-zero number of NAT routing implementations will pass a very specific kind of traffic onto local IPs. Cool. For the sake of argument let's assume that's true of all consumer routers. All you've proven is that you're potentially at risk if the attacker has assumed control of the first outbound hop at your ISP. This doesn't for one second disprove that NAT has pseudo-firewall behaviour for any traffic passing through your ISP, which is the case for 99.99% of real world security threats.

Dagger2 6y ago
I used OpenWRT, and bypassed the firewall with `iptables -I FORWARD -j ACCEPT`. There are no NAT-related rules in that chain, so I didn't do anything to the behavior of the NAT. > Regardless as I have repeatedly said, this isn't sufficient to invalidate my claim Okay, let's be clear: you've made an unsubstantiated claim with no evidence that isn't backed up by the known behavior of NAT. Your only support for this claim is to say that it's "trivial to prove" by doing this test, and when I actually went and did this test, it failed to prove your point. Rather than invalidating your claim, it would be more accurate to say that neither of us has been able to validate it. > This doesn't for one second disprove that NAT has pseudo-firewall behaviour for any traffic passing through your ISP, which is the case for 99.99% of real world security threats. You're in luck: I have the necessary setup to test this as well. I happen to have a server subnet that's reachable from the internet, so let's try NATing the outbound connections from it and seeing what happens. (I'm going to edit the prefix on these IPs because I don't particularly want to commit them to the public record, but the suffix remains unedited.) First, let's check what IP the outbound connections come from, and see what happens when we connect to that IP from a client elsewhere on the internet: webserver# curl http://icanhazip.com/ 203.0.113.136 internetclient# curl -i http://203.0.113.136/200 HTTP/1.1 200 OK That works. Now, let's add NAT and demonstrate that the source IP of outbound connections has changed: router# iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE webserver# curl http://icanhazip.com/ 203.0.113.129 And now, let's try the inbound connection again: internetclient# curl -i http://203.0.113.136/200 HTTP/1.1 200 OK So yeah, I added NAT and it did nothing to inbound connections coming from the internet, which demonstrates the lack of pseudo-firewall behavior for packets that traverse the ISP and not just ones from the next network over.

Dagger2 6y ago

I used OpenWRT, and bypassed the firewall with `iptables -I FORWARD -j ACCEPT`. There are no NAT-related rules in that chain, so I didn't do anything to the behavior of the NAT. > Regardless as I have repeatedly said, this isn't sufficient to invalidate my claim Okay, let's be clear: you've made an unsubstantiated claim with no evidence that isn't backed up by the known behavior of NAT. Your only support for this claim is to say that it's "trivial to prove" by doing this test, and when I actually went and did this test, it failed to prove your point. Rather than invalidating your claim, it would be more accurate to say that neither of us has been able to validate it. > This doesn't for one second disprove that NAT has pseudo-firewall behaviour for any traffic passing through your ISP, which is the case for 99.99% of real world security threats. You're in luck: I have the necessary setup to test this as well. I happen to have a server subnet that's reachable from the internet, so let's try NATing the outbound connections from it and seeing what happens. (I'm going to edit the prefix on these IPs because I don't particularly want to commit them to the public record, but the suffix remains unedited.) First, let's check what IP the outbound connections come from, and see what happens when we connect to that IP from a client elsewhere on the internet: webserver# curl http://icanhazip.com/ 203.0.113.136 internetclient# curl -i http://203.0.113.136/200 HTTP/1.1 200 OK That works. Now, let's add NAT and demonstrate that the source IP of outbound connections has changed: router# iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE webserver# curl http://icanhazip.com/ 203.0.113.129 And now, let's try the inbound connection again: internetclient# curl -i http://203.0.113.136/200 HTTP/1.1 200 OK So yeah, I added NAT and it did nothing to inbound connections coming from the internet, which demonstrates the lack of pseudo-firewall behavior for packets that traverse the ISP and not just ones from the next network over.