Access Control List (ACL) on Cisco ASA Firewall Appliance

1. Overview

 

Access Control List (ACL) is one of the main features of Cisco Adaptive Security Appliance (ASA). It capables of filtering the traffic flow across the connected interfaces of Cisco ASA firewall Appliance and prevents a certain traffic from entering or exiting a network.

This article will show you how to configure Access Control List (ACL) to control the traffic flow in and out to secure your network.

2. Prerequisites

 

In this tutorial, it is assumed that:

a. You already have Cisco ASAv on GNS3 VM up and running. In case that you don’t, please follow this link.
Configuring Cisco ASAv QCOW2 with GNS3 VM

b. You have a precise knowledge about security level on Cisco ASA. If you dont, you would probably like to read this link.  Understanding Security Level in Cisco ASA Firewall Appliance

3. The Main Concept Access Control List (ACL)

 

Access Control List (ACL) is used to to permit or deny traffic from a source to a destination. When traffic flowing from a source to a destination, it goes in and out the Cisco ASA interfaces. When applying the ACL to an interface, we need to choose whether it is “In” or “Out” direction. Understanding the term “In” or “Out” means is really importance to work with ACL on Cisco ASA firewall appliance.

  • The “In” direction means the traffic is coming into an interface.
  • The “Out” direction means the traffic is leaving a interfaces.

 

When ACL is apply on any interfaces,  all traffic is blocked, unless it is stated to be allowed on that applied ACL. So, even from a higher security level interface cannot access to a lower security level interface.

Protocol icmp ping also need to be stated to allow in the ACL too otherwise it cannot go from one to another interface even with icmp inspection is applied in the global policy.

The order of the ACL statement is very important. Cisco ASA reads each ACL statement from the top to bottom and decides whether to permit or deny the traffic.

For security best practice, the ACL should be placed in the lower security level interface or as closed as to the destination.

4. Command Syntax of Access Control List (ACL)

 

The following is the command syntax to create an ACL.

access-list access_list_name extended {deny | permit} {tcp | udp } source-IP destination-IP destination-port.
  • access_list_name: provide a name to identify an ACL. This name will be used when applying the ACL to an interface.>
  • source-IP: specify the IP address or network that originates the traffic.
  • destination-IP: specify the IP address or network that the source-IP requires to access.
  • destination-port: specify the port number that the source-IP need to access to.

Example: Creating access name “inside-access-dmz” to allow host with IP 10.10.10.2 to be able to remote SSH to host 10.10.20.2.

access-list inside-access-dmz extended permit tcp host 10.10.10.2 host 10.10.20.2 eq ssh

5. Access Control List (ACL)Steps

 

The follow picture describes the steps when working with  Access Control List (ACL).

Step1: We need to decide whether the traffic is incoming or exiting an interface.

Step2: When “In” or “Out” is decided, now you should know where the source address and where the destination address is.

Step3: If “In” is decided, apply the ACL to an interface as “In”. If “Out” is decided, apply the ACL to an interface as “Out”.
To apply an ACL to an interface, we use command “access-group” and below is the syntax.

access-group access_list_name {in | out} interface interface_name
  • access_list_name: the name of ACL that we want to apply it.
  • interface_name: name of the interface that ACL will apply to.

>Example: Applying an ACL name “inside-access-dmz” as “Out” direction to interface “dmz”.

access-group inside-access-dmz out interface dmz

6. Example of Access Control List (ACL)

 

We will use the following Lab to test ASA firewall appliance. Actually, it is the NGS3 and ASAv.

We have two separated networks, “inside” with subnet 10.10.10.0/24 and “dmz” with subnet 10.10.20.0/24. R1 acts as an PC and R2 will have some services running such as, telnet, SSH, HTTP, and HTTPS. We will create an Access Control List (ACL) to allow R1 access each service on R2.

Before we start testing the ACL, we need to configure our devices as the following first.

On R1, configure the IP address and default gateway.

#int f0/0
   no sh
  ip add 10.10.10.2 255.255.255.0
  ip route 0.0.0.0 0.0.0.0 10.10.10.1

On Cisco ASA, assign IP addresses both interfaces, security level value of 100 is automatically assigned to interface “inside”. For “DMZ” interface, assign security level to 50. We need also to configure global policy to allow icmp ping.

# int g0/0
    no sh
    ip add 10.10.10.1 255.255.255.0
    nameif inside
# int g0/1
    no sh
    ip add 10.10.20.1 255.255.255.0
    nameif dmz
    security-level 50
# policy-map global_policy
   class inspection_default
     inspect icmp
     inspect icmp erro

On R2, configure the IP address and default gateway.

#int f0/0
   no sh
   ip add 10.10.20.2 255.255.255.0
   ip route 0.0.0.0 0.0.0.0 10.10.20.1

Configure telnet access, so port 23 is accessible.

#username netadmin privilege 15 secret 111
#enable secret 222
#line vty 0 15
  login local
#aaa new-model

Configure SSH access, so port 22 is accessible.

#ip domain-name www.techspacekh.com
#crypto key generate rsa
#ip ssh version 2

Configure HTTP service, so port 80 is accessible.

#ip http server

Configure HTTPS service, so port 443 is accessible.

#ip http secure-serve

All services on R2 now should be able to access from R1 because the security level on “inside” interface is higher then “dmz” interface.


We can try to ping R2 from R1. The ping is result is successful.

Now let try telnet to port 23 and 22. As we can below, the connection for port 23, and 22 is open on R2.

Let try port 80 and 443. We should get the connection open on R2 as the following.

Now it is time to create an access-list to test our theory talked above. In below commands, we create an access-list name “inside-access-dmz” to permit icmp ping from R1 to R2. Access-list name “inside-access-dmz” is applied to as “Out” direction on interface “dmz”.

Apply “Out” mean packet is leaving “dmz” interface. So, the destination is R2 and the source is R1.

#access-list inside-access-dmz extended permit icmp host 10.10.10.2 host 10.10.20.2
#access-group inside-access-dmz out interface dmz

We should get the successful ping result when trying to ping from R1 to R2.

Because by default the access-list has an implicit deny statement at the end, so the rest of services on R2 is not accessible.


To be able to access all the rest of services on R2 we need to explicitly permit traffic to pass though “dmz” interface.

access-list inside-access-dmz extended permit tcp host 10.10.10.2 host 10.10.20.2 eq ssh
access-list inside-access-dmz extended permit tcp host 10.10.10.2 host 10.10.20.2 eq telnet
access-list inside-access-dmz extended permit tcp host 10.10.10.2 host 10.10.20.2 eq www
access-list inside-access-dmz extended permit tcp host 10.10.10.2 host 10.10.20.2 eq https

Now let test telnet to port 23 and 22 again. We should get the successful result as the following.

Let test telnet to port 80 and 443 again. We should get the successful result as the following.

There are three main commands to verify and troubleshoot ACL problem.

#sh run access-list
#sh run access-group
#sh access-list

7. Verify ACL Configuration

 

The following commands are very helpful to verify your ACL configuration.

# sh run access-list acl_name
# sh access-list acl_name
# sh run access-group

8. Conclusion

 

Now you should be about to configure Access Control List (ACL) to secure your network infrastructure environment. I hope you found this article informative. If you have any questions or suggestions you can always leave your comments below. I will try all of my best to review and reply them. Thank you and see you again in another post.

Comments

comments