Every time I see a new implementation of a Cisco ASA firewall I need to know how it is connected. Before doing any changes in the configuration and before answering any answers regarding the functionality of the FW i first need to have the full picture of the topology.
Often the only source of information about a firewall that I have is a configuration file. If I don´t even have that I need to see it. Trust no humans! 🙂
When processing FW configurations I always go thru the same steps:
What interfaces does the firewall have? Draw a circle in the center of an empty paper and make as many lines out of that circle as there are interfaces in the firewall. And when I say interfaces, I mean firewall zones, not physical interfaces. I don´t care very much about Ethernet0/1.123, I am more interrested in “inside”, “outside” and “dmz12”.
Which IP subnets are directly connected? Add the subnets with its mask to each line.
What routes are defined in the firewall? Add an arrow for each static route in the configuration, pointing towards next-hop direction. I don´t bother adding the ip of the next-hop, it´s already in the config. I just need to know which subnets are where in the world in the eyes of the firewall. I usually mark the default route with “def”.
Also add vpn-pools and remote networks beyond vpn tunnels to the drawings. In my example drawings I have no vpn-tunnels configured but if I had a vpn-pool of 192.168.111.0/24 I would really need to know that that address range was beyond the outside interface, not beyond inside and its 192.168/16-route. (of course my example wouldn´t work with a outside vpn-pool without also a static route of that pool pointing outwards overriding the /16-route).
If the firewall is running a routing protocol (search for “router” in the config”), of course it gets more complicated. Then you NEED to have access to the live firewall to see the output of “sh route”.
As you might know, acl:s an be applied both inbound and outbound relative to a specific interface. Also, an acl can be applied globally. To know which acl:s that affects a specific traffic flow it is really needed to have a full view of all applied access-list. I usually draw a line across the junction between an interface line and the firewall for each acl and add an arrow in the direction of the applied acl. Then I add the name of the acl next to it. See my picture below as an example of 2 cal:s applied IN-bound on each interface. If they were applied OUT-bound (please don´t do this!) the arrow would be in the other direction, from the center of the firewall circle towards towards the “blocking line”.
But what if there is no acl applied? That´s when the security-level comes in! In my example below there is no acl for the DMZ-interface. That means that the security-level-rules applies, you know lower-to-higher is blocked while higher-to-lower is allowed.
So, if there is not an acl applied to ALL interfaces, add the security-levels to the drawing as well.
Next step is to understand where and how the firewall does address translations. In small configurations I try to add this to the same drawings but NAT tends to be messy and complicated so most often I make my own NAT table on a separate piece of paper. This can be tricky because depending on which version you run there are different syntaxes for NAT configuration. This is a completely separate topic to big to cover in this blog post.
As a minimum I do this when I map the NAT-configurations:
- Find the overload-NAT that makes inside hosts share a common public IP to reach internet. It´s a nat/global-combination in older syntaxes and probably a dynamic object-nat statement in newer versions. Add to the paper which 2 interfaces this applies to and an arrow defining the direction. Then add which source ip:s this applies to above the source interface and the public ip (or “interface”) above the destination (outside) interface.
- Add all static NAT:s one by one with a dual-direction arrow between the interfaces and add each static´s real and natted ip above the interface names.
If the configurations not too complicated I tend to also add allowed inbound port for public server into the nat-table. For example, mark that for the first static NAT 10.0.0.100 – 126.96.36.199 ANY is allowed for inbound http and https, and for the second NAT ANY is allowed for inbound SMTP. By doing that I know about the (probably) most important services going thru the firewall.
I don´t write this down every single time. However when upgrading from 8.2 to 8.3+ this is a very important step since the real-ip migration messes with the acl:s and after the migration you need to make sure that the services are available.
If you don´t know the big picture of a firewall when you start modifying its configuration, the risk is huge that you will do more damage than good then configuring it. So don´t touch anything until you have a general view of how the firewall works!
The two pieces of paper that outcomes this process will never be a complete documentation. But for me the process of making the drawings will make me “learn” the topology and understand the directions of traffic flow. So far I haven´t touched a firewall without making a topology drawing. The NAT-table is optional but for me the topology-draft is mandatory!