1.Cisco ASA Access-List



The Cisco ASA firewall uses access-lists that are similar to the ones on IOS routers and switches. If you have no idea how access-lists work then it’s best to read my introduction to access-lists first.

Without any access-lists, the ASA will allow traffic from a higher security level to a lower security level. All other traffic is dropped. If you have no idea what security levels on the ASA are about then read this post first.

Access-lists are created globally and then applied with the access-group command. They can be applied in- or outbound.

There are a couple of things you should know about access-lists on the ASA:

  • When you create an ACL statement for outbound traffic (higher to lower security level) then the source IP address is the real address of the host or network (not the NAT translated one).
  • When you create an ACL statement for inbound traffic (lower to higher security level) then the destination IP address has to be:
    • The translated address for any ASA version before 8.3.
    • The real address for ASA 8.3 and newer.
  • The access-list is always checked before NAT translation.

Let’s take a look at some examples how we can use access-lists. I’ll be using this topology:

ASA1 Inside Outside DMZ

We have three devices, R1 on the inside, R2 on the outside and R3 in the DMZ. This means that by default the following traffic is allowed:

  • R1 can reach R2 or R3 (from security level 100 to 0 or 50)
  • R2 can’t reach any devices (from security level 0  to 50 or 100)
  • R3 can reach R2 but not R1 (from security level 50 to 0 or 100)

Let’s look at an example first where we restrict traffic from the inside as by default, all traffic is allowed.

1.Deny Traffic from Inside

To test this I will enable HTTP server on R2 so that we have something to connect to from R1:

R2(config)#ip http server

Now we’ll telnet from R1 to R2 using TCP port 80:

R1#telnet 192.168.2.2 80
Trying 192.168.2.2, 80 ... Open

This traffic is allowed by default, let’s create an access-list that restricts HTTP traffic. We’ll create something so that users on the inside are not allowed to connect to the HTTP server on R2. All other traffic will be permitted:

ASA1(config)# access-list INSIDE_INBOUND deny tcp any host 192.168.2.2 eq 80
ASA1(config)# access-list INSIDE_INBOUND permit ip any any

The access-list above will do the job.

Since ASA version 9.x, the “any” keyword applies to both IPv4 and IPv6 traffic. If you only want to match IPv4 traffic then you should “any4”. For IPv6 traffic, use “any6”.

Let’s enable the access-list:

ASA1(config)# access-group INSIDE_INBOUND in interface INSIDE

The access-group command enables the access-list called “INSIDE_INBOUND” inbound on the “INSIDE” interface. Let’s see if we can still reach the HTTP server on R2:

R1#telnet 192.168.2.2 80
Trying 192.168.2.2, 80 ... 
% Connection refused by remote host

This is no longer working, take a look on the ASA to see why:

ASA1# show access-list INSIDE_INBOUND
access-list INSIDE_INBOUND; 2 elements; name hash: 0x1cb98eea
access-list INSIDE_INBOUND line 1 extended deny tcp any host 192.168.2.2 eq www (hitcnt=1) 0xe9af7602
access-list INSIDE_INBOUND line 2 extended permit ip any any (hitcnt=0) 0x38288040

As expected the ASA is dropping this packet because of our deny statement. Using an access-list like this is useful to deny some traffic from hosts that is headed towards the Internet or DMZ. Let’s continue with another example…

2.Permit Traffic to DMZ

When you have a DMZ you probably want to access some of the servers in it from the Internet. To allow this, we need to create an access-list that permits our traffic. For example let’s say that we have a telnet server in the DMZ that should be reachable from the Internet. We can create an access-list like this:

ASA1(config)# access-list OUTSIDE_INBOUND permit tcp any host 192.168.3.3 eq 23

This access-list will permit traffic from any device that wants to connect with IP address 192.168.3.3 on TCP port 23. Let’s activate it:

ASA1(config)# access-group OUTSIDE_INBOUND in interface OUTSIDE

This access-list is now activate on the OUTSIDE traffic and applied to inbound traffic. Let’s test it by telnetting from R2 to R3:

R2#telnet 192.168.3.3
Trying 192.168.3.3 ... Open

Great we are able to connect from R2 to R3. Let’s verify this on the ASA:

ASA1# show access-list OUTSIDE_INBOUND
access-list OUTSIDE_INBOUND; 1 elements; name hash: 0x82be59f0
access-list OUTSIDE_INBOUND line 1 extended permit tcp any host 192.168.3.3 eq telnet (hitcnt=1) 0x19e795c8

You can see that we have a hit on our permit statement. Last but not least, let’s take a look at an example where we use an access-list for outbound traffic…

3.Restrict Outbound Traffic

In the previous examples I showed you how to use inbound access-lists. This time we’ll use an outbound access-list. For example, let’s say that we want to ensure that all our hosts and servers that are located in the inside or DMZ can only use one particular DNS server on the outside. We can create an access-list like this:

