I STRONGLY recommend that you *should* do it this way.
Your stance should not be "What new threats am I going to have to
block against today?", but rather "What are the implications of
allowing this new access some user wants?"
i.e. Deny all, and then allow what your policy says you must. DO
NOT allow all, and then try to block things that have turned out to
be problems.
David Gillett
On 5 Jun 2001, at 12:10, Grounds, Adam M wrote:
> sure.. if you want an implicit 'deny all' to start with use:
> outbound 150 deny 0 0 0
> apply (inside) 150 outgoing_src
>
> this'll kill everything outgoing, and you'll have to use outbound <#>
> excepts or a seperate list to override.
>
> but there is a weird sort of order that has to be followed.. here is an
> example from one my old configs from back in the day:
> outbound 150 permit 0.0.0.0 0.0.0.0 0 tcp
> outbound 151 deny 64.124.41.0 255.255.255.0 0 ip
> outbound 151 deny 208.178.163.56 255.255.255.248 0 ip
> outbound 151 deny 208.178.175.128 255.255.255.248 0 ip
> outbound 151 deny 208.49.239.240 255.255.255.240 0 ip
> outbound 151 deny 208.49.228.0 255.255.255.0 0 ip
> outbound 151 deny 208.184.216.0 255.255.255.0 0 ip
> outbound 151 except 216.104.23.24 255.255.255.255 0 ip
> outbound 151 except 206.113.132.134 255.255.255.255 0 ip
> outbound 151 except 216.104.23.237 255.255.255.255 0 ip
> outbound 151 except 216.104.23.56 255.255.255.255 0 ip
> outbound 152 deny 169.254.0.0 255.255.0.0 0 ip
> apply (inside) 152 outgoing_src
> apply (inside) 150 outgoing_src
> apply (inside) 151 outgoing_dest
>
> group 150 here allowed all my users to start outbound tcp connections to
> wherever they want
>
> group 151 is an explicit set of denys for specific targets (in this case
> these are for napster) - note the exceptions for my old machine ip and a few
> people who bought me lunch!
>
> group 152 is an explicit deny for an outbound connection for a subnet (in
> this case for DHCP clients that have no ip) - and it has to be a seperate
> group number too..
>
> to tweak this out for your use you'll change 151 to have an outbound like
> this:
> outbound 151 deny 0.0.0.0 0.0.0.0 6667 tcp (6667 is for one of the IRC
> listeners in this example)
>
> that should do it!
>
> -----Original Message-----
> From: Ivan Lopez, TRI [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 05 June, 2001 11:51
> To: Grounds, Adam M
> Cc: Ariel Jimenez, TRI
> Subject: RE: PIX - how to restrict IRC, MS MESSANGER
>
>
> Thanks,
> We're using conduits, not access-lists, Is there some sort of "implicit deny
> all" that I should take into account if I configure the "outbound/apply" ?
>
> -----Original Message-----
> From: Grounds, Adam M [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 05, 2001 12:51 PM
> To: 'Ivan Lopez, TRI'; Firewalls (E-mail)
> Subject: RE: PIX - how to restrict IRC, MS MESSANGER
>
>
> are you using straight conduit commands or access-lists?
>
> for conduit-based commands you'll need to use the "outbound/apply" commands
> to control access
>
> for access-lists, you can use "access-list inside deny"
>
> -----Original Message-----
> From: Ivan Lopez, TRI [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 05 June, 2001 11:27
> To: [EMAIL PROTECTED]
> Subject: PIX - how to restrict IRC, MS MESSANGER
>
>
> How can I configure the PIX to restrict users from using irc, icq and MSN
> Messenger?
>
> IRC: 6665-6669, 7777
> ICQ: 1023, 1024, 1025, 4000
> MSN Messenger: 1863
>
> I tried using conduit deny commands for these ports, but does not seems to
> work.
>
> Iv�n L�pez
>
>
>
>
> This email and any attachments hereto, contain confidential and
> privileged information intended only for the addressee. Please
> do not read, copy or disseminate it, unless your are the
> addressee. If this email is received in error, please notify
> TRICOM immediately at (809) 476-4146. TRICOM disclaims all
> responsibility from and accepts no liability for any unauthorized
> person acting, or refraining from acting, on any information
> herein contained.
>
> Este email y cualquier anexo al mismo, contiene informaci�n
> privilegiada y confidencial dirigida solo al destinatario. Por
> favor no lo lea, copie ni distribuya, a menos que sea el
> destinatario. Si recibe este email por error, por favor notifique
> inmediatamente a TRICOM al (809) 476-4146. TRICOM no es
> responsable por la acci�n u omisi�n en base a la informaci�n
> contenida en este email, de cualquier persona no autorizada.
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
>
> This email and any attachments hereto, contain confidential and
> privileged information intended only for the addressee. Please
> do not read, copy or disseminate it, unless your are the
> addressee. If this email is received in error, please notify
> TRICOM immediately at (809) 476-4146. TRICOM disclaims all
> responsibility from and accepts no liability for any unauthorized
> person acting, or refraining from acting, on any information
> herein contained.
>
> Este email y cualquier anexo al mismo, contiene informaci�n
> privilegiada y confidencial dirigida solo al destinatario. Por
> favor no lo lea, copie ni distribuya, a menos que sea el
> destinatario. Si recibe este email por error, por favor notifique
> inmediatamente a TRICOM al (809) 476-4146. TRICOM no es
> responsable por la acci�n u omisi�n en base a la informaci�n
> contenida en este email, de cualquier persona no autorizada.
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
