This lab will discuss and demonstrate the configuration and application of Cisco ASA Objects, Object Groups and Access Control Lists.
When it comes to Cisco Adaptive Security Appliances (ASA’s), they are very similar in nature to Cisco IOS Routers in that they have Access Control List (ACL) functionality. Since you’re studying for the CCNA Security Exam you should have already passed the CCNA Composite Exam and/or (ICND1/ICND2) in which case you should be familiar with how ACL’s work.
ACL’s by nature are a very simple mechanism which allows for you to permit or deny traffic based on specific criteria such as source and destination IP addresses or subnet(s). You can get even more granular by adding source and destination port numbers to further restrict the traffic when using the principal of lease privilege security model.
But ASA’s however add a nice little spin to how ACL’s can work and how they should be designed to minimize modifications and conserve resources.
First lets talk about an “ACE”, an Access Control List Entry which by definition is a single ACL line item, for example, permit ip host 10.1.1.1 host 10.2.1.1
Cisco ACL’s have a limited number of ACE resources available based on platform and available RAM in the given platform. Because ACE’s in a given ACL are processed top down, the longer the ACL the longer the time it takes to process the traffic against an ACL configured on a given interface.
Cisco ASA’s however support two cool technologies called Objects and Object Groups. Object’s are used to define a single object such as a host, subnet or service (TCP/UDP, etc..)
Object Groups however are used to define a group of objects such as multiple hosts, multiple subnets, etc…
When using an ACE that references an object-group, the ACE will automatically expand based on information contained within the object group thus only still using a single ACE.
Objects come in two flavors, network and service. A Network object defines a subnet, host, range, etc… and is configured using the object network {name} command in global configuration. An example of an object that defines a single host is given below;
! object network WEBSERVER01 host 10.1.1.100 !
Objects can also be used to define a given network host by FQDN in which case the ASA will resolve the name to an IP Address dynamically and use that dynamically resolved address in the ACL.
An example of an FQDN object is provided below;
! object network WEBSERVER01 fqdn v4 wevserver01.stublab.com !
To view the currently resolved FQDN names on the ASA you’d use the show dns command in privileged mode.
Object Groups are a nice way to group multiple objects together. For example you can group a single host as well as a subnet together and apply that to an ACL. If you want to add any specific objects to the ACL than just add in the object in the object-group and the ACL is updated automatically.
Object Groups come in multiple flavors which include the typical network and service but also include user, security, protocol and icmp-type. This lab will only focus on the network and service object-groups.
First lets take a look at a network object group where we define multiple servers as well as a subnet. First you must define the network based object group using the object-group network {name}
Next you need to add the specific network objects to the group using the network-object {object} whereas the object is a host, a nested object that is already defined, an ipv4 or ipv4 network address.
And now for an example;
! object-group network DMZ_WEBSERVERS network-object host 10.1.250.11 network-object host 10.1.250.12 network-object host 10.1.250.13 network-object 10.1.251.0 255.255.255.0 !
As you can see defined three separate servers as well as the subnet 10.1.251.0/24
Access Lists on the Cisco ASA’s come in two flavors, standard and extended. Much like the ACL’s on Cisco IOS, standard ACL’s only references source ip traffic such as a host or network whereas extended can reference source/destination address AND source/destination port numbers as well as protocol types such as TCP/UDP or GRE and more.
On the Cisco ASA you define an ACL using the access-list {NAME} {standard|extended} {permit|deny} SOURCE DESTINATION
First lets take a look at an sample standard ACL where we permit traffic from the host 10.1.250.11
! access-list EXAMPLE_STD standard permit host 10.1.250.11 !
Notice how you cannot define the destination and that any traffic from host 10.1.250.11 is permitted to any destination.
Lets make the ACL more specific using an Extended ACL that defines the source host address of 10.1.250.11 and the destination address 10.1.1.25 on UDP port 1812 (For RADIUS Authentication)
! access-list EXAMPLE_EXT extended permit udp host 10.1.250.11 host 10.1.1.25 eq 1812 !
Now that you understand basic ASA ACL syntax lets take a look at building upon the ACE’s using object groups. In this case we’re going to define an extended ACL on the OUTSIDE interface in the ingress direction permitting any traffic to the web servers located in the DMZ. The configuration is going to look like this;
! object-group network DMZ_WEBSERVERS network-object host 10.1.250.11 network-object host 10.1.250.12 network-object host 10.1.250.13 ! access-list OUTSIDE_IN extended permit tcp any object-group DMZ_WEBSERVERS eq www !
In order to see all the web servers defined in the ACE you must use the show access-list command in privileged mode as demonstrated below;
FW1# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
alert-interval 300
access-list OUTSIDE_IN; 4 elements; name hash: 0xe01d8199
access-list OUTSIDE_IN line 1 extended permit tcp any object-group DMZ_WEBSERVERS eq www (hitcnt=0) 0x649222f8
access-list OUTSIDE_IN line 1 extended permit tcp any host 10.1.250.11 eq www (hitcnt=0) 0x15d730fb
access-list OUTSIDE_IN line 1 extended permit tcp any host 10.1.250.12 eq www (hitcnt=0) 0x23c7d22f
access-list OUTSIDE_IN line 1 extended permit tcp any host 10.1.250.13 eq www (hitcnt=0) 0xb898dc16
FW1#
You will notice from the example provided above that line item that has been dynamically built due to the use of object-groups is indented and show as the same line number. In this case Line 1
ACL’s on Cisco ASA’s have the same rule as Cisco IOS ACL’s in that they end in an explicit deny. (Meaning that you wont see it in the ACL but that is the default behavior unless defined otherwise).
You can define an implicit deny ACE for the purposes of logging which is fairly common.
Finally we get to the point where you must apply the ACL. This method in which you apply an ACL is different on the ASA compared to Cisco IOS interfaces.
ACL’s are applied in a global setting and only a single ACL may be applied to a single named interface in each direction. So you may have an INGRESS and an EGRESS ACL on each named interface. The use of both ingress and egress ACL’s on the Cisco ASA is uncommon and typically adds significant complexity and requires extensive ACL knowledge of ACL construction, ASA traffic processing and troubleshooting.
The most common deployment of ACL’s on Cisco ASA’s are in the ingress direction.
You apply the ACL’s using the access-group {ACL-NAME} {in|out} interface {IFNAME}
Lets apply the OUTSIDE_IN ACL the outside interface in the inbound direction.
access-group OUTSIDE_IN in interface OUTSIDE
As a network engineer implementing the technologies outlined in this lab you should be familiar with the following commands provided in the table below;
Command | Description |
---|---|
object {service|network} {name} | This command is executed in global configuration mode to define a service or network object which defines a single object (host, subnet or fqdn) |
object-group {service|network} {name} | This command is executed in global configuration mode to define a service or network object group which contanis multiple objects. |
access-list {NAME} {standard|extended} source {destination} | This command is executed in global config and is used to define an ACL. Standard ACL’s only support source traffic whereas extended supports source destination IP/Protocol/Service. |
access-group {ACL-NAME} {in|out} interface {IFNAME} | This command is executed in ASA Global config to bind an ACL in the specified direction to a given interface name. |
show access-list {name} | This command is executed in privileged user mode to display access-list information. A Name can be defined for specific ACL’s or all ACL’s will be shown. |
The following logical topology is used in most labs found through out Section 7 of the CCNA Security Workbook;
To view the physical cabling topology please visit the Topology page.
In Section 7 you’ll only be configuring FW1. You will however use other lab devices to verify your configuration on FW1.
If you completed the previous lab you can continue where you left off otherwise you’ll need to load the following initial configurations into their respective device(s);
The following lab devices have been pre-configured to save you time as you’ll only be working with FW1 in Section 7.
In order to complete the labs in section 7 you MUST load the following pre-configuration(s);
If you are completing the labs in Section 7 in sequential order than you will not need to load the initial configurations provided above. However if you completed the previous lab than you will need to remove the RADIUS and TACACS+ configuration and restore the AAA Authentication back to local. Make sure that you have existing local credentials before removing any RADIUS/TACACS+ configuration as you may lock yourself out of the lab device and thus may need to perform a password reset!
This lab requires that you have access to a Cisco ASA. You can complete this lab using a virtual Cisco ASA within GNS3 or you can reserve free lab time on the Stub Lab to have access to a pair of Cisco ASA 5510 Series Firewalls which can be used to complete this lab.
In this lab you will complete the following objectives.
It is recommended that you attempt to complete these lab objectives the first time without looking at the Lab Instruction section.
If you are a student preparing for the Cisco CCNA Security Certification Exam than you are more likely to remember how to complete these objectives if you attempt to complete them the first time on your own with the use of the core knowledge section found in this lab. You should only resort to the Lab Instruction section to verify your work.
Objective 1. – Create an Object named RADIUS_SRV that defines the host 10.1.1.25
FW1# config term FW1(config)#object network RADIUS_SRV FW1(config-network-object)# host 10.1.1.25 FW1(config-network-object)# exit FW1(config)#
Objective 2. – Create an Object Group named DMZ_WEBSERVERS that defines the hosts 10.1.250.11, 10.1.250.12 and 10.1.250.13
FW1(config)# object-group network DMZ_WEBSERVERS FW1(config-network-object-group)# network-object host 10.1.250.11 FW1(config-network-object-group)# network-object host 10.1.250.12 FW1(config-network-object-group)# network-object host 10.1.250.13 FW1(config-network-object-group)# exit FW1(config)#
Objective 3. – Create an extended ACL named INSIDE_IN and permit the object RADIUS_SRV to access any device in the 10.1.0.0/16 network.
FW1(config)# access-list INSIDE_IN extended permit ip object RADIUS_SRV 10.1.0.0 255.255.0.0
Objective 4. – Add an additional ACE to the INSIDE_IN ACL permitting TCP port 80 traffic from the network 10.1.1.0/24 destined to the Web Servers in the DMZ.
FW1(config)# access-list INSIDE_IN extended permit tcp 10.1.1.0 255.255.255.0 object-group DMZ_WEBSERVERS eq www
Objective 5. – Add an implicit deny ACE at the end of the OUTSIDE_IN ACL that logs any hit counts.
FW1(config)# access-list INSIDE_IN extended deny ip any any log
Objective 6. – Assign the newly created INSIDE_IN ACL to ingress traffic on the INSIDE interface.
FW1(config)# access-group INSIDE_IN in interface INSIDE FW1(config)# end FW1#
Objective 7. – Verify your configuration and Access List using show commands.
FW1# sh run access-list access-list INSIDE_IN extended permit ip object RADIUS_SRV 10.1.0.0 255.255.0.0 access-list INSIDE_IN extended permit tcp 10.1.1.0 255.255.255.0 object-group DMZ_WEBSERVERS eq www access-list INSIDE_IN extended deny ip any any log FW1# FW1# show run access-group access-group INSIDE_IN in interface INSIDE FW1# FW1# show access-list INSIDE_IN access-list INSIDE_IN; 5 elements; name hash: 0xf4313c68 access-list INSIDE_IN line 1 extended permit ip object RADIUS_SRV 10.1.0.0 255.255.0.0 (hitcnt=0) access-list INSIDE_IN line 1 extended permit ip host 10.1.1.25 10.1.0.0 255.255.0.0 (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 object-group DMZ_WEBSERVERS eq www (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.11 eq www (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.12 eq www (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.13 eq www (hitcnt=0) access-list INSIDE_IN line 3 extended deny ip any any log informational interval 300 (hitcnt=0) FW1#
Objective 8. – On R1 attempt to ping 10.1.250.11 and then telnet to 10.1.250.11 on port 80 requesting the index using HTTP/1.0, once completed verify the hit counters on the INSIDE_IN ACL on FW1.
R1>ping 10.1.250.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.250.11, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R1>telnet 10.1.250.11 80 Trying 10.1.250.11, 80 ... Open GET / HTTP/1.0 HTTP/1.1 401 Unauthorized Date: Fri, 27 Feb 2015 04:53:10 GMT Server: cisco-IOS Accept-Ranges: none WWW-Authenticate: Basic realm="level_15_access" 401 Unauthorized [Connection to 10.1.250.11 closed by foreign host] R1>
FW1# show access-list INSIDE_IN
access-list INSIDE_IN; 5 elements; name hash: 0xf4313c68
access-list INSIDE_IN line 1 extended permit ip object RADIUS_SRV 10.1.0.0 255.255.0.0 (hitcnt=0)
access-list INSIDE_IN line 1 extended permit ip host 10.1.1.25 10.1.0.0 255.255.0.0 (hitcnt=0)
access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 object-group DMZ_WEBSERVERS eq www (hitcnt=1)
access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.11 eq www (hitcnt=2)
access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.12 eq www (hitcnt=0)
access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.13 eq www (hitcnt=0)
access-list INSIDE_IN line 3 extended deny ip any any log informational interval 300 (hitcnt=5)
FW1#
Objective 9 – Create an ACL called DMZ_IN permitting all traffic and apply it in the ingress direction on the INSIDE interface.
FW1# config term FW1(config)# access-list DMZ_IN permit ip any any FW1(config)# access-group DMZ_IN in interface DMZ
Objective 10 – Create an ACL called OUTSIDE_IN permitting only ICMP and apply it in the ingress direction on the INSIDE interface.
FW1(config)# access-list OUTSIDE_IN permit icmp any any FW1(config)# access-group OUTSIDE_IN in interface OUTSIDE FW1(config)# end FW1#
Prior to starting the next lab you must remove the deny IP any any from the INSIDE_IN access-list and replace it with a permit ip any any
FW1# sh access-list INSIDE_IN access-list INSIDE_IN; 5 elements; name hash: 0xf4313c68 access-list INSIDE_IN line 1 extended permit ip object RADIUS_SRV 10.1.0.0 255.255.0.0 (hitcnt=0) access-list INSIDE_IN line 1 extended permit ip host 10.1.1.25 10.1.0.0 255.255.0.0 (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 object-group DMZ_WEBSERVERS eq www (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.11 eq www (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.12 eq www (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.13 eq www (hitcnt=0) access-list INSIDE_IN line 3 extended deny ip any any log informational interval 300 (hitcnt=0) FW1# FW1# config term FW2#(config)# access-list INSIDE_IN permit ip any any FW2#(config)# no access-list INSIDE_IN line 3 deny ip any any FW1#(config)# end FW1# show access-list INSIDE_IN access-list INSIDE_IN; 5 elements; name hash: 0xf4313c68 access-list INSIDE_IN line 1 extended permit ip object RADIUS_SRV 10.1.0.0 255.255.0.0 (hitcnt=0) access-list INSIDE_IN line 1 extended permit ip host 10.1.1.25 10.1.0.0 255.255.0.0 (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 object-group DMZ_WEBSERVERS eq www (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.11 eq www (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.12 eq www (hitcnt=0) access-list INSIDE_IN line 2 extended permit tcp 10.1.1.0 255.255.255.0 host 10.1.250.13 eq www (hitcnt=0) access-list INSIDE_IN line 3 extended permit ip any any (hitcnt=0) 0x96858cf8 FW1#