ASA1(config)# access-list ALL_OUTBOUND permit udp any host 192.168.2.2 eq 53
ASA1(config)# access-list ALL_OUTBOUND deny udp any any eq 53               
ASA1(config)# access-list ALL_OUTBOUND permit ip any any

This access-list only permits DNS lookups when we use the DNS server on 192.168.2.2. Let’s activate it:

ASA1(config)# access-group ALL_OUTBOUND out interface OUTSIDE

The command above enables the access-list on the outside interface but it’s outbound. This means it will only hit on traffic from inside to outside or from the DMZ to outside. Let’s give it a try…to test this, I’ll enable a DNS server on R2:

R2(config)#ip dns server 
R2(config)#ip host R2 192.168.2.2

This turns our router into a DNS server and the only DNS record it has is for its own hostname. Let’s configure R1 and R3 to use this DNS server for lookups:

R1, R3
(config)#ip name-server 192.168.2.2

Now see if we can do a DNS lookup:

R1#ping R2
Translating "R2"...domain server (192.168.2.2) [OK]
R3#ping R2
Translating "R2"...domain server (192.168.2.2) [OK]

R1 and R3 are both able to reach the DNS server on 192.168.2.2. This traffic is permitted by default since we go from a higher security level to a lower one but let’s take a look at the ASA anyway…just to see if the access-list is active or not:

ASA1# show access-list ALL_OUTBOUND
access-list ALL_OUTBOUND; 3 elements; name hash: 0xe884e0e4
access-list ALL_OUTBOUND line 1 extended permit udp any host 192.168.2.2 eq domain (hitcnt=2) 0x99d83832 
access-list ALL_OUTBOUND line 2 extended deny udp any any eq domain (hitcnt=0) 0x741eb18e 
access-list ALL_OUTBOUND line 3 extended permit ip any any (hitcnt=10) 0x92e89284

We can see that the access-list is active since we have a match on our permit statement. Let’s see what happens when we configure another DNS server on R1 or R3:

R1(config)#no ip name-server 192.168.2.2
R1(config)#ip name-server 192.168.2.200

We will get rid of 192.168.2.2 and use 192.168.2.200 as our DNS server. Let’s see what happens when we try to reach this (not existing) DNS server:

R1#ping R2
Translating "R2"...domain server (192.168.2.200)
% Unrecognized host or address, or protocol not running.

There’s no response, and this is what you will find on the ASA:

ASA1# show access-list ALL_OUTBOUND
access-list ALL_OUTBOUND; 3 elements; name hash: 0xe884e0e4
access-list ALL_OUTBOUND line 1 extended permit udp any host 192.168.2.2 eq domain (hitcnt=3) 0x99d83832 
access-list ALL_OUTBOUND line 2 extended deny udp any any eq domain (hitcnt=4) 0x741eb18e 
access-list ALL_OUTBOUND line 3 extended permit ip any any (hitcnt=10) 0x92e89284

Our packets match the deny statement in our access-list.

You have now seen some examples of inbound and outbound access-lists. What if we want to edit an access-list that we created earlier?

4.Editing Access-Lists

What if you want to add a new entry to an existing access-list in between some other entries? Here’s an example for the access-list that we just created:

ASA1(config)# access-list ALL_OUTBOUND line 3 extended deny tcp any any

By specifying the line, you tell the ASA where to put this entry. Here’s what the access-list looks like now:

ASA1# show access-list ALL_OUTBOUND
access-list ALL_OUTBOUND; 4 elements; name hash: 0xe884e0e4
access-list ALL_OUTBOUND line 1 extended permit udp any host 192.168.2.2 eq domain (hitcnt=3) 0x99d83832 
access-list ALL_OUTBOUND line 2 extended deny udp any any eq domain (hitcnt=7) 0x741eb18e 
access-list ALL_OUTBOUND line 3 extended deny tcp any any (hitcnt=0) 0x53302aaf 
access-list ALL_OUTBOUND line 4 extended permit ip any any (hitcnt=10) 0x92e89284

It inserted the new entry where line 3 used to be and everything else is below it. What if you want to remove something? Just put no in front of the line you want to remove:

ASA1(config)# no access-list ALL_OUTBOUND line 3 extended deny tcp any any

And here’s the result:

ASA1# show access-list ALL_OUTBOUND                               
access-list ALL_OUTBOUND; 3 elements; name hash: 0xe884e0e4
access-list ALL_OUTBOUND line 1 extended permit udp any host 192.168.2.2 eq domain (hitcnt=3) 0x99d83832 
access-list ALL_OUTBOUND line 2 extended deny udp any any eq domain (hitcnt=7) 0x741eb18e 
access-list ALL_OUTBOUND line 3 extended permit ip any any (hitcnt=10) 0x92e89284

The entry has been removed…great!

