4 ms·

> My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on th

> My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. Only because your router also has a properly configured stateful firewall for ipv4 as part of its NAT implementation. I have a Mikrotik CCR2004 at home, I can enable SNAT without appropriate firewall rules and have any other customer of my ISP on the same subnet send packets towards the WAN interface of my router and have it happily forward them onto my internal network. NAT is implemented using a stateful firewall, but the mere presence of it does not mean the firewall is configured to reject unestablished connections from outside. IPv6 just exposes such poor configurations more readily.

hot_gril 3y ago
NAT is not a firewall. It's not actively blocking anything, rather it's actively forwarding things. If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. I mean sure a NAT could intentionally pick my local IP as the lucky winner of every inbound packet, but how does that happen on accident. > IPv6 just exposes such poor configurations more readily. Yes, that's the exact dealbreaker for me and many corp environments.
- snuxoll 3y ago
  > If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this: /ip firewall filter add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1 add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN /ip firewall nat add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN You would have to have a system on the same subnet as the public interface of my router to try and take advantage of these rules not being in place (because of the nature of how IP forwarding works), but without them it would absolutely forward them because the route table just looks like this DST-ADDRESS GATEWAY DISTANCE DAd 0.0.0.0/0 1.1.1.1 1 DAc 1.1.1.0/24 wan1 0 DAc 192.168.0.0/24 lan1 0 Note, it's just one route table - with IP forwarding enabled the only thing stopping anything coming in the WAN interface from being capable of forwarding to the LAN interface is the firewall rule. > Yes, that's the exact dealbreaker for me and many corp environments. My point remains, NAT is not a security measure - any corporate environment who thinks they are protected merely because they have NAT enabled is fooling themselves. The exact same set of firewall rules I need to properly secure IPv4 traffic are the same ones I need for IPv6 traffic; the only reason I haven't bothered to copy/paste them is because my ISP in 2023 still does not hand me an IPv6 allocation.
  - hot_gril 3y ago
    > You would have to have a system on the same subnet as the public interface of my router Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that. Yes, you shouldn't rely on NAT alone, rather the router should have a firewall. Usually it does, but not always. When that fails, at least it's still pretty hard to exploit. How often does this kind of attack occur?
    - snuxoll 3y ago
      > Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that. Yes, you understand the problem correctly. The fact that there's no legitimate reason to do it is precisely why routers have a default set of firewall rules to prevent it. Hell, as long as you control enough of the network to be able to route such a packet to the WAN interface of your router it doesn't even have to be on the same network segment - so compromise within your ISP's network would open you up to attack if you just assumed NAT alone without a proper stateful firewall would save you. > How often does this kind of attack occur? Due to needing to be on the same layer 2 segment or having control elsewhere of the network this would very much be a targeted attack. But one any enterprise should care about, and why the assumption that NAT alone is what protects you is dangerous. NAT just does source/destination (ip, port) rewriting, that's it.

hot_gril 3y ago

NAT is not a firewall. It's not actively blocking anything, rather it's actively forwarding things. If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. I mean sure a NAT could intentionally pick my local IP as the lucky winner of every inbound packet, but how does that happen on accident. > IPv6 just exposes such poor configurations more readily. Yes, that's the exact dealbreaker for me and many corp environments.

snuxoll 3y ago
> If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this: /ip firewall filter add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1 add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN /ip firewall nat add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN You would have to have a system on the same subnet as the public interface of my router to try and take advantage of these rules not being in place (because of the nature of how IP forwarding works), but without them it would absolutely forward them because the route table just looks like this DST-ADDRESS GATEWAY DISTANCE DAd 0.0.0.0/0 1.1.1.1 1 DAc 1.1.1.0/24 wan1 0 DAc 192.168.0.0/24 lan1 0 Note, it's just one route table - with IP forwarding enabled the only thing stopping anything coming in the WAN interface from being capable of forwarding to the LAN interface is the firewall rule. > Yes, that's the exact dealbreaker for me and many corp environments. My point remains, NAT is not a security measure - any corporate environment who thinks they are protected merely because they have NAT enabled is fooling themselves. The exact same set of firewall rules I need to properly secure IPv4 traffic are the same ones I need for IPv6 traffic; the only reason I haven't bothered to copy/paste them is because my ISP in 2023 still does not hand me an IPv6 allocation.
- hot_gril 3y ago
  > You would have to have a system on the same subnet as the public interface of my router Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that. Yes, you shouldn't rely on NAT alone, rather the router should have a firewall. Usually it does, but not always. When that fails, at least it's still pretty hard to exploit. How often does this kind of attack occur?
  - snuxoll 3y ago
    > Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that. Yes, you understand the problem correctly. The fact that there's no legitimate reason to do it is precisely why routers have a default set of firewall rules to prevent it. Hell, as long as you control enough of the network to be able to route such a packet to the WAN interface of your router it doesn't even have to be on the same network segment - so compromise within your ISP's network would open you up to attack if you just assumed NAT alone without a proper stateful firewall would save you. > How often does this kind of attack occur? Due to needing to be on the same layer 2 segment or having control elsewhere of the network this would very much be a targeted attack. But one any enterprise should care about, and why the assumption that NAT alone is what protects you is dangerous. NAT just does source/destination (ip, port) rewriting, that's it.