Firewalls

Simple ASA Access-lists Configuration Technique

The plot

Some day some application or server person comes and wants to deploy some new service on top of your network. The deployment implies installing several new network endpoints (servers, workstations or some other IP-enabled devices) in several network security zones and granting them necessary access permissions. The person is in a hurry to finish the deployment ant test it. You are in a hurry with your day-to-day tasks. The solution vendors documentation often doesn’t explain well what network protocols it uses and which direction the connections between different solution components are going to be established (I have experienced this with new CCTV solution that was being deployed this week). Or you just study the doc which seems well detailed, configure everything according to it, but the service just doesn’t work and neither of you two can be sure whether it’s a firewall or the application level configuration problem.

Solution?

One common way to resolve this is to temporarily permit all traffic between all the IP addresses involved “just to test it works”. Quite often in such cases the deployment gets successfully finished, everyone is happy, the person who was deploying this new has to go on with his or her job, you  have to go on with your job, so no one has time to correct the permissions you have configured for the tests and they stay forever…

Here is a general algorithm I try to use while operating Cisco ASA in order to avoid this:

First configure what vendor asks you to

Study the application vendor documentation. Configure the permissions it asks you to configure. If points are unclear in the documentation – just skip it. Vendor may say something like “Server A and Network Device B need ports X and Y to be opened between them” but doesn’t say which direction the traffic is going to flow and sometimes doesn’t even specify whether it is going to be TCP or UDP. You don’t want to configure both TCP and UDP in both directions, just to make sure. Skip it, and investigate later.

An important thing: configure each pair of Source/Destination hosts/networks and port/protocol as a separate line. Here is an example for some network device and two servers it should be talking to:

Initial permissions configuration
Initial permissions configuration

Second: configure an explicit deny

For each pair of Source/Destination hosts or networks configure an explicit deny line below the permit statements configured in a previous step:

Explicit deny statement
Explicit deny statement

Enable logging for these statements, set the Logging Level to the one that is being logged to ASDM (or your Syslog-server) and an interval of 1 second:

Enabling logging for explicit deny
Enabling logging for explicit deny

This will be used to collect data on denied traffic.

At the end you will have something like this:

Initial config with explicit deny statements for each Source-Destination pair
Initial config with explicit deny statements for each Source-Destination pair

Third: test, check, and correct configuration

Ask a person who deploys the new service to do the tests while observing the logs configured for deny statements. If something fails, check the logs for denied packets and if there are any, analyze  whether this traffic should be permitted or not. If it should – add necessary permissions above the deny line and do the test again:

ASA999
Check explicit deny line logs for denied packets

You may need to repeat this step several times while new features of the service that is being deployed are being tested.

Fourth: let it run for some time and then check and correct it again

Everything went up and running. Now let it work for some time and check the hit counters for ACL lines.

It depends on particular situation, but commonly if some ACL line wasn’t hit by a single packet during 2-3 moths you may consider disabling it.

Also you may disable the explicit deny line at this step.

Fifth: re-arrange the configuration if possible

Ultimately it is group the Sources and Destinations and ports/protocols into groups to make configuration look shorter and easier to read:

Final configuration. Ports and protocols grouped into Service Groups
Final configuration. Allowed ports and protocols grouped into Service Groups

The grouping might be different, for example, you may want to group some ports and protocols based on their role, creating Service Groups such as “NetworkDeviceX-ServerA-Management-Access”.

This way I normally end up having quite well organized configuration that permits just what is needed to be permitted and serves as a good reference for documenting how the deployed service works from the network point of view.