ASA – Security Levels

Security Levels

Last Updated: Oct 5, 2018 @ 9:32 am (UTC)

 

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”

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.

 

 Inspection

Some traffic types, such as ICMP or FTP, do not use flows, or have additional packets on different ports, which would require their own flow.To enable return traffic these protocols need to be inspected.

 

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.

 

Configuration

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

 

Basic Security Levels
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 Levels
same-security-traffic permit inter-interface

 

Test Scenarios

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.

 

Initial Configuration

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.

 

 
hostname Inside
!
interface GigabitEthernet0/1
 ip address 192.168.0.1 255.255.255.0
 no shut
!
ip route 0.0.0.0 0.0.0.0 192.168.0.254
hostname DMZ
!
interface GigabitEthernet0/1
 ip address 172.16.0.1 255.255.255.0
 no shut
!
ip route 0.0.0.0 0.0.0.0 172.16.0.254
hostname Outside
!
interface GigabitEthernet0/1
 ip address 10.0.0.1 255.255.255.0
 no shut
!
ip route 0.0.0.0 0.0.0.0 10.0.0.254
hostname ASA
!
interface GigabitEthernet0/0
 nameif inside
 security-level 100
 ip address 192.168.0.254 255.255.255.0 
!
interface GigabitEthernet0/1
 nameif outside
 security-level 0
 ip address 10.0.0.254 255.255.255.0 
!
interface GigabitEthernet0/2
 nameif dmz
 security-level 50
 ip address 172.16.0.254 255.255.255.0 
!
policy-map global_policy
 class inspection_default
  inspect icmp 
  inspect icmp error

 

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.

Source Destination Result
Inside DMZ Pass
Outside Pass
DMZ Inside Drop
Outside Pass
Outside Inside Drop
DMZ Drop

 

 


Scenario 1: ACLs and Security Levels

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

 

Apply ‘Deny All’ ACLs
! 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.

 

Source Destination Result
Inside DMZ Drop
Outside Drop
DMZ Inside Drop
Outside Drop
Outside Inside Drop
DMZ Drop

 

 


Scenario 2: Same Security Levels

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.

 

Configure the Same Security Levels
! 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.

Source Destination Result
Inside DMZ Drop
Outside Pass
DMZ Inside Drop
Outside Pass
Outside Inside Drop
DMZ Drop

 

 

This behaviour can be changed globally.

Permit Same Security Level Between Interfaces
! Configure same security
same-security-traffic permit inter-interface

 

 

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

 

Source Destination Result
Inside DMZ Pass
Outside Pass
DMZ Inside Pass
Outside Pass
Outside Inside Drop
DMZ Drop

 

 


Scenario 3: ACLs with Same Security Levels

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.

 

Apply ACLs With Same Security Levels
! 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.

 

Source Destination Result
Inside DMZ Drop
Outside Pass
DMZ Inside Drop
Outside Pass
Outside Inside Pass
DMZ Pass

 

 

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

Test ‘Same Level Security’ with ACLs
! 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.

 

Source Destination Result
Inside DMZ Pass
Outside Pass
DMZ Inside Pass
Outside Pass
Outside Inside Pass
DMZ Pass

 

 


Conclusion

ACLs override security levels, except between two interfaces with the same security level

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.

 

Leave a Reply