Is NAT Loopback on my router a security problem?
Some DSL routers prevent NAT loopback. Security is sometimes cited as the reason. Is NAT loopback really a security issue? And if so, how is this exploited?
NAT loopback... where a machine on the LAN is able to access another machine on the LAN via the external IP address of the LAN/router (with port forwarding set up on the router to direct requests to the appropriate machine on the LAN). Without NAT loopback you must use the internal IP address of the device when on the LAN.
EDIT: The mentions of security are admittedly from unofficial sources, which is why I would like to clarify this...
From the BT Community Forums:
This is not a fault. Most routers will not send out and receive data on the same interface (Loopback), as this is a security risk.
And further down the same page, from the same user:
As a network engineer I work with Cisco and Brocade routers daily and these will not allow loopback due to the inherent security issues. BT have adopted an approach that security is very important and as with enterprise class routers, loopback is not permitted.
Many DSL routers/modems prevent loopback connections as a security feature.
To be honest, up until now I have always assumed that failure to support NAT loopback was simply a failure in the hardware/firmware, not a 'security feature'?! It's omission is a far greater problem IMHO. (If you hadn't guessed, my router does not support NAT loopback.)
Without a specific attack scenario, a well defined threat, a well defined event that is supposed to not happen ... this "security" claim has no merit whatsoever.
"_admittedly from unofficial sources_" unofficial is not the problem here. The problem is: "_will not send out and receive data on the same interface (Loopback), as this is a security risk_" is crazy talk. Which device does _not_ "send out and receive data on the same interface"???
What you describe (a router sending information to itself, to be received on the same interface) sounds a bit like a LAND attack to me. (https://en.wikipedia.org/wiki/LAND) However, I believe the situation might be a somewhat different with NAT involved. I'd like to see someone answer this with more specifics to that regard.
@IsziRoryorIsznti "loopback" has nothing to do with "LAND", or source address spoofing, or any other IP attack. A loopback session on a NAT device is started by a TCP or UDP packet with a **destination** address which is **the external** (usually public, Internet) IP address of the NAT device and a **source** IP address which is an **internal** (usually private, non-Internet) address
Most consumer grade routers don't have any prohibition against it, it just doesn't work.
Imagine the following scenario. This isn't hypothetical, just run
tcpdumpon your own computer and you'll see it happen right now. Captured from my Buffalo ddwrt moments ago just to verify.
Players: [Router: 10.0.0.1] [Computer1: 10.0.0.3] [Computer2: 10.0.0.4]
Outside IP: 184.108.40.206, forwarded to Computer2
Computer1 to Router [10.0.0.3 -> 220.127.116.11]
Router uses DNAT to change the destination to 10.0.0.4 and pushes it back to the local network:
Router to Computer2 [10.0.0.3 -> 10.0.0.4]
Computer2 attempts to respond to the packet by sending to the source IP.
Computer2 to Computer1 [10.0.0.4 -> 10.0.0.3]
Computer1 was expecting a reply from 18.104.22.168, got one from 10.0.0.4 instead. Addresses don't match, connection failure, RST packet sent back.
Now, you ask, why doesn't the router SNAT the connection from Computer1 to the router's internal IP when it DNATs it to Computer2? Because the SNAT rule would make a mess of all the rest of the traffic which doesn't follow the pattern above.
SNAT really should only be used in one direction unless you're willing to put a lot of time and care into crafting and maintaining a NAT ruleset that won't bite you.
And to preempt anyone who says how about this:
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -d 10.0.0.0/24 -j MASQUERADE
I would point out that this rule would affect not only to NAT-loopback traffic, but also to bridge traffic (e.g. WiFi network to Wired network), which would make a WiFi router frustratingly broken. The rule would have to be tailored to match ONLY the loopback traffic, which is slightly more tricky and probably involves marking packets. Not impossible, but not the sort of engineering and debugging that goes into most routers; and certainly fraught with peril.
SNAT = Source NAT (changing the source IP)
DNAT = Destination NAT (changing the destination IP)
NAT = Network Address Translation
"_I would point out that this rule would affect not only to NAT-loopback traffic, but also to bridge traffic_" Why would **Ethernet** bridge traffic be **ip**-tabled?
"_bridged traffic still transits the kernel_" but bridged traffic should not be `iptables -t nat POSTROUTING`-ed "_flow diagram_" interesting, but I am not sure I understand this diagram: where IP, where is Ethernet?
@curiousguy Bridging is not significantly different from routing; you just forward ALL traffic by default. In the diagram, blue boxes are ebtables processing hooks while green ones ar iptables hooks. Note that iptables is consulted even for bridge traffic. The IP fields may or may not be present on all ethernet frames, but if they are present, they can be examined.
"_Note that iptables is consulted even for bridge traffic._" I see. This is surprising. Anyway, you absolutely do **not** want to mess with `-s 10.0.0.0/24 -d 10.0.0.0/24` traffic. The NAT-device is only concerned with traffic to its external IP address.
@tylerl It depends on the distro, some will have iptables called for bridge traffic some wont. Either way this behavior can be controlled with the kernel parameters mentioned in this this ebtables documentation. Disabling iptables inspection of bridge traffic will allow for simple NAT loopback configuration.