Does NPt make my internal network more secure?
-
Usually people recommend using the public IPv6 addresses directly on the internal machines, and do away with evil NAT and all that.
BUT I was thinking: I have some web services on my internal LAN that don't require any application level authentication, but are secured using the IP address the request comes from. So say I am in IPv4 world, and I have a web application that does not require any authentication, but is configured to be accessible only from clients inside the 192.168.1.0/24 network. The webapp is conveniently accessible without authentication, and is effectively secure from people from outside the LAN.
Now, with IPv6, if I configure the public addresses on the internal LAN, my LAN is something like 2001:2000:9000:3000::/64. If I configure the webapp that is hosted on 2001:2000:9000:3000::1 - and this same box is accessible from the internet - that all clients from inside the network 2001:2000:9000:3000::/64 can access it, someone from my ISP could just use one of the addresses to access my internal service from outside my lan. Right?So am I missing something obvious here? Or is this a case where using something like fdf5:2222:3333:4444::/64 internally that gets translated with NPt to 2001:2000:9000:3000::/64 externally is more secure?
-
"So am I missing something obvious here?"
Yeah.. Just because your IP is public or global doesn't mean anyone from internet can get to it. That is the whole point of the firewall.
if your app is only going allow specific prefixes to talk to you, you would use the prefixes you use internally, etc.. You wouldn't allow all of ipv6 space to get access.
"2001:2000:9000:3000::/64 can access it, someone from my ISP could just use one of the addresses to access my internal service from outside my lan. Right?"
No - how exactly would they do that??
-
You can use Unique Local Addresses, the IPv6 equivalent of IPv4 RFC 1918 addresses. You can create a prefix in that range, which those servers can use. You can then have both global and local addresses on the computers that have to access both those servers and the Internet. Contrary to what some here will say, that is an entirely valid configuration and supported by IPv6 design. Of course, there's no reason why you couldn't add a 2nd LAN interface and let pfSense route accordingly.
-
And completely pointless… Zero reason to run ULA if your going to run global..
-
"So am I missing something obvious here?"
Yeah.. Just because your IP is public or global doesn't mean anyone from internet can get to it. That is the whole point of the firewall.
if your app is only going allow specific prefixes to talk to you, you would use the prefixes you use internally, etc.. You wouldn't allow all of ipv6 space to get access.
"2001:2000:9000:3000::/64 can access it, someone from my ISP could just use one of the addresses to access my internal service from outside my lan. Right?"
No - how exactly would they do that??
Let me make a practical example:
My lan is 2001:2000:9000:3000::/64
I have an apache webserver that has multiple vhosts.Here I control my lights, and this should be accessible only from my LOCAL network:
<virtualhost *:80="">ServerName lights.myhome.com <location>Require ip 127.0.0.1 Require ip 192.168.1.0/16 Require ip 2001:2000:9000:3000::/64</location></virtualhost>This is my website, and it should be accessible from EVERYWHERE:
<virtualhost *:80="">ServerName myhome.com DocumentRoot /var/www</virtualhost>This server has IP 2001:2000:9000:3000::1. This server is on the internet, because he serves my homepage on myhome.com.
Now, if someone from my ISP uses IP 2001:2000:9000:3000::5555 and sends an HTTP request for lights.myhome.com, he gets access to the interface. I could trust my ISP not to abuse the IPs he assigned to me, but I don't want to. With ULA addresses this problem does not exist, because I can change the Vhost configuration to something like
<virtualhost *:80="">ServerName lights.myhome.com <location>Require ip 127.0.0.1 Require ip 192.168.1.0/16 Require ip fdf5:2222:3333:4444::/64</location></virtualhost>Obviously I am missing something here. But what?
-
"Now, if someone from my ISP uses IP 2001:2000:9000:3000::5555"
And how exactly are they going to do that? That /64 has been assigned to you.. They can not use it..
Lets say they could do it - which they can't… Why would you firewall allow this in from the internet?
-
And completely pointless… Zero reason to run ULA if your going to run global..
The IETF seems to think otherwise:
From https://tools.ietf.org/html/rfc4193.html section 4.6
- Nodes that can communicate with other nodes inside of the site
and outside of the site: These nodes should autoconfigure global
addresses via [ADDAUTO] or receive global address via [DHCP6].
They may also obtain Local IPv6 addresses via the same
mechanisms.
They must have thought there were valid reasons for having both. PfSense certainly has no problem providing both on an interface.
- Nodes that can communicate with other nodes inside of the site
-
Where do you read that? That does not say anything of the sort…
I can put rfc1918 and public on a box as well - doesn't mean you should...
You seem to think its ok to run multiple layer 3 on the same layer 2, which is exactly what that is.. Which is not the case, be it you can do it or not..
Who says those are the same interface? It could be a back lan, or a storage network..
If he wants to run ULA on a vlan interface, and Global on another vlan - sure ok... Pretty pointless but yeah you can do it..
I could for sure see it as storage network say.. This should be a different L2..
-
"Now, if someone from my ISP uses IP 2001:2000:9000:3000::5555"
And how exactly are they going to do that? That /64 has been assigned to you.. They can not use it..
Lets say they could do it - which they can't… Why would you firewall allow this in from the internet?
Well it's "their" IPs, no? Why should they not be able to ip -6 addr add 2001:2000:9000:3000::5555/64 dev eth0 and be ready to go?
And I am allowing it from the internet because
"This server has IP 2001:2000:9000:3000::1. This server is on the internet, because he serves my homepage on myhome.com."
If I don't allow it from the internet myhome.com is down.
-
"Well it's "their" IPs, no?"
No once the prefix has been assigned to you.. It is routed to you - they can not just use it..
If your allowing the whole internet into it.. The doesn't matter what IP they use they would be able to get to it… I think you think that a /64 is shared between all the users of the ISP or something. a prefix wold be assigned to your connection. Other users would not get that same prefix until your lease on it had expired. Same way they give you 1 IPv4, nobody else can use it - but it is theirs, etc.
-
If your allowing the whole internet into it.. The doesn't matter what IP they use they would be able to get to it…
You don't understand. I allow the whole internet onto it ON HE FIREWALL, BUT the web server has access control on the IPs that access it.
-
You don't understand that is not secure!!!
But if that is what you want…What your worried about is spoofing the source IP. Which works on UDP.. But not really a viable 2 way communication method in TCP.
But if you have /64 assigned to you - nobody else is going to be able to use it.
What do you open to the public internet for any reason to access your iot stuff - no reason to do that.. Internet does not need access to this sort of stuff. If your out and about and you want access then vpn into your network to access.
-
You don't understand that is not secure!!!
Sure johnpoz, then tell me how it's done :)
I opened this thread to ask just that.
-
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
-
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
-
@pox:
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
You block everything on your IPv6 WAN by default (which is the default policy of pfSense anyway) and in your IPv6 WAN rules you allow only the traffic that is going to your webserver. After that you can do additional access control on the webserver based on the source addresses of the requests and limit access of internal sites that you don't want to expose to the internet.
-
@kpa:
@pox:
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
You block everything on your IPv6 WAN by default (which is the default policy of pfSense anyway) and in your IPv6 WAN rules you allow only the traffic that is going to your webserver. After that you can do additional access control on the webserver based on the source addresses of the requests and limit access of internal sites that you don't want to expose to the internet.
As stated, the webserver hosts lights.myhome.com and myhome.com. lights.myhome.com should not be accessible from the internet. If I do what you say I should do, lights.myhome.com is accessible from the internet.
-
@pox:
@kpa:
@pox:
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
You block everything on your IPv6 WAN by default (which is the default policy of pfSense anyway) and in your IPv6 WAN rules you allow only the traffic that is going to your webserver. After that you can do additional access control on the webserver based on the source addresses of the requests and limit access of internal sites that you don't want to expose to the internet.
As stated, the webserver hosts lights.myhome.com and myhome.com. lights.myhome.com should not be accessible from the internet. If I do what you say I should do, lights.myhome.com is accessible from the internet.
Then you have misconfigured your webserver to allow access to those sites from the internet.
-
@kpa:
@pox:
@kpa:
@pox:
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
So, how do you manage a service like the one I described in a secure fashion without NPt?
You block everything on your IPv6 WAN by default (which is the default policy of pfSense anyway) and in your IPv6 WAN rules you allow only the traffic that is going to your webserver. After that you can do additional access control on the webserver based on the source addresses of the requests and limit access of internal sites that you don't want to expose to the internet.
As stated, the webserver hosts lights.myhome.com and myhome.com. lights.myhome.com should not be accessible from the internet. If I do what you say I should do, lights.myhome.com is accessible from the internet.
Then you have misconfigured your webserver to allow access to those sites from the internet.
Maybe. Do you think you have the skills to tell me how to do it in a secure fashion, instead of answering with snarky one-liners that don't help anyone?
-
@kpa:
If you're going to keep something open to the whole internet it makes zero difference if there is NAT involved or not. The only thing that counts for security is then what your edge router/firewall does with the incoming traffic. Sort out your filter rules on your pfSense.
This is one of the problems with NAT. People are so convinced it provides security, they forget how firewalls actually work. There is nothing NAT can do that a properly configured firewall can't.
-
Maybe. Do you think you have the skills to tell me how to do it in a secure fashion, instead of answering with snarky one-liners that don't help anyone?
It does not matter if you are passing traffic to the post-NAT address or a public (IPv6 or IPv4) address.
NAT adds no security. It only adds complexity.
The problem is that you are passing the traffic. So don't do that.
the webserver hosts lights.myhome.com and myhome.com.
Do these resolve to the same address? If so there is no way for the firewall to know what to pass and what not to pass and the decision to serve or not has to be done in the web server (unless you get into something like HAproxy). If not, then block one and pass the other.
-
the webserver hosts lights.myhome.com and myhome.com.
Do these resolve to the same address? If so there is no way for the firewall to know what to pass and what not to pass and the decision to serve or not has to be done in the web server (unless you get into something like HAproxy). If not, then block one and pass the other.
At the moment they resolve to the same address. 192.168.0.1, or 2001:2000:9000:3000::1. So if the firewall can't take the decision, and the webserver can't take the decision, who does?
-
The web server does. Use access lists there.
-
The web server does. Use access lists there.
How? And here I come back to my original question: say my ISP gave me 2001:2000:9000::/48. Clients on my lan who should be able to access 2001:2000:9000:3000::1 (the web server) are in 2001:2000:9000:1::/64.
I can tell the webserver that he should accept connections for lights.myhome.com only from addresses that are in 2001:2000:9000:1::/64.
What is preventing someone working at my ISP doing
ip -6 addr add 2001:2000:9000:1::5555/64 dev eth0
and getting access to my lights?
-
What the actual fuck, dude. Source addresses mean nothing. You either pass the traffic into WAN from any or you don't.
If you do not want traffic ingressing into your network from addresses that should only originate from inside then block them. Pretty sure there are already anti-spoofing rules that do that but if it makes you feel better, then explicitly block the traffic.
You are not making a whole lot of sense.
Clients on your LAN and clients out on WAN are two completely different things. Governed by Layer 2 in the first case and firewall rules on WAN in the second case.
-
What the actual fuck, dude. Source addresses mean nothing. You either pass the traffic into WAN from any or you don't.
If you do not want traffic ingressing into your network from addresses that should only originate from inside then block them. Pretty sure there are already anti-spoofing rules that do that but if it makes you feel better, then explicitly block the traffic.
You are not making a whole lot of sense.
Clients on your LAN and clients out on WAN are two completely different things. Governed by Layer 2 in the first case and firewall rules on WAN in the second case.
Thanks, I think this was the missing pice! So I just block anything coming with source address 2001:2000:9000::/48 (my assigned block) on the WAN interface and I should be done. Makes sense. Did I get it?
This is in contrast with "Source addresses mean nothing.". What do you mean?
-
Where do you read that? That does not say anything of the sort…
I can put rfc1918 and public on a box as well - doesn't mean you should...
You seem to think its ok to run multiple layer 3 on the same layer 2, which is exactly what that is.. Which is not the case, be it you can do it or not..
Who says those are the same interface? It could be a back lan, or a storage network..
If he wants to run ULA on a vlan interface, and Global on another vlan - sure ok... Pretty pointless but yeah you can do it..
I could for sure see it as storage network say.. This should be a different L2..
Well, here's what RFC 6724 says:
1. Introduction
The IPv6 addressing architecture [RFC4291] allows multiple unicast
addresses to be assigned to interfaces. These addresses might have
different reachability scopes (link-local, site-local, or global).
These addresses might also be "preferred" or "deprecated" [RFC4862].
Privacy considerations have introduced the concepts of "public
addresses" and "temporary addresses" [RFC4941]. The mobility
architecture introduces "home addresses" and "care-of addresses"
[RFC6275]. In addition, multi-homing situations will result in more
addresses per node. For example, a node might have multiple
interfaces, some of them tunnels or virtual interfaces, or a site
might have multiple ISP attachments with a global prefix per ISP.Notice it says "multiple unicast addresses". That implies more than two, so we can rule out just a unicast & a link local. It also mentions multiple scopes (unique local replaced site local). Clearly the IETF intended there be multiple routable addresses on a single interface. It also mentions multiple ISPs & prefixes. These are things I've mentioned were possible with IPv6. You may think it's "borked", but you're at odds with the IETF. They seem to think there are valid reasons for these things. I have also read pretty much the same in the Cisco book "IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6" 2nd ed..
