Access Control Lists - What Don't I Understand

Discussion in 'Cisco' started by John Steele, Jul 11, 2005.

  1. John Steele

    John Steele Guest

    I must be missing something. I have an Extended ACL on the Serial IN for our
    2620. This ACL has "Permits" for a number of specific ports and functions.
    The ACL ends in "deny IP any any". One would think that this would block
    everything that isn't specifically permitted.

    But for some reason a ACL that we left on the Ethernet OUT continues to
    catch things. For example this ACL has a "deny TCP any any eq 3389 log"
    statement and it shows that it has caught several packets coming through
    since the last reset. Similarly the "deny tcp any any eq 445" shows accesses
    even though in both cases they are not on the permitted list for the ACL on
    the Serial IN.

    Am I missing something? I thought I understood this stuff.
     
    John Steele, Jul 11, 2005
    #1
    1. Advertisements

  2. John Steele

    Uli Link Guest

    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.

    <- Interface1 (Int1/out)<- Routing engine (Int2/in)<- Interface2 <-
    -> Interface1 ->(Int1/in) Routing engine ->(Int2/out) Interface2 ->
     
    Uli Link, Jul 11, 2005
    #2
    1. Advertisements

  3. 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.
     
    Barry Margolin, Jul 12, 2005
    #3
  4. John Steele

    John Steele Guest

    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?
     
    John Steele, Jul 12, 2005
    #4
  5. John Steele

    Uli Link Guest

    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.
    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.
     
    Uli Link, Jul 12, 2005
    #5
  6. John Steele

    John Steele Guest

    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, Jul 12, 2005
    #6
  7. John Steele

    Uli Link Guest

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

    Only a look through the complete acl can show more.
     
    Uli Link, Jul 12, 2005
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.