Access Control Lists - What Don't I Understand

John Steele schrieb:

10- access-list 199 permit ip host 10.20.30.40 any 20- access-list 199 deny udp any eq 554 any 30- access-list 199 permit tcp any any eq 80 40- access-list 199 deny any any

An ACL is checked in sequential order from top to bottom. If the source/target clause matches the action (permit or deny) takes place and the check is exit. If source/target clause not matches the next entry is checked. The last entry (wether you specify it for explicitness or not) is always a "deny ip any any". If your last line is "permit ip any any" this second last line will catch all, so the implilicit deny any any will never be reached.

In my example a http request coming from 10.20.30.40 will match line 10. -> Stop Probably a cause of mistake. To generic, http should only match line 30.

A http request from 10.20.30.41 won't match line 10 -> Next -> Not from upd port 554 -> Next -> Line 30 matches, permit -> Stop

The direction an ACL is applied to an interface is *not* a dataflow direction from LAN to WAN.

Without seeing the ACLs in question and the log messages, it's difficult to tell what you did wrong.

One possibility is that the packets aren't coming in through the serial interface in the first place.

Uli

Thanks for your reply. I understand what you are saying and I THOUGHT that's what we had done.

I have an extended ACL assigned to the Serial WAN input from the T1. This ACL is managed by "SnortSam" and is partially dynamic in that SnortSam adds/deletes absolute IP addresses to be blocked (deny IP host xxx.xxx.xxx.xxx any). These blocks occur at the "top" of the ACL. This ACL is the one that has a limited number of "permits" for known acceptable actions such as specific IP addresses granted unlimited access, all IPs granted access on port 25 to the SMTP, all IPs granted access to Port 80 on two machines running web servers, etc. This ACL ends in an explicit "deny IP any any" just for good measure even thought as you note it is implied anyway.

I also have a static extended ACL assigned to the Ethernet output to the LAN. This ACL is the one that is catching accesses such as port 3389, port

445, etc. And this is the one hat I would have thought to be superfluous given the input side ACL implicitly denies these ports anyway.

Are the ACLs applied in some order other than the sequence of data flow? One would think that on data coming from the WAN the 'snortsam_acl' would be encountered first and then the ACL 110 on the Ethernet Out would be encountered next. If that's the case why does the explicit "deny IP any any" statement in "snortsam_acl" not simply stop everything not specifically permitted in ACL?

Uli

Thanks again. But I think I understood much of this already.

I realize that processing of the ACL will stop when a permit or deny is matched, otherwise it will continue on to the bottom of the ACL and encounter the implicit (or in my case explicit) deny. The problem I am having is grasping why for example a hit on port 445 is happening in ACL 110 when there is no permit for anything involving port 445 in snortsam_acl.

There is no mention of port 445 in snortsam_acl so nothing involving port

445 should be getting past the explicit "deny IP any any" at the end of snortsam_acl --- references to port 445 should die at the end of snortsam_acl. But for some reason they are passing through snortsam_acl and being trapped by the explicit "deny TCP any any eq 445" in ACL 445. I do not understand why this is the case.

I'd actually prefer to keep everything in one ACL at the earliest point in the data flow and I had thought that this is what snortsam_acl was doing by allowing only selected things through and blocking everything else. But that does not appear to be what is happening, hence ACL 110 remains in place on the Ethernet out to the LAN

John

John Steele schrieb:

Makes your config more readable.

If you want to deny traffic to target port 3389 a "access-list 155 deny udp any any eq 3389" must be placed before any entry with "access-list 155 permit ip any any"

If you allow "access-list 155 permit ip host 10.20.30.40 any" before, a request from

10.20.30.40 to udp 3389 will be allowed and processing is stopped. The closing deny ip any any isn't reached.

Yes.

Because processing of "snortsam_acl" stopped stopped before by matching an entry with a permit action.

Else if a match with a deny action occurs, nothing will hit the Ethernet outbound acl.

I would not apply 2 acl on different interfaces for filtering dataflow in the same direction ( here: from WAN to LAN ) if the same can be achieved by a single acl.

Search for a "permit ip xxxx any" or "permit tcp xxxx any"

Only a look through the complete acl can show more.