Is NAT can provide some kind of protection?
We have wide range of Public IP addresses, I tried to assign public ip directly to a server behined firewall( in DMZ), but I have been resisted. Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons. Is it true that NAT can provide more security? Thanks, Tarig Yassin Ahmed
On 21/03/2007 09:41, Tarig Ahmed wrote:
Is it true that NAT can provide more security?
No. Your security person is probably confusing NAT with firewalling, as NAT devices will intrinsically do firewalling of various forms, sometimes stateful, sometimes not. Stateful firewalling _may_ provide more security in some situations for low bandwidth applications, at least before you're hit by a DoS attack; for high bandwidth applications, stateful firewalling is usually a complete waste of time. Your security guy will probably say that a private IP address will give better protection because it's not reachable on the internet. But the reality is if you have 1:1 NAT to a server port, then you have reachability and his argument becomes substantially invalid. Most security problems are going to be related to poor coding anyway (XSS, improper data validation, etc), rather than port reachability, which is easy to fix. Unfortunately, many security people from large organisations do not appreciate these arguments, but instead write their own and other peoples' opinions down and call them "policy". Changing policy can be difficult. Nick
In fact our firewall is stateful. This is why I thought, we no need to Nat at least our servers. Tarig Yassin Ahmed On Jan 12, 2011, at 4:59 PM, Nick Hilliard <nick@foobar.org> wrote:
On 21/03/2007 09:41, Tarig Ahmed wrote:
Is it true that NAT can provide more security?
No.
Your security person is probably confusing NAT with firewalling, as NAT devices will intrinsically do firewalling of various forms, sometimes stateful, sometimes not. Stateful firewalling _may_ provide more security in some situations for low bandwidth applications, at least before you're hit by a DoS attack; for high bandwidth applications, stateful firewalling is usually a complete waste of time.
Your security guy will probably say that a private IP address will give better protection because it's not reachable on the internet. But the reality is if you have 1:1 NAT to a server port, then you have reachability and his argument becomes substantially invalid. Most security problems are going to be related to poor coding anyway (XSS, improper data validation, etc), rather than port reachability, which is easy to fix.
Unfortunately, many security people from large organisations do not appreciate these arguments, but instead write their own and other peoples' opinions down and call them "policy". Changing policy can be difficult.
Nick
On 3/21/2007 6:25 AM, Tarig Ahmed wrote:
In fact our firewall is stateful. This is why I thought, we no need to Nat at least our servers.
Tarig Yassin Ahmed
On Jan 12, 2011, at 4:59 PM, Nick Hilliard <nick@foobar.org> wrote:
On 21/03/2007 09:41, Tarig Ahmed wrote:
Is it true that NAT can provide more security?
No.
Your security person is probably confusing NAT with firewalling, as NAT devices will intrinsically do firewalling of various forms, sometimes stateful, sometimes not. Stateful firewalling _may_ provide more security in some situations for low bandwidth applications, at least before you're hit by a DoS attack; for high bandwidth applications, stateful firewalling is usually a complete waste of time.
Your security guy will probably say that a private IP address will give better protection because it's not reachable on the internet. But the reality is if you have 1:1 NAT to a server port, then you have reachability and his argument becomes substantially invalid. Most security problems are going to be related to poor coding anyway (XSS, improper data validation, etc), rather than port reachability, which is easy to fix.
Unfortunately, many security people from large organisations do not appreciate these arguments, but instead write their own and other peoples' opinions down and call them "policy". Changing policy can be difficult.
Nick
Tarig is sending email from the past. Spooky.
+1 on Nick's comment. If you're doing 1:1 NAT or port forwarding your server is still public facing. If your firewall is merely stateful and not deep packet inspecting all it's doing is seeing is that the statefulness of the connection meets it's requirements. You could have that and still have all kinds of naughtiness going on. Greg On Mar 21, 2007, at 6:25 AM, Tarig Ahmed wrote:
In fact our firewall is stateful. This is why I thought, we no need to Nat at least our servers.
Tarig Yassin Ahmed
On Jan 12, 2011, at 4:59 PM, Nick Hilliard <nick@foobar.org> wrote:
On 21/03/2007 09:41, Tarig Ahmed wrote:
Is it true that NAT can provide more security?
No.
Your security person is probably confusing NAT with firewalling, as NAT devices will intrinsically do firewalling of various forms, sometimes stateful, sometimes not. Stateful firewalling _may_ provide more security in some situations for low bandwidth applications, at least before you're hit by a DoS attack; for high bandwidth applications, stateful firewalling is usually a complete waste of time.
Your security guy will probably say that a private IP address will give better protection because it's not reachable on the internet. But the reality is if you have 1:1 NAT to a server port, then you have reachability and his argument becomes substantially invalid. Most security problems are going to be related to poor coding anyway (XSS, improper data validation, etc), rather than port reachability, which is easy to fix.
Unfortunately, many security people from large organisations do not appreciate these arguments, but instead write their own and other peoples' opinions down and call them "policy". Changing policy can be difficult.
Nick
On 01/12/2011 02:59 PM, Nick Hilliard wrote:
On 21/03/2007 09:41, Tarig Ahmed wrote:
Is it true that NAT can provide more security?
No.
[snip]
Your security guy will probably say that a private IP address will give better protection because it's not reachable on the internet. But the reality is if you have 1:1 NAT to a server port, then you have reachability and his argument becomes substantially invalid.
This setup will provide *less* security. Apart from the DoS scenario, should your public facing server get compromised, you have given easy access to your private infrastructure. -Lorand Jakab
On Wed, 12 Jan 2011 16:01:15 +0100, =?ISO-8859-1?Q?Lor=E1nd_Jakab?= said:
This setup will provide *less* security. Apart from the DoS scenario, should your public facing server get compromised, you have given easy access to your private infrastructure.
If a public server behind a NAT gets whacked via a php vulnerability, you've *still* given away access to everything behind the NAT that server can reach.
Is it true that NAT can provide more security?
Thanks,
Tarig Yassin Ahmed
You are going to get different answers from different people. In and of itself it doesn't provide security but it does place one more layer of difficulty in getting at your internal machines. On the other hand, NAT makes many things a lot more difficult than they need to be in many cases and outright breaks some protocols (SCTP, for example). On one hand, yes, it can make direct addressing of your servers more difficult but doesn't guarantee anything. RFC1918 routes should not be routed over the internet but sometimes people "leak" them and sometimes people accept such leaked routes. So there is the possibility that someone could "see" a route to your RFC1918 space. But on the other hand, even if you did "leak" the route, the odds of someone being able to reliably connect to your network is pretty low because if they are accepting such leaked routes from you, they might be accepting them from others, too. And your upstream's peers are probably filtering 1918 space and most likely route traffic destined to rfc1918 space they aren't using to a black hole. But your security person needs to shift their thinking because the purpose of NAT and private addressing is to conserve IP address, not to provide security. With IPv6, the concept of NAT goes away. You servers will need public IP addresses if they are going to transact information across the Internet. So the "security" concerns of public IP space are moot when it comes to IPv6.
On 12/01/2011 01:17 p.m., George Bonser wrote:
But your security person needs to shift their thinking because the purpose of NAT and private addressing is to conserve IP address, not to provide security. With IPv6, the concept of NAT goes away.
You have heard about NAT66, right? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
-----Original Message----- From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of Fernando Gont Sent: Wednesday, January 12, 2011 8:54 AM To: George Bonser Cc: Tarig Ahmed; nanog@nanog.org Subject: Re: Is NAT can provide some kind of protection?
On 12/01/2011 01:17 p.m., George Bonser wrote:
But your security person needs to shift their thinking because the purpose of NAT and private addressing is to conserve IP address, not to provide security. With IPv6, the concept of NAT goes away.
You have heard about NAT66, right?
Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Oh, yeah. But NAT66 does not provide the "security" aspect of PAT with V4. It is just a straight static NAT. So each of your machines is still directly addressable from the Internet. With v4 PAT, you can not be sure which address/port on the external IP maps to which address/port on the inside IP at any given moment and PAT is stateful in that an outbound packet is required to start the mapping. NAT66 is just straight static NAT that maps one prefix to a different prefix.
I'd eat a hat if a vendor didn't implement a PAT equivalent. It's demanded too much. There is money for it, so it will be there.
Jack
Yeah, I think you are right. But in really thinking about it, I wonder why. The whole point of PAT was address conservation. You don't need that with v6. All you need to do with v6 is basically have what amounts to a firewall in transparent mode in the line and doesn't let a packet in (except where explicitly configure to) unless it is associated with a packet that went out. PAT makes little sense to me for v6, but I suspect you are correct. In addition, we are putting the "fire suit" on each host in addition to the firewall. Kernel firewall rules on each host for the *nix boxen.
On 1/12/2011 11:21 AM, George Bonser wrote:
PAT makes little sense to me for v6, but I suspect you are correct. In addition, we are putting the "fire suit" on each host in addition to the firewall. Kernel firewall rules on each host for the *nix boxen.
As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function. Given that the internal is exclusively PAT, the DMZ is public with stateful/proxy, this provides protection for the internal network while limiting the dmz exposure. The argument everyone makes is that a stateful firewall defaults to deny. However, a single mistake prior to the deny allows traffic in. The only equivalent in a PAT scenario is to screw up port forwarding which would cause a single host to expose a single port unknowingly per mistake (which said port/host combo may not be vulnerable). In a stateful firewall, a screw up could expose all ports on a host or multiple hosts in a single mistake. Then there are the firewall software bugs. In PAT, such bugs don't suddenly expose all your hosts behind the firewall for direct communication from the outside world. In v6 stateful firewall, such a bug could allow circumvention of the entire firewall ruleset and the hosts would be directly addressable from the outside. PAT offers the smallest of security safeguards. However, many corp IT personnel feel more secure having that small safeguard in place along with the many other safeguards they deploy. In a corporate environment where they often love to break everything and anything, I don't blame them. Then we go to the educational sector, where the admins often prefer as much openness as possible. In their case, they will prefer to do away with PAT. Jack
On Wed, Jan 12, 2011 at 9:36 AM, Jack Bates <jbates@brightok.net> wrote:
As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function.
But that's not true. If you have NAT, without a firewall, I can access your internal hosts (by addressing their RFC 1918 address) because you'll be leaking your RFC 1918 addresses in and out. Granted, I might have to be in your immediate upstream, but it can be done. So at best, all it does is limit how many hops away I need to be from you to attack you. Some benefit? Yes. Enough benefit to be worth the trouble? I personally am not convinced. Considering the amount of people who mistake the amount of security NAT provides, we're probably better off without it to remove that false sense of security.
On 1/12/2011 11:57 AM, Steven Kurylo wrote:
Some benefit? Yes. Enough benefit to be worth the trouble? I personally am not convinced.
Some people believe it is. Who am I to tell them how to run their network? They block facebook and yahoo. I, unfortunately, can't. :)
Considering the amount of people who mistake the amount of security NAT provides, we're probably better off without it to remove that false sense of security.
People will then have a false sense of security with stateful firewalls that perform no better than NAT, just without the address translation. The type of stateful firewall with or without address translation will not suddenly make people become wiser and implement better security policies. Vendors will always make a cheap setup which people will use and consider themselves secure. Jack
On Jan 12, 2011, at 9:36 AM, Jack Bates wrote:
On 1/12/2011 11:21 AM, George Bonser wrote:
PAT makes little sense to me for v6, but I suspect you are correct. In addition, we are putting the "fire suit" on each host in addition to the firewall. Kernel firewall rules on each host for the *nix boxen.
As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function. Given that the internal is exclusively PAT, the DMZ is public with stateful/proxy, this provides protection for the internal network while limiting the dmz exposure.
The corp IT guy is delusional. The solution to the routing disconnect is map+encap or tunnels. Many exploits now take advantage of these technologies to use a system compromised through point-click-pwn3d to provide a route into the rest of the network. If you allow outbound access to TCP/80, TCP/443, or TCP/22, then, it is trivial to create an inbound path to your network, NAT or no.
The argument everyone makes is that a stateful firewall defaults to deny. However, a single mistake prior to the deny allows traffic in. The only equivalent in a PAT scenario is to screw up port forwarding which would cause a single host to expose a single port unknowingly per mistake (which said port/host combo may not be vulnerable). In a stateful firewall, a screw up could expose all ports on a host or multiple hosts in a single mistake.
The argument everyone is making is that a stateful firewall without mangling the headers is just as secure (and just as insecure) as one with PAT. Both can and are trivially compromised. As to the PAT scenario only exposing a single port on a single host, not entirely accurate, either. I have seen errant mappings which exposed much more in a single mapping command on some systems. Then there are the NAT Traversal mechanisms which are necessary to make things function but can also be exploited. The list of problems created by PAT goes on and on.
Then there are the firewall software bugs. In PAT, such bugs don't suddenly expose all your hosts behind the firewall for direct communication from the outside world. In v6 stateful firewall, such a bug could allow circumvention of the entire firewall ruleset and the hosts would be directly addressable from the outside.
I've seen PAT bugs that exposed multiple hosts. This is false sense of security.
PAT offers the smallest of security safeguards. However, many corp IT personnel feel more secure having that small safeguard in place along with the many other safeguards they deploy. In a corporate environment where they often love to break everything and anything, I don't blame them.
Paraphrased: A bank vault with a screen door is more secure than a bank vault without a screen door. Pay no attention to the fact that the bank vault was, in this case, built with a skylight. Owen
On 1/12/2011 1:35 PM, Owen DeLong wrote:
The corp IT guy is delusional. The solution to the routing disconnect is map+encap or tunnels. Many exploits now take advantage of these technologies to use a system compromised through point-click-pwn3d to provide a route into the rest of the network. If you allow outbound access to TCP/80, TCP/443, or TCP/22, then, it is trivial to create an inbound path to your network, NAT or no.
This presumes the inside network is already compromised. In such a case, a stateful/non-proxy firewall would also be subject to such a thing. This is not what PAT prevents that a stateful firewall doesn't.
The argument everyone is making is that a stateful firewall without mangling the headers is just as secure (and just as insecure) as one with PAT.
Except that the routing isolation means that it is not just as secure. It has one extra vulnerability over NAT.
Both can and are trivially compromised.
Agreed that there are still ways around them. Anyone relying on a single mechanism for security will often find their security to be inefficient.
As to the PAT scenario only exposing a single port on a single host, not entirely accurate, either. I have seen errant mappings which exposed much more in a single mapping command on some systems.
On a standard port redirect, I'd be interested to hear the specifics. However, as my IT guy points out, he doesn't do port or 1-1 redirects through NAT.
Then there are the NAT Traversal mechanisms which are necessary to make things function but can also be exploited.
Things don't function through his firewall. He likes breakage.
The list of problems created by PAT goes on and on.
PAT creates a lot of issues. However, for some environments, what it breaks are perfectly acceptable. Utilizing PAT in home routers and facilities that have a more open use of technology, would be crippling the protocol needlessly.
I've seen PAT bugs that exposed multiple hosts. This is false sense of security.
Specifics.
Paraphrased: A bank vault with a screen door is more secure than a bank vault without a screen door.
Pay no attention to the fact that the bank vault was, in this case, built with a skylight.
If you installed a skylight, that's your own fault. Nowhere have I said, PAT is the ultimate in security and forget everything else. I've said the opposite. PAT has it's uses and does provide certain safeguards. It is one small piece in a huge arsenal of security mechanisms implemented in a network. The entire edge firewall system is only a small piece in network security. If you strictly depend on the edge firewall for security, you may someday learn the error of doing so. Many companies have. Jack
On Jan 12, 2011, at 9:21 AM, George Bonser wrote:
I'd eat a hat if a vendor didn't implement a PAT equivalent. It's demanded too much. There is money for it, so it will be there.
Jack
Yeah, I think you are right. But in really thinking about it, I wonder why. The whole point of PAT was address conservation. You don't need that with v6. All you need to do with v6 is basically have what amounts to a firewall in transparent mode in the line and doesn't let a packet in (except where explicitly configure to) unless it is associated with a packet that went out.
PAT makes little sense to me for v6, but I suspect you are correct. In addition, we are putting the "fire suit" on each host in addition to the firewall. Kernel firewall rules on each host for the *nix boxen.
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6: 1.) Allows you to redirect a privileged port (on UNIX) to a non-privileged port. For daemons that don't implement some form of privilege revoking after binding to a low port (and/or aren't allowed to run as root), this is very useful. It's much easier to have a firewall redirect than to implement robust privilege revoking. Example: PAT 25/tcp -> 2525/tcp. 2.) Allows you to redirect multiple ports to a single one, to support legacy implementations. Suppose your application used to require separate ports for different types of requests, but now is able to multiplex them. The new daemon only listens on one port, but other applications may not have updated their configuration. Example: PAT 4443/tcp -> 443/tcp & PAT 8443/tcp -> 443/tcp. Basically the idea is that implementing PAT for IPv6 allows smoother transition for apps that made use of it in IPv4, thus accelerating the adoption of IPv6. -- bk
On Sat, Jan 15, 2011 at 4:16 PM, Brian Keefer <chort@smtps.net> wrote:
1.) Allows you to redirect a privileged port (on UNIX) to a non-privileged port. For daemons that don't implement some form of privilege revoking after binding to a low port (and/or aren't allowed to run as root), this is very useful. It's much easier to have a firewall redirect than to implement robust privilege revoking. Example: PAT 25/tcp -> 2525/tcp.
There was a patch offered for the Linux kernel years ago that exported the network ports as a filesystem where you could set who could bind which port by changing the ownership and permissions on the "files." I never understood why Linus rejected it. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Jan 15, 2011, at 1:16 PM, Brian Keefer wrote:
On Jan 12, 2011, at 9:21 AM, George Bonser wrote:
I'd eat a hat if a vendor didn't implement a PAT equivalent. It's demanded too much. There is money for it, so it will be there.
Jack
Yeah, I think you are right. But in really thinking about it, I wonder why. The whole point of PAT was address conservation. You don't need that with v6. All you need to do with v6 is basically have what amounts to a firewall in transparent mode in the line and doesn't let a packet in (except where explicitly configure to) unless it is associated with a packet that went out.
PAT makes little sense to me for v6, but I suspect you are correct. In addition, we are putting the "fire suit" on each host in addition to the firewall. Kernel firewall rules on each host for the *nix boxen.
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6: 1.) Allows you to redirect a privileged port (on UNIX) to a non-privileged port. For daemons that don't implement some form of privilege revoking after binding to a low port (and/or aren't allowed to run as root), this is very useful. It's much easier to have a firewall redirect than to implement robust privilege revoking. Example: PAT 25/tcp -> 2525/tcp.
Actually, that's just port rewriting which is mostly harmless. PAT refers, instead, to a stateful translation which is most definitely not harmless.
2.) Allows you to redirect multiple ports to a single one, to support legacy implementations. Suppose your application used to require separate ports for different types of requests, but now is able to multiplex them. The new daemon only listens on one port, but other applications may not have updated their configuration. Example: PAT 4443/tcp -> 443/tcp & PAT 8443/tcp -> 443/tcp.
That's a pretty ugly situation, but, it would require a stateful mechanism to address it. I think it is much cleaner to have the daemon listen on the multiple ports.
Basically the idea is that implementing PAT for IPv6 allows smoother transition for apps that made use of it in IPv4, thus accelerating the adoption of IPv6.
I think the lack of IPv4 resources will soon serve as sufficient acceleration of IPv6 adoption. Owen
On Sat, 15 Jan 2011, Brian Keefer wrote:
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6:
You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses. Since many residential users won't stand for an additional fee, pressure will be placed on CPE vendors to include v6 PAT in their devices. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Jan 15, 2011, at 3:06 PM, Brandon Ross wrote:
On Sat, 15 Jan 2011, Brian Keefer wrote:
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6:
You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses. Since many residential users won't stand for an additional fee, pressure will be placed on CPE vendors to include v6 PAT in their devices.
-- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
I really doubt this will be the case in IPv6. The few service providers that try this will rapidly find their customers moving to service providers that do not. I know that Comcast is not planning to do this to their customers. I can't imagine too many ISPs that might even attempt to get away with treating their customers worse than Comcast does. Owen
On Sat, 15 Jan 2011, Owen DeLong wrote:
I really doubt this will be the case in IPv6.
I really hope you are right, because I don't want to see that either, however... Why do you suppose they did that before with IPv4? Sure you can make the argument NOW that v4 is in scarce supply, but 10 years ago it was still the case. Has Comcast actually come out and committed to allowing me to have as my IPs as I want on a consumer connection in the most basic, cheapest package? Has any other major provider? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On 1/15/11 3:24 PM, Brandon Ross wrote:
On Sat, 15 Jan 2011, Owen DeLong wrote:
I really doubt this will be the case in IPv6. I really hope you are right, because I don't want to see that either, however...
Why do you suppose they did that before with IPv4? Sure you can make the argument NOW that v4 is in scarce supply, but 10 years ago it was still the case.
Has Comcast actually come out and committed to allowing me to have as my IPs as I want on a consumer connection in the most basic, cheapest package? Has any other major provider? As a customer of Comcast, you can set up a tunnel to he.net and obtain your own prefix which then enables 18 x 10^18 IP addresses at no additional cost. See: http://tunnelbroker.net/ and http://www.comcast6.net/
-Doug
On Sat, Jan 15, 2011 at 06:24:01PM -0500, Brandon Ross wrote:
On Sat, 15 Jan 2011, Owen DeLong wrote:
I really doubt this will be the case in IPv6.
I really hope you are right, because I don't want to see that either, however...
Why do you suppose they did that before with IPv4? Sure you can make the argument NOW that v4 is in scarce supply, but 10 years ago it was still the case.
The finest raisins of all: hysterical raisins. Widespread consumer internet access was dialup, with Trumpet or equivalent. The concept of "home networks" was, at best, for the uber, *uber* nerds (like most people on this list). The idea that an average home user would *ever* need more than one IP was ludicrous, so your basic dialup account provided one IP (although I recall being able to ask for more, for free, if I needed them). Then it became a "value add" to have more than one IP, and then NAT came along because the hackers at home had networks, and then the hackers at home went into IT and used consumer-grade ISPs, and so they deployed NAT in the enterprise, and then those people became the standards writers for PCI DSS... - Matt
On Jan 15, 2011, at 3:24 PM, Brandon Ross wrote:
On Sat, 15 Jan 2011, Owen DeLong wrote:
I really doubt this will be the case in IPv6.
I really hope you are right, because I don't want to see that either, however...
Why do you suppose they did that before with IPv4? Sure you can make the argument NOW that v4 is in scarce supply, but 10 years ago it was still the case.
1. IPv4 provided no convenient way for them to dynamically assign more than a /32. DHCPv6 allows for DHCP-PD. 2. IPv4 addresses were known to be scarce before most of the current residential ISPs even existed at least in their current form. 10 years ago, we knew that we had gone a decade beyond the point when we recognized that IPv4 would runout if we kept issuing addresses to consumers. Frankly, we didn't, at the time, expect NAT + single address assignments to buy us more than about 10 years and it came as a bit of a surprise when we still had a bunch of space left at that point.
Has Comcast actually come out and committed to allowing me to have as my IPs as I want on a consumer connection in the most basic, cheapest package? Has any other major provider?
No. But they have said that they are issuing prefixes and not host addresses. I doubt any ISP will commit to offering you as many IPs as you want on the most basic consumer grade service as I don't think any ISP would make that commitment on their top of the line business class service, either. However, I think you will see most ISPs offering at least /56s and hopefully /48s. Free.fr is giving out /60s, but, that's due to their limitations on their 6rd deployment and I suspect that when they migrate to native IPv6, they may use larger prefixes. I don't think there's too much to worry about providers handing out individual addresses in IPv6. It's too hard to maintain and it doesn't scale like it did in IPv4. I do think that we have to worry about things like /60s and /56s getting entrenched. I think it is unfortunate that IETF has backed off of the /48 standard in their recent update to 3177. I think that clarification that it is for an end-site would have been better. The use of /56s will hamper innovation and prevent vendors from bringing some cool things to the market. Owen
On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Ross <bross@pobox.com> wrote:
On Sat, 15 Jan 2011, Brian Keefer wrote:
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6:
You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses.
How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address?
Since many residential users won't stand for an additional fee, pressure will be placed on CPE vendors to include v6 PAT in their devices.
-- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Sun, 16 Jan 2011, Mark Smith wrote:
How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address?
Huh? Who said anything about 100%? It would take only a single reasonably sized provider that has a monopoly in a particular area (tell me that doesn't happen) or a pair of them that have a duopoly (almost everywhere in the US) and you instantly have huge incentive for someone to write some v6 PAT code. Believe me, I'm the last person who wants to see this happen. It's a horrible, moronic, bone-headed situation. Unfortunately, I'm pretty sure it's going to happen because it's been the status quo for so long, and because some marketing dweeb will make the case that the provider is leaving revenue on the table because there will always be some customers who aren't clever enough to use NAT and will buy the upgraded "5 pack" service. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Sat, 15 Jan 2011 18:39:09 -0500 (EST) Brandon Ross <bross@pobox.com> wrote:
On Sun, 16 Jan 2011, Mark Smith wrote:
How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address?
Huh? Who said anything about 100%?
I think you did .. "Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses." It would take only a single
reasonably sized provider that has a monopoly in a particular area (tell me that doesn't happen) or a pair of them that have a duopoly (almost everywhere in the US) and you instantly have huge incentive for someone to write some v6 PAT code.
And that will create a "huge incentive" for people to acquire larger amounts of address space via other mechanisms, such as 6to4, tunnels, changing to another provider etc.
Believe me, I'm the last person who wants to see this happen. It's a horrible, moronic, bone-headed situation. Unfortunately, I'm pretty sure it's going to happen because it's been the status quo for so long, and because some marketing dweeb will make the case that the provider is leaving revenue on the table because there will always be some customers who aren't clever enough to use NAT and will buy the upgraded "5 pack" service.
I'm confident the opposite will happen. People on this list and similar ones usually understand the value of more than one public address for a home, and commonly enough have routed subnets to their homes, courtesy of their employer, and have probably also been burnt by NAT. They'll be the ones who tell their management "this is how IPv6 is deployed". If they're ignored, they should then say, "and this is how our competitors will be deploying IPv6". Even though customers may not completely understand what they're getting, if one provider has a marketing bullet point of "1 IPv6 address", and another has a marketing bullet point of "Millions of IPv6 addresses", people will just assume more is better and go with the latter. There is no point pretending IPv6 addresses are expensive or trying to make them artificially so.
I hope the engineers in the organization will just tell their marketing folk that it's not possible to hand out just one IPv6 address. "Our hardware doesn't support it." I think there's still room for ISPs to charge $10/month for a static prefix, though. And that's technically possible. Frank -----Original Message----- From: Mark Smith [mailto:nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Saturday, January 15, 2011 5:30 PM To: Brandon Ross Cc: NANOG list Subject: Re: Is NAT can provide some kind of protection? On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Ross <bross@pobox.com> wrote:
On Sat, 15 Jan 2011, Brian Keefer wrote:
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6:
You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses.
How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address?
Since many residential users won't stand for an additional fee, pressure will be placed on CPE vendors to include v6 PAT in their devices.
-- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Jan 15, 2011, at 4:21 PM, Frank Bulk wrote:
I hope the engineers in the organization will just tell their marketing folk that it's not possible to hand out just one IPv6 address. "Our hardware doesn't support it."
I think there's still room for ISPs to charge $10/month for a static prefix, though. And that's technically possible.
Unfortunate, but, true. Fortunately, I don't have that problem. I got my addresses elsewhere for less. ($100/year from ARIN is less than $120/year from your ISP.) Owen
Frank
-----Original Message----- From: Mark Smith [mailto:nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Saturday, January 15, 2011 5:30 PM To: Brandon Ross Cc: NANOG list Subject: Re: Is NAT can provide some kind of protection?
On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Ross <bross@pobox.com> wrote:
On Sat, 15 Jan 2011, Brian Keefer wrote:
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6:
You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses.
How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address?
Since many residential users won't stand for an additional fee, pressure will be placed on CPE vendors to include v6 PAT in their devices.
-- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Sat, 15 Jan 2011 18:21:52 -0600 "Frank Bulk" <frnkblk@iname.com> wrote:
I hope the engineers in the organization will just tell their marketing folk that it's not possible to hand out just one IPv6 address. "Our hardware doesn't support it."
I think there's still room for ISPs to charge $10/month for a static prefix, though. And that's technically possible.
I think it is important to define what "static" means. My definition is that no matter where the customer's network attachment point moves to, the customer retains the same addressing while they have a continued commercial relationship with the SP - in effect PI address space within the SPs network. There is a fairly significant cost to preserving that, a guaranteed route table slot. This is typically a business product offering. The only other alternative people seem to think there is is dynamic, where every time the customer reconnects they may get different addressing. This is the typical residential product offering. I think there is a useful middle point of "stable" addressing, where as long as their point of attachment (or point of service delivery - i.e. their home) doesn't change, a customer would continue to get the same addressing. This idea wasn't as useful or as applicable in IPv4, but would be quite beneficial in IPv6 when DHPCv6-PD is being used. It wouldn't be an assured address assignment, however the SP would endeavour to try to ensure the addressing stays stable over quite long periods of time. It's common enough for LNS/BRASes to do this anyway if the customer's connection lands on the same one. The trick is to expand this stability over the group of all LNS/BRASes that customers can attach to when they reconnect, such that is a SP designed behaviour, rather than an implementation behaviour of each individual LNS/BRAS. Regards, Mark.
On Jan 15, 2011, at 8:03 PM, Mark Smith wrote:
On Sat, 15 Jan 2011 18:21:52 -0600 "Frank Bulk" <frnkblk@iname.com> wrote:
I hope the engineers in the organization will just tell their marketing folk that it's not possible to hand out just one IPv6 address. "Our hardware doesn't support it."
I think there's still room for ISPs to charge $10/month for a static prefix, though. And that's technically possible.
I think it is important to define what "static" means. My definition is that no matter where the customer's network attachment point moves to, the customer retains the same addressing while they have a continued commercial relationship with the SP - in effect PI address space within the SPs network. There is a fairly significant cost to preserving that, a guaranteed route table slot. This is typically a business product offering.
Uh, yeah, I think most SPs will only provide that as long as the customer is attached at the same POP or possibly in the same Region, whatever their aggregation zone happens to be. If you're going to have the customer tying up a slot in the routing table, there's not much benefit (from an SP perspective) vs. having them go get an AS and a PI Prefix.
The only other alternative people seem to think there is is dynamic, where every time the customer reconnects they may get different addressing. This is the typical residential product offering.
Well, there's static as long as the customer stays where they are or moves within the same access aggregation facility. That's relatively easy for the provider and solves 99.99% of the residential customer's problems with dynamic.
I think there is a useful middle point of "stable" addressing, where as long as their point of attachment (or point of service delivery - i.e. their home) doesn't change, a customer would continue to get the same addressing. This idea wasn't as useful or as applicable in IPv4,
Frankly, that's what I thought you meant by "static" at first.
but would be quite beneficial in IPv6 when DHPCv6-PD is being used. It wouldn't be an assured address assignment, however the SP would endeavour to try to ensure the addressing stays stable over quite long periods of time. It's common enough for LNS/BRASes to do this anyway if
Hmmm... Now your going away from your definition of "stable" to what I would call "semi-sticky dynamic addressing". It's a darker shade of gray than "stable", but, still reasonably usable.
the customer's connection lands on the same one. The trick is to expand this stability over the group of all LNS/BRASes that customers can attach to when they reconnect, such that is a SP designed behaviour, rather than an implementation behaviour of each individual LNS/BRAS.
You're making a rather large assumption here. Namely that all the world is DSL. Owen
On Jan 15, 2011, at 3:30 PM, Mark Smith wrote:
On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Ross <bross@pobox.com> wrote:
On Sat, 15 Jan 2011, Brian Keefer wrote:
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6:
You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses.
How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address?
I've talked to a lot of them... None of the ones I've talked to have any plans to assign less than a /64 to an end-user. Hopefully the ones that are planning on less than a /48 will come to their senses. Owen
On 01/15/2011 06:30 PM, Mark Smith wrote:
On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Ross<bross@pobox.com> wrote:
On Sat, 15 Jan 2011, Brian Keefer wrote:
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6:
You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses.
How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address?
Can we *please* stop this pointless thread? If not, at least I will inject a fact into this pointless thread with a factoid from Comcast's IPv6 trial, e.g. my address.... I know it is sooo terrible to have the gall to do such a treacherous thing as injecting actual information with counterexample, when such high velocity hand waving is in progress, but such it will be. - Jim jg@jg:~$ /sbin/ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:23:14:4e:3f:50 inet addr:192.168.1.118 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2001:55c:62e5:6320:223:14ff:fe4e:3f50/64 Scope:Global inet6 addr: fe80::223:14ff:fe4e:3f50/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2333470 errors:0 dropped:0 overruns:0 frame:0 TX packets:2117301 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2474359067 (2.4 GB) TX bytes:1296861717 (1.2 GB)
On Sun, 16 Jan 2011 00:12:26 -0500 Jim Gettys <jg@freedesktop.org> wrote:
On 01/15/2011 06:30 PM, Mark Smith wrote:
On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Ross<bross@pobox.com> wrote:
On Sat, 15 Jan 2011, Brian Keefer wrote:
Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6:
You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses.
How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address?
Can we *please* stop this pointless thread?
I don't think it pointless to network operators - NAT or not has operational impacts on troubleshooting, network design, addressing plans etc. I understand you aren't a network operator, so if you're not interested perhaps you should unsubscribe. Thanks, Mark.
On 01/16/2011 03:00 AM, Mark Smith wrote:
Can we *please* stop this pointless thread?
I don't think it pointless to network operators - NAT or not has operational impacts on troubleshooting, network design, addressing plans etc. I understand you aren't a network operator, so if you're not interested perhaps you should unsubscribe.
I'm sorry; it is the piece of the thread about whether network operators are going to hand out only single IP addresses in IPv6 that had got my goat. I should have made that clear. - Jim
On Jan 12, 2011, at 9:07 AM, Jack Bates wrote:
On 1/12/2011 11:01 AM, George Bonser wrote:
NAT66 is just straight static NAT that maps one prefix to a different prefix.
I'd eat a hat if a vendor didn't implement a PAT equivalent. It's demanded too much. There is money for it, so it will be there.
Jack
Fortunately, so far, it isn't. Hopefully we can cure the demand through education instead of acquiescence and profiteering. Owen
On Wednesday, January 12, 2011 12:01:27 pm George Bonser wrote:
With v4 PAT, you can not be sure which address/port on the external IP maps to which address/port on the inside IP at any given moment and PAT is stateful in that an outbound packet is required to start the mapping.
On Cisco at least you can set up static PAT rules and have multiple internal hosts on a single external IP address with static NATting. I've done this in the past, where a webcam application we were using absolutely insisted on binding port 80, and on another host the control application we were using also absolutely insisted on binding port 80, but, for several purposes, we wanted a single external address, so I set up an extendable NAT rule for port 80 on the external IP address to map to the webcam box's port 80, and port 8080 on the external IP address to map to the control application's port 80. Worked fine. But that wasn't for security, unless you consider that hiding the unused ports on those two machines is security. Since then we've found that a lot of firewalls blocked the connection to port 8080, and we had to have the developer restructure the app to handle being on two IP addresses, which was nontrivial thanks to cross-site-scripting blockers. Even my old Linksys WRT54G has 'port forwarding' rules that do static PAT.
NAT66 is just straight static NAT that maps one prefix to a different prefix.
I'm sure that PAT is on the horizon, simply for plumbing purposes to connect the gozinta to the gozouta where wierd application requirements are found (having two applications and javascripts on a single page that access two different backend servers gets blocked by some cross-site scripting 'protections' and thus having the second connection muxed onto the same address can alleviate this). Also, round-robin stateful PAT can be thought of as poor-man's load balancing, and has been used in that use case. And there is the straight NAT non-BGP multihoming use case. But that's also not for security, but for availability. If you wanted IPv6 PAT *now* you could contribute to the MAP66 project and write your own PAT66 (map66.sourceforge.net). But it will be provided by someone; since when have technical issues alone ever kept a feature from being implemented?
On Jan 12, 2011, at 8:54 AM, Fernando Gont wrote:
On 12/01/2011 01:17 p.m., George Bonser wrote:
But your security person needs to shift their thinking because the purpose of NAT and private addressing is to conserve IP address, not to provide security. With IPv6, the concept of NAT goes away.
You have heard about NAT66, right?
Yes... Hopefully it was just a bad dream. NATing IPv6 doesn't do anything good. There's no benefit, only cost. Owen
On 1/12/11 1:03 PM, "Owen DeLong" <owen@delong.com> wrote:
NATing IPv6 doesn't do anything good. There's no benefit, only cost.
Except for making sure you can switch providers without renumbering, which can be a significant benefit. (Yes, PI space accomplishes the same thing, but that's harder to get for most SMBs.) -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Tell your security guy he should be looking for another job. On 21/03/2007, at 8:41 PM, Tarig Ahmed <tariq198487@hotmail.com> wrote:
We have wide range of Public IP addresses, I tried to assign public ip directly to a server behined firewall( in DMZ), but I have been resisted. Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons.
Is it true that NAT can provide more security?
Thanks,
Tarig Yassin Ahmed
On Wed, Mar 21, 2007 at 5:41 AM, Tarig Ahmed <tariq198487@hotmail.com> wrote:
We have wide range of Public IP addresses, I tried to assign public ip directly to a server behined firewall( in DMZ), but I have been resisted. Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons.
Is it true that NAT can provide more security?
Hi Tarig, Yes NAT can provide more security, but not in the particular scenario you described. In your scenario, the firewall knows how to map incoming connections for the public address to your server's private address, so you won't see any benefit from NAT versus a merely stateful firewall -- a connection request will either get through the filter or it won't. If it gets through, the firewall knows where to send it. On the other hand, the use of any kind of stateful firewall (most of what we refer to as NAT firewalls keep per-connection state) increases your vulnerability to denial of services attacks: folks DOSing you can target both the server and the firewall's state table. So the use of NAT there is potentially counterproductive. In a client (rather than server) scenario, the picture is different. Depending on the specific "NAT" technology in use, the firewall may be incapable of selecting a target for unsolicited communications inbound from the public Internet. In fact, it may be theoretically impossible for it to do so. In those scenarios, the presence of NAT in the equation makes a large class of direct attacks on the interior host impractical, requiring the attacker to fall back on other methods like attempting to breach the firewall itself or indirectly polluting the responses to communication initiated by the internal host. In both cases there's a larger question: security value. The value of a security measure is the damage it prevents (risk times impact) minus the damage it causes (system usability, capability). NAT generally causes more damage than packet filters and other lighter-duty security measures. Look for an appropriate improvement in system security to counterbalance that damage. If you don't find it then don't use NAT. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said:
In a client (rather than server) scenario, the picture is different. Depending on the specific "NAT" technology in use, the firewall may be incapable of selecting a target for unsolicited communications inbound from the public Internet. In fact, it may be theoretically impossible for it to do so. In those scenarios, the presence of NAT in the equation makes a large class of direct attacks on the interior host impractical, requiring the attacker to fall back on other methods like attempting to breach the firewall itself or indirectly polluting the responses to communication initiated by the internal host.
Note that the presence of a firewall with a 'default deny' rule for inbound packets provides the same level of impracticality. And given the fact that Windows has had a reasonably sane host-based firewall since XP SP2, and the truly huge number of compromised PC's that sit behind a NAT on a DSL or cablemodem, it's pretty obvious that the presence of NAT is doing approximately *zero* to actually slow down the miscreants. 140 million compromised PC's, most of them behind a NAT, can't be wrong. :)
On 1/12/2011 11:16 AM, Valdis.Kletnieks@vt.edu wrote:
140 million compromised PC's, most of them behind a NAT, can't be wrong. :)
And yet blaster type worms are less common now, and I still get the occasional reinfection reported where a computer shop installs XP pre-patch with a public IP. A simple stateful firewall or NAT router would stop that and allow them to finish patching the OS. There is always a new attack vector. Jack
And yet blaster type worms are less common now, and I still get the occasional reinfection reported where a computer shop installs XP pre-patch with a public IP. A simple stateful firewall or NAT router would stop that and allow them to finish patching the OS. There is always a new attack vector.
Jack
I'd argue that the above has everything to do with firewalling, and nothing to do with NAT. Slightly OT: It boggles the mind a bit when I find desktop shops -not- using imaging. I would think most people would prefer not to stare at OS install screens - and when you can blast out a fully patched XP image easily in sub-10 minutes, the ROI is staggering. Nathan
On 1/12/2011 11:52 AM, Nathan Eisenberg wrote:
I'd argue that the above has everything to do with firewalling, and nothing to do with NAT.
I agree, but both effectively handle the job. My point is that just because we have lots of infections behind NAT, doesn't mean that NAT (or a firewall) doesn't still serve a purpose.
Slightly OT: It boggles the mind a bit when I find desktop shops -not- using imaging. I would think most people would prefer not to stare at OS install screens - and when you can blast out a fully patched XP image easily in sub-10 minutes, the ROI is staggering.
Hardware drivers? Jack
On Wed, Jan 12, 2011 at 12:16 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said:
In a client (rather than server) scenario, the picture is different. Depending on the specific "NAT" technology in use, the firewall may be incapable of selecting a target for unsolicited communications inbound from the public Internet. In fact, it may be theoretically impossible for it to do so. In those scenarios, the presence of NAT in the equation makes a large class of direct attacks on the interior host impractical, requiring the attacker to fall back on other methods like attempting to breach the firewall itself or indirectly polluting the responses to communication initiated by the internal host.
Note that the presence of a firewall with a 'default deny' rule for inbound packets provides the same level of impracticality.
Hi Valdis, There's actually a large difference between something that's impossible for a technology to do (even in theory), something that the technology has been programmed not to do and something that a technology is by default configured not to do. The hacker can't make the equipment do something impossible. He can only go around it, try a different attack vector. To push through something the technology has been programmed not to do, he needs to identify a suitable bug: hard but not quite impractical. As for default configurations... human error is a *major* part of the security equation. Identifying and exploiting configuration errors is a hacker's fertile hunting ground. On Wed, Jan 12, 2011 at 2:35 PM, Owen DeLong <owen@delong.com> wrote:
On Jan 12, 2011, at 9:36 AM, Jack Bates wrote:
As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function. Given that the internal is exclusively PAT, the DMZ is public with stateful/proxy, this provides protection for the internal network while limiting the dmz exposure.
The corp IT guy is delusional. The solution to the routing disconnect is map+encap or tunnels.
Logical fallacy, ad hominem: the sanity of Jack's IT guy is not at issue. Logical fallacy, straw man: that a security technology failed to close attack vectors it was not claimed to have closed makes no statement as to whether the tech blocked the attack vectors it did claim to block. The only technology which stops all possible network attack vectors is the off switch. Logical fallacy, circular reasoning: to bring your magic tunnels into existence, the firewall must have already been breached. Yet you claim the tunnels allow you to breach the firewall, allegedly proving that the PAT routing disconnect is a no-op. It took you only 17 words to get the trifecta. Congratulations, or something. On Wed, Jan 12, 2011 at 2:09 PM, Owen DeLong <owen@delong.com> wrote:
No, NAT doesn't provide additional security. The stateful inspection that NAT cannot operate without provides the security. Take away the address mangling and the stateful inspection still provides the same level of security.
When you'd care to offer a refutation of my explanation (above) of exactly how NAT impacts the security process beyond what the stateful inspection does, a refutation that doesn't involve a bunch of bald assertions, hand-waving and logical fallacies, you let me know. Perhaps the "security expert" you tell me you relied on when formulating your viewpoint could help you out with that? On Wed, Jan 12, 2011 at 2:21 PM, Paul Ferguson <fergdawgster@gmail.com> wrote:
There is a least one situation where NAT *does* provide a small amount of necessary security.
Try this at home, with/without NAT:
1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed
Without NAT, you're unpatched PC will get infected in less than 1 minute.
Hi Paul, That doesn't really prove your point. Owen is correct that any reasonably configured firewall of any type would tend to prevent such infections. The different firewall types don't begin to exhibit a major difference in security effectiveness until you factor in the impact of human error in specific scenarios. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Jan 12, 2011, at 6:13 PM, William Herrin wrote:
On Wed, Jan 12, 2011 at 12:16 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said:
In a client (rather than server) scenario, the picture is different. Depending on the specific "NAT" technology in use, the firewall may be incapable of selecting a target for unsolicited communications inbound from the public Internet. In fact, it may be theoretically impossible for it to do so. In those scenarios, the presence of NAT in the equation makes a large class of direct attacks on the interior host impractical, requiring the attacker to fall back on other methods like attempting to breach the firewall itself or indirectly polluting the responses to communication initiated by the internal host.
Note that the presence of a firewall with a 'default deny' rule for inbound packets provides the same level of impracticality.
Hi Valdis,
There's actually a large difference between something that's impossible for a technology to do (even in theory), something that the technology has been programmed not to do and something that a technology is by default configured not to do.
The hacker can't make the equipment do something impossible. He can only go around it, try a different attack vector. To push through something the technology has been programmed not to do, he needs to identify a suitable bug: hard but not quite impractical. As for default configurations... human error is a *major* part of the security equation. Identifying and exploiting configuration errors is a hacker's fertile hunting ground.
NAT boxes without the ability to do port forwarding are few and far between. Human error can poke a hole in a NAT as easily as in a stateful firewall with a default deny.
On Wed, Jan 12, 2011 at 2:35 PM, Owen DeLong <owen@delong.com> wrote:
On Jan 12, 2011, at 9:36 AM, Jack Bates wrote:
As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function. Given that the internal is exclusively PAT, the DMZ is public with stateful/proxy, this provides protection for the internal network while limiting the dmz exposure.
The corp IT guy is delusional. The solution to the routing disconnect is map+encap or tunnels.
Logical fallacy, ad hominem: the sanity of Jack's IT guy is not at issue.
The logical fallacy is believing that NAT provides any protection.
Logical fallacy, straw man: that a security technology failed to close attack vectors it was not claimed to have closed makes no statement as to whether the tech blocked the attack vectors it did claim to block. The only technology which stops all possible network attack vectors is the off switch.
It claimed to provide routing isolation. That alleged isolation is easily circumvented or even configured out of relevance by human error or deliberately.
Logical fallacy, circular reasoning: to bring your magic tunnels into existence, the firewall must have already been breached. Yet you claim the tunnels allow you to breach the firewall, allegedly proving that the PAT routing disconnect is a no-op.
No, the firewall is presumably configured to intentionally allow access by end users to web sites. Once you allow that, point-click-pwnm3 takes over.
It took you only 17 words to get the trifecta. Congratulations, or something.
Seriously, Bill... Just because you keep repeating the same sophistry doesn't make it any more believable.
On Wed, Jan 12, 2011 at 2:09 PM, Owen DeLong <owen@delong.com> wrote:
No, NAT doesn't provide additional security. The stateful inspection that NAT cannot operate without provides the security. Take away the address mangling and the stateful inspection still provides the same level of security.
When you'd care to offer a refutation of my explanation (above) of exactly how NAT impacts the security process beyond what the stateful inspection does, a refutation that doesn't involve a bunch of bald assertions, hand-waving and logical fallacies, you let me know. Perhaps the "security expert" you tell me you relied on when formulating your viewpoint could help you out with that?
Logical fallacy -- Circular argument. Since you call any refutation I offer "bald assertions" or "hand waving" when in reality they are behaviors I have observed in the real world, I doubt we'll ever come to agreement on this point. Also, saying things like `the "security expert" you tell me you relied on' come across as condescending. I have told you that I have discussed the matter with multiple security experts on multiple occasions. The fact that most of them have not given me permission to disclose their contact details to you does not render them any less correct. Finally, I've never told you that I relied on them in forming my viewpoint, only that I have discussed the matter at length and that they share my viewpoint. Owen
On Wed, Jan 12, 2011 at 2:21 PM, Paul Ferguson <fergdawgster@gmail.com> wrote:
There is a least one situation where NAT *does* provide a small amount of necessary security.
Try this at home, with/without NAT:
1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed
Without NAT, you're unpatched PC will get infected in less than 1 minute.
Hi Paul,
That doesn't really prove your point. Owen is correct that any reasonably configured firewall of any type would tend to prevent such infections. The different firewall types don't begin to exhibit a major difference in security effectiveness until you factor in the impact of human error in specific scenarios.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
I hesitate to venture into this thread, but while Owen is correct in the general case ("NAT qua NAT provides no more security than a stateful firewall"), there is a corner case in which security is improved via NAT. The case is that of an enterprise network which uses 1918 addressing for all internal hosts, and uses proxies or other bastions as middleboxes to relay outbound communication. The security provided is that in the event of an accidental bridging of "inside" and "outside" networks (i.e. engineer plugged a cable between the wrong two switches), the hosts will not be able to initiate communication with Internet hosts. Additionally, this same resiliency to accidental bridging does mean that the enterprise has a smaller number of possible Internet-facing machines, and thus can spend the time and effort to make them more robust. That benefit is not huge (and not relevant to the typical home user, who is not configuring a super-duper scanning proxy server), but it does exist, and it certainly fuels some of the pro-NAT feeling I've encountered among customers. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
On Jan 12, 2011, at 7:23 PM, David Barak wrote:
I hesitate to venture into this thread, but while Owen is correct in the general case ("NAT qua NAT provides no more security than a stateful firewall"), there is a corner case in which security is improved via NAT. The case is that of an enterprise network which uses 1918 addressing for all internal hosts, and uses proxies or other bastions as middleboxes to relay outbound communication.
The security provided is that in the event of an accidental bridging of "inside" and "outside" networks (i.e. engineer plugged a cable between the wrong two switches), the hosts will not be able to initiate communication with Internet hosts. Additionally, this same resiliency to accidental bridging does mean that the enterprise has a smaller number of possible Internet-facing machines, and thus can spend the time and effort to make them more robust.
That benefit is not huge (and not relevant to the typical home user, who is not configuring a super-duper scanning proxy server), but it does exist, and it certainly fuels some of the pro-NAT feeling I've encountered among customers. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
If you are proxying everything, then, there isn't any actual NAT. There are inside sessions and outside sessions. In that case, your security comes from the disconnected addresses and the proxy that sits in the middle interfacing every outside session with its related inside session. No packet is forwarded from inside to outside with only the address and port fields mangled. Each session is a separate and distinct interior and exterior session. There is a state machine between the internal client and the proxy server and a separate state machine between the external server and the proxy client. Separate sets of sequence numbers, etc. I am not denying that you may be able to get some additional isolation by having network numbers that aren't routable on the outside world if you don't have NAT. I'm saying that if you have NAT, it doesn't add to your security. Owen
On 1/12/2011 9:33 PM, Owen DeLong wrote:
If you are proxying everything, then, there isn't any actual NAT. There are inside sessions and outside sessions.
Depends on the proxy mechanism used. In a transparent firewall proxy layout, it generally is still considered NAT. The proxy capabilities of the firewall are additional security measures on top of the NAT (and definitely should be deployed for their higher security value). Jack
On Jan 13, 2011, at 9:59 AM, Jack Bates wrote:
The proxy capabilities of the firewall are additional security measures on top of the NAT (and definitely should be deployed for their higher security value).
Not in front of servers, they shouldn't - because they have a negative security value in that context. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
On 1/13/2011 10:54 AM, Dobbins, Roland wrote:
Not in front of servers, they shouldn't - because they have a negative security value in that context.
I agree. Any content checks and reporting should be handled by the server and not a firewall proxy which might have it's own security vulnerabilities (just as likely as the server app having them). That being said, a proxy setup is definitely not unheard of for web servers, though generally not for security purposes as much as content distribution purposes. Jack
On Thu, Jan 13, 2011 at 11:54 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 13, 2011, at 9:59 AM, Jack Bates wrote:
The proxy capabilities of the firewall are additional security measures on top of the NAT (and definitely should be deployed for their higher security value).
Not in front of servers, they shouldn't - because they have a negative security value in that context.
So all the folks who use reverse proxies like an http accellerator are wrong? -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 1/13/2011 11:56 AM, William Herrin wrote:
So all the folks who use reverse proxies like an http accellerator are wrong?
They have their purpose. However, depending on the security rating of the accelerator versus the security rating of the backend server will depend on the negative or positive effect it has on overall security. 1) If backend server has low security rating and proxy also serves to protect backend server flaws, then the proxy has a positive security rating. 2) If backend server is similar or better security rating than the proxy, then the proxy server has a negative security rating, as it has introduced a second application in the channel which can possibly be exploited. ie, you have to worry about backend server security as well as the proxy security, and exploiting either can possibly compromise security for both. Jack
On Thu, Jan 13, 2011 at 1:11 PM, Jack Bates <jbates@brightok.net> wrote:
On 1/13/2011 11:56 AM, William Herrin wrote:
So all the folks who use reverse proxies like an http accellerator are wrong?
They have their purpose. However, depending on the security rating of the accelerator versus the security rating of the backend server will depend on the negative or positive effect it has on overall security.
1) If backend server has low security rating and proxy also serves to protect backend server flaws, then the proxy has a positive security rating.
2) If backend server is similar or better security rating than the proxy, then the proxy server has a negative security rating, as it has introduced a second application in the channel which can possibly be exploited. ie, you have to worry about backend server security as well as the proxy security, and exploiting either can possibly compromise security for both.
That's what I think. I'm curious what Roland thinks. -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In message <AANLkTikiXF_mbuo-osKPjSW98vn5_d5WZNUi_PL37sNG@mail.gmail.com>, William Herrin writes:
On Wed, Jan 12, 2011 at 12:16 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said:
In a client (rather than server) scenario, the picture is different. Depending on the specific "NAT" technology in use, the firewall may be incapable of selecting a target for unsolicited communications inbound from the public Internet. In fact, it may be theoretically impossible for it to do so. In those scenarios, the presence of NAT in the equation makes a large class of direct attacks on the interior host impractical, requiring the attacker to fall back on other methods like attempting to breach the firewall itself or indirectly polluting the responses to communication initiated by the internal host.
Note that the presence of a firewall with a 'default deny' rule for inbou= nd packets provides the same level of impracticality.
Hi Valdis,
There's actually a large difference between something that's impossible for a technology to do (even in theory), something that the technology has been programmed not to do and something that a technology is by default configured not to do.
Well ask the firewall vendor not to give you the knob to open it up completely. Note the CPE NAT boxes I've seen all have the ability to send anything that isn't being NAT'd to a internal box so it isn't like NAT boxes don't already have the flaw you are complaining about. Usually it's labeled as DMZ host or something similar. They also have the ability to send traffic for individual port to particular boxes on the inside without it being initiated from the inside. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Jan 12, 2011 at 10:02 PM, Mark Andrews <marka@isc.org> wrote:
In message <AANLkTikiXF_mbuo-osKPjSW98vn5_d5WZNUi_PL37sNG@mail.gmail.com>, William Herrin writes:
There's actually a large difference between something that's impossible for a technology to do (even in theory), something that the technology has been programmed not to do and something that a technology is by default configured not to do.
Well ask the firewall vendor not to give you the knob to open it up completely.
Hi Mark, Why would I do that? I still have toes left; I *want* to be able to shoot myself in the foot. Still, you do follow the practical difference between can't, programmed not to and configured not to, right? Can't is 0% chance of a breach on that vector. The others are varying small percentages with "configured" the highest of the bunch.
Note the CPE NAT boxes I've seen all have the ability to send anything that isn't being NAT'd to a internal box so it isn't like NAT boxes don't already have the flaw you are complaining about. Usually it's labeled as DMZ host or something similar.
Fair enough. Implementations that can't target -something- for unsolicited inbound packets have gotten rare. The core point remains: a hacker trying to push packets at an arbitrary host behind a NAT firewall has to not only find flaws in the filtering rules, he also has to convince the firewall to send the packet to the "right" host. This is more difficult. The fact that the firewall doesn't automatically send the packet to the right host once the filtering flaw is discovered adds an extra layer of security. Practically speaking, the hacker will have better luck trying to corrupt data actually solicited by interior hosts that the difficulty getting the box to send unsolicited packets to the host the hacker wants to attack puts and end to the whole attack vector. On Thu, Jan 13, 2011 at 4:21 PM, Lamar Owen <lowen@pari.edu> wrote:
On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote:
That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny.
This is demonstrably not correct.
Hi Lamar, I have to side with Owen on this one. When a packet arrives at the external interface of a NAT device, it's looked up in the NAT state table. If no matching state is found, the packet is discarded. However it came about, that describes a firewall and it is stateful. Even if you route the packets somewhere instead of discarding them, you've removed them from the data streams associated with the individual interior hosts that present on the same exterior address. Hence, a firewall. There's no such thing as a pure router any more. As blurry as the line has gotten it can be attractive to think of selectively acting on packets with the same IP address pairs as a routing function, but it's really not... and where the function is to divert undesired packets from the hosts that don't want them (or the inverse -- divert desired packets to the hosts that do want them), that's a firewall. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Jan 13, 2011, at 5:48 PM, William Herrin wrote:
On Wed, Jan 12, 2011 at 10:02 PM, Mark Andrews <marka@isc.org> wrote:
In message <AANLkTikiXF_mbuo-osKPjSW98vn5_d5WZNUi_PL37sNG@mail.gmail.com>, William Herrin writes:
There's actually a large difference between something that's impossible for a technology to do (even in theory), something that the technology has been programmed not to do and something that a technology is by default configured not to do.
Well ask the firewall vendor not to give you the knob to open it up completely.
Hi Mark,
Why would I do that? I still have toes left; I *want* to be able to shoot myself in the foot.
Still, you do follow the practical difference between can't, programmed not to and configured not to, right? Can't is 0% chance of a breach on that vector. The others are varying small percentages with "configured" the highest of the bunch.
Can't doesn't apply to any device which forwards packets. Programmed not to is the best you can do on a piece of hardware which is capable of forwarding packets, so, I'm not sure how you think can't applies to this discussion. If the manufacturer takes away the knob, at best you have programmed not to (hopefully). If you keep the knob, then, all you have is default configuration or manual configuration.
Note the CPE NAT boxes I've seen all have the ability to send anything that isn't being NAT'd to a internal box so it isn't like NAT boxes don't already have the flaw you are complaining about. Usually it's labeled as DMZ host or something similar.
Fair enough. Implementations that can't target -something- for unsolicited inbound packets have gotten rare.
The core point remains: a hacker trying to push packets at an arbitrary host behind a NAT firewall has to not only find flaws in the filtering rules, he also has to convince the firewall to send the packet to the "right" host. This is more difficult. The fact that the firewall doesn't automatically send the packet to the right host once the filtering flaw is discovered adds an extra layer of security. Practically speaking, the hacker will have better luck trying to corrupt data actually solicited by interior hosts that the difficulty getting the box to send unsolicited packets to the host the hacker wants to attack puts and end to the whole attack vector.
No, the flaws in the filtering rules have to send the packet to the right host just like a (mis)configured stateful firewall.
On Thu, Jan 13, 2011 at 4:21 PM, Lamar Owen <lowen@pari.edu> wrote:
On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote:
That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny.
This is demonstrably not correct.
Hi Lamar,
I have to side with Owen on this one. When a packet arrives at the external interface of a NAT device, it's looked up in the NAT state table. If no matching state is found, the packet is discarded. However it came about, that describes a firewall and it is stateful.
Lamar pointed out that there are implementations where, apparently, things which don't match the state table are passed to routing without modification. I would call this a bug in the implementation, or at the very least, a very poor choice of default behavior. However, since such situations exist, what this boils down to is a NAT with a stateful firewall with a default permit any instead of a default deny. While that doesn't make a good firewall, I'd still call it a firewall and I'd still call it stateful inspection.
Even if you route the packets somewhere instead of discarding them, you've removed them from the data streams associated with the individual interior hosts that present on the same exterior address. Hence, a firewall.
Unless that somewhere happens to be the individual interior hosts in question. (I've seen hosts with both inside and outside addresses configured on their interface. Yes, this is dumb. However, it's the kind of misconception-based mistake that tends to get made by the same kind of people who would bungle firewall rulesets in the ways you are claiming NAT protects you).
There's no such thing as a pure router any more. As blurry as the line has gotten it can be attractive to think of selectively acting on packets with the same IP address pairs as a routing function, but it's really not... and where the function is to divert undesired packets from the hosts that don't want them (or the inverse -- divert desired packets to the hosts that do want them), that's a firewall.
There are at least lots of devices that can be configured to act as pure routers. Perhaps what we need is to agree on a standard set of definitions... I would propose: NAT -- The process of modifying the contents of either the source or destination address and possibly port numbers of an IP datagram prior to forwarding. May be stateful or stateless. Stateful NAT may include address overloading sometimes referred to as PAT or PNAT. Routing -- The process of forwarding packets between different layer 3 network segments. Bridging -- The process of forwarding packets between different layer 2 segments within the same layer 3 segment. Firewall -- A device which mimics the behavior of a router or a router or bridge, but, which forwards traffic only selectively based on a default or configured policy. Stateful Firewall -- A firewall which maintains a state table of active sessions and makes some of its forwarding decisions based on whether packets match the state table. Owen
On 1/13/11 5:48 PM, William Herrin wrote:
On Wed, Jan 12, 2011 at 10:02 PM, Mark Andrews<marka@isc.org> wrote:
In message<AANLkTikiXF_mbuo-osKPjSW98vn5_d5WZNUi_PL37sNG@mail.gmail.com>, William Herrin writes:
There's actually a large difference between something that's impossible for a technology to do (even in theory), something that the technology has been programmed not to do and something that a technology is by default configured not to do. Well ask the firewall vendor not to give you the knob to open it up completely. Hi Mark,
Why would I do that? I still have toes left; I *want* to be able to shoot myself in the foot.
Still, you do follow the practical difference between can't, programmed not to and configured not to, right? Can't is 0% chance of a breach on that vector. The others are varying small percentages with "configured" the highest of the bunch.
Note the CPE NAT boxes I've seen all have the ability to send anything that isn't being NAT'd to a internal box so it isn't like NAT boxes don't already have the flaw you are complaining about. Usually it's labeled as DMZ host or something similar. Fair enough. Implementations that can't target -something- for unsolicited inbound packets have gotten rare.
The core point remains: a hacker trying to push packets at an arbitrary host behind a NAT firewall has to not only find flaws in the filtering rules, he also has to convince the firewall to send the packet to the "right" host. This is more difficult. The fact that the firewall doesn't automatically send the packet to the right host once the filtering flaw is discovered adds an extra layer of security. Practically speaking, the hacker will have better luck trying to corrupt data actually solicited by interior hosts that the difficulty getting the box to send unsolicited packets to the host the hacker wants to attack puts and end to the whole attack vector.
On Thu, Jan 13, 2011 at 4:21 PM, Lamar Owen<lowen@pari.edu> wrote:
On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote:
That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny. This is demonstrably not correct. Hi Lamar,
I have to side with Owen on this one. When a packet arrives at the external interface of a NAT device, it's looked up in the NAT state table. If no matching state is found, the packet is discarded. However it came about, that describes a firewall and it is stateful.
Even if you route the packets somewhere instead of discarding them, you've removed them from the data streams associated with the individual interior hosts that present on the same exterior address. Hence, a firewall.
There's no such thing as a pure router any more. As blurry as the line has gotten it can be attractive to think of selectively acting on packets with the same IP address pairs as a routing function, but it's really not... and where the function is to divert undesired packets from the hosts that don't want them (or the inverse -- divert desired packets to the hosts that do want them), that's a firewall. Hi Bill,
Unfortunately, a large number of web sites have been compromised, where an unseen iFrame might be included in what is normally safe content. A device accessing the Internet through a NATs often creates opportunities for unknown sources to reach the device as well. Once an attacker invokes a response, exposures persist, where more can be discovered. There are also exposures related to malicious scripts enabled by a general desire to show users dancing fruit. Microsoft now offers a toolkit that allows users a means to 'decide' what should be allowed to see fruit dance. Users that assume local networks are safe are often disappointed when someone on their network wants an application do something that proves unsafe. Methods to penetrate firewalls are often designed into 'fun' applications or poorly considered OS features. -Doug
On 1/13/2011 10:50 PM, Douglas Otis wrote:
Unfortunately, a large number of web sites have been compromised, where an unseen iFrame might be included in what is normally safe content. A device accessing the Internet through a NATs often creates opportunities for unknown sources to reach the device as well. Once an attacker invokes a response, exposures persist, where more can be discovered. There are also exposures related to malicious scripts enabled by a general desire to show users dancing fruit. Microsoft now offers a toolkit that allows users a means to 'decide' what should be allowed to see fruit dance. Users that assume local networks are safe are often disappointed when someone on their network wants an application do something that proves unsafe. Methods to penetrate firewalls are often designed into 'fun' applications or poorly considered OS features.
I have to agree with this, but I believe it is outside the scope of what NAT or stateful firewalls provide. Neither is designed to mitigate this attack. Application level filtering within such firewalls often are designed to protect users in this case. Application level filtering, however, does not protect from the cell phone hidden in a box which was sent to the wrong party and awaiting to be shipped back. There is not, and will probably never be, a single solution and approach to security. Jack
On Thu, Jan 13, 2011 at 11:50 PM, Douglas Otis <dotis@mail-abuse.org> wrote:
Unfortunately, a large number of web sites have been compromised, where an unseen iFrame might be included in what is normally safe content. A device accessing the Internet through a NATs often creates opportunities for unknown sources to reach the device as well. Once an attacker invokes a response, exposures persist, where more can be discovered. There are also exposures related to malicious scripts enabled by a general desire to show users dancing fruit. Microsoft now offers a toolkit that allows users a means to 'decide' what should be allowed to see fruit dance. Users that assume local networks are safe are often disappointed when someone on their network wants an application do something that proves unsafe. Methods to penetrate firewalls are often designed into 'fun' applications or poorly considered OS features.
Doug, Passive attacks. Very effective. Breeze past the firewall like it wasn't there. Hard to target though; work best when you're fishing for whatever you can get instead of trying to crack a particular system. Some success combining them with social engineering. Not terribly relevant to the discussion in this thread. Firewalls mostly block active attacks where a hacker is pushing unsolicited data at a host instead of waiting for the host to request data. Whether or not NAT is involved doesn't really change that larger picture of the general class of attacks firewalls obstruct. -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Jan 14, 2011, at 6:24 AM, William Herrin wrote:
On Thu, Jan 13, 2011 at 11:50 PM, Douglas Otis <dotis@mail-abuse.org> wrote:
Unfortunately, a large number of web sites have been compromised, where an unseen iFrame might be included in what is normally safe content. A device accessing the Internet through a NATs often creates opportunities for unknown sources to reach the device as well. Once an attacker invokes a response, exposures persist, where more can be discovered. There are also exposures related to malicious scripts enabled by a general desire to show users dancing fruit. Microsoft now offers a toolkit that allows users a means to 'decide' what should be allowed to see fruit dance. Users that assume local networks are safe are often disappointed when someone on their network wants an application do something that proves unsafe. Methods to penetrate firewalls are often designed into 'fun' applications or poorly considered OS features.
Doug,
Passive attacks. Very effective. Breeze past the firewall like it wasn't there. Hard to target though; work best when you're fishing for whatever you can get instead of trying to crack a particular system. Some success combining them with social engineering.
Grabbing whatever you can get near the thing you're trying to crack is often a good first step. Afterall, once you pwn a system inside the firewall in the same security zone as your target, it becomes a lot easier to attack your target.
Not terribly relevant to the discussion in this thread. Firewalls mostly block active attacks where a hacker is pushing unsolicited data at a host instead of waiting for the host to request data. Whether or not NAT is involved doesn't really change that larger picture of the general class of attacks firewalls obstruct.
Ah, but, the point here is that NAT actually serves as an enabling technology for part of the attack he is describing. Another example where NAT can and is a security negative. The fact that you refuse to acknowledge these is exactly what you were accusing me of doing in my previous emails. Owen
On 1/14/2011 1:43 PM, Owen DeLong wrote:
Ah, but, the point here is that NAT actually serves as an enabling technology for part of the attack he is describing. Another example where NAT can and is a security negative. The fact that you refuse to acknowledge these is exactly what you were accusing me of doing in my previous emails.
Explain how it acts as an enabler. Jack
On 1/14/11 11:49 AM, Jack Bates wrote:
On 1/14/2011 1:43 PM, Owen DeLong wrote:
Ah, but, the point here is that NAT actually serves as an enabling technology for part of the attack he is describing. Another example where NAT can and is a security negative. The fact that you refuse to acknowledge these is exactly what you were accusing me of doing in my previous emails.
Explain how it acts as an enabler. Consider the impact the typical NAT or "firewall" has on DNS.
-Doug
On Fri, Jan 14, 2011 at 2:43 PM, Owen DeLong <owen@delong.com> wrote:
Ah, but, the point here is that NAT actually serves as an enabling technology for part of the attack he is describing.
Hi Owen, Doug's comments on that were pretty abstract, so let me try to ground it a little bit. He basically observed that if I originate a UDP packet from behind a NAT, there's a window of opportunity in which that port is somewhat open through the NAT firewall and could return packets originated by a hacker. I watch the movies too and I hang in suspense as the protagonist waits for the bad guy to make a network connection and then activates the phlebotinum that backhacks his tubes. And I know there are some real-life examples where giving a hacker a large file to download has kept him connected to a modem long enough to get a phone trace. But I haven't read of a _nonfiction_ example where the dynamic opening in a stateful firewall (NAT or otherwise) has directly provided the needed opening for an _active_ attack by a third party. Can you cite one? Even if such an attack is practical, I fail to see how a NAT firewall is any more vulnerable to it than a merely stateful firewall. Perhaps you can explain? As for strictly passive attacks, like the so-called drive by download, it is not obvious to me that they would operate differently in a NAT versus non-NAT stateful firewall environment. Please elucidate. On Fri, Jan 14, 2011 at 5:52 PM, Douglas Otis <dotis@mail-abuse.org> wrote:
On 1/14/11 11:49 AM, Jack Bates wrote:
Explain how [NAT] acts as an enabler. Consider the impact the typical NAT or "firewall" has on DNS.
Hi Doug, You'd make the argument that NAT aggravates Kaminsky? If you have something else in mind, I'll have to ask you to spell it out for me. Interesting argument. Tough sell. The more hosts behind a NAT, the more likely they're relying on an interior resolver anyway which aggregates the query source regardless of the presence or absence of NAT. Worst case I can think of is you have a badly implemented NAT which negates the source port randomization. But you have a tougher sell if you want to convince me that NAT firewalls have a higher probability of being badly implemented. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
From: William Herrin Sent: Friday, January 14, 2011 4:11 PM To: nanog@nanog.org Subject: Re: Is NAT can provide some kind of protection?
On Fri, Jan 14, 2011 at 2:43 PM, Owen DeLong <owen@delong.com> wrote:
Ah, but, the point here is that NAT actually serves as an enabling technology for part of the attack he is describing.
I watch the movies too and I hang in suspense as the protagonist waits for the bad guy to make a network connection and then activates the phlebotinum that backhacks his tubes. And I know there are some real-life examples where giving a hacker a large file to download has kept him connected to a modem long enough to get a phone trace. But I haven't read of a _nonfiction_ example where the dynamic opening in a stateful firewall (NAT or otherwise) has directly provided the needed opening for an _active_ attack by a third party. Can you cite one?
The extent to which NAT is a security hazard in my experience is that it simply makes it harder to find a compromised machine. Someone might inform us that they are seeing suspicious traffic that matches a virus profile from an IP address but the NAT makes it difficult to determine the actual source of the traffic. In that case NAT isn't, in and of itself, the enabling mechanism, but it does offer the compromised host some additional time to do its malicious work while it is being tracked down and eliminated. It also adds more work for providers when someone wants to know who was responsible for certain traffic at certain times. This is particularly true of NAT devices that get their "outside" IP by DHCP. Now they have to search their records and sort out who had that IP at that time and then associate that with a specific customer. Then at the customer location, there might be several more devices (or a neighbor connected over an unsecured wireless) and at that point there is no telling where the traffic came from. So NAT itself isn't a security threat, but it sure gives a real security threat a lot of woodwork in which to hide. G
On 01/15/2011 02:01 AM, George Bonser wrote:
From: William Herrin Sent: Friday, January 14, 2011 4:11 PM To: nanog@nanog.org Subject: Re: Is NAT can provide some kind of protection?
On Fri, Jan 14, 2011 at 2:43 PM, Owen DeLong <owen@delong.com> wrote:
Ah, but, the point here is that NAT actually serves as an enabling technology for part of the attack he is describing.
I watch the movies too and I hang in suspense as the protagonist waits for the bad guy to make a network connection and then activates the phlebotinum that backhacks his tubes. And I know there are some real-life examples where giving a hacker a large file to download has kept him connected to a modem long enough to get a phone trace. But I haven't read of a _nonfiction_ example where the dynamic opening in a stateful firewall (NAT or otherwise) has directly provided the needed opening for an _active_ attack by a third party. Can you cite one?
The extent to which NAT is a security hazard in my experience is that it simply makes it harder to find a compromised machine. Someone might inform us that they are seeing suspicious traffic that matches a virus profile from an IP address but the NAT makes it difficult to determine the actual source of the traffic. In that case NAT isn't, in and of itself, the enabling mechanism, but it does offer the compromised host some additional time to do its malicious work while it is being tracked down and eliminated.
It also adds more work for providers when someone wants to know who was responsible for certain traffic at certain times. This is particularly true of NAT devices that get their "outside" IP by DHCP. Now they have to search their records and sort out who had that IP at that time and then associate that with a specific customer. Then at the customer location, there might be several more devices (or a neighbor connected over an unsecured wireless) and at that point there is no telling where the traffic came from.
So NAT itself isn't a security threat, but it sure gives a real security threat a lot of woodwork in which to hide.
G
I'm a full supported for getting rid of NAT when deploying IPv6, but have to say the alternative is not all that great either. Because what do people want, they want privacy, so they use the IPv6 privacy extensions. Which are enabled by default on Windows when IPv6 is used on XP, Vista and 7. And now you have no idea who had that IPv6-address at some point in time. The solution to that problem is ? I guess the only solution is to have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- address combinations ? Or is their an other solution I'm missing.
On 1/15/11 1:24 PM, Leen Besselink wrote:
I'm a full supported for getting rid of NAT when deploying IPv6, but have to say the alternative is not all that great either.
Because what do people want, they want privacy, so they use the IPv6 privacy extensions. Which are enabled by default on Windows when IPv6 is used on XP, Vista and 7.
There aren't enough hosts on most subnets that privacy extensions actually buy you that much. sort of like have a bunch of hosts behind a single ip, a bunch of hosts behind a single /64 aren't really insured much in the way of privacy, facebook is going to know that it's you.
And now you have no idea who had that IPv6-address at some point in time. The solution to that problem is ? I guess the only solution is to have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- address combinations ?
Or is their an other solution I'm missing.
On 01/15/2011 03:01 PM, Joel Jaeggli wrote:
On 1/15/11 1:24 PM, Leen Besselink wrote:
I'm a full supported for getting rid of NAT when deploying IPv6, but have to say the alternative is not all that great either.
Because what do people want, they want privacy, so they use the IPv6 privacy extensions. Which are enabled by default on Windows when IPv6 is used on XP, Vista and 7. There aren't enough hosts on most subnets that privacy extensions actually buy you that much. sort of like have a bunch of hosts behind a single ip, a bunch of hosts behind a single /64 aren't really insured much in the way of privacy, facebook is going to know that it's you.
Now this gets a bit a offtopic, but: If you already have a Facebook account, any site you visit which has "Facebook Connect" on it usually points directly at facebook.com for downloading the 'Facebook connect' image so the Facebook-cookies have already been sent to Facebook. Why would Facebook care about your IP-address ?
And now you have no idea who had that IPv6-address at some point in time. The solution to that problem is ? I guess the only solution is to have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- address combinations ?
Or is their an other solution I'm missing.
On Jan 15, 2011, at 9:19 AM, Leen Besselink wrote:
On 01/15/2011 03:01 PM, Joel Jaeggli wrote:
On 1/15/11 1:24 PM, Leen Besselink wrote:
I'm a full supported for getting rid of NAT when deploying IPv6, but have to say the alternative is not all that great either.
Because what do people want, they want privacy, so they use the IPv6 privacy extensions. Which are enabled by default on Windows when IPv6 is used on XP, Vista and 7. There aren't enough hosts on most subnets that privacy extensions actually buy you that much. sort of like have a bunch of hosts behind a single ip, a bunch of hosts behind a single /64 aren't really insured much in the way of privacy, facebook is going to know that it's you.
Now this gets a bit a offtopic, but:
If you already have a Facebook account, any site you visit which has "Facebook Connect" on it usually points directly at facebook.com for downloading the 'Facebook connect' image so the Facebook-cookies have already been sent to Facebook.
That assumes that you use the same browser for Facebook as for other uses. I recommend not doing that, but to dedicate a browser for Facebook only, precisely because Facebook plays these sorts of games and is such a security hole. Regards Marshall
Why would Facebook care about your IP-address ?
And now you have no idea who had that IPv6-address at some point in time. The solution to that problem is ? I guess the only solution is to have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- address combinations ?
Or is their an other solution I'm missing.
On Jan 15, 2011, at 6:01 AM, Joel Jaeggli wrote:
On 1/15/11 1:24 PM, Leen Besselink wrote:
I'm a full supported for getting rid of NAT when deploying IPv6, but have to say the alternative is not all that great either.
Because what do people want, they want privacy, so they use the IPv6 privacy extensions. Which are enabled by default on Windows when IPv6 is used on XP, Vista and 7.
There aren't enough hosts on most subnets that privacy extensions actually buy you that much. sort of like have a bunch of hosts behind a single ip, a bunch of hosts behind a single /64 aren't really insured much in the way of privacy, facebook is going to know that it's you.
Privacy extensions aren't intended to hide the location of the transaction. They are intended to prevent a given MAC address from being tracked across a variety of networks. All that they really solve is the problem of "I disabled my cookies, but, the website still knows who I am no matter where I go." Owen
I'm a full supported for getting rid of NAT when deploying IPv6, but have to say the alternative is not all that great either.
Because what do people want, they want privacy, so they use the IPv6 privacy extensions. Which are enabled by default on Windows when IPv6 is used on XP, Vista and 7.
And now you have no idea who had that IPv6-address at some point in time. The solution to that problem is ? I guess the only solution is to have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- address combinations ?
Or is their an other solution I'm missing.
You can solve this problem any of the ways you could solve it in IPv4. Either assign static addresses from DHCPv6, or assign static addresses by hand.
On 01/15/2011 11:06 PM, Stephen Davis wrote:
I'm a full supported for getting rid of NAT when deploying IPv6, but have to say the alternative is not all that great either.
Because what do people want, they want privacy, so they use the IPv6 privacy extensions. Which are enabled by default on Windows when IPv6 is used on XP, Vista and 7.
And now you have no idea who had that IPv6-address at some point in time. The solution to that problem is ? I guess the only solution is to have the IPv6 equivalant of arpwatch to log the MAC-addresses/IPv6- address combinations ?
Or is their an other solution I'm missing. You can solve this problem any of the ways you could solve it in IPv4. Either assign static addresses from DHCPv6, or assign static addresses by hand. If you like privacy, you don't need to even have static from DHCPv6, you could have a new address every day (if you turn off your machine daily).
Everything else can just query DNS for the address.
On 1/14/11 4:10 PM, William Herrin wrote:
On Fri, Jan 14, 2011 at 2:43 PM, Owen DeLong<owen@delong.com> wrote:
Ah, but, the point here is that NAT actually serves as an enabling technology for part of the attack he is describing. As for strictly passive attacks, like the so-called drive by download, it is not obvious to me that they would operate differently in a NAT versus non-NAT stateful firewall environment. Please elucidate. Systems having poor integrity are often _incorrectly_ considered 'safe' behind typical firewalls, but their exposure often includes more than just IP address contacted in a URI. Once initiated, often internal hosts remain connected with any IP address on non-symmetric NATs for some period beyond an initial exchange. A behavior promoted to support teredo, for example. Don't think no one is using IPv6, even when there is only IPv4 access.
Explain how [NAT] acts as an enabler.
Consider the impact the typical NAT or "firewall" has on DNS. Hi Doug,
You'd make the argument that NAT aggravates Kaminsky? If you have something else in mind, I'll have to ask you to spell it out for me. Many of these products themselves are insecure due to bugs in their reference design dutifully replicated by CPE manufactures. These devices often keep no logs, and might even redirect specific DNS queries when owned, where a power-cycling removes all evidence. Even Cisco firewalls were mapping a range of IP addresses, rather than port mapping, and exposed systems unable to endure this type of exposure to
http://www.symantec.com/avcenter/reference/Teredo_Security.pdf the Internet. While it is possible to have a well implemented NAT, many are unable to support DNS TCP exchanges or handle DNSsec. The same devices often restrict port ranges, where prior access to an attacker's authoritative servers gives significant poisoning clues on subsequent exchanges driven by injected iFrames. A system not safe on the Internet, often is also not safe behind the typical CPE NAT/firewall. -Doug
On Wednesday, January 12, 2011 12:16:27 pm Valdis.Kletnieks@vt.edu wrote:
140 million compromised PC's, most of them behind a NAT, can't be wrong. :)
How many more would there be if most PC's were not behind NAT or stateful firewalling? Or, to turn it on its ear, "Windows is the best OS; 250 million Windows PC's can't be wrong." Uh, yes they can. The various implementations of NAT, the various implementations of stateless and stateful firewalling, and any other ingress protections only cover a few attack vectors; surf-by client-driven web bugs aren't in that set of vectors. However, mechanisms like PVLANs and internal firewalling can help mitigate those, as can host-based protections.
On Jan 13, 2011, at 11:44 AM, Lamar Owen wrote:
On Wednesday, January 12, 2011 12:16:27 pm Valdis.Kletnieks@vt.edu wrote:
140 million compromised PC's, most of them behind a NAT, can't be wrong. :)
How many more would there be if most PC's were not behind NAT or stateful firewalling?
Here you've hit the key... "or stateful firewalling". Stateful firewalling provides the security. NAT just mangles the header. Overloaded NAT depends inherently on the stateful firewall and this has lead to confusion where people don't realize that the term "NAT" is often (mis)used to refer to the combined process. Owen
On Jan 12, 2011, at 9:04 AM, William Herrin wrote:
On Wed, Mar 21, 2007 at 5:41 AM, Tarig Ahmed <tariq198487@hotmail.com> wrote:
We have wide range of Public IP addresses, I tried to assign public ip directly to a server behined firewall( in DMZ), but I have been resisted. Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons.
Is it true that NAT can provide more security?
Hi Tarig,
Yes NAT can provide more security, but not in the particular scenario you described.
In your scenario, the firewall knows how to map incoming connections for the public address to your server's private address, so you won't see any benefit from NAT versus a merely stateful firewall -- a connection request will either get through the filter or it won't. If it gets through, the firewall knows where to send it. On the other hand, the use of any kind of stateful firewall (most of what we refer to as NAT firewalls keep per-connection state) increases your vulnerability to denial of services attacks: folks DOSing you can target both the server and the firewall's state table. So the use of NAT there is potentially counterproductive.
In a client (rather than server) scenario, the picture is different. Depending on the specific "NAT" technology in use, the firewall may be incapable of selecting a target for unsolicited communications inbound from the public Internet. In fact, it may be theoretically impossible for it to do so. In those scenarios, the presence of NAT in the equation makes a large class of direct attacks on the interior host impractical, requiring the attacker to fall back on other methods like attempting to breach the firewall itself or indirectly polluting the responses to communication initiated by the internal host.
No, NAT doesn't provide additional security. The stateful inspection that NAT cannot operate without provides the security. Take away the address mangling and the stateful inspection still provides the same level of security. Owen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong <owen@delong.com> wrote:
No, NAT doesn't provide additional security. The stateful inspection that NAT cannot operate without provides the security. Take away the address mangling and the stateful inspection still provides the same level of security.
There is a least one situation where NAT *does* provide a small amount of necessary security. Try this at home, with/without NAT: 1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed Without NAT, you're unpatched PC will get infected in less than 1 minute. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNLf8gq1pz9mNUZTMRAjduAJ4w7az13wwn1zsze0DoLTRvOajxxQCgmWMG ZckeFBpLWyoqG/g9iD2cKIk= =yYof -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
There is a least one situation where NAT *does* provide a small amount of necessary security.
Try this at home, with/without NAT:
1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed
Without NAT, you're unpatched PC will get infected in less than 1 minute.
Its the firewall included with the NAT which protects against the infection, not the NAT. So you can remove the NAT, leave the firewall, and be just as secure.
On Jan 12, 2011, at 11:21 AM, Paul Ferguson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong <owen@delong.com> wrote:
No, NAT doesn't provide additional security. The stateful inspection that NAT cannot operate without provides the security. Take away the address mangling and the stateful inspection still provides the same level of security.
There is a least one situation where NAT *does* provide a small amount of necessary security.
Try this at home, with/without NAT:
1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed
Without NAT, you're unpatched PC will get infected in less than 1 minute.
Wrong. Repeat the experiment with stateful firewall with default inbound deny and no NAT. Yep... Same results as NAT. NAT != security. Stateful inspection = some security. Next!! Owen
Few home users have a stateful firewall configured and AFAIK none of the consumer models come with a good default set of rules much less a drop all unknown. For end users NAT is and will likely to continue to be the most significant and effective front line security they have. Home router manufacturers have very limited budgets for training or support for home end users so the approach is likely to remain the least expensive thing that produces the fewest inbound support calls. If the question is whether NAT was designed to be a security level then I agree your stance and I'd also agree that correctly configured firewalls do a better job at security. Where I disagree is your position that there is no extra security inherent in the default NAT behavior. Until someone makes an effort to create either a DMZ entry or starts doing port forwarding all (AFAIK) of the common routers will drop packets that they don't know where to forward them. Is this a tenuous and accidental security level based on current defaults in cheap gear? Of course, but given how normal users behave until routers can automagically configure firewall settings in a safe (i.e. not UPNP) manner I don't see things changing. On 1/12/2011 2:57 PM, Owen DeLong wrote:
On Jan 12, 2011, at 11:21 AM, Paul Ferguson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong<owen@delong.com> wrote:
No, NAT doesn't provide additional security. The stateful inspection that NAT cannot operate without provides the security. Take away the address mangling and the stateful inspection still provides the same level of security.
There is a least one situation where NAT *does* provide a small amount of necessary security.
Try this at home, with/without NAT:
1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed
Without NAT, you're unpatched PC will get infected in less than 1 minute.
Wrong.
Repeat the experiment with stateful firewall with default inbound deny and no NAT.
Yep... Same results as NAT.
NAT != security. Stateful inspection = some security.
Next!!
Owen
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum --------------------------------
Once upon a time, Scott Helms <khelms@ispalliance.net> said:
Few home users have a stateful firewall configured
Yes, they do. NAT requires a stateful firewall. Why is that so hard to understand? -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
No it really doesn't. Thank you for leaving the key word when you quoted me (configured). The difference is the _default_ behavior of the two. NAT by _default_ drops packets it doesn't have a mapped PAT translation for. Home firewalls do not _default_ to dropping all packets they don't have a rule to explicitly allow. The behaviors when configured by someone knowledgeable behave the in a similar fashion (allowing packets that are configured to pass and dropping all others) but end users don't do that as a rule. On 1/12/2011 3:31 PM, Chris Adams wrote:
Once upon a time, Scott Helms<khelms@ispalliance.net> said:
Few home users have a stateful firewall configured Yes, they do. NAT requires a stateful firewall. Why is that so hard to understand?
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum --------------------------------
On Wed, 12 Jan 2011, Chris Adams wrote:
Yes, they do. NAT requires a stateful firewall. Why is that so hard to understand?
Um. No. NAT requires stateful inspection (because NAT needs to maintain a state table), but does not require a stateful firewall. You can (and many CPE appliances do/did) have no firewall, or stateless firewall in front of NAT. All NAT does is give you an implied deny-all-inbound rule, but doesn't, in and of itself, prevent someone probing open (configured by you or the vendor) ports that are forwarded or on the device. Or from having unfettered inside access of 1 internal IP if you NAT all external ports to an internal IP. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On 1/12/2011 2:13 PM, Scott Helms wrote:
Until someone makes an effort to create either a DMZ entry or starts doing port forwarding all (AFAIK) of the common routers will drop packets that they don't know where to forward them.
This can be easily implemented in stateful firewalls for home routers. The code is almost identical to NAT, just no address mangling. I suspect that v4 NAT and v6 stateful inspection will actually use the same code in many cases. Not to say NAT doesn't have other uses, but they generally are useful for enterprise networks or sometimes service providers, not home routers. Jack
In article <xs4all.4D2E0B77.9060504@ispalliance.net>, Scott Helms <khelms@ispalliance.net> wrote:
Few home users have a stateful firewall configured and AFAIK none of the consumer models come with a good default set of rules much less a drop all unknown.
The v6 capable CPEs for home users I've seen so far all include stateful firewalling with inbound default deny. (including the one I'm using right now) Is your experience with such CPEs any different ? Mike.
Miquel, Almost no home users have an IPv6 connection currently and the ones that do are the extreme outliers. IPv6 gear (depending on the deployment method) will hopefully handle this well, but no I haven't seen any that did a default drop all. In truth most of the CPE I've seen don't even run v6 well even if their marketing claims otherwise. However, v6 is an entirely different generation of gear that will _hopefully_ get things right since they will _hopefully_ avoid NAT. Having said that so far the smoothest (from an end user perspective) way of moving forward is often 4 to 6 in the home and I expect that to be dirt common for very long time in the future. On 1/12/2011 3:37 PM, Miquel van Smoorenburg wrote:
In article<xs4all.4D2E0B77.9060504@ispalliance.net>, Scott Helms<khelms@ispalliance.net> wrote:
Few home users have a stateful firewall configured and AFAIK none of the consumer models come with a good default set of rules much less a drop all unknown. The v6 capable CPEs for home users I've seen so far all include stateful firewalling with inbound default deny.
(including the one I'm using right now)
Is your experience with such CPEs any different ?
Mike.
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum --------------------------------
On Jan 12, 2011, at 12:13 PM, Scott Helms wrote:
Few home users have a stateful firewall configured and AFAIK none of the consumer models come with a good default set of rules much less a drop all unknown. For end users NAT is and will likely to continue to be the most significant and effective front line security they have. Home router
That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny. It then takes the extra step of mangling the packet header. This header mangling step is unnecessary in IPv6 and is not part of the security mechanism. Unfortunately, because these two features have been bundled for so long in IPv4, many people, apparently yourself included, don't see that what most people call a "NAT" box is actually a stateful-inspection+NAT box doing both steps.
manufacturers have very limited budgets for training or support for home end users so the approach is likely to remain the least expensive thing that produces the fewest inbound support calls. If the question is whether NAT was designed to be a security level then I agree your stance and I'd also agree that correctly configured firewalls do a better job at security. Where I disagree is your position that there is no extra security inherent in the default NAT behavior. Until someone makes an effort to create either a DMZ entry or starts doing port forwarding all (AFAIK) of the common routers will drop packets that they don't know where to forward them.
And there's no reason they can't function exactly that way in IPv6 without mangling the packet header.
Is this a tenuous and accidental security level based on current defaults in cheap gear? Of course, but given how normal users behave until routers can automagically configure firewall settings in a safe (i.e. not UPNP) manner I don't see things changing.
Actually, even if it's deliberate, the point here is that it's a three-step process: 1. State table update/match 2. Mangle packet header 3. Forward packet In IPv6, we can discard step 2 without changing the security provided by step 1 and improve the functionality of step 3. Owen
On 1/12/2011 2:57 PM, Owen DeLong wrote:
On Jan 12, 2011, at 11:21 AM, Paul Ferguson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Jan 12, 2011 at 11:09 AM, Owen DeLong<owen@delong.com> wrote:
No, NAT doesn't provide additional security. The stateful inspection that NAT cannot operate without provides the security. Take away the address mangling and the stateful inspection still provides the same level of security.
There is a least one situation where NAT *does* provide a small amount of necessary security.
Try this at home, with/without NAT:
1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed
Without NAT, you're unpatched PC will get infected in less than 1 minute.
Wrong.
Repeat the experiment with stateful firewall with default inbound deny and no NAT.
Yep... Same results as NAT.
NAT != security. Stateful inspection = some security.
Next!!
Owen
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers?
Follow us on Twitter! http://twitter.com/ZCorum --------------------------------
That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny.
Really? I just tested this with 8 different router models from 5 different manufacturers and in all cases the default behavior was the same. Put a public IP on a PC behind the router, tell the router how to connect (DHCP in this case), and leaving everything else as default meant that all traffic to the public IP was allowed through unless I configured rules. One of the Netgear models (IIRC) did block ICMP but any TCP or UDP traffic was allowed through. Now, this certainly isn't an exhaustive test, but it tested the devices we needed checked. If someone knows of a model that does block incoming (non-established TCP) traffic by default I'd like to know about it. That's especially true of combo DSL modem routers. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum --------------------------------
On Wed, 12 Jan 2011 16:05:42 EST, Scott Helms said:
That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny.
Really? I just tested this with 8 different router models from 5 different manufacturers and in all cases the default behavior was the same. Put a public IP on a PC behind the router
At which point you're not running NAT, so it's a different configuration than the one under discussion.
On Jan 12, 2011, at 1:05 PM, Scott Helms wrote:
That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny.
Really? I just tested this with 8 different router models from 5 different manufacturers and in all cases the default behavior was the same. Put a public IP on a PC behind the router, tell the router how to connect (DHCP in this case), and leaving everything else as default meant that all traffic to the public IP was allowed through unless I configured rules. One of the Netgear models (IIRC) did block ICMP but any TCP or UDP traffic was allowed through. Now, this certainly isn't an exhaustive test, but it tested the devices we needed checked. If someone knows of a model that does block incoming (non-established TCP) traffic by default I'd like to know about it. That's especially true of combo DSL modem routers.
It may be that the default behavior of the models you tested is to turn off the stateful firewall if there's a public inside address, but, the same code that does the stateful inspection for NAT can do it without NAT if the vendor chooses. I suspect that the vendors chose to automatically disable stateful inspection to avoid tech support calls from ignorant users with public IPs that didn't understand why their packets weren't getting through. Owen
On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote:
That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny.
This is demonstrably not correct. Even in the case of dynamic overloaded NAT, at least on Cisco, there is no firewalling going on (if firewalling is defined as blocking something). It looks like there is, but that's an illusion, a sleight-of-hand, not reality. In the NAT order of operations in IOS at least you'll find NAT occurs before the routing decision does. Thus, if you change the address in the packet header, you change which routing table entry will be used to route that packet. It's the rewriting of the address that then causes the routing to send the packet in a different direction; in practice most of the time there is either no route or a null route to the inside global address or address block, but it doesn't have to be that way. You could easily set up a NAT where the inside local addresses are on, say, GigabitEthernet0/0 and the inside global address(es) are on Null0.... or GigabitEthernet0/1 (where the honeynet or tarpit resides, perhaps?), or whatnot. Packets that don't match the NAT can just be routed elsewhere, not just to a null route, easily enough. The default destination for most cases happens to be a null route; this is certainly a good imitation of a deny.
On Jan 13, 2011, at 1:21 PM, Lamar Owen wrote:
On Wednesday, January 12, 2011 03:50:28 pm Owen DeLong wrote:
That's simply not true. Every end user running NAT is running a stateful firewall with a default inbound deny.
This is demonstrably not correct. Even in the case of dynamic overloaded NAT, at least on Cisco, there is no firewalling going on (if firewalling is defined as blocking something). It looks like there is, but that's an illusion, a sleight-of-hand, not reality. In the NAT order of operations in IOS at least you'll find NAT occurs before the routing decision does. Thus, if you change the address in the packet header, you change which routing table entry will be used to route that packet. It's the rewriting of the address that then causes the routing to send the packet in a different direction; in practice most of the time there is either no route or a null route to the inside global address or address block, but it doesn't have to be that way.
The rewriting is done by matching the packet against a state table. No match, no rewrite, no forward. If you have a state table and packets have to match the state table to get forwarded, that is, by definition, a stateful firewall.
You could easily set up a NAT where the inside local addresses are on, say, GigabitEthernet0/0 and the inside global address(es) are on Null0.... or GigabitEthernet0/1 (where the honeynet or tarpit resides, perhaps?), or whatnot. Packets that don't match the NAT can just be routed elsewhere, not just to a null route, easily enough. The default destination for most cases happens to be a null route; this is certainly a good imitation of a deny.
The difference between drop, deny, and forward to null0 is a subtlety that doesn't have much to do with the outcome of what happens to the packet. In all cases, the packet is discarded. The bottom line is that a default forward to null0 is a default deny. Yes, it can be overridden like most defaults. Yes, the mechanism for overriding a default deny in an ACL and overriding a default forward to null0 in a state table may be in different parts of the configuration or require different commands, but, it doesn't change the fact that you have a stateful firewall of one form or another. Owen
On Thursday, January 13, 2011 04:32:17 pm Owen DeLong wrote:
No match, no rewrite, no forward.
This is what you're missing; 'no rewrite' does not mean 'no forward'. Non-rewritten packets along with the rewritten *are* forwarded to routing; in a firewall they're not forwarded to routing. What routing does with either packet isn't the NAT's concern. The clever network engineer can take advantage of this to do things with NAT that are difficult to do with firewalls. Now, policy routing can do the same things that NAT can do in this context, without the packet header munging. But if you're already needing to do the translation, NAT kills two birds with one stone. But, you are correct in that most folks lump the words 'NAT' and 'firewall' into the same process, when they are not. I do look forward to the day when NAT will not be necessary for any reason; route-maps and policy routing are more easily understood and just as powerful for the type of packet redirection that NAT enables, with its twist. (route-maps can be the source of the NAT translation, for that matter, in Cisco IOS NAT past a fairly old IOS version). Policy routing doesn't break protocols, either. But policy routing isn't firewalling, any more than NAT is. Even if the route-map points to a next hop of Null0. :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 12, 2011 at 1:16 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 12 Jan 2011 15:13:43 EST, Scott Helms said:
Few home users have a stateful firewall configured
What percent of home users are running a Windows older than XP SP2?
I don't have stats per specific XP SP version, but a sampling of OSs visiting a blog that I admin: 43.40% WinXP 26.33% Win7 13.00% MacOSX 12.60% WinVista 1.60% unknown 1.00% iOS 0.87% Linux 0.87% Android 0.13% Win2003 0.13% Win2000 0.07% SymbianOS Of course, this is just a sampling that may or may not be relevant. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNLhzuq1pz9mNUZTMRAgN0AJ4hrUq0qSfLLNMWq6RAXleb8bya2ACglxTU tT/sP0oVu89WeWrG6XodcKU= =+pa8 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
On 1/12/2011 2:57 PM, Owen DeLong wrote:
Try this at home, with/without NAT:
1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed
Without NAT, you're unpatched PC will get infected in less than 1 minute. Wrong. Repeat the experiment with stateful firewall with default inbound deny and no NAT. Yep... Same results as NAT.
Now let that laptop (or another one on the home subnet) show up with Bridging or Internet Connection Sharing enabled with wired/wireless connections and see what you get. Still maybe OK if it's the "host" firewall, and it's turned on, and it's not domain-joined with the local subnet allowed, etc., but that was post-SP2 and assumes some malware [or the user] hasn't turned it off. NAT+RFC1918 = no accidental leakage/bridging (yes, they could spoof RFC1918 destinations, assuming they get routed all the way to the endpoint... but that's a bigger "if" than a public address) "Perfect stateful firewall with perfect default inbound deny and no other variables thrown in the mix" and yes, but it's breakable in contrast to the NAT+RFC1918 case. There is something to be said for "unreachable" (i.e., "not in your forwarding table") -- else the VPN / VRF / MPLS / etc folks wouldn't have a leg to stand on :-) With that said, this isn't a one-size-fits-all, everybody's perfect solution. We've covered the gamut from home CPE to server farms here, with the original question being about a DMZ case. They are however legitimate security layers applied to certain cloves of this particular bulb of garlic (a more appropriate model than the homogeneous "onion") :-) Jeff
On Wed, 12 Jan 2011 11:21:24 PST, Paul Ferguson said:
Try this at home, with/without NAT:
1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed
Without NAT, you're unpatched PC will get infected in less than 1 minute.
What release of Windows?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jan 12, 2011 at 1:18 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 12 Jan 2011 11:21:24 PST, Paul Ferguson said:
Try this at home, with/without NAT:
1. Buy a new PC with Windows installed 2. Install all security patches needed since the OS was installed
Without NAT, you're unpatched PC will get infected in less than 1 minute.
What release of Windows?
Okay, okay -- you got me on that one. :-) It used to be a much bigger problem when XP was shipping on PCs, but of course that has changed. I suppose there's a sliding-window principle (no pun intended) with regards to the number of security vulnerabilities that are remotely exploitable and the amount of time since the OS version was introduced, but you get my point. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFNLhwjq1pz9mNUZTMRAstGAKDhsX9AYZL6sGMIH5WWJM2GpilQNQCgm3TH UQ26ucDTFifTB3eAQEZxj0M= =Lh9p -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
On Wed, Mar 21, 2007 at 2:41 AM, Tarig Ahmed <tariq198487@hotmail.com> wrote:
We have wide range of Public IP addresses, I tried to assign public ip directly to a server behined firewall( in DMZ), but I have been resisted. Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons.
Is it true that NAT can provide more security?
Thanks,
Tarig Yassin Ahmed
I assume you are talking about the protection to the current running "public facing" servers, hence the NAT could not provide more protection to them compares to a proper configed firewall. However, for a small business who does not have its own ASN & Provider Independent IP block(s), a NAT (NAT44 and NAT66) could provide lots of protection on IT resources when there is a need to install multiple Internet access lines for providing quickly failover (manual or automatic, doesn't matter) and/or load-sharing capability to end users. -- Michel~
On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote:
Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons.
He's wrong.
Is it true that NAT can provide more security?
No, it makes things worse from an availability perspective. Servers should never be NATted or placed behind a stateful firewall. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
Unfortunately there are some sets of requirements which require this type of configuration. The PCI-DSS comes to mind for those who deal with credit card transactions. -Justin On Wednesday, January 12, 2011, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote:
Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons.
He's wrong.
Is it true that NAT can provide more security?
No, it makes things worse from an availability perspective. Servers should never be NATted or placed behind a stateful firewall.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
On Jan 13, 2011, at 12:02 AM, Justin Scott wrote:
The PCI-DSS comes to mind for those who deal with credit card transactions.
Luckily, there are ways to 'comply' with the PCI-DSS security theater regime without placing the availability and overall security of one's public-facing servers at risk, starting with mod_security. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
PCI DSS does not require it. It suggests it. It allows you to do other things which show equivalent security. Also, the PCI DSS requirements for NAT are not on the web server, they are on the back-end processing machine which should NOT be the same machine that is talking to the customers. (I believe that's also part of the PCI DSS, but, I haven't read it recently). PCI DSS is in desperate need of revision and does not incorporate current knowledge. Owen On Jan 12, 2011, at 9:02 PM, Justin Scott wrote:
Unfortunately there are some sets of requirements which require this type of configuration. The PCI-DSS comes to mind for those who deal with credit card transactions.
-Justin
On Wednesday, January 12, 2011, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote:
Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons.
He's wrong.
Is it true that NAT can provide more security?
No, it makes things worse from an availability perspective. Servers should never be NATted or placed behind a stateful firewall.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
PCI DSS just came up with version 2 in October 2010 and one of the changes was: "Removed specific references to IP masquerading and use of network address translation (NAT) technologies and added examples of methods for preventing private IP address disclosure." - merike On Jan 12, 2011, at 10:01 PM, Owen DeLong wrote:
PCI DSS does not require it. It suggests it. It allows you to do other things which show equivalent security.
Also, the PCI DSS requirements for NAT are not on the web server, they are on the back-end processing machine which should NOT be the same machine that is talking to the customers. (I believe that's also part of the PCI DSS, but, I haven't read it recently).
PCI DSS is in desperate need of revision and does not incorporate current knowledge.
Owen
On Jan 12, 2011, at 9:02 PM, Justin Scott wrote:
Unfortunately there are some sets of requirements which require this type of configuration. The PCI-DSS comes to mind for those who deal with credit card transactions.
-Justin
On Wednesday, January 12, 2011, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote:
Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons.
He's wrong.
Is it true that NAT can provide more security?
No, it makes things worse from an availability perspective. Servers should never be NATted or placed behind a stateful firewall.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
On Wednesday, March 21, 2007 05:41:00 am Tarig Ahmed wrote:
Is it true that NAT can provide more security?
Blast from the past.... Whew, is there any subject more guaranteed to cause a long thread than this? :-) I have some ideas on this; there are some creative manglings one can do with NAT that specifically exist to break protocols used by black hats (and others; but if I know a Teredo tunnel isn't used by a server, I should try to break it in as many ways as I can, right?), but lets the desired bits out. Hey, if NAT can make desired protocols break, it can make undesired protocols break, too. Breakage can be considered a feature, depending upon how demented and devious you are. NAT is just another packet tool; like various types of firewalling, it requires intelligent application to be useful. Things like setting up a static PAT for the IRC port on the inside global address to get translated to the IP of an outside IRC server (whose operator has agreed to let you do this, of course!)....or a honeypot IRC server on a different internal network.... can do wonders for the rate of successful entries. I've found by trial and error that outright blocking an attack is far less effective in stopping an intruder than creatively and partially breaking the attack (tarpits, for instance). A quick block will be answered by a quick try at another attack; a tarpit makes nothing quick, and unless it's a targeted-at-you attack to own (most aren't) most attackers will go on to other, lower-hanging, fruit. And I'm sure that I'll continue seeing attacks, and seeing successful workstation exploits, for a long time to come, and neither NAT nor firewalling is much help for certain workstation operating systems in the hands of users who know enough to be dangerous. But one-to-one port-agnostic NAT for a server does nothing to improve security, and, as some have said, will probably make security worse.
participants (40)
-
Brandon Ross -
Brian Keefer -
Chris Adams -
Dave Pooser -
David Barak -
david raistrick -
Dobbins, Roland -
Douglas Otis -
Fernando Gont -
Frank Bulk -
George Bonser -
Greg Ihnen -
Jack Bates -
Jay Mitchell -
Jeff Kell -
Jim Gettys -
Joel Jaeggli -
Justin Scott -
Lamar Owen -
Leen Besselink -
Loránd Jakab -
Mark Andrews -
Mark Smith -
Marshall Eubanks -
Matthew Palmer -
Merike Kaeo -
Michel de Nostredame -
Miquel van Smoorenburg -
ML -
Nathan Eisenberg -
Nick Hilliard -
Owen DeLong -
Paul Ferguson -
Scott Helms -
Seth Mattinen -
Stephen Davis -
Steven Kurylo -
Tarig Ahmed -
Valdis.Kletnieks＠vt.edu -
William Herrin