> [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.
>
> Once again (for like the MILLIONTH time) I invite anyone to
> to explain the additional security that filters provide over
> dynamic (many to one) NAT where there are no static NAT mappings
> or PAT mappings. I get to posit that the NAT implementation does
> not allow packets from the outside for the private inside range
> (unlike Cisco NAT ;).
>
> 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".
I took NAT to be defined in a precise sense, as the rewriting of any IP
addresses in the data stream and the recomputing of any associated
checksums. So for example, that allows an internal client in a
many-to-1 NAT to initiate a normal (i.e non-passive) FTP connection to a
server and establish the FTP command channel. But when the server
attempts to open the data channel back--*boom*--it socks up against your
posit that connections cannot come from outside, in.
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...
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? No, you wouldn't, and not just because it looks to the
customer like you didn't work hard for all the money they paid you. You
wouldn't do it because you're assuming the NAT implementation will
always work in the way you hope it does, with no surprises or
pathological edge cases. The Expert Security Guy doesn't _assume_
this. If you're implementing a fw for which you have source code and
don't have to assume, then maybe you do it that way, but I doubt it.
You also probably wouldn't get as detailed logging information, as if
you had explicit filtering permit/deny rules in use, for example. So my
second point was, don't do this as a matter of practice. 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
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
