4 ms·

You are wrong because you are being overly pedantic. NAT provides security because normally it disallows external actors on the outside from accessing resource

• deleted 9mo ago
  [deleted]
• fc417fc802 9mo ago
  Busses aren't for safety. Seatbelts and airbags and etc are. Busses are just for moving large numbers of people around efficiently. And yet statistically I'm safer on a bus. Therefore it's reasonable to ride the bus "for safety".
  • wink 9mo ago
    I would phrase it as: NAT accidentally "breaks" or "makes harder/impossible" something which yields increased security, under some circumstances.
    • Dagger2 9mo ago
      It doesn't though. NAT edits your outbound connections to appear to come from the router's IP; it doesn't do anything to make inbound connections harder.
      • fc417fc802 9mo ago
        If you don't initiate a corresponding outbound connection first then any attempt at an inbound connection will be dropped (unless you have a DMZ configured ofc). The router literally can't forward the traffic because it doesn't know where it should go.
        • Dagger2 9mo ago
          It might be dropped by a firewall, but not by NAT. IP packets have a "destination IP" field in the header. The router knows where to forward packets because it reads that IP out of the header.
          • tsimionescu 9mo ago
            Sure, but the Internet will not route packets going to RFC1918 addresses. So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped. And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused. This is all behavior that happens even with no firewall whatsoever.
            • Dagger2 9mo ago
              So? How is any of that relevant?
              • tsimionescu 9mo ago
                Because this is exactly what the GP was claiming, and you denied: even without a firewall, packets that don't correspond to an open connection will get dropped by a NAT, even without a firewall. Sure, maybe "dropped" is wrong, as the NAT box will probably instead send a RST packet, but this is almost entirely irrelevant.
                • Dagger2 9mo ago
                  Right, we were talking about NAT. So how is any of that non-NAT-related stuff relevant? > Sure, but the Internet will not route packets going to RFC1918 addresses This is about RFC1918, not NAT. > So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped. This is about reverse path filtering, not NAT. > And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused. And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
