All things being equal may cause a small dilemma for your network. Or, it may secure it. Here, we are talking about the ASA’s Security Levels, which can have an important impact on your your traffic flow.

Security Levels are applied to an interface to describe a level of trust. This is a mandatory configuration item, and can be set anywhere in the range of 0 – 100. The higher the value the more the interface is trusted.

There is something that is a little inaccurate about that last sentence. Setting the security level on an interface is not really about how much you trust the interface, but about how much you trust the network behind it. For this reason, security levels play a part in creating logical security zones.

Typically, when an interface is configured, a default security level of 0 is applied, which says that this is a completely untrusted interface. It’s up to the firewall administrator to select a more meaningful value.

The exception to this is when creating the inside interface. When this interface is named with the nameif command, the ASA automatically assigns it security level 100, the highest level of trust.

It is also quite common for an ASA to be configured with a DMZ interface. This is typically set to a security level of 50.

The importance of security levels is not really about how high or how low they are. Security Levels are relative.

The standard behaviour for the ASA is to permit traffic travelling from an interface with a higher security level to an interface with a lower security level. For example, traffic will be allowed to flow from the inside interface to the outside interface. Correspondingly, the ASA will deny traffic from a lower level interface to a higher level interface.

This means that setting the inside and outside interfaces to 100 and 0 would have the same result as setting them to 51 and 50. As long as one is higher than the other, traffic will flow from the higher to the lowe interface, and be denied from the lower to the higher.

There is a scenario that has not been considered yet. What if the interfaces have the same security level? The default behaviour is to deny traffic between interfaces with the same security level. This behaviour can be changed by using the same-security-traffic permit inter-interface command. This is a global command, and will allow traffic between all interfaces of the same level, which may not always be desirable. This cannot be configured selectively.

The security level check applies to the first packet in a flow. This means that, once a flow has been established, security levels are not evaluated for the rest of the packets in the flow. The result is that return traffic is permitted from a lower interface to a higher one.

This behaviour changes again when ACL’s are applied. In most cases, once an ACL is applied, it takes precedence over the security level of an interface. Incidentally, this is required if  you need to get traffic flowing from a lower interface to a higher one.

In certain cases, there is some unexpected behaviour when mixing ACLs and interface with the same security levels. The scenarios below will make this clear.

Security levels are quite simple to configure, as shown below.

interface gigibit 0/0
  nameif DMZ
  security-level 50

Allowing traffic between interfaces with the same security level is in global configuration, and will affect all interfaces with the same security level.

same-security-traffic permit inter-interface

In the next few sections, we’re going to look at the paractical behaviour of the ASA security levels, especially when combined with ACLs. To do this, we’ll use the simple topology below, with an ASA with three interfaces; Inside, DMZ, and Outside.

The configuration below has been tested in VIRL, using an ASAv running IOS 9.5.2

The routers are used as hosts for generating test ping traffic. Their configuration won’t change for the rest of the lab. Alternatively, hosts of some sort could be used in their place.

[rtbs name=”asaseclevel-initialconfig”]

Finally, to get a baseline, we can try pinging from the various routers. The table below shows the results of the ping.

As expected, traffic from higher security levels to lower security levels is passed, while traffic from lower security levels to higher is dropped.

In the first scenario, we will apply a ‘deny all’ ACL to each interface:

! Create ‘deny all’ ACLs
access-list Inside extended deny ip any any 
access-list DMZ extended deny ip any any 
access-list Outside extended deny ip any any 

! Apply to interfaces
access-group Inside in interface inside
access-group Outside in interface outside
access-group DMZ in interface dmz

The ping test shows that this overrides the security level configuration, as even traffic from a higher level cannot pass to a lower level interface.

For the first part of the second scenario, the ‘deny all’ ACLs are removed, and traffic between interfaces of the same security level are tested.

For this reason, the Inside and DMZ interfaces are both set to a security level of 80.

! Remove ACLs
no access-group Inside in interface inside
no access-group Outside in interface outside
no access-group DMZ in interface dmz

! Set Inside and DMZ to the same security-level
interface GigabitEthernet0/0
 security-level 80

interface GigabitEthernet0/1
 security-level 80

The ping test shows that traffic between the inside and DMZ traffic is now dropped.

This behaviour can be changed globally.

! Configure same security
same-security-traffic permit inter-interface

Which allows traffic to pass between ALL interfaces with the same security level.

Things get a bit murky with scenario three. Here, the same-security-traffic command is removed, and the ACL’s are applied again. They are then configured to ‘Allow All’ traffic (‘Deny all’ is removed).

The Inside and DMZ interfaces are stillboth configured with security level 80.

! Disable same-level security
no same-security-traffic permit inter-interface

! Apply ACLs to interfaces again
access-group Inside in interface inside
access-group Outside in interface outside
access-group DMZ in interface dmz

! Add allow rule
access-list Inside extended permit ip any any 
access-list DMZ extended permit ip any any 
access-list Outside extended permit ip any any 

! Remove deny rule
no access-list Inside extended deny ip any any 
no access-list DMZ extended deny ip any any 
no access-list Outside extended deny ip any any

As shown with the ping test, this does not allow all traffic. This is one case where the ACL does not completely override the security level.

Simply put, traffic will not flow between interfaces of the same security level, unless explicitly configured to do so with teh same-security-traffic command. This is true regardless of ACL configuration.

To further prove this, traffic is allowed over interfaces of the same security level once again.

! Enable same-level security
same-security-traffic permit inter-interface

And, as expected with this configuration and the ‘Allow All’ ACLs, all traffic passes through the ASA.

Security levels are applied to an ASA interface to describe how much the network behind it is trusted. If no ACLs are applied to the interface, traffic will be permitted to pass from an interface with a higher security level to an interface with a lower security level. However, traffic from a lower interface to a higher interface will be denied.

Generally when applying ACLs to an interface, the ACL takes precedence over the security level. However, as shown in the scenarios above, if the interfaces have the same security level, traffic will not be permitted, unless the same-security-traffic global configuration command is used.