Re: Is NAT can provide some kind of protection?

[Owen DeLong <owen () delong com>]

On Jan 12, 2011, at 6:13 PM, William Herrin wrote:

> On Wed, Jan 12, 2011 at 12:16 PM,  <Valdis.Kletnieks () vt edu> wrote:
> > On Wed, 12 Jan 2011 12:04:01 EST, William Herrin said:
> > > In a client (rather than server) scenario, the picture is different.
> > > Depending on the specific "NAT" technology in use, the firewall may be
> > > incapable of selecting a target for unsolicited communications inbound
> > > from the public Internet. In fact, it may be theoretically impossible
> > > for it to do so. In those scenarios, the presence of NAT in the
> > > equation makes a large class of direct attacks on the interior host
> > > impractical, requiring the attacker to fall back on other methods like
> > > attempting to breach the firewall itself or indirectly polluting the
> > > responses to communication initiated by the internal host.
> >
> > Note that the presence of a firewall with a 'default deny' rule for inbound
> > packets provides the same level of impracticality.
>
> Hi Valdis,
>
> 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.
>
> The hacker can't make the equipment do something impossible. He can
> only go around it, try a different attack vector. To push through
> something the technology has been programmed not to do, he needs to
> identify a suitable bug: hard but not quite impractical. As for
> default configurations... human error is a *major* part of the
> security equation. Identifying and exploiting configuration errors is
> a hacker's fertile hunting ground.
NAT boxes without the ability to do port forwarding are few and far
between. Human error can poke a hole in a NAT as easily as in a
stateful firewall with a default deny.


> On Wed, Jan 12, 2011 at 2:35 PM, Owen DeLong <owen () delong com> wrote:
> > On Jan 12, 2011, at 9:36 AM, Jack Bates wrote:
> > > As my corp IT guy put it to me, PAT forces a routing disconnect
> > > between internal and external. There is no way to reach the hosts
> > > without the firewall performing it's NAT function. Given that the
> > > internal is exclusively PAT, the DMZ is public with stateful/proxy,
> > > this provides protection for the internal network while limiting the
> > > dmz exposure.
> >
> > The corp IT guy is delusional. The solution to the routing disconnect is
> > map+encap or tunnels.
>
> Logical fallacy, ad hominem: the sanity of Jack's IT guy is not at issue.
The logical fallacy is believing that NAT provides any protection.

> Logical fallacy, straw man: that a security technology failed to close
> attack vectors it was not claimed to have closed makes no statement as
> to whether the tech blocked the attack vectors it did claim to block.
> The only technology which stops all possible network attack vectors is
> the off switch.
It claimed to provide routing isolation. That alleged isolation is easily
circumvented or even configured out of relevance by human error
or deliberately.

> Logical fallacy, circular reasoning: to bring your magic tunnels into
> existence, the firewall must have already been breached. Yet you claim
> the tunnels allow you to breach the firewall, allegedly proving that
> the PAT routing disconnect is a no-op.
No, the firewall is presumably configured to intentionally allow access
by end users to web sites. Once you allow that, point-click-pwnm3
takes over.

> It took you only 17 words to get the trifecta. Congratulations, or something.
Seriously, Bill... Just because you keep repeating the same sophistry
doesn't make it any more believable.

> On Wed, Jan 12, 2011 at 2:09 PM, Owen DeLong <owen () delong com> wrote:
> > No, NAT doesn't provide additional security. The stateful inspection that
> > NAT cannot operate without provides the security. Take away the
> > address mangling and the stateful inspection still provides the same
> > level of security.
>
> When you'd care to offer a refutation of my explanation (above) of
> exactly how NAT impacts the security process beyond what the stateful
> inspection does, a refutation that doesn't involve a bunch of bald
> assertions, hand-waving and logical fallacies, you let me know.
> Perhaps the "security expert" you tell me you relied on when
> formulating your viewpoint could help you out with that?
Logical fallacy -- Circular argument. Since you call any refutation I offer
"bald assertions" or "hand waving" when in reality they are behaviors
I have observed in the real world, I doubt we'll ever come to agreement
on this point.

Also, saying things like `the "security expert" you tell me you relied on'
come across as condescending. I have told you that I have discussed
the matter with multiple security experts on multiple occasions. The
fact that most of them have not given me permission to disclose their
contact details to you does not render them any less correct.

Finally, I've never told you that I relied on them in forming my viewpoint,
only that I have discussed the matter at length and that they share my
viewpoint.

Owen

> On Wed, Jan 12, 2011 at 2:21 PM, Paul Ferguson <fergdawgster () gmail com> wrote:
> > There is a least one situation where NAT *does* provide a small amount of
> > necessary security.
> >
> > Try this at home, with/without NAT:
> >
> > 1. Buy a new PC with Windows installed
> > 2. Install all security patches needed since the OS was installed
> >
> > Without NAT, you're unpatched PC will get infected in less than 1 minute.
>
> Hi Paul,
>
> That doesn't really prove your point. Owen is correct that any
> reasonably configured firewall of any type would tend to prevent such
> infections. The different firewall types don't begin to exhibit a
> major difference in security effectiveness until you factor in the
> impact of human error in specific scenarios.
>
> 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