Last but not least, there’s one access-list topic I have for you. We have seen access-lists that were applied in- or outbound to interfaces but there is another option…something called global access-lists.

5.Global Access-List

The global access-list is useful when you have many interfaces and you don’t want to enable an access-list on each one of them. When you use this, you create an access-list like you normally do but instead of enabling on an interface, we enable it globally.

When you do this…the access-list is applied to all inbound traffic on all interfaces. It doesn’t work for outbound traffic.

Here’s an example, let’s say we want to ensure that all devices on any interface that is connected to the ASA are only allowed to use a SMTP server on 192.168.3.3. All other SMTP traffic is not allowed:

ASA1(config)# access-list SMTP extended permit tcp any host 192.168.3.3 eq 25  
ASA1(config)# access-list SMTP extended permit tcp host 192.168.3.3 eq 25 any
ASA1(config)# access-list SMTP extended deny tcp any any eq 25
ASA1(config)# access-list SMTP extended permit ip any any

The access-list above allows SMTP traffic to 192.168.3.3 and denies all other SMTP traffic. Now let’s activate it:

ASA1(config)# access-group SMTP global

That’s it, instead of specifying the interface and direction we use the global keyword. Let’s give this a try:

R2#telnet 192.168.3.3 25

I’ll use R2 to connect to TCP port 25 on 192.168.3.3, here’s what you will see on the ASA:

ASA1# show access-list SMTP
access-list SMTP; 4 elements; name hash: 0x818892dc
access-list SMTP line 1 extended permit tcp any host 192.168.3.3 eq smtp (hitcnt=1) 0xf14d14d3 
access-list SMTP line 2 extended permit tcp host 192.168.3.3 eq smtp any (hitcnt=0) 0xf5f9ab76 
access-list SMTP line 3 extended deny tcp any any eq smtp (hitcnt=0) 0xfd6e59b2 
access-list SMTP line 4 extended permit ip any any (hitcnt=0) 0x1eceb9d1

This proves the access-list is active as we have a match on the first access-list entry.

That’s all I have on access-lists for now, I hope these examples has been useful…if you have any questions feel free to leave a comment!

Comments

Post a Comment

Popular posts from this blog

Cisco ASA Packet Drop Troubleshooting

Image
As a firewall, the Cisco ASA drops packets. That’s great until it drops packets that you want to permit, and you have no idea what is going on. Fortunately, the ASA supports different tools to show you why and what packets it drops. In this lesson, we’ll cover the following tools: Connection State Interface Drops Syslog ASP Drops Packet Capture Packet Tracer Service Policy Conclusion Here is the topology I use: We use a simple topology: Two “host” devices: These are routers with ip routing disabled, and they use ASA1 as their default gateway. An HTTP server is enabled on both devices. ASA1 runs ASAv Version 9.9(2) and has two interfaces: INSIDE: security level 100 OUTSIDE: security level 0 In this topology, H1 will be able to initiate a connection to H2. H2 won’t be able to initiate a connection to H1 because we go from a  low-security level (0) to a high-security level (100) . Configurations ASA1 H1 H2 hostname ASA1 ! interface GigabitEthernet0/0 nameif INSIDE security-level 100...
Read more

show asp drop Command Usage

The  show asp drop  command shows the packets or connections dropped by the accelerated security path, which might help you troubleshoot a problem. See the general operations configuration guide for more information about the accelerated security path. This information is used for debugging purposes only, and the information output is subject to change. Consult Cisco TAC to help you debug your system with this command. The following sections include each drop reason name and description, including recommendations: rame Drop Reasons   ---------------------------------------------------------------- Name: natt-keepalive NAT-T keepalive message: This counter will increment when the appliance receives an IPSec NAT-T keepalive message. NAT-T keepalive messages are sent from the IPSec peer to the appliance to keep NAT/PAT flow information current in network devices between the NAT-T IPSec peer and the appliance.   Recommendation: If you have configured IPSec NAT-T on your ...
Read more

1.Cisco ASA Clock Configuration

The Cisco ASA firewall has a battery on the motherboard that saves the clock settings. Even when it’s is powered off, the clock will be stored. There are two important reasons why you want to make sure that your ASA has the correct date/time: In case of a security breach you want to track log files for events. With an incorrect timestamp, your log files are useless. PKI (Public Key Infrastructure) that we use for digital certificates to authenticate remote users (IPSEC or SSL VPN) requires the correct date/time. The most simple method is to configure the date/time manually, you can do it like this: ASA1(config)# clock set 13:15:00 Dec 19 2014 Just use the  clock set  command and enter the correct time/date. You can verify it like this: ASA1# show clock 13:15:15.709 UTC Fri Dec 19 2014 As you can see, the default timezone is UTC. If you are in another timezone like me then you have to change this: ASA1(config)# clock timezone CET +1 Use the  clock timezone  command t...
Read more