Options

Really struggle with access lists!

Jas21Jas21 Member Posts: 51 ■■□□□□□□□□
I don't know why! It seems so simple, and yet every practice question becomes really difficult........

Are there any good sources of material for nailing the concept of ACL's, access groups, and where and when they should be applied etc.?

Thanks in advance

Comments

  • Options
    YFZbluYFZblu Member Posts: 1,462 ■■■■■■■■□□
    I thought CBT nuggets was a nice high-level explanation of ACL's.

    I have sort of a weird way of remembering ACL group placement. Think of Standard ACL's as an inaccurate weapon, such as a shotgun - In order to use it effectively, you have to be up close. Place Standard ACLs as close to the destination as possible. The reason is because Standard ACL's only inspect for the source IP address, so you don't want to block more traffic than you need to. Conversely, an Extended ACL is a very precise weapon, such as a sniper rifle. You use Extended ACL's as far from the destination host as possible. The reason for this is because you don't want to allow more traffic through the network than you need to. Why saturate bandwidth if the packet is just going to be dropped by a router in the long run?

    .02
  • Options
    Jas21Jas21 Member Posts: 51 ■■□□□□□□□□
    That's a nice way of looking at it, thanks. I think I need to re-visit Jeremy's CBT's!!! :)
  • Options
    pseniorpsenior Member Posts: 28 ■□□□□□□□□□
    The IOS IPv4 Access List **** sheet at packetlife.net helped my understanding greatly. You may want to check it out at http://media.packetlife.net/media/library/14/IOS_IPv4_Access_Lists.pdf. Other than that, I liked the Lammle book and I did ACL labs and practice questions over and over again until the concepts made sense.
  • Options
    Ltat42aLtat42a Member Posts: 587 ■■■□□□□□□□
    Try using association with ACL's. Standard ACL goes close to the destination, Extended ACL goes close to the source.

    Standard/Destination - Ends & begins with a "D" (or a "Double D")

    Extended/Source - Begins & ends with an "E"

    hth
  • Options
    Ltat42aLtat42a Member Posts: 587 ■■■□□□□□□□
    Oh....cardinal rule, you have to "permit" as least 1 thing, if not, everything will be denied.
  • Options
    Jas21Jas21 Member Posts: 51 ■■□□□□□□□□
  • Options
    docricedocrice Member Posts: 1,706 ■■■■■■■■■■
    I love access lists. I spend every day working on either static packet filters (IOS standard and extended ACLs) or ASA stateful inspection ACLs or configuring iptables or looking at Snort rules.

    But when you're starting out, it takes a while to "get it" as well as the syntax convention and ordering. If you think standard and extended ACLs are a bit confusing, wait until you get into named ACLs, then reflexive ACLs where you start learning about state, timeouts, etc., and even using ACLs for matching against "interesting traffic" for IPsec tunnels.

    One thing I wish Cisco really drilled on when discussing access lists are the fundamentals of packet header structure. The CCNA doesn't really get into this at all, but I think in the long run it really helps to know what a layer 3 / 4 (IP vs. TCP / UDP) header looks like and what parts IOS looks at when inspecting a given packet coming in (or going out) of an interface.

    For example, if you do a permit statement for address source "any" and destination port 80, wouldn't it clarify things a bit if you knew that the router is really trying to match against IP header byte offset 12 (where the source IP is located) and TCP header byte offset 2 (destination port), respectively? These values don't exist in a vacuum. Every filtering device that is processing packets against some kind of access list has to check specific places in the headers.

    Another example - say you're doing a router ACL for passing IPsec traffic to another tunnel endpoint (say, ESP). You'd do something like "permit esp host 1.2.3.4 host 5.6.7.8" and this is where the router has to look at IP header byte offset 9 to check the protocol field (in this case of ESP, that's protocol 50, whereas TCP would have been 6). Something that a lot of people miss is specifying source port. For IPsec ISAKMP, you can do "permit udp host 1.2.3.4 eq 500 host 5.6.7.8 eq 500"; in this case, the UDP traffic for IKE uses port 500 for both source and destination. You usually don't see symmetric port usage. Normally for someone surfing the web from your inside network, you can do "permit tcp 10.0.0.0 0.0.0.255 gt 1023 any eq 80."

    Hope that helps a bit. Or maybe it just made things more confusing. Like anything else, it takes practice.
    Hopefully-useful stuff I've written: http://kimiushida.com/bitsandpieces/articles/
Sign In or Register to comment.