Access Control Lists (Beyond Standard and Extended) · Access Control Lists (Beyond Standard and Extended)

Access Control Lists (Beyond Standard and Extended)

www.ine.com

Copyright © www.INE.com

Course Prerequisites and Assumptions » Prerequisite = CCNA ACL Videos » ACLs are used as a classification tool by many

different features…this course will concentrate on using ACLs purely for packet filtering.

Presenter

Presentation Notes

Our class today assumes that you’ve already learned about the basics of IOS Access-Lists from the CCNA Routing-and-Switching videos. As such it is assumed you already know the following: --- Differences between standard and extended ACLs. -- How to use, and interpret, wildcard masks -- How to configure and use Named Access-Lists - How to apply ACLs to an interface using the “ip access-group” command. - The difference between ACLs and ACEs (terminology) - I’m not going to spend any time on other features that can utilize ACLs for classification such as NAT, Class-Maps, etc as this class will purely concentrate on the formation/configuration of the ACLs themselves.


Agenda

»Using L4/ L5 Extensions in Access-Lists »Reflexive Access-Lists »Dynamic Access-Lists »Using Object-Groups with ACLs »Time-Based Access-Lists »Access-List Logging Options


Review Quiz #1

» Shown below are some examples of the first few IOS commands to configure various access-lists.

» Which of these, if completed, will only allow matching on the source IP address of a packet?

access-list 85 permit …….. A access-list 100 permit …….. B access-list 156 permit …….. C access-list 1450 permit …….. D access-list 2420 permit …….. E


Review Quiz #2 » Given the following access-list and topology, which of the statements are true?

None of these PCs will be able to reach the server. A All of these PCs will be able to reach the server. B Only PC-A and PC-C will be able to reach the server. C Only PC-A and PC-B will be able to reach the server. D Only PC-B will be able to reach the server. E

access-list 1 permit 150.75.1.0 255.255.254.254 interface FastEthernet0/0 ip access-group 1 in


Review Quiz #3

21.45.0.242 88.243.0.138 178.101.0.135

» The three IP addreses below share some common bits. Create a named, standard access-list called, “INE” that contains only a single ACE which will permit any packet from these source addresses and any other addresses matching only these common bits:

Using L4/ L5 extensions in ACLs

www.ine.com


Accessing Layer-4/ 5 ACL Options

» Extended ACLs provide ability to match on Layer-4 and/ or Layer-5 information.

» Must supply “TCP” or “UDP” keywords as top-level protocol.

Only L3 options are available.

L3-L5 options are available.


Matching on TCP/ UDP Port Numbers

»Session-Layer Port Numbers may be matched in a variety of ways: • eq 23 (matching on an exact port number that “equals” the supplied

value) • lt 1000 (matching on any value “less than” the supplied value). • gt 500 (matching on any value “greater than” the supplied value). • neq 20 (matching on any value “not equal to” the supplied value). • range 100-200 (matching on any value in the supplied range of

values).


How would you do this?

» Network Engineers within the Corporate Intranet should be able to open TCP sessions to devices within the Testing Lab.

» Deny any devices from within lab from init iating outbound TCP sessions to the Corporate Intranet.

Testing Lab

Corporate Intranet

200.1.x.x /16

Fast0/0 200.1.199.1 /30 A

Presenter

Presentation Notes

In this scenario, if one were to create a detailed spreadsheet of every single TCP application that could POSSIBLY be initiated from within the Testing Lab…and then create an ACL with multiple lines of ACEs in which each of those TCP destination port numbers are denied…that would certainly prevent outbound TCP sessions from being initiated by the Testing Lab devices. - But is there an easier way?


How would you do this? » When TCP segments are received on Fast0/ 0 as a response

from sessions init iated from within the Corporate Intranet, what will they all have in common?

Testing Lab

Corporate Intranet

200.1.x.x /16

Fast0/0 200.1.199.1 /30

TCP Flags=Sync TCP Flags=Sync+ACK

TCP Flags=ACK

TCP Flags=ACK All Subsequent Permitted Traffic

TCP Flags=Reset

A

Presenter

Presentation Notes

Wouldn’t it be nice if we could create an ACL with only a single ACE entry that matched on these two flags?


Solution #1

RouterA(config)#access-list 101 permit tcp any any ack RouterA(config)#access-list 101 permit tcp any any rst RouterA(config)#interface FastEthernet0/ 0 RouterA(config)#ip access-group 101 in

Testing Lab

Corporate Intranet

200.1.x.x /16

Fast0/0 200.1.199.1 /30

TCP Flags=ACK All Permitted Traffic

