On Thu, 22 Feb 2001, mouss wrote:
> "If you can reach them, they can reach you".
this is very true, and often overlooked. without some sort of outbound
check on traffic, a trojan horse could initiate an outbound connection and
give up control to an outside party.
> 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,...
i will agree with you about SMTP messages and HTTP session info (please
see http://www.crimelabs.net/docs/passive.html for some of my toughts on
this matter).
however, i will say this: only the most poorly designed protocols actually
stick header data (ie source/dest addresses) in the payload of a packet.
as such, i think you're argument about an 'administration burden' is weak
here. if you have an ICQ hangout, or a printing haven and they're behind a
NAT box, you are right. for a bunch of workstations browsing the net,
using email, NAT works wonders. most corporate or lab environments are
great examples of this.
most items that don't play well with NAT can use a proxy like SOCKS5. when
used in conjunction, almost every common protocol works just fine behind a
NAT firewall.
____________________________
jose nazario [EMAIL PROTECTED]
PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80
PGP key ID 0xFD37F4E5 (pgp.mit.edu)
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
