Ok; let's have the "Does DNAT contribute to Security" argument one more time...

Mailman List Mirror (Read Only)
1

Kill this subject if you're sick of it.

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

2

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.

3

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

4

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

5

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

6

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. :wink:

Cheers,
mh

7

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.

8

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

9

Jay Ashworth wrote:

10

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

11

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 :slight_smile:

Jeff

12

[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.

13

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. :wink:

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.

14

> 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. :wink:

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

15

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

16

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

17

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 :slight_smile:
Perhaps unnecessary NAT is trading a theoretical protection (routing
isolation) for a real vulnerability (trans table overflow).