Basic ACL Question - Outbound Traffic

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

------------------------------------------------------------------------------------

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

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

"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 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, 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).

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