How to Control Traffic Filtering ACLs on the ASA

The quick definition: Traffic filtering allows you to identify specific traffic that you want to permit through your ASA that would otherwise normally be blocked. Traffic filtering is "punching a hole in the firewall."

A Quick Overview of Traffic Filtering [VIDEO]

In this video, Anthony Sequeira covers how to control traffic filtering configurations with ACLs on the Cisco ASA. In a default firewall configuration, low-security interfaces cannot go in and access high-security interfaces. This is fine until you need to allow temporary access from outside your organization, and that's where traffic filtering comes into play.

When Would You Need Traffic Filtering?

Anytime you want to permit someone on the outside of your protected network access something on the inside, or prevent someone on the inside from accessing specific resources on the outside, you need traffic filtering.

With a Cisco Adaptive Security Appliance set up on your network, by default, a low-security interface — like a so-called "outside" interface at Level 0 — can't go in and access resources on a high-security interface — like an "inside" interface at level 100. Traffic filtering allows for it and a powerful and customizable way to do that is with Access Control Lists.

But what about when you need someone on the outside to be able to come in and do things on the inside? Or what if you want to stop someone on the inside from accessing specific outside resources? Fortunately, it's possible to instruct your ASA about which traffic is permissible.

What is an Access Control List?

An Access Control List, often referred to as an ACL, is a list of rules that explain what can or cannot enter or leave a router's interface. When a packet tries to enter an Adaptive Security Device, it gets tested against every rule in the ACL. If a matching rule is found, the packet is allowed to proceed. If no match is found, then the packet is denied.

What Should Our Test Network Look Like?

In this case, because we want to set up traffic filtering through ACLs on the ASA, you'll want to imagine placing an Adaptive Security Appliance in between a device on an outside network and a device on an "Inside" network.

For the explanation that follows, assume that the Outside (originator) network's host IP is 192.168.1.1. Inside (target) network's host IP is 10.10.10.1 and that we're trying to gain access on Port 23 (telnet).

What Tools Should You Use to Visualize Network Traffic?

Any time you're experimenting with new technologies or skills on a network, we recommend using GNS3  (Graphical Network Simulator-3). It's a network software emulator that lets you see everything that's happening on a network as it happens.

How Does an ASA Affect Network Traffic?

By default, your ASA should block requests from sources in low security levels while permitting traffic from high security levels to stream out.

In our GNS3 simulation, the Inside network should be able to access the Outside network, and the Outside should be restricted from accessing the Inside. To see your ASA automatically block traffic, go to the Outside device's interface and attempt to telnet to the router that's on the Inside. (for our example, this should be 192.168.1.1 attempting to telnet 10.10.10.1 on Port 23.

That attempt should not succeed, and if you navigate to the ASA where you've enabled logging you can see that the ASA was blocking that traffic dynamically. And if you've configured your ASA properly, you'll see the IP address that'd been trying to access which port, and what packets are being used.

It's important to understand that traffic getting blocked like this isn't dependent on special configurations on the ASA. The traffic gets blocked because a low-security, (0 security level interface) was trying to access a resource in a high-security (security level 100) interface. The ASA is doing the job it was born to do: blocking that particular traffic attempt.

How Do We Tell an ASA to Allow Normally Blocked Traffic?

If we want that telnet to succeed, we can punch a hole in the firewall – that's actually the common language for creating a filtering access control list. It's recommended that if you're using GNS3 to simulate this that you leave the logging on for the next section: you'll see what your current configurations are doing to the traffic.

How to Create a Filtering Access Control List Inside GNS3

To demonstrate how to create a filtering ACL, let's first imagine in English what we want the ASA to do. In this example, we want to instruct the ASA to "create an extended Access Control List called "OUT_IN" that allows TCP traffic from a host IP to a recipient IP, when that traffic is going to a specific port."

In global configuration mode, the command to create that exact ACL (using the sample information we detailed earlier) is "access-list OUT_IN extended permit tcp host 192.168.1.1 host 10.10.10.1 eq 23".

Let's walk through each part of that command. And while you write your ACL, don't forget to use context-sensitive help to guide you in the creation of your ACL.

First, the entire input starts with "access-list" – this begins the creation of the ACL, and we can add the arguments onto the tail end of it.

Next, give the ACL a name. Since in this case we're generating an ACL to manage outside access to an inside network, we've called it "OUT_IN".

Different ACLs are configured with different capabilities. In our case, we've created an "extended" ACL. Doing that allows us to configure the type of traffic permissions carefully.

After that, we specify what traffic that's currently being denied should be permitted – specifically TCP traffic from host 192.168.1.1.

Last, we specify where the traffic is headed. In this case, it's going to the host 10.10.10.1 and specifically it is going to a particular port: 23 for telnet.

Let's review. By typing the command "access-list OUT_IN extended permit tcp host 192.168.1.1 host 10.10.10.1 eq 23", you instruct your ASA to "write an extended ACL titled "OUT_IN" that allows TCP traffic from 192.168.1.1 to access 10.10.10.1, when traffic is going to port 23."

How Does an ACL Start Allowing Traffic?

An Access Control List doesn't do anything on its own. In order for it to manage traffic it must be assigned to Access Groups that have users.

In our console, for this example, we'll write "access-group OUT_IN in interface Outside". This assigns the ACL,which we previously titled "OUT_IN", to inbound traffic for the interface for Outside. Just like when writing your ACL, be sure to use the context-sensitive help to craft your Access Groups.

If you've followed along and assigned your newly minted ACL to your Access Group, you should get a sense of just how quick and easy the process is, but also how powerful it is. If you replace our example variables with the host and destination ports of your own, you'll see it takes very little to "punch that hole" through your ASA.

How Can an ACL Be Verified?

Once you've followed all these steps in your console, you should be able to go to the outside device and retry the telnet. If the ACL was written properly, and assigned to the right group, your telnet should gain access.

It can be helpful to review your logs to get a sense of what's been happening during these attempts. They should say that a local host — Outside 192.168.1.1 – connection was built to a local host — Inside 10.10.10.1. It should also show that there is an inbound TCP connection for that outside device going to this inside device.

A helpful command while you're inspecting your connections is "show conn detail". With it, you can view the connection details and view the connection which was built to allow the particular telnet to flow.

What Other Traffic Does an ACL Permit?

What else does the ACL allow? Actually, nothing. Remember that, by default, an ACL possesses a deny any/any as its last implicit command. In other words, you might be allowing this specific traffic to flow, but any other types of traffic will meet with a "Deny".

But there's something else you can do with a traffic-filtering ACL like this. Again, imagine you've set up an ASA with two interfaces: an outside interface and an inside interface. By default, things from inside can go out with no problem thanks to the logic of the ASA.

But if you didn't want a particular traffic from going from the inside to the outside – for instance maybe you don't want gaming traffic going through your ASA during regular business hours – you could set that up with an ACL denying that traffic flow that was previously permitted just by the inherent logic of the adaptive security appliance.

Permit or Deny Traffic Through Your Networks With ACLs

A properly written traffic-filtering Access Control List, applied to the right Access Group, can permit traffic that's normally blocked by your ASA, or block traffic that's normally permitted by it. Using the template we provided you with above, you can now allow different hosts to communicate with one another in the way that you need them to — maintaining your security and control of your network.