Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Access Control Lists

High-level overview of ACLs, primarily in a Cisco context.
by

Russell Wiegand

on 19 February 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Access Control Lists

{ ACL
Access Control List permit or deny network traffic based on a list of rules basic ACLs are simple
the only rules are source IP filters access-list number {permit|deny} {sourcehost|sourcenet hostmask|any} extended ACLs are more complex (and more powerful)
rules cover source and destination IP, protocol, source and destination port, and several other parameters access-list [dyanmic dnynamic-name [timeout minutes]] { } permit
deny { } <100-199>
<2000-2699> { } host sourceIP
sourceNet hostMask
any lt
gt
eq
neq

range } ahp
eigrp
esp
gre
icmp
igmp
ip
ipinip
nos
ospf
pcp
pim
tcp
udp
<0-255> only for TCP & UDP <0-65535>
service-name { } { } <0-65535>
service-name <0-65535>
service-name { } host destinationIP
destinationNet hostMask
any { } <0-65535>
service-name lt
gt
eq
neq

range only for TCP & UDP { } { } { } <0-65535>
service-name <0-65535>
service-name { } <0-255>
ICMP-message-type [{ }] <0-255>
ICMP-message-code only for ICMP [IGMP-message-type] only for IGMP [established] [precendence precendence][tos tos][time-range time-range-name][fragments][log [word] | log-input [word]] The syntax is VERY Catch all that? Do we really need to know *all* of this? Well, we could look at a slightly simplified version... access-list number {deny|permit} protocol source destination only for TCP This is much easier to understand. access-list 101 permit tcp host 10.10.10.7 host 10.13.10.4 eq www Now that we know the syntax,
how do we define a rule? Let's start with a simple example.
10.10.10.7 is our user
10.13.10.4 is a web server
In order to allow connectivity, add this rule: This defines our access-list.
What do we do with it? An ACL gets applied to an interface using the ip access-group command ip access-group {access-list-name | access-list-number} {in | out} Where should we add this configuration?

According to the syntax, we can apply it in or out.
It is generally better to filter traffic as early as possible.
By applying our ACL on the inbound interface, we make all permit/deny decisions before the router does any other processing of that traffic. access-list 101 permit tcp host 10.10.10.7 host 10.13.10.4 eq www

interface Vlan101
ip access-group 101 in interface Vlan101
description Users
ip address 10.10.10.1 255.255.255.0
ip access-group 101 in

interface Vlan103
description LDAP servers
ip address 10.10.13.1 255.255.255.0
ip access-group 103 in

interface Vlan107
description WWW servers
ip address 10.13.10.1 255.255.0.0
ip access-group 107 in ACLs are rarely that simple... Our rules:
Let users access web servers for www traffic

Let web servers send TCP 389 queries to LDAP servers

Don't let users and LDAP communicate directly. access-list 101 permit tcp any 10.13.0.0 0.0.255.255 eq www access-list 107 permit tcp any 10.10.13.0 0.0.0.255 eq 389 access-list 103 deny ip any 10.10.10.0 0.255.255.255 Don't you mean 255.255.0.0 ? Wildcard mask ACLs utilize wildcard masks, rather than subnet masks.
(Don't ask why, unless you want a lot of speculation...)

Wildcard masks, also know as hostmasks or inverse masks, indicate what portions of an IP address to ignore while matching.

In their simplest form, the misnomer "inverse mask" is correct, since a wildcard mask is often a binary inverse of a netmask.

Looking at a single octet, 255 is 11111111, its inverse is 00000000 or 0.
192 is 11000000, its inverse is 00111111 or 63. (notice 255 - 192 = 63)
For a netmask of 255.255.192.0, the wildcard mask is 0.0.63.255

Wildcard masks, unlike netmasks, do *not* require consecutive ones.
Netmasks may contain only 0, 128, 192, 224, 240, 248, 252, 254 and 255
Wildcard masks may contain any value 0-255, although it can be more difficult to figure out what the other numbers mean. By the way, these don't work! access-list 101 permit tcp any 10.13.0.0 0.0.255.255 eq www Our rules:
Let users access web servers for www traffic

Let web servers send TCP 389 queries to LDAP servers

Don't let users and LDAP communicate directly. access-list 107 permit tcp any 10.10.13.0 0.0.0.255 eq 389 access-list 103 deny ip any 10.10.10.0 0.255.255.255 Why? We forgot about return traffic
and implicit denies... By default, every ACL ends with a hidden statement:

Any traffic that doesn't match an earlier rule is dropped. deny any any permit tcp any any established By default, every ACL ends with a hidden statement:

Any traffic that doesn't match an earlier rule is dropped. A session needs a permit statement to be allowed. Once established, we can allow subsequent communications by using an 'established' keyword. It is easy to start every ACL with this statement:
Full transcript