Pere,
>1) Is there any way on the PIX to specifify
>dest-unreach:df-set-but-frag-needed only?
Yes. See the conduit command documentation. Specifically you can allow 18 different
types of ICMP messages using conduit on the PIX.
>2) Can anybody think of the security implications of allowing
>dest-unreach:* to the web servers (apart from a weird combo that would
>crash the server itself).
Is it important that the web server have routing info or the router? If you implement
any kind of multiple server load balancing scheme the info would need to get as far
as those boxes.
>3) Having an access-list that denies all outgoing (private-> internet)
>traffic (the web servers should never connect on their own to the
>internet, they only received connections), do you remember any ICMP
>traffic that should be allowed from the web servers to the internet?
Very arbitrary. Depends on your security policy and degree of assumed risk.
Regards,
Brian
>From: Pere Camps <[EMAIL PROTECTED]>
>Subject: conf: PIX and destination-unreacheables
>
>Hi!
>
> I'm currently using two Cisco PIXes (on failover) doing a very
>simple job: static NAT.
>
> Basically they do a static NAT for a public IP address and
>translate it to a private internal IP address.
>
> The access-list denies everything by default (because of the
>security levels) and the incoming access-list only allows port 80.
>
> I want to enable icmp:dest-unreachable messages to be forwarded to
>the private machines on one way only (ie: internet->private).
>
> So my question(s) are:
>
>1) Is there any way on the PIX to specifify
>dest-unreach:df-set-but-frag-needed only?
>
>2) Can anybody think of the security implications of allowing
>dest-unreach:* to the web servers (apart from a weird combo that would
>crash the server itself).
>
>3) Having an access-list that denies all outgoing (private-> internet)
>traffic (the web servers should never connect on their own to the
>internet, they only received connections), do you remember any ICMP
>traffic that should be allowed from the web servers to the internet?
>
> Thanks!
>
>- -- p
Brian Ford
[EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
