At 19:23 21/02/01 -0500, Anthony Teelucksingh wrote:
>NAT, as a concept, offers fine security. If you can't route to the internal
>network, you can't reach the internal network.
"If you can reach them, they can reach you".
If it's just for denying what is not part of a legitimate session, the best is
to use a stateful filter.
NAT should be avoided for all the problems it introduces. It breaks too many
protocols (see the draft/RFC about commplications created by NAT).
It creates administration burden.
It doesn't map addresses/ports that are inside data (except for some few
protocols): Received lines in smtp messages, private addresses that may
go in http cookies, forms or anything like that,...
One of the classical problems is:
you see a log from your filter stating that a packet with destination=10.1.2.3
is denied. Is this a packet that someone tried to send to 10.1.2.3 or was it
going to a public addr and NATed to 10.1.2.3? if so, what was the original
destination? to find it, you need to check NAT logs, but these may be huge
and are generally unavailable.
a related one is that if you have a setup like the following:
Inside ---- FW ---- NAT router ---- internet
and you configure the NAT router to convert 10.* to say 1.2.3.4. then you can't
configure your FW to deny 10.* (a classical anti-spoofing measure). The FW no
more knows the original destination address of the packet.
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
