That would cause worse confusion when working with teams from different localisations. Not to mention the complexity of now adding localisations to the address parser.
The nice thing about NAT is it makes the security model easier to reason about.
By this, I don’t mean it’s more secure, because I know it isn’t. But it is a lot easier to see and to explain what has access to what. And the problem with enterprise is that 80% of the work is explaining to other people, usually non-technical or pseudo-technical decision makers, why your design is safe.
I really do think IPv6 missed a trick by not offering that.
> The nice thing about NAT [...] I really do think IPv6 missed a trick by not offering that
IPv6 supports NAT [0], and nearly all routers make it easy to enable. The primary differences compared to IPv4 is that no-NAT is the default, and that it's more heavily discouraged, but it still works just as well as it does with IPv4.
[0]: In the same way that IPv4 "supports" NAT, meaning that the protocol doesn't officially support it, but it's still possible to implement.
But would we have said the same in 1996 or 2000? Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4. And a good chunk of the complexity of IPv6 is that some of the early ideas are very persistent, both in some deployed systems and in people's minds
> But would we have said the same in we 1996 or 2000?
IPv6 the protocol supported NAT just as well back then as it does now, but the software probably didn't. Which goes back to my point [0] [1] that IPv6 is a great protocol with bad tooling and documentation.
> Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4.
The only abandoned IPv6 concept that I'm personally aware of is A6 records [2], but I'm pretty young, so I'm sure that there are others that I'm just not aware of. My impression from reading the RFCs and Wikipedia is that IPv6 hasn't changed very much, but that doesn't really mean anything, since I wouldn't expect for current sources to talk about concepts abandoned 20+ years ago.
My consumer router, and every router I have configured, implicitly supports IPv4 NAT out of the box. But it will never NAT an IPv6 network. If I enable IPv6 then it operates by IPv6 rules, which means each device gets a Network ID and each Network ID gets routed directly and transparently. The router has no NAT table and no NAT settings for this protocol.
So if NAT is “supported” whatever that means, it simply isn’t possible for most end-users.
Consumer routers don't support lots of useful stuff though, so them not supporting NAT66 isn't very surprising. Enthusiasts are likely to use OpenWRT or nftables, both of which support NAT66 [0], and quickly Googling some random enterprise routers shows that they all support NAT66 too [1] [2] [3].
This isn't enabled by default because it's usually a bad idea, but it's certainly possible if you really want. (It's discouraged because NAT in general is a bad idea, but it's no worse with IPv6 than with IPv4; the only difference being that IPv4 effectively requires NAT.)
If you've got a car that can't go 100, that doesn't mean nobody can, or that it doesn't exist. I don't care if you can't do it, it IS supported in the spec.
That’s an interesting analogy because there’s several ways you could easily dismiss it.
For example: if roads aren’t built to support cars travelling at 100 miles per hour then it doesn’t matter how much you argue that cars are can do 100MPH, because you’re still not going to be travelling at 100MPH.
Or
But if the only cars that can travel at 100 MPH are Bugatti Veyrons then it’s safe to say that 100MPH cars isn’t something available to even the average consumer of high end sports cars.
Or
Sure, some cars can travel at 100 MPH, but they’re so unstable at those speeds that it’s not even safe to attempted it.
> The nice thing about NAT is it makes the security model easier to reason about.
I first heard that relying on the 'moated castle' design of security (firewalls) was bad idea and no longer best practice a decade or two ago, and while inside/outside may be a convenient mental shortcut for security, it shouldn't be relied about.
Sure, sensible people know that NAT ≠ security, but by having private/public IPs I think it makes people's thinking lazy. Every system having publicly routable addresses (but not publicly accessible, due to SPI) would force more folks to actually examine their security controls.
It's too easy to think "ah, this has a 10.x.y.z address, therefore it's inside and safe". No, because most attacks nowadays involve compromised/ing clients, and then running around 10.x networks where people got lazy because these things are on the "inside".
The price you pay is that it's more difficult to reason about what is accessible from elsewhere, because all devices are represented by your router from the outside, and there are no great ways to opt out of that.
With NAT removed, you've still got the firewall rules, and that's fairly easy to reason about for me: Block anything from outside to inside, except X. Allow A talking to B. Allow B to receive Y from outside.
But we aren’t talking about someone technical glancing at their home routers firewall. We are talking about explaining a network topology to enterprise teams like change management, CISO, etc in large infrastructure environments.
That’s a whole different problem and half the time the people signing off that change either aren’t familiar with the infrastructure (which means explaining the entire context from the ground up) and often aren’t even engineers so need those changes explained in a simplified yet still retaining the technical detail.
These types of organisations mandate CIS / NIST / etc compliance even where it makes zero sense and getting action items in such reports marked as “not required” often takes a meeting in itself with deep architectural discussing with semi-technical people.
Are these types of organisations overly bureaucratic? Absolutely. But that’s typical for any enterprise organisation where processes have been placed to protect individuals and the business from undue risk.
In short, what works for home set ups or even a start up isn’t necessarily what’s going to work for enterprise.
> But we aren’t talking about someone technical glancing at their home routers firewall.
Are we not? Because I suppose most people here are only disgruntled by a new protocol that changes how their home router works, and having to spend some learning effort.
For network admins in commercial settings, this is even less of an excuse. IPv6, the protocol, is fairly well documented and understandable if you put in the work to do so. And I am confident in saying it is absolutely able to deliver on any kind of corporate network scenario, even moreso than IPv4.
> Are we not? Because I suppose most people here are only disgruntled by a new protocol that changes how their home router works, and having to spend some learning effort.
People at home don’t care about protocols. If the WiFi works and the TV plays Netflix or Hulu or whatever, the protocol can be anything.
Last time I “cared” was when I changed the DHCP network to not overlap with the VPN. And that was a long time ago.
Also I’m really not seeing many people here “bikeshedding” over their home gear. Are you sure you’re reading these comments and not some other IPv6 discussion? Because those conversations definitely do happen but this particular thread hasn’t gone like that.
> Are we not? Because I suppose most people here are only disgruntled by a new protocol that changes how their home router works, and having to spend some learning effort.
I did make the context pretty clear when I said:
> the problem with enterprise is…
Also, you completely missed my point when you said:
> if you put in the work to do so. And I am confident in saying it is absolutely able to deliver on any kind of corporate network scenario, even moreso than IPv4.
My point wasn’t that IPv6 cannot deliver enterprise solutions. It’s that some of the design around it makes the process of deploying enterprise solutions more painful than it needed to be.
Nope, it doesn't. The security model is based on your firewalls and routing, not on NAT. NAT just gets in the way and makes it harder to understand what's going on.
For example, on a normal home network, if you don't have a firewall on your router then your ISP can connect to anything on your network. Even when they don't control the router and even if you're NATing.
If you didn't realize this then apparently NAT didn't make it easier to reason about after all.
Can you say more about the ISP connecting to any computer on your network? I can’t find any references to this aspect in googling the right terms and the concept is foreign to me.
There are a bunch of ways to break it, or misconfigure it. But I have idea what this isp method is.
It's just normal routing. If you send packets to a router, it'll route them.
More concretely, they can run the equivalent of `ip route add 192.168.1.0/24 via <your WAN IP>` on a machine that's connected to your WAN network, and then their machine will send packets with a dest of 192.168.1.x to your router. Your router will route them onto your LAN because that's what its own routing table says to do with them.
Anyone on your immediate upstream network can do this, not just your ISP. Also, if you use ISP-assigned GUAs then this inbound route will already exist and anyone on the Internet can connect. Applying NAT to your outbound connections will change their apparent source address, but it won't make that inbound route disappear.
20 some years ago when cable broadband was new, you connected a computer and got public IP. For this example let's just assume it was a public/24. Back then there was no firewall built into Windows, it didn't ask you if you were connecting to a public or private network.
For some ISPs you could connect a switch or hub (they still existed with cable came out, 1gbps switches were expensive) and connect multiple computers and they would all get different public IPs.
Back then a lot of network applications like windows filesharing heavily used the local subnet broadcast IP to announce themselves to other local computers on the network. Yes this meant when you opened up windows file sharing you might see the share from Dave's computer across town. I don't recall if the hidden always on shares like $c where widely know about at this time.
ISPs fixed this by blocking most of the traffic to and from the subnet broadcast address at the modem/headend level but for some time after I could still run a packet capture and see all the ARP packets and some other broadcasts from other models on my node, but it wasn't enough to be able to interfere with them anymore.
I understand this aspect, and this conversation is tricky because most consumer routers have this barebones firewall built in to reject the routing mentioned by the OP. So what we think of as a "router doing nat" often is subtly doing more. I'd hate to call what a barebones consumer router is doing a firewall because there are important firewall features that it does not have that are necessary for security.
It's just one firewall rule at the border to block all inbound traffic to a subnet or a range unless related to an outbound connection. Now you have identical security to a NAT. The huge win is you can forget about port forwarding and later just open the ports you need to the hosts you need or even the whole host if required.
At this point, the people who would be worried about this ought to know that temporary addresses are a thing, and that they prevent workstation N from having a single fixed IP for its outbound connections that it could be identified with.
> any website can now not only log that the traffic originated from org A, but specifically from org A, workstation N.
GeoIP databases and Cookies exist. So I'm not sure how your threat profile has increased here.
> I wonder, is privacy implication is not important enough for people to worry about this?
The most you can do over what is already possible is attempt an inventory or unit count of my office; however, you'd have to get every computer in my office to go to the same website that you control. Then you'd have to control for upgrades and other machine movements. I don't think this enables anything in particular.
One good thing about IPv6 is that any reasonable allocation will be large enough to use sizable chunks as functional divisions.
A small company might have a /48. You don't have to be concerned about address space when you just go, ok, first bit is for security zones. Or first 2 bits. Or first 3 bits. Do you need more than 8 security zones?
(Also, ULAs¹ exist, and most people should use them, independent of a possible consideration to not roll out GUAs² in parallel as one would normally do.)
> And if the target uses sudo at all you don't even need an exploit!
Why would a target executable use sudo? There are proper mechanisms for automated elevation of permissions and sudo isn’t it.
sudo is designed for user interactivity. And by default prompts for a password. However some people get lazy and disable the password entry requirement.
A target user. If you get local code execution on the account of a user that uses sudo you can trivially got root. Doesn't matter if they disabled the password authentication or not.
Of course it matters if they disabled password authentication. If you require password authentication when running sudo then an attacker has to find a RCE exploit and then crack a password. Which is waaay beyond any effort the average attacker is willing to invest. Because At that point, root access isn’t really worth the effort.
An attacker will probably just use the host for sending spam emails, bot / DDoS traffic or look for other daemons they can jump to which weren’t web accessible (eg a database).
And furthermore, if you’ve got a RCE in a daemon then that code is the running as the daemons’ user. Which shouldn’t be in the sudoers file (eg wheel group) to begin with.
Interesting. If that’s possible (I haven’t tested it, but I’m sure it is) then you wouldn’t even need to log the password. You could just alias sudo to a bash script that runs your malicious payload using the real sudo. Then the user would run the command, be prompted for their password by the real sudo, and be none the wiser that a malicious script has just been executed
For what it’s worth, Windows’ security model says it’s not an exploit that programs can grant themselves admin rights if the user is an admin (https://github.com/hfiref0x/UACME). But afaik Linux doesn’t have that model so it is a bit of an issue that this is possible
It’s literally in the opening post you replied to:
> A local privilege escalation to root via an exploitable service?
> Doesn't Linux have one of these CVEs...each week?
Why else would people be talking about docker, and user/group ownership of running services, and so on and so forth, in response to their comment and yours?
- the discussion was about how Defender might have “root” access but Linux services have CVEs too.
The reason Defender has elevated access is precisely because it needs to do stuff like hook into file system events and scan files irrespective of their underlying ACLs.
So it’s not the same as desktop anpplication exploit that would be running as the same user/group as the person logged in. And it’s also not the same as any other type of service, be that a RDBMS, web server, IRC server, nor any other type of server you might think off.
In fact this is true for both Windows AND Linux. Your average service will not have access to read user files and desktop applications are not services running as root.
I get you’re trying to make a balanced argument. And I do agree that Linux has had a great many poorly thought out design decisions (and even more problems inherent from its POSIX lineage). But the specific arguments you’re making in this thread are just misinformed and misunderstand how these operating systems work.
How are you going to do that without write access to the users home directory?
Like I said before, your RCE exploit will be running as the user and group of the service you exploited. For example www:www
So you’re not going to be able to write into Joe Bloggs .bashrc file unless Joe was stupid enough to enable write permission to “other”. Which, once again, requires the user to purposely modify the system into being less secure than its default configuration
> your RCE exploit will be running as the user and group of the service you exploited. For example www:www
Only if the exploit is through a web server or similar. If it's through the user's web browser, email client, video player, etc. etc. then you'll have write access to their home directory.
But thats not a daemon then. Thats a completely different type of exploit from the ones we were originally talking about.
Yes, if a desktop application has a bug then it can do damage. But at that point, who cares about sudo? The exploit already has access to your ssh keys, browser cookies and history (so can access banking and shopping sites), crypto-currency wallets and so on and so forth.
What an exploit has access to here is so much worse than getting root access on a desktop OS.
Only if you’re running daemons as root. Which would be an idiotic move to begin with because that’s not how distros package their services. So you’d have to intentionally make this mistake.
That’s just the docker daemon. The actual docker services would (or at least should) still be running as its own user/group just like they would if you were running them on the host.
And that’s exactly how any reputable image would be built.
“Higher quality” isn’t an objective measurement though. And it certainly doesn’t matter if the end result is that people cannot afford to buy it.
What I’d be interested to understand is whether changes to materials (be that buildings or home appliances) has caused an increase in the cost to manufacturer.
I’d wager most things have gotten cheaper to produce these days because the same improvements in technology that can be integrated into the product also applies to technology used to reduce the cost to manufacturer. Plus if wages are below inflation then any labour costs would have declined (relatively speaking) in that time too.
Having worked in both the US and EU, I can tell you the quality of life is vastly better in the EU.
US does have some perks for sure. But there are so many issues of its own and those issues are almost always pushed downwards to the most vulnerable groups. Which means, on average, you do end up with a better quality of life outside the US.
JavaScript didn’t kill Flash a Java. The web becoming cross platform did.
People started browsing on a plethora of devices from the Dreamcast to PDAs. And then Steve Jobs came a long and doubled down on the shift in accessibility. His stance on Flash was probably the only thing I agreed with him on too.
My only gripe with IPv6 addresses is they look too similar to MAC addresses. But as a representation, I think they’re absolutely fine.
reply