TCP Flags=Reset

A

Presenter

Presentation Notes

In this case we’ve created an ACL with two ACEs that are permitting only packets with either the TCP “Acknowledgement” or “Reset” flags set.


Solution #2

RouterA(config)#access-list 101 permit tcp any any established RouterA(config)#interface FastEthernet0/ 0 RouterA(config)#ip access-group 101 in

Testing Lab

Corporate Intranet

200.1.x.x /16

Fast0/0 200.1.199.1 /30

TCP Flags=ACK All Permitted Traffic

TCP Flags=Reset

A

Presenter

Presentation Notes

In this case we’ve created an ACL with only a single ACE that is permitting only TCP segment in the “Established” state…which means EXACTLY the same thing as TCP segments with either the TCP “Acknowledgement” or “Reset” flags set. -

Reflexive Access-Lists (IP Session Filtering)

www.ine.com


How would you do this?

» Network Engineers within the Corporate Intranet should be able to transmit any type of data to devices within the Testing Lab.

» If the Testing Lab is compromised, deny any devices from within lab from initiating outbound sessions to the Corporate Intranet.

Testing Lab

Corporate Intranet

200.1.x.x /16

Fast0/0 200.1.199.1 /30 A

Presenter

Presentation Notes

In the previous section, we were specifically concerned only with preventing Testing Lab devices from initiating TCP sessions. But now we’ve increased the scope to denying the lab devices from transmitting ANY data into the Corporate Intranet unless that data is IN RESPONSE to a request FROM the Corporate Intranet. - This includes things like UDP and ICMP or even Routing Protocol traffic. - Since these other types of packets don’t necessarily have any flags we can match on in the Layer-4 header…how can we do this without creating massively long lists of ACEs?


The Solution – Reflexive Access Lists » Reflexive ACLs monitor for permitted, outgoing data of any type.

Testing Lab Corporate Intranet

200.1.1.1/30 Fast0/0 200.1.199.1 /30 A

1 ICMP Echo-Request from 200.2.1.1 to 200.1.1.1 (IP Protocol = 1)

200.2.1.1

» Reflexive ACLs create a mirror-image of transmitted traffic which will be permitted upon return.

Permit from 200.1.1.1 to 200.2.1.1 (IP Protocol = 1) 2

3 ICMP Echo-Response from 200.1.1.1 to 200.2.1.1 (IP Protocol = 1)

» Reflexive entries expire after configurable timeout value.

4

Presenter

Presentation Notes

Expiration timer will be discussed in a moment. Value depends on the type of traffic seen.


Reflexive ACL Configuration (1)

» Create a Named, Extended ACL for monitoring egress traffic from trusted sources.

Testing Lab

Corporate Intranet

200.1.x.x /16

Fast0/0 200.1.199.1 /30 A

RouterA(config)#ip access-list extended EGRESS RouterA(config-ext-nacl)#permit ip any any reflect Mirror

Can be any name.

Presenter

Presentation Notes

Only named, extended ACLs can be used when creating Reflexive ACLs. - The name of “Mirror” in this context is the name given to the dynamic, reflexive ACL that is created. It could be any name you wish. -


Reflexive ACL Configuration (2)

» Create a Named, Extended ACL for monitoring ingress traffic from untrusted sources.

Testing Lab

Corporate Intranet Fast0/0 200.1.199.1 /30 A

200.1.x.x /16

RouterA(config)#ip access-list extended INGRESS RouterA(config-ext-nacl)#evaluate Mirror

Can be any name.

Name must match the name previously supplied after “reflect” keyword.


Reflexive ACL Configuration (3) » Apply both ACLs to interface facing untrusted networks.

Testing Lab

Corporate Intranet Fast0/0 200.1.199.1 /30 A

200.1.x.x /16

RouterA(config)#ip access-list extended INGRESS RouterA(config-ext-nacl)#evaluate Mirror

RouterA(config)#ip access-list extended EGRESS RouterA(config-ext-nacl)#permit ip any any reflect Mirror

RouterA(config)#interface FastEthernet0/ 0 RouterA(config-if)#ip access-group EGRESS out RouterA(config-if)#ip access-group INGRESS in


Reflexive ACL Timeout Values

»Reflexive ACLs have timeout values. A. Graceful TCP Close (2-segments seen with FIN flags): Timeout=5-secs B. TCP Reset: Timeout = immediate C. TCP packets no longer seen? Timeout = 300-seconds D. UDP, ICMP and all others? Timeout = 300-seconds after last packet seen.

»Changing the t imeout value. • Values for “A” and “B” above cannot be changed. • Values for “C” and “D” above can be changed per ACE or

