Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Sunday March 04 2018, @06:39PM   Printer-friendly
from the knock-knock dept.

Network guru Wesley George noticed the strange traffic earlier this week as part of a larger attack on a DNS server in an effort to overwhelm it. He was taking packet captures of the malicious traffic as part of his job at Neustar's SiteProtect DDoS protection service when he realized there were "packets coming from IPv6 addresses to an IPv6 host."

The attack wasn't huge – unlike this week's record-breaking 1.35Tbps attack on GitHub – and it wasn't using a method that is exclusive to IPv6, but it was sufficiently unusual and worrying to flag to the rest of his team.

Computers behind 1,900 IPv6 addresses were attacking the DNS server as part of a larger army of commandeered systems, mostly using IPv4 addresses on the public internet. Anyone running an IPv6 network needs to, therefore, ensure they have the same level of network security and mitigation tools in place as their IPv4 networks – and fast.

"The risk is that if you don't have IPv6 as part of your threat model, you could get blindsided," Neustar's head of research and development Barrett Lyon told us.

[...] Adding to the list of potential IPv6 security issues are: the fact that some mitigation tools only work with IPv4 (often thanks to hard-coded addresses written into their code) – or are put into IPv4 and only later ported across to IPv6; that a lot of IPv6 networking is being done in software (rather than hardware) opening up many more potential security holes; and that the expansion of packet headers in the IPv6 protocols creates potential new attack vectors.

[...] George hypothesized that one big future problem could be if a network is hit with a combination of IPv4 and IPv6 attack traffic – as happened in this case. A sysadmin could pull out all the normal mitigation tools but only kill off the IPv4 traffic, leaving the network under attack and the person in charge unable to figure out why.

Thanks to the dual-stack system most people are using to rollout IPv6 alongside their existing systems, Lyon also worries that an IPv6 attack could compromise the routers and switches used to run the networks side-by-side and so attack IPv4 networks through the backdoor.

This week's attack is "only the tip of the iceberg", Lyon said. His hope is this it serves as a wake-up call for sysadmins to apply best practices to IPv6 networks, and argues that "anything you do in the IPv4 world, you should be doing in the IPv6 world."

It's fair to say he is not confident that people will learn the lesson ahead of time though. "People don't tend to think of security as a priority for later," said Lyon. "It doesn't come until there's a crisis."


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: -1, Spam) by Anonymous Coward on Sunday March 04 2018, @06:40PM (2 children)

    by Anonymous Coward on Sunday March 04 2018, @06:40PM (#647689)

    It was a warm, sunny day. Four women were chatting happily on a park bench when a smiling man walked up to them. The women wondered who this man was, but he seemed friendly enough, so they didn't think much about it. Suddenly, his smile became truly disgusting.

    And then there was nothing. Nothing remained. Why, you might wonder, did nothing remain? The answer is all too simple: The motion of the women had become deathly silence. The man had already departed.

    The man walked away from the naked women's battered corpses, his face wearing a wide grin. "Now then," he said, "who will be my next toy...?"

    • (Score: 2, Touché) by Anonymous Coward on Sunday March 04 2018, @08:52PM (1 child)

      by Anonymous Coward on Sunday March 04 2018, @08:52PM (#647719)

      He didn't know what the weather was, as he was sitting in his small, dark basement as always, posting his fantasies about women-killers. He just had finished yet another post, as he noticed some movement behind him.

      He turned around, and he immediately recognized the biggest horror he could imagine. Behind him was the object of his greatest and most secret fear. He got into panic from the mere view. One of them had found him and his hideout, managed to get past all his security measures, which consisted of an old, rusty lock that every five-year-old would have broken even accidentally, and now finally the source of all his fear had entered his basement. Behind him was a woman.

      She didn't have to do anything at all, since he got a heart attack just from viewing her. She watched until he was dead, and then she went away smiling. The source of those troll posts had finally been eliminated.

      • (Score: 3, Funny) by Anonymous Coward on Sunday March 04 2018, @09:09PM

        by Anonymous Coward on Sunday March 04 2018, @09:09PM (#647727)

        Mom?

  • (Score: -1, Flamebait) by Anonymous Coward on Sunday March 04 2018, @06:55PM (1 child)

    by Anonymous Coward on Sunday March 04 2018, @06:55PM (#647692)

    IPv6 is all growed up. Even cyber criminals are using it!

    Normally we say a new technology has been accepted by society when the technology is used for murder. It's just such a shame that all of the innovative apps produced by faggoty tech bros are completely intangible. Try harder, shitheads. You don't change the fucking world with intangible bullshit.

    • (Score: 3, Funny) by driverless on Monday March 05 2018, @03:57AM

      by driverless (4770) on Monday March 05 2018, @03:57AM (#647850)

      What's more impressive is that there was an IPv6 attack and there were enough people using it that someone noticed. I was actually going to post something along the lines of "both users were rather inconvenienced", but it looks like there were 1,900 users hit. That's the population of a small town in the Sudan, it's really arrived now.

  • (Score: 0) by Anonymous Coward on Sunday March 04 2018, @08:20PM (1 child)

    by Anonymous Coward on Sunday March 04 2018, @08:20PM (#647709)

    George hypothesized that one big future problem could be if a network is hit with a combination of IPv4 and IPv6 attack traffic – as happened in this case. A sysadmin could pull out all the normal mitigation tools but only kill off the IPv4 traffic, leaving the network under attack and the person in charge unable to figure out why.

    What kind of an idiot...? Oh nevermind.

    • (Score: -1, Offtopic) by Anonymous Coward on Sunday March 04 2018, @08:29PM

      by Anonymous Coward on Sunday March 04 2018, @08:29PM (#647710)

      Duh yeah. I runs mah blag on mah phone. I gots me BusyBox and muh BusyBox netstat dont bee showin me any EyePeeVee6.

  • (Score: 2) by requerdanos on Sunday March 04 2018, @08:34PM (1 child)

    by requerdanos (5997) Subscriber Badge on Sunday March 04 2018, @08:34PM (#647713) Journal

    "The risk is that if you don't have IPv6 as part of your threat model, you could get blindsided," Neustar's head of research and development Barrett Lyon told us. "If you have IPv6, you totally need to purchase more DDoS protection," said DDoS protection vendor spokesman Cpt. Obvious.

    • (Score: 3, Insightful) by MostCynical on Sunday March 04 2018, @08:51PM

      by MostCynical (2589) on Sunday March 04 2018, @08:51PM (#647718) Journal

      "Please look at our company's offerings"

      Fascinating that this is both a statement of the bleeding obvious *and* an advertisement.

      --
      "I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
  • (Score: 2) by requerdanos on Sunday March 04 2018, @10:03PM (19 children)

    by requerdanos (5997) Subscriber Badge on Sunday March 04 2018, @10:03PM (#647737) Journal

    [Lyon's] hope is this it serves as a wake-up call for sysadmins to apply best practices to IPv6 networks, and argues that "anything you do in the IPv4 world, you should be doing in the IPv6 world."

    What's good for the IPv4 is good for the IPv6: Within the context of security, let's look at that.

    There is a range of network security, with "live, routeable address and no security measures" at one end, and "air gap enforced by armed guards" at the other.

    In the middle somewhere is NAT. I have read rants about how NAT is "worse than nothing" and "no security help at all", and how "NAT doesn't have a place in IP6" but NAT does take a network off the routable, live network, which is no substitute for other, specific security measures, but serves as a sanity check all its own--anything address+port you want open to the network only gets that way because you configured it that way (or ran software that configured it that way).

    I think that just because NAT eases address strain on the IPv4 pool doesn't mean that it doesn't do other things. On my office network, everything's behind NAT, and sure, I only have a single IPv4 address per net connection, but the NAT gives me other benefits as well.

    Do any of the anti-NAT folks care to refute this, that my knowledge may be increased? Or is this general common sense that all but a few understand?

    • (Score: 2) by rleigh on Sunday March 04 2018, @10:47PM

      by rleigh (4887) on Sunday March 04 2018, @10:47PM (#647754) Homepage

      Properly configuring a firewall for IPv6 is no more difficult than configuring IPv4 NAT port forwarding. In fact, my 5 year old ADSL router uses the same UI to do both.

    • (Score: 5, Informative) by NotSanguine on Sunday March 04 2018, @11:08PM (5 children)

      I think that just because NAT eases address strain on the IPv4 pool doesn't mean that it doesn't do other things. On my office network, everything's behind NAT, and sure, I only have a single IPv4 address per net connection, but the NAT gives me other benefits as well.

      Do any of the anti-NAT folks care to refute this, that my knowledge may be increased? Or is this general common sense that all but a few understand?

      NAT is good for what it is. NAT, RFC 1918 [ietf.org] addressing and CIDR [wikipedia.org] have extended the life and usability of IPv4 significantly. So hooray for NAT!

      I'm all for it. However, NAT is not and never was considered a permanent solution. Rather it was designed to maximize the utility of the IPv4 32-bit address space until IPv6 achieved broad adoption.

      Once you move to IPv6, NAT becomes unnecessary. The address space is big enough for everyone to use globally routable addresses. If you're using NAT now, you have some kind of gateway/firewall device(s) which can block the traffic without NAT anyway.

      That's the idea, at least. If, however, you need to communicate with IPv4 devices (you know, like most of the Internet at this point), you'll need to connect to endpoints that are IPv4.

      In such circumstance, you have several options, not all of which require NAT as implemented in IPv4.

      You'll could run a dual-stack [techopedia.com] environment, where NAT would still be required for IPv4 IPv4 host traffic.

      You could also use translation mechanisms [ietf.org] (while this is not NAT, you'll likely still need globally routable IPv4 address(es)), or you can use something like NAT64 [wikipedia.org].

      Once IPv6 has broad enough implementation however, dual stack NAT/NAT64/other translation is neither necessary nor desirable.

      NAT has significant operational, security and resource utilization issues and should only be used where (sadly, this is in a lot of places) necessary.

      You can also use 6to4 relays [wikipedia.org] and web gateways like SixXS [sixxs.net], although those are pretty kludgy IMHO.

      --
      No, no, you're not thinking; you're just being logical. --Niels Bohr
      • (Score: 2) by requerdanos on Sunday March 04 2018, @11:27PM

        by requerdanos (5997) Subscriber Badge on Sunday March 04 2018, @11:27PM (#647775) Journal

        This is a terrific "why not NAT" answer, and I appreciate your taking the time to explain it. Thanks.

      • (Score: 2) by Azuma Hazuki on Monday March 05 2018, @07:43PM (3 children)

        by Azuma Hazuki (5086) on Monday March 05 2018, @07:43PM (#648116) Journal

        Question: why the haemorrhaging fuck would i want all my devices to have globally routable addresses? NAT is, if nothing else security-wise, good for making sure some wiseass can't directly poke anything behind the gateway/router. I see no reason to give up that little bit of usefulness, mainly because setting it up requires virtually no effort.

        --
        I am "that girl" your mother warned you about...
        • (Score: 2) by NotSanguine on Monday March 05 2018, @09:28PM (2 children)

          Question: why the haemorrhaging fuck would i want all my devices to have globally routable addresses? NAT is, if nothing else security-wise, good for making sure some wiseass can't directly poke anything behind the gateway/router. I see no reason to give up that little bit of usefulness, mainly because setting it up requires virtually no effort.

          Answer: Because NAT is not a firewall. It was designed to slow the depletion of IPv4 addresses. Full stop.

          NAT, despite what many think, doesn't provide *any* security features. If you're using NAT and not using a firewall to manage ingress/egress on your network, you're just asking to be pwned. NAT doesn't provide the features of a firewall, and you're still vulnerable to attack unless you secure your network with appropriate firewall rules.

          NAT also has significant operational (it breaks a variety of applications), security (it provides a false sense that you're "protected" although NAT doesn't provide any such protections -- firewall features do) and resource utilization (managing NAT translation tables and rewriting packets can slow network performance considerably, and if your gateway is underpowered, cause CPU bottlenecks) issues.

          As such, not using NAT (but using firewall features like packet inspection, address/port blocking/redirection, application proxies, etc.) is far superior to using NAT (because you need those firewall features when using NAT too!), especially with IPv6, as the address space is vastly larger (128-bit vs. 32-bit) and applications (SIP and others) that won't function properly with NAT will. What's more, there's no effort to *not* set up NAT.

          At the same time, if you *really* want to use NAT with IPv6, you can do so. You can even use the IPv6 equivalent of private addresses (ULAs [wikipedia.org]). It's wasteful of resources and completely unnecessary, except to access IPv4 network resources from your IPv6 hosts. Even then, NAT is not the preferred mechanism [ietf.org] for that scenario either.

          --
          No, no, you're not thinking; you're just being logical. --Niels Bohr
          • (Score: 2) by Azuma Hazuki on Monday March 05 2018, @09:58PM (1 child)

            by Azuma Hazuki (5086) on Monday March 05 2018, @09:58PM (#648207) Journal

            Oh, don't misunderstand, of *course* I use a proper firewall. I know NAT's purpose isn't to be a firewall. It's just a nifty side effect of NAT that nothing on the LAN side is directly reachable from the WAN side, that's all.

            --
            I am "that girl" your mother warned you about...
            • (Score: 2) by NotSanguine on Monday March 05 2018, @10:53PM

              Oh, don't misunderstand, of *course* I use a proper firewall. I know NAT's purpose isn't to be a firewall. It's just a nifty side effect of NAT that nothing on the LAN side is directly reachable from the WAN side, that's all.

              That's not really true. As I mentioned in another comment [soylentnews.org]:

              Actually, that's a feature of RFC1918 IP addressing, not NAT. Since the IP networks defined in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are defined as "private," no ISP router will forward packets with addresses within those ranges. *That's* why, in the absence of appropriate firewalls/firewall rules, those systems aren't reachable from the outside. NAT has nothing to do with it.

              When you use NAT, it *allows* access to/from those internal hosts.

              So, more correctly, you should say "Therefore the RFC1918-style addressing has a side effect of acting as a (very primitive) firewall."

              What's more, Any "perceived" security benefit (primarily "security through obscurity," which isn't really security at all) of NAT are easily implemented via ingress filtering on your firewall. In a nutshell, NAT does not provide any security.

              But please don't change on my account. That said, I'd strongly recommend that you *not* use a consumer router/firewall as your firewall.

              Rather, use a minimal install of BSD (pfSense [pfsense.org]) or Linux (xbps-install iptables, examples [archlinux.org]) on a multi-homed system [protectli.com] (not recommending the linked device, it's just an example) as your firewall. The feature sets are significantly richer and the implementations are demonstrably more secure.

              --
              No, no, you're not thinking; you're just being logical. --Niels Bohr
    • (Score: 1, Interesting) by Anonymous Coward on Sunday March 04 2018, @11:56PM (11 children)

      by Anonymous Coward on Sunday March 04 2018, @11:56PM (#647789)

      NAT is not a firewall.

      NAT is an ugly hack invented by people who don't understand the axiom there's nothing more permanent than a temporary patch. NAT doesn't actually offer any additional security over a proper layer two firewall. In fact, there are things a proper firewall can do that NAT can't do, such as controlling outbound traffic. A proper firewall will prevent an attacker from successfully using a 0-day "phone home" script on your server. NAT will happily allow the phone home script to phone home, giving the attacker a simple foothold on your network. NAT adds latency to an already expensive router hop that could otherwise be mitigated with a layer three switch. NAT requires additional, far uglier hacks to make things like SIP and other UDP protocols work. NAT breaks IPSec. This is only the snowflake on the top of the tip of the iceberg of the "bad" list for NAT.

      NAT is like one of those drugs you see advertised on TV. It kinda-sorta works most of the time at its intended purpose but brings a laundry list of side effects that range in severity from "worse than the disease it treats" to "this shit will kill you."

      The current state of IPv6 adoption is where we should have been 20 years ago. NAT is the network protocol RFC equivalent of kicking a can down a road. Everything that NAT does except prolonging the inevitable IPv4 exhaustion can be done better with other protocols/tools/configurations. Since IPv4 exhaustion is inevitable it can be summed up by saying "NAT does nothing useful."

      • (Score: 2) by requerdanos on Monday March 05 2018, @12:39AM

        by requerdanos (5997) Subscriber Badge on Monday March 05 2018, @12:39AM (#647800) Journal

        Since IPv4 exhaustion is inevitable it can be summed up by saying "NAT does nothing useful."

        While IPv4 exhaustion is indeed inevitable, IPv6 adoption doesn't seem to be.

        Also, since coping with that exhaustion is what NAT does, your "nothing useful" statement makes no sense.

      • (Score: -1, Flamebait) by Anonymous Coward on Monday March 05 2018, @01:11AM (8 children)

        by Anonymous Coward on Monday March 05 2018, @01:11AM (#647803)

        Let me guess. You were at a bar one night and someone who *actually* knew what he was talking about was pretty drunk and went on a rant about NAT. You were a little less drunk and actually remembered a few things and now think you have some sort of clue. Does that sound about right?

        Unfortunately, your blathering doesn't come close to the real story, although within your angry ramblings there are few kernels of truth.

        Perhaps you should actually learn about something *before* you embarrass yourself, rather than confirming that you're a moron.

        tl;dr: you're talking out of your ass and it smells that way too.

        • (Score: 0) by Anonymous Coward on Monday March 05 2018, @02:32AM (7 children)

          by Anonymous Coward on Monday March 05 2018, @02:32AM (#647820)

          Uh he is right. You strawman attack him with no refutations of what he said that was wrong.

          NAT is a translator that HAPPENS to have a side effect of acting like a firewall. It is not a firewall. We have real firewalls that do the work of a firewall. They exist in both IPV4 and 6.

          Still think NAT is awesome? Lets say I want to forward some port into my NAT network. In almost all routers it is 1 port to 1 machine. With a real firewall I can have 5 boxes with that port if I want to do so. Then I also do external and internal ingress and egress filtering. Most consumer routers do not even have that concept because of the NAT stacks they use. NAT only works if the internal side creates the connection.

          You can use NAT in IPV6 if you want. There is even an RFC for it. There is however 0 reason to do so. My ISP hands out /56 networks/IPs I have heard as low as /64. /56, that is huge being 68719476736x what I had before in address space. I can use a proper firewall and get all the same effects as NAT but with the correct tools and simpler config. NAT serviced us well for a long time. But it is time for it to go.

          Maybe you can make up more things about them? Maybe you can hallucinate more about how amazing NAT is then go on to make up more things about other people and put words in their mouth?

          • (Score: 0) by Anonymous Coward on Monday March 05 2018, @04:14AM (6 children)

            by Anonymous Coward on Monday March 05 2018, @04:14AM (#647856)

            Uh he is right. You strawman attack him with no refutations of what he said that was wrong.

            Uh, no he's not. That's funny too, as there have already been two other (count [soylentnews.org] 'em [soylentnews.org]) comments on this specific topic.

            NAT is a translator that HAPPENS to have a side effect of acting like a firewall. It is not a firewall. We have real firewalls that do the work of a firewall. They exist in both IPV4 and 6.

            So, NAT expert, please explain this to me. Better yet, tell me where in the NAT spec [ietf.org] (it's only a few pages long) *any* "firewall" features are defined?

            You can't, because NAT doesn't "act like a firewall" and it has no "firewall" features *at all*. In fact, the NAT spec (RFC 1631) doesn't specify *any* security features.

            Anything that provides firewall-like features in whatever device you use for NAT is not part of NAT. What you're ascribing as "firewall features" to NAT is, presumably, a firewall feature of whatever device/software you're using. I'll bet that you don't really know what NAT is and why it was implemented either.

            Perhaps you think, "Well, it's a feature on my home router/firewall. So it must be a firewall!" That's flat wrong.

            Still think NAT is awesome? Lets say I want to forward some port into my NAT network. In almost all routers it is 1 port to 1 machine. With a real firewall I can have 5 boxes with that port if I want to do so. Then I also do external and internal ingress and egress filtering. Most consumer routers do not even have that concept because of the NAT stacks they use. NAT only works if the internal side creates the connection.

            Where did I (or anyone, other than you) say that "NAT is awesome?" Who's putting words in other people's mouths? NAT (along with CIDR and private IP address ranges) were designed for the express purposes of staving off IP address exhaustion and limiting the size of routing tables. NAT was first published in 1994 as a stopgap measure for those purposes, to be used until new protocols with larger address spaces could be developed. IPv6 was first published in 1996.

            For what NAT is, it's done an admirable job in slowing the depletion of IPv4 address space. That was/is its purpose and it never had another.

            Like I said, you probably only have experience with consumer-grade routers/firewalls. They are garbage. For your own sake, at least install a BSD or Linux box and use a halfway decent NAT implementation, as well as a decent firewall, instead of that consumer garbage. I considered asking if you had *any* real networking experience other than setting up your little home WiFi/router (probably a Linksys or some other such garbage) with limited firewall features, but it's clear you don't, so I won't bother.

            You can use NAT in IPV6 if you want. There is even an RFC for it. There is however 0 reason to do so. My ISP hands out /56 networks/IPs I have heard as low as /64. /56, that is huge being 68719476736x what I had before in address space. I can use a proper firewall and get all the same effects as NAT but with the correct tools and simpler config. NAT serviced us well for a long time. But it is time for it to go.

            Yes, NAT64 is available, but not recommended. Rather other translation mechanisms are preferred [ietf.org] *if* they are necessary. If IPv4 connectivity isn't an issue (although you can use dual-stack implementations to avoid NAT64 or other IPv6 translation mechanisms) NAT is completely unnecessary with IPv6 and is, in fact, discouraged.

            Given that every continent except Africa has exhausted its normal IPv4 allocation space (and Africa will do so later this year), what shall we use instead of NAT until IPv6 adoption is widespread enough to free up (what will then be) legacy IPv4 address space?

            What's that? You don't know? There's a shocker!

            Let's review:
            1. You aren't clear on what NAT is or does;
            2. You assume, based on your limited experience with garbage software and hardware that you know what you're talking about;
            3. You are ignorant of the history and need for NAT/CIDR/RFC1918 addressing;
            4. You have no clue what the *current* need for conserving IPv4 address space is or why NAT is still important for that purpose.

            I'll echo what i said to other AC, because it applies to you just as much: You're talking out of your ass and it smells that way too.

            • (Score: 2) by maxwell demon on Monday March 05 2018, @04:59AM (5 children)

              by maxwell demon (1608) on Monday March 05 2018, @04:59AM (#647864) Journal

              Better yet, tell me where in the NAT spec [ietf.org] (it's only a few pages long) *any* "firewall" features are defined?

              Better learn some English first. If there were a defined firewall functionality in that SPEC, the claim that it has "a side effect of acting like a firewall" would be clearly wrong.

              NAT has the effect that certain computers on the local network don't have an address reachable from outside the local network, while they still themselves can access the local network (if it wouldn't, it wouldn't be able to reduce the number of publicly visible IPs). Making computers inaccessible from the internet is a typical firewall property. Therefore the NAT has a side effect of acting as a (very primitive) firewall.

              --
              The Tao of math: The numbers you can count are not the real numbers.
              • (Score: 2) by NotSanguine on Monday March 05 2018, @05:42AM (4 children)

                NAT has the effect that certain computers on the local network don't have an address reachable from outside the local network, while they still themselves can access the local network (if it wouldn't, it wouldn't be able to reduce the number of publicly visible IPs). Making computers inaccessible from the internet is a typical firewall property. Therefore the NAT has a side effect of acting as a (very primitive) firewall.

                Actually, that's a feature of RFC1918 IP addressing, not NAT. Since the IP networks defined in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are defined as "private," no ISP router will forward packets with addresses within those ranges. *That's* why, in the absence of appropriate firewalls/firewall rules, those systems aren't reachable from the outside. NAT has nothing to do with it.

                When you use NAT, it *allows* access to/from those internal hosts.

                So, more correctly, you should say "Therefore the RFC1918-style addressing has a side effect of acting as a (very primitive) firewall."

                What's more, there are various types of NAT.

                One-to-many [wikipedia.org] NAT. With one-to-many NAT, the NAT gateway uses high port ranges to differentiate between different hosts, but uses a single IP address on the external network.

                One-to-one (or Basic) NAT [wikipedia.org], on the other hand, maps each specific IP address to another specific IP address.

                With the former, it's necessary (via port-forwarding) make some changes to the source/destination ports in order to allow certain applications to function properly. That's not firewall functionality, it's a *limitation* of NAT.

                With the latter, all that goes out the window. All packets sent to the external IP address are forwarded to the internal address and vice versa. Without appropriate *actual* firewall rules, the host is, essentially, out on the Internet.

                There are issues with applications (e.g., SIP) which encode source and/or destination IP addresses into the *payload* of packets which, cause serious problems for such applications.

                The local system embeds its true (presumably RFC1918-style) IP address into the payload of the packet, so even though the packet headers are modified for the NAT, the remote side is unable to send data back, as it will use the address embedded in the payload.

                Most software using protocols which have these issues will usually provide some sort of mechanism to embed the NATted IP address to allow the application to function.

                So, no. NAT does not, in fact, have "firewall-like" side effects.

                --
                No, no, you're not thinking; you're just being logical. --Niels Bohr
                • (Score: 2) by maxwell demon on Monday March 05 2018, @05:25PM (3 children)

                  by maxwell demon (1608) on Monday March 05 2018, @05:25PM (#648050) Journal

                  Well, in this case, it turns out that I somehow managed to write something different than I meant. I really should proofread more …

                  What I meant to write was:

                  NAT has the effect that certain computers on the local network don't have an address reachable from outside the local network, while they still themselves can access the internet.

                  According to what I actually wrote, you're right, that's already a feature of RFC1918. But what I actually meant is not. Without NAT, the only way to have internet access from a local computer without the local computer being accessible from the internet is a firewall. And therefore the NAT as side effect acts as a (very primitive) firewall.

                  --
                  The Tao of math: The numbers you can count are not the real numbers.
                  • (Score: 4, Informative) by NotSanguine on Monday March 05 2018, @09:05PM (2 children)

                    ...what I actually meant is not. Without NAT, the only way to have internet access from a local computer without the local computer being accessible from the internet is a firewall.

                    Actually, that's not true. Through the use of a proxy server [wikipedia.org], a system with a private (RFC1918) address can access Internet resources without NAT.

                    But leaving aside proxy servers, you said "the only way to have internet access from a local computer without the local computer being accessible from the internet is a firewall." That's patently false.

                    A correct version would be "the only way to have internet access from a local computer without the local computer being accessible from the internet is to use NAT and/or a proxy server."

                    In fact, without NAT you *still* can't have internet access (except via a proxy with an external IP -- but that's not NAT) whether you have a firewall or not. If you don't NAT, RFC1918-style private addresses will be in the headers of sent packets and the first internet router that sees it will (as is required by the protocol specs) silently discard those packets.

                    So. Once again. NAT does not act *in any way* as a firewall.

                    Given that many NAT implementations are hosted/managed on/with the same platforms/tools as typical firewall (proxy, packet inspection, address/port blocking/redirection, etc.) features, it's understandable that those disparate features would be conflated as parts of a whole. Which may be where the confusion lies.

                    But that isn't the case. What's more, NAT is not only used to broker access to globally-routed networks from private networks, although that is the most common use case. NAT is for Network Address Translation. It does not have any "firewall-like" side effects.

                    NAT is also used to connect disparate networks which have conflicting address spaces. For example, a provider of data/applications or a client/customer may require an organization to connect to its internal network to access needed resources. If both organizations (with separate, discrete networks) are using overlapping private (RFC1918) IP address spaces, NAT is required to connect those networks.

                    Let's say company A has multiple, geographically distributed, interconnected physical networks, each using a private 192.168.x.0/24 network:
                    Site 1: 192.168.10.0/24
                    Site 2: 192.168.11.0/24
                    Site 3: 192.168.12.0/24
                    [...]
                    Site 8: 192.168.17.0/24

                    Routing tables at each site will pass traffic through appropriate network links when such traffic needs to travel to other sites.

                    Company B is a vendor of some data needed for company A's operations. They also have multiple sites using private address spaces:
                    Site 1: 192.168.8.0/24
                    Site 2: 192.168.9.0/24
                    Site 3: 192.168.10.0/24
                    [...]
                    Site 5: 192.168.12.0/24

                    A network link (whether it's a VPN across the Internet or a physical link is unimportant) between the two companies is established.
                    At company A, users at site 2 (with network range 192.168.226.11.0/24) need to access resources at company B's site 5 (192.168.12.0/24).

                    The link is up and active and the endpoints of the link are able to communicate. However, when users at any site at company A attempt to access the resources at company B/site5, they are unable to access such resources.

                    What's going on here? Well, since company A's site 1 has the same address range as company B's site 3, routing tables at company A erroneously route traffic from company A/site 2 to company A/site 1 rather than Company B.

                    No problem. Let's set up a route at company A/site 2 that points network traffic bound for company B/site 5 (192.168.12.0/24) through the Company A-Company B network link, and Bob's your uncle, Fanny's your granny, right? Not so much.

                    While you certainly can now send traffic *to* Company B. However, since Company A sites 1/2/3 have conflicting IP address ranges with Company B sites 3/4/5, company B's routers will forward any replies to packets from Company A sites 1/2/3 to its own, conflicting local networks.

                    And so you add "appropriate" routes to Company B's routers to send traffic back to Company A. Hooray! Users at company A can now access the needed resources at Company B. So we're all done.

                    Not even close. Since you've now created routes that send data between for sites B5 and A1/2/3, internal network connections at company A between all sites and site 3 are now being sent to company B rather than company A/siite 3. At the same time, internal connections between company B's sites destined for Company B/sites 3/4/5 are now being routed through the network link to Company A.

                    We've just broken both networks pretty severely.

                    So. How do we make this work without breaking both networks? I imagine you've already figured it out. Yup, with NAT.

                    Company A and company B both set up NAT (in company B's case, they need to accept traffic from all of company A's networks, and Company B needs to accept traffic just from the hosts/subnet on which the data/applications reside).

                    This is called "double NAT." So Company A adds DNS entries for Company B's resources with IP addresses that don't conflict with Company A's existing IP numbering scheme (e.g., using IP addresses in the 172.16.10.0/24 range) and then sets up routes for that new IP range to be sent through the link between company A and company B.

                    Company B then NATs incoming traffic from Company A to another non-conflicting range (e.g., 10.10.10.0/24) with many to one [wikipedia.org] NAT (AKA NAT masquerade) and sets its routes accordingly as well, et voila!

                    This is not a hypothetical. I've implemented this on several occasions. Please note that there is no "firewall" functionality involved, nor is a firewall necessary to make this work (although it's a good idea to restrict access to just the required resources).

                    N.B: You and I have been here on SN for a while, and I've often been impressed by your knowledge and insight on a variety of topics.

                    This time, however, you're off-base. I've attempted to explain why, as I respect your critical thinking skills (otherwise, I'd just ignore you) and hope I've been able to dispel your misconceptions about NAT.

                    If I've been unclear, I'd be happy to further explain this and/or provide you with resources you can peruse yourself.

                    Please take this in the spirit in which it's been offered. Thanks.

                    --
                    No, no, you're not thinking; you're just being logical. --Niels Bohr
                    • (Score: 2) by maxwell demon on Tuesday March 06 2018, @07:10AM (1 child)

                      by maxwell demon (1608) on Tuesday March 06 2018, @07:10AM (#648392) Journal

                      If you don't NAT, RFC1918-style private addresses will be in the headers of sent packets and the first internet router that sees it will (as is required by the protocol specs) silently discard those packets.

                      Sure, without NAT the computer will have to have a public internet address to be able to access the internet. But having a public internet address does not mean being accessible from the public internet. If the firewall just drops all packets addressed to that computer, unless it's part of a connection initiated by that computer, you won't be able to access the computer from the public internet, but the computer can access the public internet just fine. That's exactly the type of job a firewall is supposed to do.

                      And the fact that you can have other NAT setups that doesn't as side effect act as primitive firewall is completely irrelevant to the discussion at hand. Just as it is irrelevant for the discussion at hand that firewalls can do things that you won't be able to do with NAT. The point is that the by far most common NAT setup, and more importantly the one relevant for the discussion at hand, indeed does act as primitive firewall.

                      --
                      The Tao of math: The numbers you can count are not the real numbers.
                      • (Score: 2) by NotSanguine on Tuesday March 06 2018, @04:55PM

                        Sure, without NAT the computer will have to have a public internet address to be able to access the internet. But having a public internet address does not mean being accessible from the public internet.

                        Yes, but that's irrelevant to NAT.

                        If the firewall just drops all packets addressed to that computer, unless it's part of a connection initiated by that computer, you won't be able to access the computer from the public internet, but the computer can access the public internet just fine. That's exactly the type of job a firewall is supposed to do.

                        Not necessarily. A gateway (which is, after all, what a firewall is) would need to allow both egress (outbound), ingress (inbound) and the ability to forward traffic in specific ways before *any* internal resources can access an external network.

                        Some rules similar (using whatever firewall you might be using) to this would be required:
                        Allow source [Internal Network Range] destination [any] interface [internal] direction [inbound]
                        Allow source [Internal Network Range] destination [any] interface [external] direction [outbound]
                        And often something like this as well:
                        Allow source [Internal Network Range] destination [any] action [forward-packets]

                        But even that's not enough to allow successful access to external networks. You'll also need rules similar to:
                        Allow destination [Internal Network Range] source [any] interface [external] direction [inbound] connection-state [ESTABLISHED | RELATED]
                        Allow destination [Internal Network Range] source [any] interface [internal] direction [outbound] connection-state [ESTABLISHED | RELATED]
                        Allow destination [Internal Network Range] source [any] interface [external] action [forward-packets] connection-state [ESTABLISHED | RELATED]

                        While this may be hidden for some firewall UIs, such rules are still required. Depending on the firewall, you may also have to explicitly specify protocol types (TCP, UDP, ICMP, etc.) as well.

                        it is irrelevant for the discussion at hand that firewalls can do things that you won't be able to do with NAT.

                        Exactly. And vice versa. NAT and the suite of functionality generally referred to as "firewall" (packet inspection, address/port blocking/forwarding, proxy apps, etc.) are separate and do not impact one another.

                        The point is that the by far most common NAT setup, and more importantly the one relevant for the discussion at hand, indeed does act as primitive firewall.

                        I've attempted (apparently unsuccessfully) to describe to you exactly why that's an incorrect assumption.

                        NAT does not provide (purposefully or inadvertently) any "firewall" functionality. It does not provide packet inspection, address/port blocking/redirection, proxies or any other firewall functionality.

                        NAT provides a mechanism for rewriting source/destination IP addresses in IP headers and creation/maintenance of a table to manage such rewrites in a sane way. Full stop.

                        Go ahead and believe what you wish. You're flat wrong, but it doesn't impact me in the slightest.

                        --
                        No, no, you're not thinking; you're just being logical. --Niels Bohr
      • (Score: 4, Interesting) by NotSanguine on Monday March 05 2018, @01:33AM

        Everything that NAT does except prolonging the inevitable IPv4 exhaustion can be done better with other protocols/tools/configurations. Since IPv4 exhaustion is inevitable it can be summed up by saying "NAT does nothing useful."

        Actually, that address exhaustion [wikipedia.org] is here, unless you're in Africa, and they'll be done later this year.

        The only purpose for NAT [ietf.org] was to stave off that inevitable exhaustion, and it's done an admirable job too. However, without CIDR [ietf.org] and private IP addressing [ietf.org], we'd have been there a long time ago. But don't believe me, read the specs (I've helpfully linked them for you) and see for yourself. Each of which were created in 1993/1994.

        Any other purposes ascribed to NAT are figments of your imagination. There are no "security" features of NAT. And no one besides you is claiming that anyone has said that there are.

        So. Please do tell what other "features" NAT is claimed to have. I'd really like to know, as I've been implementing Internet-connected IP networks since 1991 or so, and I've never heard anything about such "features."

        --
        No, no, you're not thinking; you're just being logical. --Niels Bohr
  • (Score: 0) by Anonymous Coward on Sunday March 04 2018, @11:02PM (3 children)

    by Anonymous Coward on Sunday March 04 2018, @11:02PM (#647760)

    But there's hardly anyone using IPv6.

    • (Score: 0) by Anonymous Coward on Monday March 05 2018, @02:37AM (1 child)

      by Anonymous Coward on Monday March 05 2018, @02:37AM (#647824)

      https://www.google.com/intl/en/ipv6/statistics.html [google.com]

      It is about 1 in 4.

      Most of that adoption is due to people using old routers. Or companies with outdated policies. Just upgraded my fathers router. +1 IPV6 user. Pretty much all of the major ISPs are IPV6 ready.

      • (Score: 2) by NotSanguine on Monday March 05 2018, @04:41AM

        It is about 1 in 4.

        Most of that adoption is due to people using old routers. Or companies with outdated policies. Just upgraded my fathers router. +1 IPV6 user. Pretty much all of the major ISPs are IPV6 ready.

        And does your father's router get assigned an IPv6 address by his ISP? I would hope so. Most major ISPs in the US [wikipedia.org] (with the exception of Comcast) offer IPv6 to their customers. It's unclear (to me at least) whether or not that's implemented by default, or if customers must request it. ISP deployments have been uneven around the world.

        Just about every major OS has (since 2011 or so) IPv6 enabled by default [wisc.edu]. Most routers/gateways/firewalls (including commercial/enterprise/carrier-grade systems) have IPv6 available and ready to use as well.

        The vast majority of TLDs and major DNS providers support IPv6, but few DNS zones or BGP routing tables include IPv6 addresses/networks [wikipedia.org]:

        In November 2016, 1491 (98.2%) of the 1519 top-level domains (TLDs) in the Internet supported IPv6 to access their domain name servers, and 1485 (97.8%) zones contained IPv6 glue records, and approximately 9.0 million domains (4.6%) had IPv6 address records in their zones. Of all networks in the global BGP routing table, 29.2% had IPv6 protocol support.[3] [4]

        So, the infrastructure is in place, and carriers (backbone, transit and ISPs) have support for IPv6, but until a large fraction of the tens of millions (or more) of various entities that have DNS zones and broadcast BGP routes that include IPv6 addressing, actual usage will continue to lag.

        More's the pity.

        --
        No, no, you're not thinking; you're just being logical. --Niels Bohr
    • (Score: 3, Interesting) by TheRaven on Monday March 05 2018, @09:43AM

      by TheRaven (270) on Monday March 05 2018, @09:43AM (#647917) Journal

      My ISP is BT (in the UK) and all of their lines now support IPv6. When I do a DNS lookup of soylentnews.org, if I don't explicitly specify a protocol (i.e. I use getaddrinfo, as most vaguely modern programs do), I get back 2600:3c00::f03c:91ff:fe98:b8fe. That is the address that my web browser uses, so I'm connecting via IPv6 here.

      My hosting provider charges for IPv4 addresses, but gives out IPv6 addresses (well, /64 prefixes) for free, so if I could guarantee everywhere that I want to access my email from supported v6 then I'd save a bit of money each month.

      --
      sudo mod me up
(1)