Is NAT can provide some kind of protection?

Owen DeLong owen at delong.com
Fri Jan 14 02:59:22 UTC 2011


On Jan 13, 2011, at 5:48 PM, William Herrin wrote:

> On Wed, Jan 12, 2011 at 10:02 PM, Mark Andrews <marka at isc.org> wrote:
>> In message <AANLkTikiXF_mbuo-osKPjSW98vn5_d5WZNUi_PL37sNG at 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 at 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





More information about the NANOG mailing list