You are here: Home » Cisco » ASA Firewall

Cisco ASA Security Levels

The Cisco ASA Firewall uses so called “security levels” that indicate how trusted an interface is compared to another interface. The higher the security level, the more trusted the interface is. Each interface on the ASA is a security zone so by using these security levels we have different trust levels for our security zones.

An interface with a high security level can access an interface with a low security level but the other way around is not possible unless we configure an access-list that permits this traffic.

Here are a couple of examples of security levels:

Security level 0: This is the lowest security level there is on the ASA and by default it is assigned to the “outside” interface. Since there is no lower security level this means that traffic from the outside is unable to reach any of our interfaces unless we permit it within an access-list.
Security level 100: This is the highest security level on our ASA and by default this is assigned to the “inside” interface. Normally we use this for our “LAN”. Since this is the highest security level, by default it can reach all the other interfaces.
Security level 1 – 99: We can create any other security levels that we want, for example we can use security level 50 for our DMZ. This means that traffic is allowed from our inside network to the DMZ (security level 100 -> 50) and also from the DMZ to the outside (security level 50 -> 0). Traffic from the DMZ however can’t go to the inside (without an access-list) because traffic from security level 50 is not allowed to reach security level 100. You can create as many security levels as you want…

Let’s take a look at a Cisco ASA firewall with three interfaces so you can see this behavior in action, here’s the topology I will use:

Above you see the Cisco ASA in the middle with three interfaces:

Interface E0/0 as the INSIDE.
Interface E0/1 as the OUTSIDE.
Interface E0/2 as our DMZ.

I will use the routers so we can generate some traffic between the different security levels. Let’s configure the ASA with these interfaces:

ASA1(config)# interface E0/0
ASA1(config-if)# nameif INSIDE
INFO: Security level for "INSIDE" set to 100 by default.
ASA1(config-if)# ip address 192.168.1.254 255.255.255.0
ASA1(config-if)# no shutdown

ASA1(config)# interface E0/1
ASA1(config-if)# nameif OUTSIDE
INFO: Security level for "OUTSIDE" set to 0 by default.
ASA1(config-if)# ip address 192.168.2.254 255.255.255.0
ASA1(config-if)# no shutdown

ASA1(config)# interface E0/2
ASA1(config-if)# nameif DMZ
INFO: Security level for "DMZ" set to 0 by default.
ASA1(config-if)# security-level 50
ASA1(config-if)# ip address 192.168.3.254 255.255.255.0
ASA1(config-if)# no shutdown

The nameif command is used to specify a name for the interface, unlike the description command the name of your interface is actually used in many commands so pick something useful. As you can see the ASA recognizes INSIDE, OUTSIDE and DMZ names. It uses a default security level of 100 for INSIDE and 0 for OUTSIDE/DMZ. I manually changed the security level of the DMZ interface to 50.

Let’s see what traffic patterns are allowed now shall we? First we’ll send some pings from the ASA…

Traffic from the ASA

The ASA can reach any device on any interface:

ASA1# ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

ASA1# ping 192.168.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

ASA1# ping 192.168.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

As you can see the ASA can reach any device in each of the different security zones. This makes sense since these devices are also using the ASA as their default gateway. Next step is to test some traffic between devices in different security zones.

By default the ASA has a global inspection policy (that we’ll discuss in another lesson) that doesn’t permit ICMP traffic. If you want to ping between devices through your ASA firewall then we have to inspect ICMP traffic, you can do it like this:

ASA1(config)# policy-map global_policy
ASA1(config-pmap)# class inspection_default
ASA1(config-pmap-c)# inspect icmp

Now ICMP traffic will be allowed between different interfaces.

Traffic from Inside

Let’s send some pings from R1 to R2 (outside) and R3 (DMZ):

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
Full Access to our 641 Lessons. More Lessons Added Every Week!
Content created by Rene Molenaar (CCIE #41726)

Give Membership a try - it's just $1 ►

452 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Previous Lesson
Cisco ASA ASDM Configuration

Next Lesson
Cisco ASA Dynamic NAT Configuration

Tags: Security

Forum Replies

telnet is working fine and I actually found 2 ways to allow ping in ASA
first one is ;

class-map global_policy
class-map icmp-class
 match default-inspection-traffic
class-map icmp
 match any
class-map inspection_default
!
!
policy-map icmp_policy
 class icmp
  inspect icmp 
!
service-policy icmp_policy global

and the second one is creating access list like this ;

access-list ICMP extended permit icmp any any
access-group ICMP interface global

both do the same job .

ReneMolenaar says:

Hi Donald,

In this example, I only used the routers so that I would have some devices to ping with/to. I also could have used computers but routers are easier since you can access them through the CLI and you don’t have to worry about firewalls blocking ICMP traffic.

Sometimes, it can be useful to have a router in front of the ASA. As a firewall, the ASA does a great job at packet filtering / VPNs but it’s a poor router. If you want to use specific features (like policy based routing) then using a router in front of the ASA works very well. If you don’t need an
... Continue reading in our forum
zahanison says:

Hi Rene,

To allow the DMZ traffic would you need to put an ACL on the inside interface allowing DMZ traffic or on the Inside interface allowing DMZ source to come in? Or do you need to put ACLs on both interfaces?

If DMZ is say 172.16.1.0/24 range and Inside is 192.168.1.0/24 range. Would you put ACL in DMZ interface allowing 172.16.1.0/24 access to 192.168.1.0/24 and then put the same ACL on inside as well?
robbo7987 says:

Hi,quick question regarding the service policy placement on the ASA, not including global because that’s pretty self explanatory. I created just a simple topology where the ASA was in the middle and has 2 routers on either side, the outside interface had a security level of 0 and inside 100, the outside interface is also blocking all traffic coming in. I implemented NAT on the ASA as well to change the inside network IP’s to the outside interface.

My policy map inspects ICMP and i applied it to a service policy that was placed on the inside interface, i tested
... Continue reading in our forum
MOD-NETWORK says:
Hi, Thanks From Post,
i have Done Everything and Worked find, unfortunately my firewall Dose not Allow DNS resolution from outside interface to in inside
should i apply another ACL or inspect DNS Traffic from outside to inside and VS ?
----------------------------------------------------------------------------------------------------------------------------
```
ASA3/SRV-A(config)# packet-tracer input TO-OUT tcp 0.0.0.0 53 6.6.6.6  53

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROU
```
... Continue reading in our forum

25 more replies! Ask a question or join the discussion by visiting our Community Forum