Configure Interface Security Levels and Access Lists on a Cisco ASA

Before you run this

This guide sets the security level on each ASA interface (its trust ranking, 0–100) and applies extended access lists to control which traffic is allowed into an interface. On an ASA, traffic from a higher-security interface to a lower one is permitted by default, but the moment you apply an inbound access-group to an interface, the ASA enforces that ACL and drops everything the ACL doesn't explicitly permit — there is an implicit deny ip any any at the end of every ACL. A single applied ACL can therefore cut production traffic and lock you out of management in one command.

You need privileged EXEC (enable) mode and then configuration mode on the ASA — this is the equivalent of root. You reach it over the console or an SSH session with an account that has privilege level 15.

Do this in a maintenance window, and:

• Keep the physical console cable connected (or a serial-over-LAN / OOB path). If your SSH session is on an interface you're about to filter, you can strand yourself.
• Back up the running config before you touch anything (shown below).
• Set a safety-net reload before applying ACLs, so a lockout self-recovers.
• Test in prose first: read every line, and if you have an ASAv lab or a spare unit, apply it there before the production box. Use packet-tracer (below) to prove the effect before you trust it.

Changes here are held in the running config until you write memory. That gives you a clean rollback: as long as you haven't saved, a reload restores the last saved config. Once you save, the old state is gone unless you kept the backup.

I'm writing for ASA software 9.x (5500-X series or ASAv) driven from the CLI. ASDM can do all of this through Configuration → Device Setup → Interfaces and Configuration → Firewall → Access Rules, but the CLI is the normal path for an ASA and is what I use here.

Step 0: Back up and set a safety net

Save the current config somewhere off-box and take a safety reload.

enable

! Save a copy to a TFTP server you control (replace the address/filename)
copy running-config tftp://192.0.2.50/asa-config-backup.txt

! Safety net: if you lock yourself out, the ASA reloads to the SAVED config in 10 min.
! Cancel it with "reload cancel" once you've confirmed everything works.
reload in 10

reload in 10 reloads to the startup (saved) config. So the workflow is: make changes, verify, then write memory, then reload cancel. If a change strands you, do nothing and the box comes back on the old config.

Step 1: Understand the security-level model

• Every named interface has a security level from 0 (least trusted) to 100 (most trusted).
• By convention inside is 100, outside is 0, and DMZs sit in between (e.g. 50).
• High → low traffic is allowed by default (subject to any ACL you apply).
• Low → high traffic is denied by default and needs an explicit ACL permit.
• Traffic between two interfaces at the same level is blocked unless you enable same-security-traffic permit inter-interface.

Step 2: Name interfaces and set security levels

Assign a name, security level, and IP to each interface. Replace names, levels, and addresses with your own.

configure terminal

interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 203.0.113.2 255.255.255.0
 no shutdown

interface GigabitEthernet0/1
 nameif inside
 security-level 100
 ip address 10.10.10.1 255.255.255.0
 no shutdown

interface GigabitEthernet0/2
 nameif dmz
 security-level 50
 ip address 172.16.1.1 255.255.255.0
 no shutdown

At this point, inside hosts can reach dmz and outside, and dmz can reach outside, all by default. Nothing from outside or dmz can initiate a connection inward to a higher level yet.

Step 3: Build extended ACLs for the traffic you want to allow inbound

Use object definitions for anything you'll reference more than once — it keeps rules readable and is the standard modern style on 9.x. Then write the ACL. Here I let the internet reach one web server in the DMZ on 443, and let the DMZ web server reach an internal database on one port.

! Named hosts (replace addresses/names with your own)
object network WEB-SERVER
 host 172.16.1.10
object network DB-SERVER
 host 10.10.10.20

! Inbound rule set for the OUTSIDE interface
access-list OUTSIDE_IN extended permit tcp any object WEB-SERVER eq https

! Inbound rule set for the DMZ interface
access-list DMZ_IN extended permit tcp object WEB-SERVER object DB-SERVER eq 1433

Two things worth stating plainly:

• ACL lines are evaluated top to bottom, first match wins, and there's an implicit deny at the end. Anything you don't permit is dropped.
• Because you're only creating the ACLs here, nothing is enforced yet. Enforcement happens in Step 4.

If your public-facing service also needs a NAT rule to translate the outside address to the DMZ host, that's a separate nat configuration — check the Cisco ASA Series CLI Configuration Guide, "Network Address Translation" chapter, for the exact nat (real,mapped) syntax rather than guessing it here.

Step 4: Apply the ACLs — the moment enforcement starts

access-group binds an ACL to an interface in a direction. Inbound (in) is the standard place to filter on the ASA.

access-group OUTSIDE_IN in interface outside
access-group DMZ_IN in interface dmz

The instant you run these, the implicit deny is live on those interfaces. Confirm with packet-tracer before you save.

Step 5: Verify before you commit

packet-tracer simulates a packet through the whole ASA policy and tells you the verdict without touching real traffic. Test both an allowed and a denied flow.

! Should end in ALLOW
packet-tracer input outside tcp 198.51.100.7 40000 172.16.1.10 443

! Should end in DROP (nothing permits SSH inbound from the internet)
packet-tracer input outside tcp 198.51.100.7 40000 172.16.1.10 22

Check the configuration and live hit counters:

show interface ip brief          ! interfaces up/up with correct IPs
show nameif                      ! names + security levels
show run access-list             ! the ACLs as configured
show run access-group            ! which ACL is bound where
show access-list OUTSIDE_IN      ! per-line hit counts once traffic flows

Confirm you still have your management session and that expected production flows work. Only then commit:

write memory
reload cancel

write memory saves to startup config; reload cancel cancels the safety-net reload from Step 0.

Undo and rollback

If you haven't saved yet and something is wrong, the simplest, safest recovery is to let the scheduled reload fire (or trigger reload yourself) — the ASA comes back on the last saved config.

To back out specific changes by hand, negate them. Removing the access-group stops enforcement immediately; removing the ACL and objects cleans up:

configure terminal
no access-group OUTSIDE_IN in interface outside
no access-group DMZ_IN in interface dmz

! Remove a single ACL line by re-typing it with "no", or clear the whole ACL:
clear configure access-list OUTSIDE_IN
clear configure access-list DMZ_IN

To change a security level, just re-enter the interface and set the value (security-level 40) or no security-level to drop it back to the default for that interface.

To restore the whole config from your backup, copy it back and reload:

copy tftp://192.0.2.50/asa-config-backup.txt startup-config
reload

That replaces the startup config with your backup and reboots onto it — the cleanest full rollback when a piecemeal fix isn't enough.

For exact syntax on NAT, object-groups, and time-based or logging options on ACLs, the authoritative reference is Cisco's ASA Series CLI Configuration Guide for your specific 9.x release on cisco.com — check it rather than guessing a keyword, because these move between minor versions.