3 ms·

Due to the extreme address shortage in v4, of course it's typical to be putting your internal hosts on a private IP range. But "putting your internal hosts on a

Due to the extreme address shortage in v4, of course it's typical to be putting your internal hosts on a private IP range. But "putting your internal hosts on a private IP range" isn't NAT. And in fact, putting your internal hosts on a private IP range doesn't prevent inbound connections either. It'll limit the set of people that can do them, but anybody on your immediate upstream connection can do it just by sending packets to your router. That probably means at least your ISP and anybody who can order them to cooperate. NAT isn't a security boundary. (And if you replace your routing rules with NAT then everything will break, because the only thing NAT does is rewrite addresses in packets. They still need to go through the routing table to be routed.)

Dylan16807 7y ago
> Due to the extreme address shortage in v4, of course it's typical to be putting your internal hosts on a private IP range. But "putting your internal hosts on a private IP range" isn't NAT. Maybe not private, but I think it's fair to say that putting them on a different IP range is expected enough that you can reasonably call it part of NAT. > They still need to go through the routing table to be routed. You're looking at things from a very iptables-centric view. "Accept packets on one network interface, rewrite them, spit out the other interface if the rewrite succeeded" is a valid description of NAT that replaces all other routing. It also prevents the "ISP screwed up" and "malicious ISP" scenarios, if your NAT is port-based. It doesn't even care if you used different IP spaces or just one.
- Dagger2 7y ago
  The choice of IP range for your network is still a conceptually separate thing from the choice of whether or not to NAT outbound connections from said network. Certain choices of IP range might make NAT more or less useful to you, and thus might influence your choice, but it's still a separate thing. Yes, I'm describing behavior from the perspective of Linux and iptables because that's what I'm familiar with... but this is the generally-understood meaning of "NAT" when used in this context, and as far as I'm aware this is how basically everything implements it. This is the behavior you'll be seeing.
  - Dylan16807 7y ago
    Nevermind the discussion of IP range for now, I didn't explain well enough and I don't want it being a distraction. > this is the generally-understood meaning of "NAT" If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right? I think that's a reasonable expectation, and it does not require any routing to do. And since the attack we're talking about depends on using routing to bypass the NAT, a dumb device that doesn't route is not vulnerable, and does not make your network vulnerable.
    - pdkl95 7y ago
      [I'm posting this as an attempt at general education. No personal attacks or hostility intended] > If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right? Only if they haven't read RFC 2883 (or similar documentation). I would describe a "device that does NAT but not routing" as highly unusual, possibly purpose-built to update an older network or workaround some kind of compatibility/interoperability problem. Such a device would probably be a custom iptables (or equiv) configuration on a standard linux (or equiv) box, not a branded "router". However, another interpretation is that the terms "NAT" and "routing" are being used in the colloquial sense that usually only refers to NAT and routing to refer to something roughly similar to the home devices that sit between the LAN and a {cable,ADSL} modem. In that sense, a device with two cables attached might not appear to "routing" anything. In previous posts, I'm using the technical definition of NAT as defined by RFC 2883, not this broader colloquial definition. By the technical definition, the device is "routing packets"! NAT is defined as something that performs "transparent routing" between address realms. From RFC 2883: [1] 2.2. Transparent routing The term "transparent routing" is used throughout the document to identify the routing functionality that a NAT device provides. This is different from the routing functionality provided by a traditional router device in that a traditional router routes packets within a single address realm. Transparent routing refers to routing a datagram between disparate address realms, by modifying address contents in the IP header to be valid in the address realm into which the datagram is routed. NAT transparently[2] "routes" between address realms[3], which are defined as: 2.1. Address realm or realm An address realm is a network domain in which the network addresses are uniquely assigned to entities such that datagrams can be routed to them. Routing protocols used within the network domain are responsible for finding routes to entities given their network addresses. NAT accomplishes this "routing" between realms "by modifying address contents in the IP header". Changing the SRC Address field in the header is routing the packet! Any further routing decisions do not involve NAT. Once the packet's address has been changed, the actual handling of the packet is performed by the "routing protocols used within the network domain". This is also what happens to packets that were received directly into that network domain. A simple implementation might do something roughly similar to this (note: oversimplified): | | /-----------\ | | / [Firewall] \ \ New Packet Received / | unroutable, | \ From NIC / \ drop packet / \-------------------/ \-----------/ | ^ v addr: unknown | +----------------+ +-----------------+ | is DST addr in | Y | [Packet Router] | | realm "WAN"? |--->| rules: "WAN" | +----------------+ +-----------------+ N | addr: NAT | v v +----------------+ /--------------------------\ | is DST addr in | / "Route" from realm "WAN" \ | realm "LAN" | | to realm "LAN" by changing | +----------------+ \ the IP header address / N | | Y \--------------------------/ v | | /-----------\ | v / [Firewall] \ | +---------------------------+ | Bad addr, | | | Hand off packet to be | \ drop packet / | | routed into its new realm | \-----------/ | +---------------------------+ v | +-----------------+ / | [Packet Router] |<--------------/ | rules: "LAN" | +-----------------+ | To: the "LAN" firewall, | other processing, | maybe TX at the v LAN's NIC (...) NAT simply hands the packet back to be routed to the LAN. Since NAT is defined as a "transparent" routing, a NAT-translated packet should be handled the same as any other packet addressed to the LAN. > a dumb device that doesn't route is not vulnerable If packets going into the device are retransmitted in any way, the device is "routing" packets. Dumb retransmitting/repeating packets ix a type of routing, even if it isn't making important decisions about each packet. Fortunately, most devices include a stateful firewall that DOES make important decisions about how to handle each individual packet. > does not make your network vulnerable. *If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?). They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN. The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router. Fortunately, most routers are not vulnerable.... because they include a firewall that drops "obviously invalid" packets. [1] https://tools.ietf.org/html/rfc2663#section-2.2 https://tools.ietf.org/html/rfc2663#section-2.2 [2] Transparent to the src and dst hosts that sent/received the packet. This "transparent" is referring to the hosts using the NATing router do not need to do anything special when sending/receiving packets. The address changes are invisible to the endpoints.

Dylan16807 7y ago

> Due to the extreme address shortage in v4, of course it's typical to be putting your internal hosts on a private IP range. But "putting your internal hosts on a private IP range" isn't NAT. Maybe not private, but I think it's fair to say that putting them on a different IP range is expected enough that you can reasonably call it part of NAT. > They still need to go through the routing table to be routed. You're looking at things from a very iptables-centric view. "Accept packets on one network interface, rewrite them, spit out the other interface if the rewrite succeeded" is a valid description of NAT that replaces all other routing. It also prevents the "ISP screwed up" and "malicious ISP" scenarios, if your NAT is port-based. It doesn't even care if you used different IP spaces or just one.

Dagger2 7y ago
The choice of IP range for your network is still a conceptually separate thing from the choice of whether or not to NAT outbound connections from said network. Certain choices of IP range might make NAT more or less useful to you, and thus might influence your choice, but it's still a separate thing. Yes, I'm describing behavior from the perspective of Linux and iptables because that's what I'm familiar with... but this is the generally-understood meaning of "NAT" when used in this context, and as far as I'm aware this is how basically everything implements it. This is the behavior you'll be seeing.
- Dylan16807 7y ago
  Nevermind the discussion of IP range for now, I didn't explain well enough and I don't want it being a distraction. > this is the generally-understood meaning of "NAT" If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right? I think that's a reasonable expectation, and it does not require any routing to do. And since the attack we're talking about depends on using routing to bypass the NAT, a dumb device that doesn't route is not vulnerable, and does not make your network vulnerable.
  - pdkl95 7y ago
    [I'm posting this as an attempt at general education. No personal attacks or hostility intended] > If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right? Only if they haven't read RFC 2883 (or similar documentation). I would describe a "device that does NAT but not routing" as highly unusual, possibly purpose-built to update an older network or workaround some kind of compatibility/interoperability problem. Such a device would probably be a custom iptables (or equiv) configuration on a standard linux (or equiv) box, not a branded "router". However, another interpretation is that the terms "NAT" and "routing" are being used in the colloquial sense that usually only refers to NAT and routing to refer to something roughly similar to the home devices that sit between the LAN and a {cable,ADSL} modem. In that sense, a device with two cables attached might not appear to "routing" anything. In previous posts, I'm using the technical definition of NAT as defined by RFC 2883, not this broader colloquial definition. By the technical definition, the device is "routing packets"! NAT is defined as something that performs "transparent routing" between address realms. From RFC 2883: [1] 2.2. Transparent routing The term "transparent routing" is used throughout the document to identify the routing functionality that a NAT device provides. This is different from the routing functionality provided by a traditional router device in that a traditional router routes packets within a single address realm. Transparent routing refers to routing a datagram between disparate address realms, by modifying address contents in the IP header to be valid in the address realm into which the datagram is routed. NAT transparently[2] "routes" between address realms[3], which are defined as: 2.1. Address realm or realm An address realm is a network domain in which the network addresses are uniquely assigned to entities such that datagrams can be routed to them. Routing protocols used within the network domain are responsible for finding routes to entities given their network addresses. NAT accomplishes this "routing" between realms "by modifying address contents in the IP header". Changing the SRC Address field in the header is routing the packet! Any further routing decisions do not involve NAT. Once the packet's address has been changed, the actual handling of the packet is performed by the "routing protocols used within the network domain". This is also what happens to packets that were received directly into that network domain. A simple implementation might do something roughly similar to this (note: oversimplified): | | /-----------\ | | / [Firewall] \ \ New Packet Received / | unroutable, | \ From NIC / \ drop packet / \-------------------/ \-----------/ | ^ v addr: unknown | +----------------+ +-----------------+ | is DST addr in | Y | [Packet Router] | | realm "WAN"? |--->| rules: "WAN" | +----------------+ +-----------------+ N | addr: NAT | v v +----------------+ /--------------------------\ | is DST addr in | / "Route" from realm "WAN" \ | realm "LAN" | | to realm "LAN" by changing | +----------------+ \ the IP header address / N | | Y \--------------------------/ v | | /-----------\ | v / [Firewall] \ | +---------------------------+ | Bad addr, | | | Hand off packet to be | \ drop packet / | | routed into its new realm | \-----------/ | +---------------------------+ v | +-----------------+ / | [Packet Router] |<--------------/ | rules: "LAN" | +-----------------+ | To: the "LAN" firewall, | other processing, | maybe TX at the v LAN's NIC (...) NAT simply hands the packet back to be routed to the LAN. Since NAT is defined as a "transparent" routing, a NAT-translated packet should be handled the same as any other packet addressed to the LAN. > a dumb device that doesn't route is not vulnerable If packets going into the device are retransmitted in any way, the device is "routing" packets. Dumb retransmitting/repeating packets ix a type of routing, even if it isn't making important decisions about each packet. Fortunately, most devices include a stateful firewall that DOES make important decisions about how to handle each individual packet. > does not make your network vulnerable. *If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?). They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN. The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router. Fortunately, most routers are not vulnerable.... because they include a firewall that drops "obviously invalid" packets. [1] https://tools.ietf.org/html/rfc2663#section-2.2 https://tools.ietf.org/html/rfc2663#section-2.2 [2] Transparent to the src and dst hosts that sent/received the packet. This "transparent" is referring to the hosts using the NATing router do not need to do anything special when sending/receiving packets. The address changes are invisible to the endpoints.