«

Howdy,

On a PIX515 6.3
It is my understnading that Outbound traffic is allowed by default.

This ACL allows outbound traffic, i.e. SMTP to an Internet mail server.

access-list acl_collector permit icmp any any
access-list acl_collector permit ip any any
access-list acl_collector permit tcp 192.168.10.0 255.255.255.0 any eq
ssh
access-group acl_collector in interface collector


This ACL DOES NOT allow outbound traffic, i.e. SMTP to the same
Internet mail server.

access-list acl_collector permit icmp any any
access-list acl_collector permit ip any any
access-list acl_collector permit tcp 192.168.10.0 255.255.255.0 any eq
ssh
access-group acl_collector in interface collector

What am I missing here? If I have this correct then the "ip any any"
rule is OK or should it be set to "ip local_interface_subnet any"?

Thanks,
Dan Foxley

"Dan Foxley" <> wrote in message
news: oups.com...
> Howdy,
>
> On a PIX515 6.3
> It is my understnading that Outbound traffic is allowed by default.
>
> This ACL allows outbound traffic, i.e. SMTP to an Internet mail server.
>
> access-list acl_collector permit icmp any any
> access-list acl_collector permit ip any any
> access-list acl_collector permit tcp 192.168.10.0 255.255.255.0 any eq
> ssh
> access-group acl_collector in interface collector
>
>
> This ACL DOES NOT allow outbound traffic, i.e. SMTP to the same
> Internet mail server.
>
> access-list acl_collector permit icmp any any
> access-list acl_collector permit ip any any
> access-list acl_collector permit tcp 192.168.10.0 255.255.255.0 any eq
> ssh
> access-group acl_collector in interface collector
>
> What am I missing here? If I have this correct then the "ip any any"
> rule is OK or should it be set to "ip local_interface_subnet any"?
>
> Thanks,
> Dan Foxley
>

Dan,

Those two ACL's look identical to me. What is supposed to be different?

permit icmp any any
permit ip any any
permit tcp 192.168.10.0 255.255.255.0 any eq ssh
acl_collector in interface collector

Anyway, the 'permit ip any any' will allow that SSH traffic so the ssh line
isn't required. And yes, that will allow all IP traffic so why would you put
that acl on the interface anyway?

Chris.

Oops. It should have been as below. I thought all traffic is allowed
going out a lower security interface by default? These ACL's don't
allow outbound traffic to the Internet. If I do leave "permit IP any
any" what is blocking unwanted traffic? Only the "static" that is in
place?
-------------------------------------------
This ACL DOES NOT allow outbound traffic, i.e. SMTP to the same
Internet mail server.


access-list acl_collector permit icmp any any
access-list acl_collector permit tcp 192.168.10.0 255.255.255.0 any eq
ssh
access-group acl_collector in interface collector
------------------------------------------------------------------------------------
Thanks,
Dan Foxley

<> wrote in message
news: oups.com...
> Oops. It should have been as below. I thought all traffic is allowed
> going out a lower security interface by default? These ACL's don't
> allow outbound traffic to the Internet. If I do leave "permit IP any
> any" what is blocking unwanted traffic? Only the "static" that is in
> place?
> -------------------------------------------
> This ACL DOES NOT allow outbound traffic, i.e. SMTP to the same
> Internet mail server.
>
>
> access-list acl_collector permit icmp any any
> access-list acl_collector permit tcp 192.168.10.0 255.255.255.0 any eq
> ssh
> access-group acl_collector in interface collector
> ------------------------------------------------------------------------------------
> Thanks,
> Dan Foxley
>

Ah, now it makes more sense. As you say, with no acl in place and NAT
configured correctly traffic from a high security interface to a lower one
(eg inside to outside) is permitted. However, once you apply an acl then all
traffic is checked against that acl. So, you have,

permit icmp any any
permit tcp/ssh from 192.168.10.0/24 to any

But, remember that on the end of every acl is a 'deny ip any any'. So, as
you haven't allowed SMTP in the acl then it will be blocked by the implicit
deny all at the end of the acl.

