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

Tue Nov 15 15:44:51 UTC 2011

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 at 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
>
>
>