We have been looking at Cisco Firewall Technologies in the first two articles of this series. In the first, we discussed and configured the Cisco IOS Zone-based policy firewall (ZFW) and in the second, we did an in-depth study on the Cisco IOS ZFW self-zone which handles traffic from/to the IOS firewall router itself. Now let’s talk about something more fun: the Cisco Adaptive Security Appliance (ASA). We will begin with some theory and then get down into the configuration like we love doing.
Cisco Adaptive Security Appliance (ASA)
The Cisco ASA is a standalone (or module in 6500 switch) firewall that provides packet filtering, stateful inspection, VPN functionality and many more in one box. Cisco’s firewall product was formerly the PIX (Private Internet eXchange) but things have since changed so it’s now known as the Cisco ASA.
CCNA Training – Resources (Intense)
As a mainline firewall device, Cisco had to implement a stronger operating system than the basic Cisco IOS devices and so the Cisco ASA runs off a Linux kernel. It is good to note this here because to make something secure, you must limit some functionality. This is the case with the Cisco ASA, especially for those familiar with the Cisco IOS devices. The Cisco ASA contains only the necessary features that a firewall needs to do its job, and it is expected that for all your heavy and complex routing decisions, you will rely on your normal Cisco routers and/or switches. But don’t despair – there’s enough on the ASA to keep you up at odd hours of the night.
To understand the ASA, you must understand the concept of security levels because almost everything rises and falls on this concept. So what are security levels? If you work in a financial institution for example, the level of security in the canteen will be much lower than that in the vault where the money is. It means the vault is at a higher security level than the canteen and this is based on the value of what is being protected. This is how an ASA works: by dividing the network into security levels, it is able to make decisions based on the level of trust. The higher the security level, the higher the trust.
The ASA uses security levels between 0 and 100, with 100 being the most trusted portion of the network (usually the inside, LAN) and 0 being the least trusted (usually the Internet). Interfaces can be assigned any value in this range.
Default Traffic Flow
Now that we have seen what security levels are, let’s look at another important thing to know about the ASA. By default, traffic will flow from an interface on a higher security level to an interface on a lower security level without restriction. The reverse is not the case. So it means a user on the Internet (interface with security level of 0) cannot connect to a user on the inside network (interface with security level 100). Let’s drive this home with a diagram.
Understanding this foundation of the ASA is very important for almost all other features of the device. Now remember that this is the default flow of traffic and more often than not, this default policy may need to be overridden. Consider the scenario in the diagram below:
Imagine you have some servers in the DMZ as shown above and these servers should be accessible from the Internet. With your configuration and the DMZ servers on an interface with security level of 50, the external user’s traffic to the DMZ will be denied by default because it is coming from a lower security level. This is an example of a situation where the default policy has to be changed and we do this by applying access-lists. We will see this configuration soon.
The firewall can be configured in two different firewall modes: Routed and Transparent. In Routed mode, the ASA is a router hop on the network. In Transparent mode, the ASA acts in stealth mode, like a bump in the wire, connecting the same network on its inside and outside interfaces. The Routed mode supports more features than the transparent mode. Transparent mode also makes you more prone to anger. Lol.
An ASA can also function in two context modes: Single and Multiple. Multiple context mode allows you to partition the ASA into multiple virtual devices known as security contexts. Each context can be seen as a standalone device with its interfaces, configuration, etc. Before version 9.0 of the ASA image, some features like VPN and dynamic routing were not supported in multiple context mode. Some of these features are now supported (some with limited capability).
If you are a network manager, a suitable punishment for any erring member of your network team is to ask the person to configure an ASA in transparent, multiple mode context.
Configuring the ASA
Now let the fun begin. In this article, we will focus on configuration through the CLI. We will see how to configure the ASA using the ASDM (Adaptive Security Device Manager) in the next article. The network diagram we will be using is shown below.
The routers have been configured with basic settings: IP addresses and default routes pointing to the ASA IP address for the respective interface.
On the ASA, let’s begin by configuring a hostname and domain-name for the ASA. The command to set the hostname is the same command that you use on the Cisco IOS devices: hostname<name>. The command to set the domain name is quite similar to the IOS but without the ‘ip’ so it is only: domain-name<domain>. As we continue, you will notice a trend with the ASA CLI commands that they usually don’t include the ‘ip’ part that the Cisco IOS has. For example instead of show ip route, the ASA uses show route.
There is no default enable password so just hitting the Enter key again will place you in enable mode. Now we can configure the interface settings. To enable an interface for use, four things need to be done: Enter a name for the interface using the nameif command, assign the interface a security level using the security-level command, assign an IP address to it using the ip address command, and bring the interface up using the no shutdown command.
NOTE: Things are a bit different on the ASA 5505 which has 8 Fast Ethernet Layer 2 switchports. These ports can be used to connect directly to hosts. The name, security-level and IP addressing are configured on the interface vlan<vlan>.
Notice from the above that by default, if you assign a name of ‘inside‘ to an interface, that interface is automatically assigned a security level of 100. Any other name on an interface assigns a security level of zero to it.
Basic configuration is done so let’s test. Keep in mind those security levels because we will begin to see their application.
As you can see, the Inside_Rtr can ping the inside interface of the ASA. Next, I try to ping the DMZ_Rtr. Since the Inside_Rtr is on a higher security level interface, this connection should go through, so what’s wrong? Let’s check on the ASA. One of the easiest ways is to enable logging on the console at level 7 (on a non-production network). I enable logging and initiate the ping again and this is what I see:
Here’s a brief explanation of what is happening. We mentioned that the ASA is a stateful firewall but state information is mostly useful for TCP and UDP traffic, not ICMP. Therefore by default, the ASA does not inspect ICMP. It means if I open a Telnet connection from Inside_Rtr to DMZ_Rtr, it should be allowed through since Telnet is TCP.
So before you start panicking that your configuration is wrong or that the ASA has turned to a cyborg that has a mind of its own, you need to know how the ASA operates. For the purposes of this article, I want ICMP to be one of the protocols to be inspected so I will add it. I know it’s beyond the scope of this article to show you how but I’m in a happy mood. 🙂
There’s a default class-map (called inspection_default) and policy-map (called global_policy) in the configuration of the ASA. Under the policy-map, you will see several inspect statements. Just add inspect icmp there and you are good to go, as we will see.
If you are using GNS3 to practice, you may not see this default policy-map in the configuration. There is a way to make it ‘magically’ appear. You can change the mode of the firewall to multiple context, save the configuration, stop the ASA, start it again and change it back to single mode, save again and stop and start. If that process is too long, just go to the Cisco site and the ASA configuration guide to copy the default class-map and policy-map.
That was a necessary detour. Now that we are back on track and are inspecting ICMP, let’s ping from Inside_Rtr to DMZ_Rtr again:
Aha! Now we are good. Likewise, I can ping the outside router.
Let’s move to the DMZ_Rtr. Will the DMZ_Rtr be able to ping the Inside_Rtr? And will the DMZ_Rtr be able to ping the Outside_Rtr? Remember your security-levels and then see the result below.
So the answer is No to the 1st question and then Yes to the second one. 50 cannot ping 100 by default but 50 can ping 0. You will get a log such as the one shown below when the ASA denies such traffic.
Finally, what do you think the Outside_Rtr can ping?
You are right. The Outside_Rtr won’t be able to ping anyone because it’s on the lowest security level among the three. There you have seen the default traffic flow of the ASA. But I want to take you a step further.
We have said that, by default, traffic will only flow from a higher security level to a lower security level. What if they are on the same level? 😀 Let’s briefly change the security level of the DMZ interface to zero and then ping between the DMZ_Rtr and the Outside_Rtr.
Now it fails. It means by default traffic between two interfaces on the same security level is not permitted. We can change this default setting with the same-security-traffic permit inter-interface command.
That’s my first hint for you. I will now return the DMZ interface to a security level of 50 as we had before. For my second hint, let’s ping from the Inside_Rtr to the outside interface of the ASA itself.
You will wonder why it isn’t working since the Inside_Rtr is on a higher security interface. This is the answer: The ASA will NOT allow a host to connect to its (the ASA’s) interface other than the interface on which that host is connected. You need to keep this in mind and not be tempted to do this during a troubleshooting session and conclude that you found the problem.
Cool! It’s not even Christmas yet and you get all these hints and tips. Okay, moving on. Let’s configure one more thing before we call it a day on this article. Let’s assume there’s an HTTP server on the DMZ that we want to be accessed from the outside network. As we know, this traffic is not currently being permitted. So how do we override it? By using access control lists. Yes, these ACLs are everywhere. Luckily, the concept is the same.
Configuring an ACL on the ASA is similar to configuring it on an IOS device. You still use the access-list command to configure the ACL and the access-group command to attach it to an interface. But we will see the difference soon.
On the IOS device, you attach the ACL under the interface configuration mode but not so with the ASA. You can read the “access-group outside_in in interface outside” as: Apply the ACL called outside_in to the outside interface in the inbound direction.
So let’s test. We can simulate an HTTP connection to the DMZ_Rtr by opening a Telnet connection to port 80 from the Outside_Rtr.
If we check the ASA, we will see the traffic hit on the ACL.
Oh and I hope you noticed the cool thing about the ASA: You can issue a “show” command from anywhere!
A note of warning though: Ensure you understand where you apply your ACLs. Let’s assume my ACL had a permit tcp any anyeq 80 statement and I attached it to the outside interface, I have effectively allowed any source IP address from the outside to access not just the DMZ server but also any inside device that will respond on the port 80.
One last thing: let’s ping from the DMZ_Rtr to Outside_Rtr.
As you can see, the ping succeeds. The default “deny any any” at the end of the outside_in ACL did not affect this traffic. Why is that? This is because of the stateful nature of the ASA (and the fact that we are inspecting ICMP). Now if you are running a dynamic routing protocol with a device on the other side of your firewall, you want to explicitly permit the routing protocol traffic in the ACL attached on the interface because that traffic is not inspected. These are just a few things for you to consider. Let’s stop here for now.
In this post we have been introduced to the Cisco ASA. The ASA operates on the concept of security levels and by default, traffic flows from a higher security level to a lower security level and not vice versa. To change this default behaviour, access control lists (ACLs) can be used. In the next post, we will see how to manage the ASA remotely (and there’s a shocker for you if you are not previously familiar with the ASA). We will also see how to use the ASDM for basic configuration. Till then, success in your studies.
Reference and Further Reading
Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 and 8.6: http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/asa_84_cli_config.html