Chris.

Chris,

Awesome. So, If I have NO ACL's on an interface I can get from Higher
to Lower w/o issue (as Long as NAT & Global are configured) - BUT as
soon as I apply ANY ACL to an interface, ALL traffic has to be defined
in an ACL EVEN Higher to Lower - Outbound?

Thanks,
Dan

<> wrote in message
news: oups.com...
> Chris,
>
> Awesome. So, If I have NO ACL's on an interface I can get from Higher
> to Lower w/o issue (as Long as NAT & Global are configured) - BUT as
> soon as I apply ANY ACL to an interface, ALL traffic has to be defined
> in an ACL EVEN Higher to Lower - Outbound?
>
> Thanks,
> Dan
>

Correct.

Thanks Chris. You've been very helpful.

Don't forget though, that you're responsible for all traffic leaving
your network, aware of it or not.

So having no outbound ACL on a PIX is not suggested (although works
fine and is the way its configured out of the box).

If at the very least its generally recommended to apply an ACL that
allows all internal networks to go out to anything, and deny all
others. This way someone can't spoof from your network.

But this is at the very least, generally you'll want to consider
exactly what you want to allow out, and deny the rest. This is a
security device, and most security devices should NEVER just permit ALL
traffic in any direction. The PIX is designed to act as protection in
BOTH directions, so if you take this shortcut, please just be aware of
the possible ramifications.

A good example of this is propagating viruses from your network to
others, or being hacked then becoming a gateway for others to be
hacked, etc. If you apply even a very simple ACL like I mentioned
above, it'll provide a MUCH higher level security than just leaving it
default.

Ryan

In article < .com>,
rdymek <> wrote:
>Don't forget though, that you're responsible for all traffic leaving
>your network, aware of it or not.

>So having no outbound ACL on a PIX is not suggested (although works
>fine and is the way its configured out of the box).

"configured out of the box" is only the case for the PIX 501 and 506/506E,
with new enough software [some 506's might be old enough not to have it.]
For all the other PIX models, although there is no access-group applied
"in" the inside interface, there is no default NAT set up, and traffic
is not allowed to flow until the user sets up NAT or static.


>If at the very least its generally recommended to apply an ACL that
>allows all internal networks to go out to anything, and deny all
>others. This way someone can't spoof from your network.

If you have no static, and no nat 0 access-list, then you can accomplish
the same thing by restricting your nat policies to only the network
addresses you are expecting to be inside. For example, instead of

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

you can use

nat (inside) 1 192.168.75.0 255.255.255.240
nat (inside) 1 192.168.75.80 255.255.255.252

which would permit out only 192.168.75.0 to .15 and .80 to .83

Mind you, this looks uglier in the logs

Walter Roberson wrote:

> "configured out of the box" is only the case for the PIX 501 and 506/506E,
> with new enough software [some 506's might be old enough not to have it.]
> For all the other PIX models, although there is no access-group applied
> "in" the inside interface, there is no default NAT set up, and traffic
> is not allowed to flow until the user sets up NAT or static.

Walter, you are 100% accurate when discussing NAT (prior to PIX v7.0),
but we were not discussing NAT at all, we were specifically discussing
the ACL method, and it is configured out of the box to permit all
outbound traffic (on ALL PIX models) and NAT is another discussion,
although as you mentioned, can be used in this manor. In PIX OS 7.0+
NAT is not required, and "out of the box" permits all traffic to flow
through the pix UN-NATed; without an ACL applied nothing would need to
be performed to permit everything outbound from your network (of course
private addressing won't be permitted through the Internet, but
nonetheless, will be allowed out).

>
> Mind you, this looks uglier in the logs

ACL's definitely tend to do a better job with logging as well as
security (this is a security appliance, so we should treat it like one,
and NAT should never be used in place of ACL's). With NAT you only
have control over the IP's, not the protocols or ports being used.
Industry standard would be to use both methods discussed (to only NAT
what you should be using), and also apply ACL's providing multiple
layers of security.

~Ryan