Cheers, Ben. <raises glass>
> > NAT definitely does not add *fine* security. IMHO, it doesn't
> > help you any
> > more than a stateful packet filter.
>
> I'd argue that, in theory, it also doesn't help you any less. I'm more or
> less happy to use just NAT for low threat sites. I usually configure
> filtering rules as well, but they're only there to keep me in the habit.
>
True, to perform NAT you need to do the same as in a stateful packet filter,
so they're pretty much equal in potential protection. However, what is more
important than the technology itself is how it is implemented. Here, NAT and
statefuls are still equal, but from the little experience I have, it seems
like NAT is very often configured in an "everything from the inside is
allowed out, we don't restrict inbound, since that'll get dropped anyhow by
the NAT".. Could be that many statefuls are configured that way as well, but
it's definitely not along the "deny everything and only allow what you need
to" track. I would still place filtering rules on the outside interface, no
matter what. Maybe that's overdoing it, I dunno, but it makes me feel
better--is that already on the same level as the warm fuzzies the
pointy-heads get?
And I am rather suspicious that the post that set this thread off is talking
about a "NAT as the only form of security" approach, with a configuration of
the sort I describe above.
> > both need special code to
> > handle non-NAT-friendly protocols, such as FTP, etc. That's
> > the first place
> > that's compromisable.
>
> But that's not an argument against NAT - it's an argument against bad
> code.
> FTP is always going to be a stupid protocol, and people are always going
> to
> have to do stupid things to get it to work. FTP has led to people making
> errors in NAT, packet filters and ALGs.
>
True, but it's more difficult to get right in statefuls and NAT. Add to that
that ALGs are often written with security in mind, while that can't be said
of NATs, as they are focussed on making connectivity available. This is true
of Linux IP Masquerading, IMHO, at least, the NAT implementations of
firewall manufacturers should put more emphasis on security, but the track
record isn't as comforting as it could be...
> > Additionally, most of the time NAT is
> > performed on the
> > firewall itself, which means that the firewall must accept
> > packets destined
> > to itself. I have a general creepy feeling about that...
>
> You should install more ALG style firewalls, then. ;)
>
> (There's nothing inherently bad about the firewall accepting packets
> destined to itself)
>
Agreed, the key word being 'inherently' here. I don't generally favour the
one-box solution, so I try to design firewall systems with choke routers
(aka paket filters) and separate ALGs (on 'hardened' hosts with packet f
iltering, etc. in place) in one or more DMZs. This may be overkill for a
small shop, in which case I'd probably use OpenBSD or Linux on an x86
platform and use packet filtering in conjunction with ALGs. As for packets
being addressed at the firewall, I still kind of hope that authors of
security proxy code place more of a focus on security than an IP
Masquerading module coder.
> > And
> > there have been
> > examples of NAT implementations being buggy
>
> And SPFs aren't shipped buggy, right? C'mon. I _know_ you know better than
> that.
>
No, they're identical there. Actually, you could have replaced 'NAT' with
'NAT and SPF' in my original post.
> > the outside. Bottom line: NAT is a weak element of security.
>
> None of your arguments support your conclusion here, sorry. You may as
> well
> say that stateful filtering is a weak element of security.
>
> Of course, if you _are_ saying that, I apologise, and agree.
>
Well, I'm not saying that flat out. I am of the opinion that SPF/NAT alone
does not provide the level of security I prefer. I prefer to use ALGs
wherever possible (and only as long as I trust the ALG, of course). NAT/SPF
have their place in the big picture and I'd definitely use them as *one*
element of security in a firewall system. As always, the strength of a
solution lies very much in its implementation and I see NATs being
misconfigured more often than not, from a security point of view. I may have
gone over the edge or at least rather close to it in my last post, but this
is the reason I advise against NAT as a (or often the only) security measure
when newbies ask about it.
> I'm not picking on you here,
>
And you don't sound it. Your input is very welcome, your posts are among
those I have come to respect in this list and I'm all for meaningful (for
lack of a better word) discussions.
> but this argument has come up a few times
> before, and people tend to fire off their "NAT is not secure" opinions
> knowing that they're accepted wisdom.
>
> Well, nobody has ever proved it to me, so I _don't_ accept it. ;)
>
All of your points well taken. And there is some security in NAT that
shouldn't be disregarded. However, there is also a lot of mumbo-jumbo flying
around with mostly non-experts (can you say vendors of 'cheap' 'solutions')
claiming that NAT is the magic bullet that will make your network safe.
In any case,.. um.., yeah, that's it.
Tobias
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
