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.
InspectionSome 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.
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.
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
The ASA has ICMP inspection enabled to allow ping to work correctly. Other than this and the basic interface configuration, the rest of the configuration is lest as default.
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.
Scenario 1: ACLs and Security Levels
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.
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.
! 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.
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.
! 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.
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.
Last update 2017-08-29 09:20