Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Possibly never, because security. NAT at least tries to hide insecure IoT device on your grandma's wifi.

shodan.io has support for ipv6. With ipv4 you're somewhat restricted to devices that get public ip (corporate networks) or devices that drill a hole (uPnP/port forward). IPv6 devices are publicly visible by default and you need to manually setup firewall to filter this out (not trivial - especially for UDP and ICMP)



Every firewall I’ve dealt with since forever has default deny on inbound traffic, state full allow for outbound connections. Regardless of NAT or not, and regardless of how cheap it is.


Name one vendor? I can name you 3 that don't. Zyxel, Ubiquiti, Mikrotik. Also anything wrt based (eg. dd-wrt).

In fact one of the warnings on dd-wrt official IPv6 tutorial: """ Keep in mind it can be dangerous to enable IPv6 without also having a firewall on each client that handles IPv6 packets, or having ip6tables on your router to filter incoming connections. ip6tables is NOT included by default with DD-WRT, which means your clients will be directly exposed to the Internet once you have enabled IPv6. """


Ubiquiti do -- and it's very nice to be able to punch holes in it when I do want to let HTTPS traffic in to specific addresses, rather than need to try to shoehorn everything onto a single IPv4 address.

IPv6 support is sufficiently widespread that pretty much the only place I can't access IPv6-only services from is the office :P.


This is my concern too. NAT is nice because it's stupid and secure by default. No matter how you misconfigure it, the router simply doesn't know where to forward inbound packets to, unlike a firewall which has to actively block. My assumption for routers is that they won't handle firewalls right, especially the many cheapo ones.


It's not actually secure; your router will route inbound packets to whatever IP is in the packet's destination header, and that can be a machine on your LAN. This remains true whether or not you're applying NAT to your outbound connections.

If anything, NAT makes you less secure by tricking you into a false sense of security.

(It's also worse if you're deliberately running servers, because it catastrophically reduces the search space needed for a hostile actor to find those servers via network scanning. At least, it does on v6 -- on v4 the search space is already too small to be a relevant factor.)


> your router will route inbound packets to whatever IP is in the packet's destination header, and that can be a machine on your LAN

The dst is going to be the router's address, not one of the LAN's private IPs.


Not necessarily. What enforces that? You can't rely on your attackers to kindly not send traffic to IPs you don't want them to.


The routers. My ISP can't route dst=192.168.1.2 to anywhere, and even if someone managed to splice the packet in between my router and the ISP, my router won't take that dst. That address doesn't exist on the WAN.


No, the routers don't enforce that, and your ISP can route packets with a destination IP of 192.168.1.2, or anything else they like, to you just fine.

Your router will happily "take" that destination IP. The only reason it won't is because of a firewall, not because of NAT.


Ok, my PC's address is 192.168.1.3 and I have UDP port 9000 open, please send me a packet.


Okay, but since that's RFC1918 you'll need to give me access to your immediate upstream network in order to send the packet to your router. How do you want to do that?


Hmm, I think you’re right! Apologies! And now off to check my firewall rules!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: