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.
  • (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