Is NAT can provide some kind of protection?

Douglas Otis dotis at
Thu Jan 13 22:50:55 CST 2011

On 1/13/11 5:48 PM, William Herrin wrote:
> On Wed, Jan 12, 2011 at 10:02 PM, Mark Andrews<marka at>  wrote:
>> In message<AANLkTikiXF_mbuo-osKPjSW98vn5_d5WZNUi_PL37sNG at>, 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 at>  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.


More information about the NANOG mailing list