globally.


Configuring Timeout Values

» Modifying Global Reflexive ACL Timeout value.

» Modifying Reflexive Timeout within ACE entries.

Presenter

Presentation Notes

The global timeout value here does not apply against TCP resets (which are deleted immediately) or TCP sessions that are gracefully closed (5-second expiration). - Remember, other “normal” ACE entries can also be added, deleted, or changed within your named access-list.


Monitoring Reflexive ACLs

»Before the dynamic entry is created by the reflexive ACL:

»After the Reflexive ACL entry is created:

Presenter

Presentation Notes

How can I tell exactly WHEN the reflexive ACL was created? - The only debug I could find to do this would be “debug ip access-list data-plane” but this doesn’t show you any details of the packet that caused the reflexive ACE entry to be created. Also, the debug is VERY chatty! Do NOT allow it to your console! - One could also accomplish this by adding the “log” keyword to the end of the ACE containing the “reflect” keyword. But this would only be valuable if your egress ACL (containing one-or-more “reflect” statements) did NOT contain any “normal” ACEs (without “reflect”). - More on logging of ACEs coming up.

Dynamic Access Lists “Lock and Key”

www.ine.com


The Objective…

Corporate Intranet

Internet

Fast0/0 A Project-X Temporary

Contractor

» You’ve hired a contractor for the next 3-months to work on Project-X.

» This project requires that the contractor be allowed access to certain devices/ subnets…but not others.

» Access should be denied after 5-minutes of inactivity, or an absolute timeout of 15-minutes.

Presenter

Presentation Notes

Green are items that the temporary contractor is allowed to access. Red are the items that are off-limits. - This is a small-scale topology, but imagine if we were talking about dozens of servers and access to dozens of subnets?


Solution #1

Authentication Server

Internet

Fast0/0 A Project-X Temporary

Contractor

» Every authentication request offloaded to a central authentication database.

» Might require manual configuration of each device.

Presenter

Presentation Notes

In this solution, if you already have an authentication server installed in your network it might just be easiest to add a new, temporary username/password on that server for the contractor. - But what if many/most of the devices don’t point to that authentication server? Now you’ll have to also configure all of those web servers, tftp servers, routers, etc to POINT to that authentication server before they allow local access. - How are you going to ensure that the permitted user loses his/her access after being idle for 5-minutes?


Solution #2 – Dynamic ACLs 1. User must first telnet to router.

1

I’ll allow that user to access those resources

for 5-minutes!

2

2. After successful authentication, Telnet session closed and dynamic ACL created on interface.

3. Dynamic ACL removed from interface after configurable, absolute-timeout (or idle-timeout) value.

15-minutes are up! User is no longer allowed!

3

Presenter

Presentation Notes

The absolution timeout value is a configurable value…however there is NO default. If you don’t configure it, once the security hole is opened for this user it will stay open forever!


Dynamic ACL Configuration (1) username bob password 0 projX username bob autocommand access-enable t imeout 5

Line vty 0 4 autocommand access-enable t imeout 5

Or…

Presenter

Presentation Notes

First step is to create a single username/password statement that will be used to “unlock” the dynamic ACL. - The autocommand option of “access-enable” is primarily for use with Dynamic ACLs. It allows the creation on a Dynamic ACL after successful user authentication. - The “access-enable” and “timeout” commands will not show up in the CLI help (?). You just have to remember these commands. - The “timeout” shown in this command is the idle-timeout value. This is optional. - You may configure more than one username/password command that has an “autocommand access-enable” associated to it, but only one user at-a-time may access your network through the Dynamic ACL. If another user attempts to Telnet into the router while the Dynamic ACL is in-place for User#1, the second user will see the message, “List#x <Dynamic ACL name> already contains this IP address pair” - Additionally you may configure other username/password pairs that do NOT have the “autocommand” option if you have network admins that will need to telnet into this router to administer/maintain it.


Dynamic ACL Configuration (2)

access-list 101 dynamic Project timeout 15 permit ip any 2.4.0.0 0.0.0.255 access-list 101 permit tcp any host 1.1.1.1 eq telnet ! line vty 0 4 login local Named ACLs can also be used.

Presenter

Presentation Notes

In this example, we’re using the Dynamic ACL to give the Project-X Contractor full IP connectivity to all resources within the 2.4.0.x/24 subnet. - ACL 101 may only have a single line of “dynamic” that can be named whatever you wish (“Project” was used in this case). - The “timeout” keyword in this ACL is the absolute timeout. Should be larger/greater than any idle-timeout you configured. - If you wanted to restrict this even further to either a group of host addresses, a group of different subnets, or a group of different TCP/UDP port numbers you’d need to reference Object-Groups within your ACL (covered later in this presentation). - At minimum, another (normal) line of ACL 101 must exist permitting Telnet traffic to the specified local router IP address. -


