Ok; let's have the "Does DNAT contribute to Security" argument one more time...
Kill this subject if you're sick of it. ----- Original Message -----
From: "Gabriel McCall" <Gabriel.McCall@thyssenkrupp.com>
If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public.
This assertion is frequently made -- it was made a couple other times this morning -- but I continue to think that it doesn't hold much water, primarly because it doesn't take into account *the probability of various potential failure modes in a firewall*. The basic assertion made by proponents of this theory, when analyzed, amounts to "the probability that a firewall between a publicly routable internal network and the internet will fail in such a fashion as to pass packets addressed to internal machines is of the same close order as the probability that a DNAT router will fail in such a fashion as to allow people outside it to address packets to *arbitrary* internal machine IP addresses (assuming they have any way to determine what those are)." Hopefully, my rephrasing makes it clearer why those of us who believe that there is, in fact, *some* extra security contributed by RFC 1918 and DNAT in the over all stack tend not to buy the arguments of those who say that in fact, it contributes none: they never show their work, so we cannot evaluate their assertions. But in fact, as someone pointed out this morning in the original thread: even if you happen to *know* the internal 1918 IP of the NATted target, the default failure mode of the NAT box is "stop forwarding packets into private network at all". Certainly, individual NAT boxes can have other failure modes, but each of those extra layers adds at least another 0 to the probability p-number, in my not-a-mathematician estimation. On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of "NAT contributes no security" can't, either.
That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue.
It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue. And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On Mon, 14 Nov 2011 15:55:14 EST, Jay Ashworth said:
On the other hand, since a firewall's job is to stop packets you don't want,
One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating badness". A firewall's job isn't to stop unwanted packets, it's to pass only wanted packets.
if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets.
As a result, a firewall that fails open rather than closed is mis-designed. And if you're deploying a firewall and don't know if the failure mode is open or closed, you probably get what you deserve when it fails.
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On the other hand, since a firewall's job is to stop packets you don't want,
One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating badness". A firewall's job isn't to stop unwanted packets, it's to pass only wanted packets.
From 30,000ft those are equivalent.
When you get down below 5000ft, it starts to matter which approach you take to it. There are lots and lots of people, though, whose exposure to firewalls is "a set of rules you drop over a router" -- in consequence of which there are a lot of *firewalls* that are designed that way. You're correct in implying that that's strategically bad, but both components of that paragraph impact the issue.
if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets.
As a result, a firewall that fails open rather than closed is mis-designed.
And if you're deploying a firewall and don't know if the failure mode is open or closed, you probably get what you deserve when it fails.
Can't argue with that at all. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Jay Ashworth wrote:
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On the other hand, since a firewall's job is to stop packets you don't want,
One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating badness". A firewall's job isn't to stop unwanted packets, it's to pass only wanted packets.
From 30,000ft those are equivalent.
Speaking of 30,000 ft., saw this on Dave Farber's IP list: https://plus.google.com/u/0/110897184785831382163/posts/5qsNxFEaiML
For the common good it doesn't matter if the "NAT is good" guys are right or the "NAT is useless" guys are right, as they both fail to decrease the numbers of their opposing parts. We must get IPv6 done for both of them. It seems that application reverse-proxies can make "NAT is good" guys happy, so let's get it or some other solution on the market (both commercial and open-source) and move on with what really matters, getting v6 done. Rubens On Mon, Nov 14, 2011 at 6:55 PM, Jay Ashworth <jra@baylink.com> wrote:
Kill this subject if you're sick of it.
----- Original Message -----
From: "Gabriel McCall" <Gabriel.McCall@thyssenkrupp.com>
If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public.
This assertion is frequently made -- it was made a couple other times this morning -- but I continue to think that it doesn't hold much water, primarly because it doesn't take into account *the probability of various potential failure modes in a firewall*.
The basic assertion made by proponents of this theory, when analyzed, amounts to "the probability that a firewall between a publicly routable internal network and the internet will fail in such a fashion as to pass packets addressed to internal machines is of the same close order as the probability that a DNAT router will fail in such a fashion as to allow people outside it to address packets to *arbitrary* internal machine IP addresses (assuming they have any way to determine what those are)."
Hopefully, my rephrasing makes it clearer why those of us who believe that there is, in fact, *some* extra security contributed by RFC 1918 and DNAT in the over all stack tend not to buy the arguments of those who say that in fact, it contributes none: they never show their work, so we cannot evaluate their assertions.
But in fact, as someone pointed out this morning in the original thread: even if you happen to *know* the internal 1918 IP of the NATted target, the default failure mode of the NAT box is "stop forwarding packets into private network at all".
Certainly, individual NAT boxes can have other failure modes, but each of those extra layers adds at least another 0 to the probability p-number, in my not-a-mathematician estimation.
On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of "NAT contributes no security" can't, either.
That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue.
It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue.
And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports.
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On 11/14/2011 4:21 PM, Rubens Kuhl wrote:
For the common good it doesn't matter if the "NAT is good" guys are right or the "NAT is useless" guys are right, as they both fail to decrease the numbers of their opposing parts. We must get IPv6 done for both of them.
Hehehe... depending on your ISPs / transit providers / border technology level, putting critical infrastructure on IPv6[only] might be the safest most unreachable network of all :) Jeff
There really is no winner or "right way" on this thread. In IPv4 as a security guy we have often implemented NAT as an extra layer of obfuscation. In IPv6, that option really isn't there. So it's a cultural change for me. I'm not shedding any tears. We've talked to our FW vendors about various 6to6 and 4to6/6to4 options and we may consider it but given the push in the IPv6 community for native addressing I really am hesitant to add NAT functionality given that no one really knows what the IPv6 future holds. -Hammer- "I was a normal American nerd" -Jack Herer On 11/14/2011 02:55 PM, Jay Ashworth wrote:
Kill this subject if you're sick of it.
----- Original Message -----
From: "Gabriel McCall"<Gabriel.McCall@thyssenkrupp.com>
If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public.
This assertion is frequently made -- it was made a couple other times this morning -- but I continue to think that it doesn't hold much water, primarly because it doesn't take into account *the probability of various potential failure modes in a firewall*.
The basic assertion made by proponents of this theory, when analyzed, amounts to "the probability that a firewall between a publicly routable internal network and the internet will fail in such a fashion as to pass packets addressed to internal machines is of the same close order as the probability that a DNAT router will fail in such a fashion as to allow people outside it to address packets to *arbitrary* internal machine IP addresses (assuming they have any way to determine what those are)."
Hopefully, my rephrasing makes it clearer why those of us who believe that there is, in fact, *some* extra security contributed by RFC 1918 and DNAT in the over all stack tend not to buy the arguments of those who say that in fact, it contributes none: they never show their work, so we cannot evaluate their assertions.
But in fact, as someone pointed out this morning in the original thread: even if you happen to *know* the internal 1918 IP of the NATted target, the default failure mode of the NAT box is "stop forwarding packets into private network at all".
Certainly, individual NAT boxes can have other failure modes, but each of those extra layers adds at least another 0 to the probability p-number, in my not-a-mathematician estimation.
On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of "NAT contributes no security" can't, either.
That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue.
It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue.
And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports.
Cheers, -- jra
Le lundi 14 novembre 2011 à 15:43 -0600, -Hammer- a écrit :
There really is no winner or "right way" on this thread. In IPv4 as a security guy we have often implemented NAT as an extra layer of obfuscation. In IPv6, that option really isn't there. So it's a cultural change for me. I'm not shedding any tears. We've talked to our FW vendors about various 6to6 and 4to6/6to4 options and we may consider it but given the push in the IPv6 community for native addressing I really am hesitant to add NAT functionality given that no one really knows what the IPv6 future holds.
I consider that a good way of looking a things. ;) Cheers, mh
-Hammer-
"I was a normal American nerd" -Jack Herer
On 11/14/2011 02:55 PM, Jay Ashworth wrote:
Kill this subject if you're sick of it.
----- Original Message -----
From: "Gabriel McCall"<Gabriel.McCall@thyssenkrupp.com>
If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public.
This assertion is frequently made -- it was made a couple other times this morning -- but I continue to think that it doesn't hold much water, primarly because it doesn't take into account *the probability of various potential failure modes in a firewall*.
The basic assertion made by proponents of this theory, when analyzed, amounts to "the probability that a firewall between a publicly routable internal network and the internet will fail in such a fashion as to pass packets addressed to internal machines is of the same close order as the probability that a DNAT router will fail in such a fashion as to allow people outside it to address packets to *arbitrary* internal machine IP addresses (assuming they have any way to determine what those are)."
Hopefully, my rephrasing makes it clearer why those of us who believe that there is, in fact, *some* extra security contributed by RFC 1918 and DNAT in the over all stack tend not to buy the arguments of those who say that in fact, it contributes none: they never show their work, so we cannot evaluate their assertions.
But in fact, as someone pointed out this morning in the original thread: even if you happen to *know* the internal 1918 IP of the NATted target, the default failure mode of the NAT box is "stop forwarding packets into private network at all".
Certainly, individual NAT boxes can have other failure modes, but each of those extra layers adds at least another 0 to the probability p-number, in my not-a-mathematician estimation.
On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of "NAT contributes no security" can't, either.
That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue.
It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue.
And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports.
Cheers, -- jra
Firewalls and NATs are "warm fuzzy feeling" devices. The best way to keep secure is to run up to date software and to only provide services you need. Firewalls and NAT both inhibit inventions. Both really do very little with modern operating systems that have been designed to be connected without a firewall in front of them to the Internet. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
There really is no winner or "right way" on this thread. In IPv4 as a security guy we have often implemented NAT as an extra layer of obfuscation.
It's worse than just obfuscation. The 'security' side effect of NAT can typically be implemented by four or five rules in a traditional firewall. But a NAT implementation adds thousands of lines of code to the path the packets take, and any time you introduce complexity you decrease the overall security of the system. And the complexity extends beyond the NAT box. Hacking on IPsec, SIP, and lord knows what else to work around address rewriting adds even more opportunities for something to screw up. If you want security, you have to DEcrease the number of lines of code in the switching path, not add to it. Complexity is evil. It's a shame this is no longer taught in computing courses. And I mean taught as a philosophy, not as a function of line count or any other bean-counter metrics. --lyndon
On Mon, Nov 14, 2011 at 6:01 PM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
But a NAT implementation adds thousands of lines of code to the path the packets take, and any time you introduce complexity you decrease the overall security of the system. And the complexity extends beyond the NAT box. Hacking on IPsec, SIP, and lord knows what else to work around address rewriting adds even more opportunities for something to screw up.
If you want security, you have to DEcrease the number of lines of code in the switching path, not add to it.
Hi Lyndon, Counterpoint: Using two firewalls in serial from two different vendors doubles the complexity. Yet it almost always improves security: fat fingers on one firewall rarely repeat the same way on the second and a rogue packet must pass both. The same two firewalls in parallel surely reduces security. Is complexity the enemy of security? In general principle yes, but as with many things IT DEPENDS. 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 Mon, 14 Nov 2011 19:06:13 EST, William Herrin said:
Using two firewalls in serial from two different vendors doubles the complexity. Yet it almost always improves security: fat fingers on one firewall rarely repeat the same way on the second and a rogue packet must pass both.
Fat fingers are actually not the biggest issue - a far bigger problem are brain failures. If you thought opening port 197 was a good idea, you will have done it on both firewalls. And it doesn't even help to run automated config checkers - because you'll have marked port 197 as "good" in there as well. ;) And it doesn't even help with fat-finger issues anyhow, because you *know* that if your firewall admin is any good, they'll just write a script that loads both firewalls from a master config file - and then proceed to fat-finger said config file.
On Nov 14, 2011 9:22 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 14 Nov 2011 19:06:13 EST, William Herrin said:
Using two firewalls in serial from two different vendors doubles the complexity. Yet it almost always improves security: fat fingers on one firewall rarely repeat the same way on the second and a rogue packet must pass both.
Complexity equals downtime. I know at least one definition of security includes availability .
Fat fingers are actually not the biggest issue - a far bigger problem are brain failures. If you thought opening port 197 was a good idea, you will have done it on both firewalls. And it doesn't even help to run automated config checkers - because you'll have marked port 197 as "good" in there as well. ;)
And it doesn't even help with fat-finger issues anyhow, because you *know* that if your firewall admin is any good, they'll just write a script that loads both firewalls from a master config file - and then proceed to fat-finger said config file.
And, stateful firewalls are a very common dos vector. Attacking firewall sessions per second capacity and blowing up a session table can bring a service down real quick. Furthermore, firewalls are frequently installed at a choke point ... Which makes them a topological single point of failure.... So, they are deployed in pairs .... And therefore have a nice cascading failure behavior when hit with a dos. Cb
On Mon, Nov 14, 2011 at 2:55 PM, Jay Ashworth <jra@baylink.com> wrote:
The basic assertion made by proponents of this theory, when analyzed, amounts to "the probability that a firewall between a publicly routable internal network and the internet will fail in such a fashion as to pass packets addressed to internal machines is of the same close order as the probability that a DNAT router will fail in such a fashion as to allow people outside it to address packets to *arbitrary* internal machine IP addresses (assuming they have any way to determine what those are)." [snip]
There is really no sound argument made that the probability is inherently any different. When we are referring to security devices failing to do what they are supposed to do, by definition, the correct level of protection has been lost, and you have a serious problem if this happens, regardless of whether your firewall is a NAT device or not. What will be most important is you have solid layers of defense behind the firewall, such as host security, IDS units, monitoring, and scanning regimes to detect the failure of the firewall function. The security appliance has failed, and all bets may be off. It should be noted, that "detecting" a failed simple firewall with a straight port scan is a much simpler more easily automatable process than detecting a failed 1:many NAT firewall. The ease of detecting the problem lowers the chance that you have a problem. The potential security failure modes of a 1:many NAT firewall are much more complicated than "simply pass packets it's not supposed to pass"; the quirks of the flaw mean that with a NAT firewall, it is likely the failure of the firewall function will go undetected by the security admin, resulting in a situation where you have an insidious problem... that is, a problem that is not obvious, but definitely exploitable to a determined attacker. Failure modes such as a "an intruder compromised the firewall" and injected a trojanned firmware result in equal risks regardless of whether NAT is implemented or not. -- -JH
On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of "NAT contributes no security" can't, either.
Perhaps this misunderstanding of the job of a firewall explains your errant conclusions about their failure modes better than anything else in the thread. I would say that your description above does not fit a stateful firewall, but, instead describes a packet-filtering router. A stateful firewall's job is to forward only those packets you have permitted. If ti stops doing it's job, it's default failure mode is to stop forwarding packets. Please explain to me how mutilating the packet header makes any difference in this.
That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue.
It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue.
It's a lovely hypothetical description of how those devices should work. IME, and, as has been explained earlier in the thread, it is not necessarily how they ACTUALLY work. Since security depends not on the theoretical ideal of how the devices should work, but, rather on how they actually work, perhaps it is worth considering that our addressing reality instead of theory is actually a feature rather than a bug.
And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports.
I think that is what the discussion has been about all along. Owen
There are some methods of security that NAT has a good use for. We use NAT to prevent reachibility. In other words, not only does an ACL have to allow traffic thru the FW, but a complimenting NAT rule has to allow the actual layer 3 reachibility. If not, even with the ACL, the routing path won't be available. It is a great "safety" check when we implement FW rules because it forces almost every manual entry to have two specific steps. In our layered environments, we also use local routing in some of our DMZs. In other words, a server on a subnet will only be aware of it's local broadcast domain. Even with a default GW, if it doesn't have a NAT in the FW, it can't route thru it. So even if a server gets compromised, the bad guy doesn't have a method to reach beyond the local DMZ without also making adjustments on the FW. I don't think this complicates our design to much and definitely keeps us in check from human errors. -Hammer- "I was a normal American nerd" -Jack Herer On 11/15/2011 09:00 AM, Owen DeLong wrote:
On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of "NAT contributes no security" can't, either.
Perhaps this misunderstanding of the job of a firewall explains your errant conclusions about their failure modes better than anything else in the thread.
I would say that your description above does not fit a stateful firewall, but, instead describes a packet-filtering router.
A stateful firewall's job is to forward only those packets you have permitted. If ti stops doing it's job, it's default failure mode is to stop forwarding packets. Please explain to me how mutilating the packet header makes any difference in this.
That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue.
It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue.
It's a lovely hypothetical description of how those devices should work. IME, and, as has been explained earlier in the thread, it is not necessarily how they ACTUALLY work. Since security depends not on the theoretical ideal of how the devices should work, but, rather on how they actually work, perhaps it is worth considering that our addressing reality instead of theory is actually a feature rather than a bug.
And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports.
I think that is what the discussion has been about all along.
Owen
Against my better judgment to get in the middle of this classic discussion, two points... One, many firewalls have fail-safe capabilities, in addition to fail-secure; even if they didn't it could be trivially programmed, or configured to do so in series, and as configuration is fairly arbitrary the comments about "how firewalls work" aren't really valid. My firewall most certainly works differently than yours ... There are also issues with stateful failover versus stateless failover. The two schools of thought on this issue are, as far as I know: a) Fail as little as possible and as compartmentalized as possible, attempting to keep service online at the expense of security (perhaps) (fail-safe) or b) Fail with the intent to keep the network as secure as possible, even if it means causing total service failure. (fail-secure) I find both to be valid and each network should be individually evaluated for application of A or B. If you have a secretless, isolated, read-only environment there is no reason to be concerned about people mucking about. in theory. Two, I would almost guarantee the combination of NAT+firewall is better than only firewall, however the fact that NAT is inherently stateful and really quite vulnerable to DoS makes for an interesting situation. At least with only firewall you could revert to stateless mode during a translation attack (if you chose 'A'). For a NAT to have a similar approach you would need a dark address pool for static translation... that doesn't seem likely or practical, saving a situation where you paid for address time. On the negative case, not having a NAT implies that you won't have any NAT failures or NAT hardware costs :) Perhaps unnecessary NAT is trading a theoretical protection (routing isolation) for a real vulnerability (trans table overflow). On Tue, Nov 15, 2011 at 10:00 AM, Owen DeLong <owen@delong.com> wrote:
On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of "NAT contributes no security" can't, either.
Perhaps this misunderstanding of the job of a firewall explains your errant conclusions about their failure modes better than anything else in the thread.
I would say that your description above does not fit a stateful firewall, but, instead describes a packet-filtering router.
A stateful firewall's job is to forward only those packets you have permitted. If ti stops doing it's job, it's default failure mode is to stop forwarding packets. Please explain to me how mutilating the packet header makes any difference in this.
That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue.
It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue.
It's a lovely hypothetical description of how those devices should work. IME, and, as has been explained earlier in the thread, it is not necessarily how they ACTUALLY work. Since security depends not on the theoretical ideal of how the devices should work, but, rather on how they actually work, perhaps it is worth considering that our addressing reality instead of theory is actually a feature rather than a bug.
And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports.
I think that is what the discussion has been about all along.
Owen
participants (14)
-
-Hammer- -
Cameron Byrne -
Charles Morris -
Jay Ashworth -
Jeff Kell -
Jimmy Hess -
Lyndon Nerenberg -
Mark Andrews -
Michael Hallgren -
Michael Painter -
Owen DeLong -
Rubens Kuhl -
Valdis.Kletnieks＠vt.edu -
William Herrin