Does NPt make my internal network more secure?
-
@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..