Dynamic ACL Configuration (3)

interface FastEthernet0/0 ip address 1.1.1.1 255.255.255.252 ip access-group 101 in ! interface FastEthernet0/ 1 ip address 1.2.1.1 255.255.255.252 !

Presenter

Presentation Notes

You apply the ACL to the interface in the usual way. - This must be defined as an “inbound” ACL on the interface that leads AWAY from your protected network/resources.


Monitoring Dynamic ACLs

»Before the Dynamic ACL is applied…

»After successful authentication…


Clearing Dynamic ACL Entries

» If you ever need to manually delete a Dynamic ACL entry:


Extending Dynamic ACL Entries » IOS command allows users to extend the life of

their Dynamic ACE by an additional 6-minutes;

Presenter

Presentation Notes

The user must re-initate the Telnet session to the router a second time before the absolute timer expires. If they do, they will be granted an additional 6-minutes. - As you can see, this IOS command cannot be applied selectively to different Dynamic ACLs. Its an all-or-nothing command.


Dynamic ACL Rules

» Cannot be used to provide different access rights to different users.

» Dynamic ACLs may use either an “idle-timeout” or “absolute-timeout” value.

» “autocommand access-enable” may be configured either; • At the “username” level • Within the VTY line

Presenter

Presentation Notes

Because you can only have a single ACE with the keyword “dynamic” this means you cannot use this feature to provide certain access right to “Bob” and different access rights to “Sally”. - Idle-timeout is not exact. Expires roughly 1-minute AFTER the time you set. - If using both an idle-timer and an absolute-timer…the idle-timer should be LESS than the absolute timer. - When the “autocommand” is applied against individual usernames, this allows you to have some users who can still Telnet locally into the router (network admins) and other users who may only temporarily telnet…just long enough to initiate a dynamic ACL. - If the “autocommand” is applied within the VTY lines, NOBODY will be able to maintain a telnet session into the router as ALL incoming Telnets will be terminated (upon successful authentication) and then all users will be subjected to the same Dynamic ACL.

Object Groups in IOS

www.ine.com


Object Groups

» Originally designed for Cisco ASA Firewalls » Command Syntax slightly different on IOS Routers than

ASA Firewalls » Object Groups simplify ACL management by grouping

similar “objects” together. • E.g. Public_Web_Servers Group

» Allows for more modular changes • A change to an Object Group dynamically affects all ACE’s referencing that group.

<output ommitted>

Presenter

Presentation Notes

I’ll only be talking about how to use, configure, and monitor Object Groups on Cisco Routers…not ASAs. - We’ve also seen that some features, like Dynamic ACLs…only allow you to create a single ACE. In this case, an object group can be used in that single ACE to match on several different things (that would normally require multiple ACEs).


Types of Object Groups in Routers

»Cisco routers provide two types of Object Groups: • Network Group: For defining IP Address-related objects • Service Group: For defining Protocols and Ports

Presenter

Presentation Notes

Network Group Type = Used to define things related to IP addresses such as host addresses, network addresses, a range of host addresses. - Service Group = Used to define everything else you would normally match within an ACL such as: ---Protocol Number (IP, EIGRP, TCP, etc) ---Port Numbers ---TCP Flags


Simplification with Object Groups (1)

» From this… 200.0.0.1

200.0.0.2

x.x.x.x

10.0.0.100

10.0.0.101

OK!!

OK!! NO!!


Simplification with Object Groups (2) » To this…

200.0.0.1

200.0.0.2

x.x.x.x

10.0.0.100

10.0.0.101

OK!!

OK!! NO!!

Presenter

Presentation Notes

LAB DEMONSTRATION - - In this example, if we ever need to add/delete/change any of the trusted hosts, we can simply modify the Object-Group without ever touching the ACE. - GOTCHA: When specifying a Port Number (UDP or TCP) by default it will be applied against the DESTINATION port number of matched packets. You must use the keyword of “SOURCE” to specify source ports.

Time-Based Access-Lists

www.ine.com


The Objective

» Employees should NOT be allowed to surf the Internet during work hours.

Corporate Intranet

Internet Fast0/0 A

2.2.x.x /16


The Solution: Time-Based ACLs

» Time-Based ACLs activate ACEs during times you define.

» Times defined within a global “Time-range” » May be periodic or absolute.

Corporate Intranet

