In this article, I’ve compiled a base configuration to be used for setting up new Cisco Adaptive Security Appliances, or ASAs for short, and included some pointers on which other configuration steps are necessary to get most typical deployments up and running.
If you are setting up High Availability between two ASA firewalls, I recommend looking the article in the link below before following along further in this article.
Cisco ASA - High Availability Configuration (CLI)
Introduction
The purpose of this article is to quickly go through several general settings and configurations that should be applied in most deployments. I mainly created this article for myself so that I always have quick access to this “template” of configuration and have it function as a checklist for future deployments.
The following general configuration is presented as-is, with some commentary where I felt it was necessary.
Activate Physical Interface
Assuming you have your ASA up and running powerwise, first thing that needs to be done it to activate its physical interfaces. For standard ASA hardware (older non-Firepower hardware), this step can be skipped but if you have Firepower hardware running ASA software, you may need to activate the physical interfaces form the chassi management system before they can be used in the ASA configuration.
Firepower hardware running ASA software comes in two different modes: Appliance mode and Platform mode.
In Appliance mode, all configuration is done inside the ASA operating system.
In Platform mode, most of the configuration is done in the ASA operating system but some system features, like activating physical interfaces, is done in the chassi’s operating system called FXOS. There are also some other parameters, like NTP, that needs to be configured on the chassi itself if the ASA is in platform mode. For Appliance mode, this is done in the ASA.
Appliance mode should be the default mode on newer Firepower hardware running ASA, and we want to keep it that way. However, to make sure your Firepower hardware is in the correct mode, use the command “show fxos mode” to confirm it.
General Configuration
The following general configuration is presented as-is, with some commentary where I felt it was necessary.
username netadmin password DISCO123! privilege 15
enable password DISKO123!
no service password-recovery
clear configure dhcpd
! Configure Outside Interface (facing the Internet):
! If possible, assign Standby IP address for improved High Availability monitoring.
interface Ethernet1/1
nameif outside
security-level 0
ip address 209.165.201.11 255.255.255.0 standby 209.165.201.12
no shutdown
! Configure Inside Interface (facing internal networks via linknet to Core or similar):
! If possible, assign Standby IP address for improved High Availability monitoring.
interface Ethernet1/2
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0 standby 10.1.1.2
no shutdown
! Optional: Configure Dedicated Management interface. Shutdown if not needed.
interface Management1/1
management-only
shutdown
nameif management
security-level 100
no ip address
! Disable DHCP server on all data interfaces (non-management):
no dhcpd enable inside
no dhcpd enable outside
! Configure time/DNS/miscellaneous settings:
clock timezone Europe/Stockholm
dns domain-lookup outside
dns server-group DefaultDNS
name-server 10.10.20.101 inside
name-server 208.67.220.222 outside
domain-name yourCompany.com
! Configure NTP servers:
ntp server 192.121.108.100
ntp server 162.159.200.1
ntp server 91.209.0.17
! Configure basic SNMP parameters:
snmp-server location Datacenter Main Floor 1 Rack AA01
snmp-server contact itsecurity@yourCompany.com
snmp-server host inside 10.10.20.10
snmp-server enable traps all
! Configure general logging and Syslog settings:
logging enable
logging timestamp
logging asdm informational
logging buffer-size 20000
logging buffered informational
logging host inside 10.10.20.11 udp/514
logging queue 8192
logging trap informational
logging permit-hostdown
no logging monitor
no logging console
no asdm history enable
! Enable Local user accounts for SSH/Telnet/HTTPS(ASDM) logins:
aaa authentication enable console LOCAL
aaa authentication http console LOCAL
aaa authentication serial console LOCAL
aaa authentication ssh console LOCAL
aaa authentication telnet console LOCAL
aaa authentication login-history
aaa authorization exec LOCAL auto-enable
console timeout 15
! Enable ASDM access and specify Network Administrator networks:
asdm image disk:0/asdm-7191.95.bin
http server enable 443
http server idle-timeout 30
http 10.10.10.0 255.255.255.0 inside
http 10.10.20.0 255.255.255.0 inside
http 10.10.30.0 255.255.255.0 inside
! Don't forget your VPN IP Pool network if needed for managing via Remote Access VPN:
http 192.168.99.0 255.255.255.0 inside
! Enable SSH access and specify Network Administrator networks:
ssh 10.10.10.0 255.255.255.0 inside
ssh 10.10.20.0 255.255.255.0 inside
ssh 10.10.30.0 255.255.255.0 inside
! Don't forget your VPN IP Pool network if needed for managing via Remote Access VPN:
ssh 192.168.99.0 255.255.255.0 inside
ssh timeout 15
ssh version 2
ssh key-exchange group dh-group14-sha256
! Create a Key Pair for SSH etc., see 3DES/AES Strong Encryption section further down.
! Use either RSA or ECC algorithm for your Key Pair:
crypto key generate rsa general-keys modulus 4096
crypto key generate ecdsa elliptic-curve 256/384/521
! Deny traffic between interfaces of the same security level. To enable (permit) traffic between interfaces of the same security level, use permit statements in the interfaces access-lists (which is the way you should be working with firewall rules anyway, do not rely on security levels):
no same-security-traffic permit inter-interface
! Permit traffic entering an interface and exiting the same interface (hairpin/u-turn, which can be needed in some VPN use-cases where traffic comes in via one VPN tunnel and needs to exit another tunnel, be it Remote Access VPN and/or site-2-site VPN):
same-security-traffic permit intra-interface
! Configure Default Route and Internal Network Routes:
route outside 0.0.0.0 0.0.0.0 209.165.201.1
route inside 10.0.0.0 255.0.0.0 10.1.1.254
route inside 172.16.0.0 255.240.0.0 10.1.1.254
route inside 192.168.0.0 255.255.0.0 10.1.1.254
! Enable Reverse Path Forwarding to compare incoming traffic's source address to the routing table, to prevent spoofing, by making sure traffic is coming in on expected interfaces:
ip verify reverse-path interface inside
ip verify reverse-path interface outside
! Designate a “management” interface. While the ASA can still be accessed via IP addresses belonging to interfaces other than the one specified, this command specifies which interface can be accessed through other interfaces and via VPN (remote-access and site-2-site tunnels), which would be considered traffic coming in from the “outside” interface and hitting the “inside” interface.
management-access inside
The command above also affects some traffic that is originated by the firewall itself and needs to enter VPN tunnels to get where it needs to go (for instance, an ASA at a branch office sending syslog messages via a site-2-site tunnel to headquarters where the syslog server/collector is hosted).
! Configure various banners.
! Look up proper (legal) banner examples that work for your organization:
banner exec ========================================================
banner exec !! UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED !!
banner exec ========================================================
banner login ========================================================
banner login !! UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED !!
banner login ========================================================
banner motd ========================================================
banner motd !! UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED !!
banner motd ========================================================
banner asdm ========================================================
banner asdm !! UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED !!
banner asdm ========================================================
! Enable basic global settings for Remote Access VPN. While this is just a snippet of the configuration needed, most Remote Access VPNs will need these features activated:
webvpn
enable outside
anyconnect enable
! Disable VPN IP address assignments from DHCP/AAA servers, if not needed:
no vpn-addr-assign dhcp
no vpn-addr-assign aaa
! Configure AnyConnect images (now Cisco Secure Client) for various operating system: anyconnect image disk0:/cisco-secure-client-win-5.0.04032-webdeploy-k9.pkg 1 anyconnect image disk0:/cisco-secure-client-macos-5.0.04032-webdeploy-k9.pkg 2
! Enable ICMP Inspection globally for "stateful" ICMP behavior:
policy-map global_policy
class inspection_default
inspect icmp
inspect icmp error
Install 3DES/AES Strong Encryption License
Cisco Firewalls are usually shipped without strong encryption enabled out of the box, this needs to be enabled using a 3DES/AES strong encryption license. This license usually comes free with the purchase.
You can activate this license either using a PAK license token (for old ASAs) or Smart Licensing (new ASAs). The Smart Licensing variants of the license comes either as a specific 3DES/AES Encryption License or a general Firepower 2k/3k/4k appliance license. Either one will activate 3DES/AES strong encryption, which is something you really want.
Once you have activated your 3DES/AES strong encryption license, reboot your firewall(s) for it to take full effect. After the reboot, generate a new key pair for things like SSH etc., or you might run into weird issues.
! Use either RSA or ECC algorithm for your Key Pair:
crypto key generate rsa general-keys modulus 4096
crypto key generate ecdsa elliptic-curve 256/384/521
Upgrade ASA software to the latest recommended release
Since new ASAs can be delivered with whatever software version made sense at the time, make sure to check what the current recommended software version is and upgrade to it pre-deployment.
Cisco Secure Firewall ASA Compatibility
Configure Interface Access Control Lists
Interface ACLs are up to you to configure to match your needs, below is just an example of a simple ACL for basic web access.
! Create ACL and configure basic inside (outbound) access (Web/DNS/ping):
access-list INSIDE_INTERFACE_IN extended permit tcp any any eq www
access-list INSIDE_INTERFACE_IN extended permit tcp any any eq https
access-list INSIDE_INTERFACE_IN extended permit udp any any eq 53
access-list INSIDE_INTERFACE_IN extended permit tcp any any eq 53
access-list INSIDE_INTERFACE_IN permit icmp any any
access-list INSIDE_INTERFACE_IN deny ip any any
! Assign the ACL to the inside interface:
access-group INSIDE_INTERFACE_IN in interface inside
! Create ACL and configure basic outside (inbound) access (deny everything, unless you are hosting something on the inside that needs to be published on the outside):
access-list OUTSIDE_INTERFACE_IN extended deny ip any any
! Assign the ACL to the outside interface:
access-group OUTSIDE_INTERFACE_IN in interface outside
Configure Network Address Translation
Configuring NAT/PAT is also highly dependent on what your particular needs are, so I’m going even going to try to explain all the different NAT/PAT types here.
But just for the sake of it, the configuration below can be used to NAT/PAT all traffic from the inside to the outside using the outside interface’s IP address. This works reasonably well for smaller deployments, for bigger deployments I would suggest to try to use multiple public IP addresses for NAT/PAT and “hiding” different internal IP networks behind different public IP addresses.
nat (inside,outside) after-auto source dynamic any interface
The "after-auto" parameter makes sure this NAT rule is placed in the section furthest down in the NAT ruleset (after Network Object NAT rules, which are created automatically based on NAT settings inside Objects), making it easier to make more detailed NAT rules above it that will be hit first.