THE CURIOUS CASE OF THE ASA’S SECURITY LEVELS
Sunday November 13, 2016
The Misunderstood Firewall
A few weeks ago, I found that I did not understand the ASA as well as I thought I did. Again.
Even after years of working with the ASA, I still seem to underestimate them. Just when I think I know them well, I find myself in a scenario that causes me to reevaluate what I thought I knew.
A colleague and I were asked to create a few new networks for some corporate Business Units. They intended to have their customer’s data in these networks, so they needed multitenancy. Fair to say that it’s a standard request so far.
We go about creating VLANs, VRF’s, putting the appropriate trunking in place. We go to the ASA, create two sub-interfaces, enter IP addressing, give them names, assign security level 80 to them both, and finally apply an ACL.
Sound fine so far? It looked good to us too. No traffic could pass between them, but they could still get to the internet and their DR sites, so it looked like mission accomplished. Well, it would be a pretty dull blog post if it were that simple.
A few days later, it became known to us that we needed to create a management network that could access both of these environments. OK, fine, no worries, we can do that.
So we repeat the same process of allocating VLANs, sub interfaces, names, security level 80, and so on. Only we have a problem. The management network can’t access either of the Business Unit networks.
I begin to check ACLs. No problem there… How about NAT? Looks fine. Surely not routing? Nope, it’s ok. What is going on?
What We Have Here Is A Failure To Communicate
So, I was under the impression that security-levels are only used for out of the box security, and they are superseded when ACLs were applied to an interface. It’s this misunderstanding that lead to be scratching my head for an hour, wishing I had a bottle of scotch and two glasses in my drawer, like they do in the movies.
Eventually, out of desparation and because I had nearly pulled out every hair on my head, I started thinking about security levels. I knew that there was a command to allow traffic between interfaces with different security levels, but ACL’s override them anyway, so that shouldn’t apply, right?
Well, as I said, I was running out of ideas. So, I went ahead and changed the security level of the management interface to 85, just for kicks.
Hold on a sec… that ping I had running just started working… What just happened?
So, I Did Some Research…
It was clear that I did not understand the ASA like I think I did. Clearly ACLs don’t override security levels. But a quick Google search tells me that they do… What’s going on? Time to do my own research.
So I pulled out VIRL, created a simple topology with three-armed ASA and tested out a few different scenarios, which I documented in the ASA Security Levels article.
The basic answer is that ACLs DO override interface security levels. With one exception.
What it comes down to is this: When two interfaces have the same security level, no ACL, even if it’s an ‘Allow All’ ACL, will allow traffic to flow between them without the same-security-traffic global configuration command.
The Conclusion of the Matter
In the end, there are two ways we can deal with this situation (assuming we want traffic passing between these two interfaces).
The first option is to use the same-security-traffic command. This will definitely solve the problem, but it is a global command. This causes a potential problem; If there are several interfaces with the same level, they will all have traffic allowed between them. This may not be a suitable scenario for multitenancy.
In my case, I needed to change the security levels on the interfaces that needed to communicate. Then the ACLs would apply, and I wouldn’t change anything globally.
One thing to keep in mind though, is that this can be fantastic in a true-multitenancy environment. Every customer or business unit that needs to be isolated can have the same security level applied. Then there will be no leakage between them, even if there’s a misconfigured ACL.
For me, the real conclusion of the matter, all things having been considered, is to show a bit of humility and not assume I know the ASA as well as I think.
I hope this is helpful to someone.