Internet Fast0/0 A

2.2.x.x /16

Presenter

Presentation Notes

Periodic is appropriate when you want the time to be recurring over and over again. - Absolute is appropriate when you only need the ACL to be implemented once…during a single range of time (like JUST this Monday from 8am to 5pm and never again).


Time-Based ACL Configuration (1)

» Ensure your router/ switch has an accurate clock:

» Create a global t ime-range:

Presenter

Presentation Notes

It is advisable to use NTP for your clock source…but for a simple ACL like we need here (applied to only a single router) locally setting the clock will suffice.


Time-Based ACL Configuration (2)

» Decide on either absolute or periodic

Presenter

Presentation Notes

In this example, periodic would be most appropriate for our needs.


Time-Based ACL Configuration (3) » Complete the command by defining the time interval (s)

» Apply the time-range to your ACL

Presenter

Presentation Notes

Both named and numbered ACLs may use the “time-range” keyword.


Monitoring Time-Based ACLs

Access-List Logging

www.ine.com


Logging » ACE entries can be appended with Logging-related

keywords • Access-list x ………….log • Access-list x …………..log-input

» Logging allows for Syslogs to be displayed providing hit-counts and evidence of ACL activity.

» Logging forces packets matching ACE entries to be process-switched = increased CPU load.


Log and Log-Input Access-list 101 permit icmp any host 22.22.22.22 log

Access-list 101 permit icmp any host 22.22.22.22 log-input

Access-list 101 xxxxxxxxxxx log-input EmailServer Optional “cookie”

Presenter

Presentation Notes

Both the Log and Log-Input keywords will (by default) collect statistics against packets that matched the ACE, and display those statistics every 300-seconds by default. - Logging is NOT triggered by packets matching the “implicit deny”.


How often is logging displayed? (1) » Individual ACEs can have the “log” or “log-input”

keywords. » When an ACL is applied to an interface, syslogs are

generated: • Once every 5-minutes for packets matching a particular ACE. • If any log-enabled ACE in any ACL on any interface matches a

packet within one second of the init ial log message, the match or matches are counted for five minutes and then reported.


How often is logging displayed? (2) 5-minutes

1-second

ACE#2 match ACE#3 match

Syslog for ACE#1

Syslog for ACE#2

Syslog for ACE#3

ACE#1 match #2 ACE#1 match #3 ACE#1 match #4

Syslog for ACE#1 Initial ACE#1 match


Decreasing the Log Interval

» If you want logs for ACEs to be displayed MORE frequently than every 5-minutes…it can be done.

»Use caution…this INCREASES the CPU load.

Presenter

Presentation Notes

With this command, you define the number of “hits” that must take place before a syslog that matches an ACE is generated. - The larger the number (the more hits) the longer it will take for a syslog to display. - For example, if you used the number “10”, after ten packets matched an ACE then a syslog would be generated. If ten matching packets are happening every 2-seconds then you’ll see a Syslog every 2-seconds. - Notice that this affects ALL ACEs that contain the log or log-input keywords. No way to assign this to only CERTAIN ACEs.


Save my CPU!!!

»Even though logs for individual ACEs are only displayed every 5-minutes…EVERY packet that matches the ACE must be process-switched.

»This can result in heavy CPU load »How to reduce this?

Presenter

Presentation Notes

The verbiage of this command is a little misleading because it READS as if you are able to control how often syslogs are generated…and that is NOT what this is doing. - This command controls how often packets that match an ACE (with the “log” or “log-input” keywords) are allowed to be LEAKED by CEF to the CPU. - In this example, only a single packet is allowed to be “leaked” by CEF to the CPU every 500msecs. - If you have 100 ACEs, each with the “log” or “log-input” keyword you have no way of knowing WHICH matching packet will be the one that is sent to the CPU for process-switching. - Packets that are NOT process-switched (but rather CEF switched) will not count against “log” and “log-input” keywords and will never generate syslog messages.


Filtering on log output (1)

» ACL syslogs have different identifiers depending on type of traffic that triggered the log.


Filtering on log output (2) » When sending ACL Syslogs to logging buffer, one can filter

on these identifiers.


Filtering on log output (3) » From this (yuck!!)…


Filtering on log output (3) » To this (YAY!!)…

Presenter

Presentation Notes

In this case we’re filtering our log output (which contains a LOT of logging) to only those items that include a capital “RP” which…in this case…matches on our ACE logging that is denying EIGRP!

Copyright © INE Inc. All rights reserved.

Q&A

Documents

Access Control Lists (Beyond Standard and Extended) · Access Control Lists (Beyond Standard and Extended)