• dspillett 9mo ago
  > NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side. Any good firewall does the same, by having a default “no” rule for incoming connections. > A firewall is not required for NAT to work Do you have any examples of NAT that isn't implemented in a more general firewall subsystem? > NAT effectively reduces the attack surface for a home network to the router. While true, this doesn't add to the argument for/against IPv6. That is just security provided by default configuration, which can be provided many other ways and could be before the subset of NAT you are talking about was common.
  • sedawkgrep 9mo ago
    > Do you have any examples of NAT that isn't implemented in a more general firewall subsystem? When I was a network engineer, we did NAT on edge routers for B2B connections all the time. Like literally hundreds of thousands of them. I am 100% serious on this.
    • dspillett 9mo ago
      My understanding is that almost all edge routers provide at least basic firewalling, not just pure routing. How were you “doing NAT” on the edge routers you were using otherwise? (Baring in mind that what most people are referring to as NAT here and elsewhere is “IP masquerading with connection tracking” rather than simple static SNAT & DNAT)
      • sedawkgrep 9mo ago
        In an enterprise network, it's very, very unlikely that an edge router is doing any firewalling. They can do it, but it's not only cumbersome to do it there, but also a massive resource drain. Often they do basic stateless packet filtering, but definitely nothing akin to stateful, connection-oriented firewalling. It's important to make the distinction, because filtering in this case is completely uni-directional and if you want bi-directional equivalence you have to write an inverse rule for it. Filtering polices are applied per interface, so generally you apply them on the outside only. Think of it as sort of a reverse of an inbound Internet policy - you write all the drop stuff first (e.g. drop any any eq snmp) and the last rule is a permit ip any any. Next hop is your firewall which does the rest. For site-tos-site b2b connections, we performed NAT (of the untrusted network space) on the border/edge b2b router, and then the traffic was immediately routed to the firewall. So in this instance, NAT was happening on the router for the customer IP range, and on the firewall for our enterprise IP range. As a convenience to our customers/partners we always presented ourselves as one of our public IP blocks that wasn't Internet-routed. This prevented them from having any overlapping IP space. Otherwise, NAT is simply a question of configuring it. And at least in the cisco IOS world (I'm a dinosaur) the two features (NAT vs. firewall) are utterly independent. https://community.cisco.com/legacyfs/online/legacy/0/8/0/60080-NAT%20Virtual%20Interface.pdf https://community.cisco.com/legacyfs/online/legacy/0/8/0/600... https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/13772-12.html https://www.cisco.com/c/en/us/support/docs/ip/network-addres...
• throw0101a 9mo ago
  > NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side. Which NAT? A 1:1 'basic' NAT [1] could allow stateless flow between two different address schemes. Then you have NAPT where multiple IPs can be mapped via one-IP-many-port system, in which you need state and thus have a filtering mechanism. Similarly you can have IPv6 ULA and do a stateless address translation (NPT) without any blocking policy, which would achieve the same (lack of) security as the 1:1 scenario above. Address translation can have the same level (or not) of security in both IPv4 and IPv6. [1] https://datatracker.ietf.org/doc/html/rfc2663#section-4.1.1 https://datatracker.ietf.org/doc/html/rfc2663#section-4.1.1
• tbrownaw 9mo ago
  > And indeed, if a firewall is off NAT can still function (if NAT is separate). Well technically you can translate your /16 to look like a different /16 from the outside. IE each internal address gets turned into its own separate external address. But that's not how NAT gets used in practice. How it actually gets used is to but many hidden addresses behind one or a few public addresses. And that multiplexing necessarily implies that incoming connections must be specifically told where to go; ie that there's a firewall.
  • Dagger2 9mo ago
    No, it doesn't imply that. Let's say your LAN is using 192.0.2.0/24, and your router has 203.0.113.42 on its WAN interface. With NAT, outbound connections from 192.0.2.x will appear to be coming from 203.0.113.42 -- in your words, the 192.0.2.x addresses on the LAN are hidden behind 203.0.113.42. Now imagine an inbound connection to 192.0.2.10. Does this connection need to be told where to go? It already clearly states where it needs to go in the packet itself: to 192.0.2.10, and the fact that your outbound connections all appear to be coming from 203.0.113.42 didn't prevent that at all. So no, NAT doesn't necessarily imply that incoming connections need to be told where to go. The packets themselves can specify that.
• nobody9999 9mo ago
  >NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side. No. NAT enables internal, non-routable (cf. rfc1918[0]) actors on the inside to access external resources on the Internet. Generally, that's done via NAT masquerade[1] (one-to-many NAT), but can also be done with one-to-one NAT. >A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate). No. It isn't. And if you enable NAT without firewall rules, it will happily expose your internal network to external actors. In fact, that's the whole point of NAT. In fact, not using IPv4 NAT is enormously more secure than using IPv4 NAT, assuming you're using RFC1918 addresses internally. Primarily because non-NATted RFC1918 addresses won't be forwarded by routers on the Internet (CGNAT notwithstanding). >Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking. Again, no. Enabling NAT increases the attack surface for all networks, regardless of type. Without NAT, external actors need to compromise your router first, then get it to accept spoofed packets. Yes, there's detail that I've ignored, as it's irrelevant to the statements made. Most of that is related to "I want to access Internet resources, but my ISP won't give me anything but a single, ephemeral, routable IPv4 address, so I need to use NAT to share that one address." That's not an argument for the "security" of NAT, it's an argument for being mad at your ISP, especially if they won't give you a /56 block of IPv6 addresses. [0] https://www.rfc-editor.org/rfc/rfc1918 https://www.rfc-editor.org/rfc/rfc1918 [1] https://en.wikipedia.org/wiki/Network_address_translation#One-to-many_NAT https://en.wikipedia.org/wiki/Network_address_translation#On...
  • tsimionescu 9mo ago
    > No. It isn't. And if you enable NAT without firewall rules, it will happily expose your internal network to external actors. In fact, that's the whole point of NAT. How exactly would a regular NAT implementation, such as s consumer router's NAT, remove security compared to a direct connection? Assuming there is no port forwarding configured, the NAT will drop (or NACK) any packets addressed to the router's IP on any port that doesn't correspond to a currently open connection. Since the machines behind the NAT have RFC1918 addresses, remote actors will not be able to send a packet to them, other than by sending packets to the router's IP. So, overall, a NAT box with no firewall rules configured still acts like a stateful firewall for remote attackers. It's true that attackers that have access to the WAN port of the router, such as someone infecting your ISP, can still send traffic directly to the RFC1918 addresses behind the router, and the router would deliver them (whereas with a firewall, those would also get dropped). So a firewall is still preferable, but the difference in security is actually quite low. > In fact, not using IPv4 NAT is enormously more secure than using IPv4 NAT, assuming you're using RFC1918 addresses internally. Primarily because non-NATted RFC1918 addresses won't be forwarded by routers on the Internet (CGNAT notwithstanding). This statement makes no sense. If you are not using NAT of some kind, and your machines only have RFC1918 addresses, then your machines can't access the Internet at all. Now, sure, that is quite secure - but you can get the exact same security by disconnecting the WAN port of the router, with the exact same effects - so this is quite irrelevant to the use-cases being discussed.
• Dagger2 9mo ago
  > NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side. No... it doesn't do that. NAT edits your packets so that your outbound connections appear to come from your router's IP. If you set up a port forward rule, then it edits matching inbound connections so they appear to be coming to a different destination IP. Notice how no part of that description involves blocking or preventing inbound connections. That's because that's just not something NAT does.
  • tsimionescu 9mo ago
    So what do you think will happen with a packet that arrives at the router with destination IP set to the router's IP, and destination port set to some port for which there is no port forward rule (and no currently open TCP connection)? Will it reach some machine on the network, or will it get dropped/NACKed?
    • Dagger2 9mo ago
      It will reach the router, obviously. If it's a TCP SYN packet and there's a server listening on that port, you'll connect to that server. If there's no listener then you get a RST.
      • tsimionescu 9mo ago
        So, assuming the router doesn't have any server running, the connection will be reset, thus protecting all of the machines behind the router from any incoming connection, almost exactly like a firewall (sure, a firewall might just drop the packet instead of responding with a RST). So, in other words, NAT alone can act like a security perimeter, even with no firewall present.
        • Dagger2 9mo ago
          How does the router rejecting a connection to the router protect the machines behind the router? That doesn't make any sense.