> -----Original Message-----
> From: Michael Batchelder [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 02, 2001 1:03 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Penetrating a NAT
>
> > [Steve Riley]
> > Some "security experts" claim that NAT could be used as a firewall
> > (or let's say, some means of hiding the internal network).
> >
> >>[Michael Batchelder]
> >>No security expert I know would assert such a thing. If they did,
> >>I'd give their title an instant expertectomy.
> >
> > [Ben Nagy]
> > D'oh. Guess I was never an expert, then.
[...]
> > My claim remains that NAT can provide about as much protection as
> > a dumb stateful packet filter.
>
> I was taking issue with the part of the sentence that said
> "NAT could be
> used as a firewall". That is not, at face value, equivalent to the
> above
> statement you subsequently made that "NAT can provide about as much
> protection as a dumb stateful packet filter", even with the posit that
> you and Steve both made that the NAT *implementation* "not allow
> connections from the outside".
People use dumb stateful packet filters as firewalls all the time - standard
IOS ACLs and ipchains being the worst offenders.
What _I'm_ taking issue with is people (and don't take this as a personal
insult) making knee-jerk remarks about the security or otherwise of certain
solutions which are, IMNSHO, wrong.
I hear that NAT one quite a lot. I haven't yet recanted on my claim above,
and I've made it a lot of times. I would hate to think that somewhere out
there is someone who read all the rhetoric that flew around on this thread
and decided that I was a moron and knew nothing about security.
Let me be frank - NAT _can_ be used as a firewall. Take a good look at a PIX
one day. Sure, it does some tricks, but the core of the device is built for
NAT. Although I always use filters for IOS "firewalls", they're only there
as defense in depth, double-check type things and don't really add anything
to the security.
[...]
> Now, if you want to add another
> posit/given/assumption/whatever that the
> NAT *implementation* also groks multi-connection protocols like FTP,
> then you've essentially created a stateful packet filter. If you add
> this posit, his and your statements become equivalent, and I
> agree with
> you that you get the same effect as a "dumb stateful packet filter".
> But that's going very far afield to *define* all that as NAT, and I
> would then disagree with you on that semantic point...
I don't actually care much for active FTP, so I'm happy to have my imaginary
site use passive FTP and not know about real FTP. It's more secure that way,
anyway.
> Moreover, my post was arguing (perhaps not explicitly enough) in
> practical terms against using NAT in this way, as a matter of Expert
> Security Guy practice. If you had clients to firewall, and your
> customer's only requirement was for them to be protected
> while only they
> initiate connections, would you take your Check Point, PIX,
> or whatever,
> and simply set up the many-to-1 NAT, an any-any-any-permit
> rule, and be
> done with it?
Uh, a PIX is a bad example - that's actually exactly what you'd do. 8)
Your point, however, is perfectly valid and quite correct. Defense in depth
is a good principle for this sort of thing. Bear in mind, though, that the
whole point of defense in depth is to cover you against things that "can't
happen" in theory. That makes defense in depth just as important whether
your primary barrier is NAT or a FW-1.
[...]
> IOW, you may
> be able to drive nails with your forehead, a dead cat, or last month's
> half-eaten baguette, but why not use the hammer lying next to you?
>
> Michael
Sometimes all you have is that cat.
A realistic and accurate assessment of the security of any solution is
critical. Anti-NAT propaganda makes it less likely that assessments will be
accurate. This is me saying that NAT is very secure - it's me saying that
it's more secure than many people claim.
Cheers,
--
Ben Nagy
Network Security Specialist
Marconi Services Australia Pty Ltd
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
