ASA Firewall Configuration

--- title: ASA Firewall Configuration tags: Cisco IOS, networking, manual, reference, router, switch, technical, security, firewall --- <header> <h6>ASA Firewall Configuration</h6> > [toc] </header> --- # Getting Started ## ASA CLI Overview The ASA command line interface has a similar look and feel to the Cisco router IOS. However, the ASA CLI also has different commands. This table contrasts common IOS router and ASA commands. | IOS Router COmmand | Equivalent ASA Command | | ------------------ | ---------------------- | | <div class='mono'>enable secret password</div> | <div class='mono'>enable password password</div> | | <div class='mono'>line vty 0 4 &ensp;password password &ensp;login</div> | <div class='mono'>password password</div> | | <div class='mono'>ip route</div> | <div class='mono'>route int_name</div> | | <div class='mono'>show ip route</div> | <div class='mono'>show route</div> | | <div class='mono'>show ip interface brief</div> | <div class='mono'>show interface ip brief</div> | | <div class='mono'>show ip nat translations</div> | <div class='mono'>show xlate</div> | | <div class='mono'>copy running-config startup-config</div> | <div class='mono'>write [memory]</div> | | <div class='mono'>erase startup-config</div> | <div class='mono'>write erase</div> | :::info ASA CLI commands can be executed regardless of the current configuration mode prompt. The IOS command <code>do</code> is not required nor recognized. ::: ## Factory Default Configuration Most ASA devices ship with a **default configuration** that, in the majority of cases, is sufficient for a basic SOHO deployment. The default hostname is **ciscoasa**. By default, the privileged EXEC and console line passwords are not configured. All interfaces are **shut down** and **unnamed**. :::success The ASA can be restored to its factory default configuration by using the <code>configure factory-default</code> global configuration mode command. ::: ## Interactive Setup Wizard he ASA provides an **interactive setup initialization wizard** to simplify the initial configuration of the device. This wizard is displayed when there is **no startup configuration**, or if the startup configuration is erased and the ASA is rebooted using the <code>write erase</code> and <code>reload</code> privileged EXEC commands. To cancel the wizard and display the ASA default user EXEC mode prompt, enter <code>no</code> at the startup prompt. After the interactive portion of the wizard is completed, the security appliance displays the summary of the new configuration and prompts the user to save or reject the settings. Answering **yes** saves the configuration to **flash** and displays the configured hostname prompt. Answering **no** restarts the Setup Initialization wizard from the beginning with any changes that had been made as the new default settings. This enables the administrator to correct a misconfigured setting. # Basic Configuration Settings An ASA should be configured with basic management settings: * <code>hostname name</code> * <code>domain-name name</code> * <code>enable password password</code> * <code>banner motd message</code> * <code>key config-key password-encryption [new-pass [old-pass]]</code> * <code>password encryption aes</code> :::info The privileged EXEC password is automatically encrypted using **MD5**. However, stronger encryption using **AES** should be enabled. ::: Like the IOS CLI, legal notification is provided using the <code>banner motd</code> command. However, the command is configured somewhat differently than the IOS version. To configure a banner with several lines, the <code>banner motd</code> must be entered multiple times. To remove a line(s), use the <code>no banner motd message</code> command. ## Interface Configuration Settings Each configured interface must have a **name**, a **security-level**, an **address**. * <code>nameif name</code> — Configure the interface name. * <code>security-level {0-100}</code> — Interfaces with a security-level of 100 are considered completely **trusthworthy**. Interfaces with a security-level of 0 are considered **untrustworthy**. The security level **default behavior** is to **implicitly permit** traffic from a higher security interface to an interface with the same or lower security level. Traffic moving from **lower to higher** security levels is **implicitly denied**. * <code>ip address address mask</code> — (Optional) manually configure the interface's IP address. :::danger Using the <code>no nameif name</code> command will delete **all configurations** that refer to the named interface. To rename an interface, simply use the <code>nameif</code> command with a new value. ::: #### Example ```pug ASA(config-if)# interface g1/3 ASA(config-if)# nameif DMZ ! INFO: Security level for "DMZ" set to 0 by default. ASA(config-if)# security-level 50 ASA(config-if)# ip address 192.168.2.1 255.255.255.0 ASA(config-if)# no shutdown ASA(config-if)# exit ASA(config)# ``` ### DHCP/PPPoE Addresses For interfaces that may be assigned IP addresses through remote means (dynamically or through remote management), an alternate configuration may be used: * **DHCP** — Used when an interface is connecting to an **upstream device providing DHCP** services. The interface can be a **DHCP client** and discover its IP address and DHCP-related information from the **upstream device**. ```pug ASA(config-if)# ip address dhcp ASA(config-if)# ip address dhcp setroute ``` * **PPPoE** — Used when an interface is connecting to an **upstream DSL device** providing **point-to-point connectivity over Ethernet** services. The interface can be a **PPPoE client** and discover its IP address from an **upstream PPPoE DSL device**. ```pug ASA(config-if)# ip address pppoe ASA(config-if)# ip address pppoe setroute ``` ### Bridged Virtual Interfaces In ASA IOS software versions 9.7 and later, individual ports can be **combined into bridge groups** that make them act like switch ports on the same logical network. In this way, multiple devices can be connected directly to the ASA device inside **logical networks**. This is done by configuring the ports into **bridged virtual interfaces (BVI)**. The BVI is then configured with a name, security-level, IP address and mask, and other settings. In order to permit devices on different physical interfaces, the <code>same-security-traffic permit inter-interface</code> global configuration command must be configured. A drawback to using BVIs is that many commands, such as **`no shutdown`**, must be configured on the individual interfaces. In addition, if an **access list** is to be used on the BVI, the list must be grouped with each physical interface individually. ## Default Static Routes If an ASA is configured as a **DHCP client**, then it can receive and install a default route from the **upstream device**. Otherwise, a default static route must be configured using the <code>route interface-name 0.0.0.0 0.0.0.0 next-hop-address</code> command. To verify the route entry, use the <code>show route</code> command. ## Remote Access Services Telnet or SSH is required to manage an ASA device, when using the CLI remotely. To enable Telnet services, use the following commands: ### Telnet Configuration ```pug ASA(config)# password <password> ASA(config)# telnet { ip-address mask | ipv6-address/prefix } ifname // optional settings: ASA(config)# telnet timeout <minutes> ``` :::success To remove the Telent configuration, use the <code>clear config telnet</code> command. ::: To configure the Telnet service to use the local authentication database instead, use the <code>aaa authentication telnet console LOCAL</code> command. #### Example ```pug ASA(config)# password cisco ASA(config)# telnet 192.168.1.3 255.255.255.255 INSIDE ASA(config)# telnet timeout 3 ASA(config)# ASA(config)# show run telnet ! telnet 192.168.1.3 255.255.255.255 INSIDE ! telnet timeout 3 ! ASA(config)# ``` ### SSH Configuration ```pug ASA(config)# username <name> password <password> ASA(config)# aaa authentication ssh console LOCAL ASA(config)# crypto key generate rsa modulus <modulus_size> ASA(config)# ssh { ip-address mask | ipv6-address/prefix} <interface-name> // optional settings: ASA(config)# ssh version <number> ASA(config)# ssh <authorized-host-ip> <subnet> <interface-expected> ASA(config)# ssh timeout <minutes> ``` :::success To remove the SSH configuration, use the <code>clear config ssh</code> command. ::: #### Example ```pug ASA(config)# username ADMIN password class ASA(config)# aaa authentication ssh console LOCAL ASA(config)# crypto key generate rsa modulus 2048 ! Keypair generation process begin. Please wait... ASA(config)# ASA(config)# ssh 192.168.1.3 255.255.255.255 INSIDE ASA(config)# ssh 192.168.1.4 255.255.255.255 INSIDE ASA(config)# ssh 172.16.1.3 255.255.255.255 OUTSIDE ASA(config)# ssh version 2 ASA(config)# show ssh ASA(config)# ! Timeout: 5 minutes ! Version allowed: 2 ! ! <...output truncated...> ! ! Hosts allowed to ssh into the system: ! 172.16.1.3 255.255.255.255 OUTSIDE ! 192.168.1.3 255.255.255.255 INSIDE ! 192.168.1.4 255.255.255.255 INSIDE ! ASA(config)# ``` ## Network Time Protocol Network Time Protocol (NTP) services can be enabled on an ASA to obtain the date and time from an NTP server: ```pug ASA(config)# ntp authenticate ASA(config)# ntp trusted-key <id> ASA(config)# ntp authentication-key <id> sha-256 <key-pass> ASA(config)# ntp server <ip> [key <id>] ``` #### Example ```pug ASA(config)# ntp authenticate ASA(config)# ntp trusted-key 1 ASA(config)# ntp authentication-key 1 sha-256 cisco123 ASA(config)# ntp server 192.168.1.254 ASA(config)# ``` ## DHCP Services ### DHCP Provisioning An ASA can be configured to be a DHCP server to provide IP addresses and DHCP-related information to hosts: ```pug ASA(config)# dhcpd address <low_address> - <high_address> <interface> ASA(config)# dhcpd enable <interface> // optional settings: ASA(config)# dhcpd dns <external-dns-server-addresses> ASA(config)# dhcpd lease <seconds> ASA(config)# dhcpd domain <domain_name> ``` :::info If the ASA outside interface was configured as a **DHCP client**, then the <code>dhcpd auto_config OUTSIDE</code> global configuration mode command can be used to pass the DHCP-obtained information to the DHCP clients inside the secured network. ::: #### Example ```pug ASA(config)# dhcpd address 10.0.0.1-10.0.0.255 INSIDE ASA(config)# dhcpd dns 192.168.1.10 192.168.1.11 ASA(config)# dhcpd lease 1800 ASA(config)# dhcpd domain example.com ASA(config)# dhcpd enable INSIDE ASA(config)# ``` To verify DHCP settings, use the following commands: * <code>show dhcpd state</code> — Displays the current DHCP state for inside and outside interfaces. * <code>show dhcpd binding</code> — Displays the current DHCP bindings of inside users. * <code>show dhcpd statistics</code> — Displays the current DHCP statistics. ### ASA as a DHCP Client When an ASA device has an interface that is connected to an **upstream device** providing **DHCP services**, the interface can be configured as a **DHCP client**, to discover its IP address and DHCP-related information from the upstream device. ```pug ASA(config)# ip address dhcp ASA(config)# ip address dhcp setroute ``` # Configuration Objects Objects are **reusable components** for use in configurations. Objects make it easy to **maintain configurations**, because when an **object is modified**, the change is **automatically applied** to all rules that use the **specified object**. There are two types of objects that can be configured: * **Network object** — A network object can contain a host, a network IP address, a range of IP addresses, or a fully qualified domain name (FQDN). * **Service object** — Contains a protocol and optional source and/or destination port. These objects can be used in **NAT**, **access lists**, and **object groups**. ## Object Groups Objects can be **attached** or **detached** from one or more **object groups** as needed, ensuring that the objects are **not duplicated**, but can be re-used wherever needed. By grouping like objects together, an **object group** can be used in an **access control entry** (ACE) instead of having to enter an ACE for each object separately. Object groups can include any of the following components: * **Network** — Specifies a group of host or subnet IP addresses. * **User** — Specifies single user, local or import user group. * **Service** — Specifies a group of TCP/UDP ports and services. * **ICMP-Type** — Specifies a group of ICMP types, such as **echo**. * **Security** — Specifies identity attributes such as a **security-group**. * **Protocol** — Specifies a group of protocols, such as **TCP**, etc. :::warning Although **protocol** object groups can be created, it is recommended against. **Service** object groups should be used instead. ::: ### Object Group Configuration To create an object group, use the <code>object-group group-type name</code> configuration command to enter the **object-group subconfiguration** mode. After entering the command, add objects to the group using object configuration commands of the **appropriate type** (i.e. network-objects for network-groups, etc). **Other group-objects** may also be assigned while in **object-group subconfiguration** mode. This creates **nested object-groups**. To remove **all object groups** from the configuration, use the **`clear config object-group`** configuration command. Verify object group configurations via the **`show run object-group`** command. #### Network Groups **Network** object groups can contain **multiple network objects** as well as **inline networks** or **hosts**. Network object groups can also include a mix of both **IPv4 and IPv6** addresses. :::info **Network object groups** cannot be used to implement **NAT**. Individual **network objects** are required to implement **NAT**. ::: #### Service Groups When configuring a **service object group** for **TCP**, **UDP**, or **TCP & UDP**, specify the mode in the group declaration, via the <code>object-group service grp-name [tcp | udp | tcp-udp]</code> configuration command. When specified this way, **service objects** should be added via the <code>port-object operator \{ service \| port(s) \}</code> #### General Guidance The following guidelines and limitations apply to object groups: * Object groups and objects must have **unique names**. * Objects and object groups share the **same name space**. * An object group cannot be **removed** or **emptied** if it is currently used in a configuration. * The ASA does not support IPv6 **nested object groups**. #### Example ```pug ASA(config)# object-group network ADMIN-HOST ASA(config-network-object-group)# description Administrative hosts ASA(config-network-object-group)# network-object host 192.168.1.3 ASA(config-network-object-group)# network-object host 192.168.1.4 ASA(config-network-object-group)# exit ASA(config)# object-group network ALL-HOSTS ASA(config-network-object-group)# description All inside hosts ASA(config-network-object-group)# network-object 192.168.1.32 255.255.255.240 ASA(config-network-object-group)# group-object ADMIN-HOST ASA(config-network-object-group)# exit ASA(config)# show run object-group ! object-group network ADMIN-HOST ! description Administrative host IP addresses ! network-object host 192.168.1.3 ! network-object host 192.168.1.4 ! object-group network ALL-HOSTS ! network-object 192.168.1.32 255.255.255.240 ! group-object ADMIN-HOST ASA(config)# ``` ## Network Objects Network objects are a vital part of configuring NAT and can greatly simplify ACLs. To create a network object, use the <code>object network object-name</code> configuration command. The prompt changes to **network object configuration** mode. The commands available in network object configuration mode are shown in the table below. <div class=code-table> | ASA Command | Description | | ----------- | ----------- | | <div>attribute attribute-agent attribute-type attribute-value</div> | Used to filter traffic associated with one or more **virtual machines**.| | <div>description message</div> | Enter a description of the object up to 200 characters in length. | | <div>fqdn domain</div> | A fully-qualified domain name such as the name of a host, such as www.example.com. Specify **`v4`** to limit the address to IPv4, and **`v6`** for IPv6. If you do not specify an address type, **IPv4 is assumed**. | | <div>host address</div> | The IPv4 or IPv6 address of a **single host**. | | <div>range start-address end-address</div> | A range of addresses. You can specify IPv4 or IPv6 ranges. **Do not include masks or prefixes.** | | <div>subnet \{ address mask \| ipv6/prefix \}</div> | Associates a **network subnet** with the current object. | </div> ## Services Objects To create a service object, use the <code>object service object-name</code> configuration command. The prompt changes to service object configuration mode. The service object can contain a **protocol**, **ICMP**, **ICMPv6**, **TCP port**, or **UDP port**, or port ranges. The table provides an overview of common service options available. <div class=code-table> | ASA Command | Description | | ----------- | ----------- | | <div>service protocol</div> | Specifies an IP protocol name or number. | | <div>service \{tcp\|udp} [source operator port] [destination operator port]</div> | Specifies that the service object is for the TCP or UDP protocol. | | <div>service \{icmp\|icmp6} [icmp-type [icmp-code]]</div> | Specifies that the service object is for the ICMP or ICMPv6 protocol. | </div> :::success Operators—such as **eq**, **neq**, **lt**, **gt**, and **range**—can be used while configuring a port for a given protocol. If no operator is specified, the **default operator** is **eq**. ::: Use the **`no`** form of the command to remove a **specific service object**. To erase **all service objects**, use the **`clear config object service`** command. To verify, use the **`show running-config object service`** command. #### Example ```pug ASA(config)# object service SERV-1 ASA(config-service-object)# service tcp destination eq ftp ASA(config-service-object)# service tcp destination eq www ASA(config-service-object)# exit ASA(config)# show run object service ! object service SERV-1 ! service tcp destination eq www ASA(config)# ``` # Access Control Lists Cisco ASAs provide **basic traffic filtering** capabilities with ACLs. ACLs control access in a network by **preventing defined traffic** from entering or exiting. In addition, an ACL can be used to **select traffic** to which a feature will apply, thereby performing a **matching service** rather than a **control service**. There are many similarities between ASA ACLs and IOS ACLs. For example, both are made up of **ACEs**, processed sequentially from the **top down**, and there is an implicit **deny any** at the bottom. Additionally, the rule of **only one ACL** per **interface**, **protocol**, or **direction**, still applies. Like IOS Router ACLs, those on ASAs can be **enabled/disabled** based on **time ranges**. :::success ASA ACLs **differ** from IOS ACLs in that they use a **network mask** (e.g., 255.255.255.0) instead of a **wildcard mask** (e.g. 0.0.0.255). Nearly all ASA ACLs are **named** instead of **numbered**. ::: **The ASA supports five types of access lists:** * **Standard** - Unlike IOS where a standard ACL identifies the **source** host/network, **ASA standard ACLs** are used to identify the **destination IP addresses**. They are typically only used for **OSPF routes** and can be used in a route map for **OSPF redistribution**. Standard access lists cannot be applied to interfaces to control traffic. * **Extended** - The most common type of ACL. Contains one or more ACEs to specify **source** and **destination** addresses and protocol, ports (for TCP or UDP), or the ICMP type (for ICMP). They are used to **filter traffic** and to **identify traffic** that should be handled by **specific features**. * **EtherType** - An EtherType ACL can be configured only if the security appliance is running in **transparent mode**. * **Webtype** - Used for filtering for **clientless SSL VPN** traffic. These ACLs can **deny access** based on **URLs** or **destination addresses**. * **IPv6** - Used to determine which IPv6 traffic to block and which traffic to forward at **router interfaces**. :::info **Standard ACLs** may also be used to filter traffic for **LAN-to-LAN (L2L)**, **Cisco VPN Client**, and the **Cisco AnyConnect** Secure Mobility Client traffic. ::: ## ACL Filtering In addition to filtering packets **passing through** the ASA on the way to a destination host (called **through-traffic filtering**), ACLs can also be used to filter packets **destined for** the ASA directly (called **to-the-box-traffic filtering**). ASA devices differ from their **router counterparts** because of interface **security levels**. By default, security levels apply **implicit access control** (without an ACL configured). For instance, traffic from a smore secure interface, such as security level 100, is **allowed to access** less secure interfaces, such as level 0. Traffic from a less secure interface is blocked from accessing more secure interfaces. ## ACL Configuration The full ACL configuration syntax has a very long list of parameters, including object-context, filter-type, direction, interface, protocol/port, and logging options. However, for most needs, a more useful and condensed version of the syntax is shown below. <pre>ASA(config)# access-list id extended { deny | permit } protocol { src-ip mask | any | host src-ip | interface interface } [operator [port]] { dst-ip mask | any | host dst-ip | interface interface } [operator [port]] [log] [time-range name] </code></pre> ![](https://hackmd.io/_uploads/rJPc3Jv_K.png) :::success **Time-ranges** allow ACLs to be dynamically rotated based on a **periodic schedule** or a **lifespan**. This allows granular control of **time-of-day based** network restrictions. Configure a time-range using the <code>time-range name</code> command to enter the **time-range subconfiguration** mode. ::: ### Applying ACLs <pre>ASA(config)# access-group id { in | out } interface interface [ per-user-override | control-plane ]</code></pre> The **per-user-override** keyword indicates that ACLs downloaded from an AAA server should be used to **override entries** on the ACL applied to the interface. The **control-plane** keyword indicates that the applied ACL should be used to limit **management traffic** destined for the ASA. To erase a configured ACL, use the <code>clear config access-list id</code> command. To verify ACLs, use the <code>show access-list</code> and <code>show run access-list</code> commands. #### Example ```pug ASA(config)# access-list ACL-IN extended deny ip 192.168.1.0 255.255.255.0 209.165.201.0 255.255.255.224 ASA(config)# access-list ACL-IN extended deny tcp any host 209.165.201.29 eq www ASA(config)# access-list ACL-IN extended permit ip any any ASA(config)# access-group ACL-IN in interface INSIDE ``` ### same-security-traffic To allow connectivity between interfaces with the **same security levels**, the **`same-security-traffic permit inter-interface`** global configuration command is required. To enable traffic to enter and exit the **same interface**, such as when encrypted traffic enters an interface and is then routed out the same interface unencrypted, use the **`same-security-traffic permit intra-interface`** global configuration command. ## ACL Using Object Groups Object grouping for ACL configuration is a way to group **similar items** together to reduce the number of **individual ACEs**. By grouping like objects together, object groups can be **reused** in multiple ACLs instead of having to enter an ACE for each object separately. This also simplifies **reading** ACL configurations. <pre>ASA(config)# access-list id extended { deny | permit } protocol object-group src-network-group-id object-group dst-network-group-id object-group service-group-id [log] [time-range name] </code></pre> #### Example ```pug ASA(config)# object-group network NET-HOSTS ASA(config-network-object-group)# description OG matches PC-A and PC-B ASA(config-network-object-group)# network-object host 209.165.201.1 ASA(config-network-object-group)# network-object host 209.165.201.2 ASA(config-network-object-group)# exit ASA(config)# ASA(config)# object-group network SERVERS ASA(config-network-object-group)# description OG matches Web / Email Servers ASA(config-network-object-group)# network-object host 209.165.202.131 ASA(config-network-object-group)# network-object host 209.165.202.132 ASA(config-network-object-group)# exit ASA(config)# ASA(config)# object-group service HTTP-SMTP tcp ASA(config-service-object-group)# description OG matches SMTP / WEB traffic ASA(config-service-object-group)# port-object eq smtp ASA(config-service-object-group)# port-object eq www ASA(config-service-object-group)# exit ASA(config)# ASA(config)# access-list ACL-IN remark Only permit PC-A / PC-B -> Internal Servers ASA(config)# access-list ACL-IN extended permit tcp object-group NET-HOSTS object-group SERVERS object-group HTTP-SMTP ``` # NAT Services As with IOS routers, the ASA supports Network Address Translation (NAT). NAT is typically used to translate private IP network addresses into public IP addresses. NAT can be deployed using one of the following methods: * **Inside NAT** - The typical NAT deployment method is when a host from a **higher-security** interface has traffic destined for a **lower-security** interface and the ASA translates the internal host address into a **global address**. The ASA then restores the original **inside IP address** for return traffic. * **Outside NAT** - This method is used when traffic from a **lower-security** interface that is destined for a host on the **higher-security** interface must be translated. This method may be useful to make an enterprise host located on the outside of the internal network appear as one from a known **internal** IP address. * **Bidirectional NAT** - Indicates that both inside NAT and outside NAT are used together. View current NAT usage via the <code>show xlate</code> command. Additional configuration information can be verified using the <code>show nat</code> and <code>show nat detail</code> commands. ## NAT Types Cisco ASA devices support the following common types of NAT: * **Dynamic NAT/PAT** - This is a **many-to-one** translation. This is also known as **NAT with overload**. Usually an **inside pool** of private addresses overloading an **outside interface or address**. * **Static NAT** - This is a **one-to-one** translation. Usually an outside address mapping to an **internal server**. * **Policy NAT** - Policy-based NAT is based on a set of rules. These rules can specify that only **certain source addresses**, that are intended for **specific destination addresses/ports**, will be translated. * **Identity NAT** - A real address is statically translated to itself, essentially **bypassing NAT**. You might want to configure NAT this way when you want to translate a large group of addresses, but then want to **exempt a subset** of addresses. :::info Another ASA NAT feature is called **Twice-NAT**. Twice-NAT identifies **both** the source and destination address in a **single rule** (nat command). Twice-NAT is used when configuring **remote-access IPsec and SSL VPNs**. ::: These types of NAT are referred to as **network object NAT** because they require [network objects](#Network-Objects) to be configured. ## Dynamic NAT Configuration To configure network object dynamic NAT, two **network objects** are required: 1. An object identifying the **pool of public IP addresses** into which internal addresses are translated. 1. An object identifying the **internal addresses** to be translated. These are identified using the **`range`** or **`subnet`** network object commands. The two objects are then bound together using the following network object command syntax: <pre><code>ASA(config)# object network name ASA(config-network-object)# nat [(real_if_name,mapped_if_name)] dynamic mapped_object [interface [ipv6]] [dns]</code></pre> The <code>real_if_name</code> is the pre-NAT interface. The <code>mapped_if_name</code> is the post-NAT interface. Notice that there is **no space** after the comma in the command syntax. To allow inside hosts to ping outside hosts, you can use a **policy map** to permit ICMP messages to return through the external interface. **NAT Configuration Example** ```pug ASA(config)# object network PUBLIC ASA(config-network-object)# range 209.165.200.240 209.165.200.248 ASA(config-network-object)# exit ASA(config)# ASA(config)# object network DYNAMIC-NAT ASA(config-network-object)# subnet 192.168.1.0 255.255.255.224 ASA(config-network-object)# nat (INSIDE,OUTSIDE) dynamic PUBLIC ASA(config-network-object)# exit ASA(config)# ``` **Permit ICMP Example** ```pug ASA(config)# policy-map global_policy ASA(config-pmap)# class inspection_default ASA(config-pmap-c)# access-list ICMPACL extended permit icmp any any ASA(config)# access-group ICMPACL in interface OUTSIDE ASA(config)# ``` ## Dynamic PAT Configuration **Port Address Translation (PAT)** is a variant of NAT. Cisco ASA devices can be configured for **Dynamic PAT**. Dynamic PAT is used any time multiple internal hosts need to share a single public IP address. Only one network object is required when overloading the outside interface. To enable inside hosts to overload the outside address (using Dynamic PAT), use the <code>nat [(real_if_name,mapped_if_name)] dynamic interface</code> network object configuration command. #### Example ```pug ASA(config)# object network INSIDE-NET ASA(config-network-object)# subnet 192.168.1.0 255.255.255.224 ASA(config-network-object)# nat (INSIDE,OUTSIDE) dynamic interface ASA(config-network-object)# end ASA# ``` ## Static NAT Configuration Static NAT is configured when an inside address is mapped to an outside address. For instance, static NAT can be used when a server must be accessible from the outside. To configure static NAT, use the <code>nat [(real_if_name,mapped_if_name)] static mapped_ip</code> network object configuration command. :::success An ACL is required for a dynamic translation to be successful. ::: #### Example ```pug ASA(config)# object network DMZ-SERVER ASA(config-network-object)# host 192.168.2.3 ASA(config-network-object)# nat (DMZ,OUTSIDE) static 209.165.200.227 ASA(config-network-object)# exit ASA(config)# ASA(config)# access-list OUTSIDE-DMZ extended permit ip any host 192.168.2.3 ASA(config)# access-group OUTSIDE-DMZ in interface OUTSIDE ASA(config)# ASA(config)# policy-map global_policy ASA(config-pmap)# class inspection_default ASA(config-pmap-c)# access-list ICMPACL extended permit icmp any any ASA(config)# access-group ICMPACL in interface DMZ ASA(config)# ``` # AAA Authentication Service Cisco ASA can be configured to authenticate using a local user database or an external server for authentication or both. To enable authentication of users connecting via console port, SSH, HTTPS, or Telnet, or to authenticate users attempting to access privilieged EXEC mode, use the following command syntax: <pre><code>ASA(config)# aaa authentication {serial|enable|telnet|ssh|http} console { LOCAL | server-group [LOCAL] }</code></pre> Use the <code>username name password password [privilege priv-level]</code> command to create local user accounts. To erase a user from the local database, use the <code>clear config username [name]</code> command. To view all user accounts, use the <code>show running-config username</code> command. To configure a TACACS+ or RADIUS server, use the following steps: <ol class='step-list'> <li>Create a TACACS+ or RADIUS AAA server group via the <code>aaa-server server-tag protocol { tacacs+ | radius }</code> configuration command. This will enter the AAA-server-group subconfiguration mode.</li> <li>Configure a AAA server as part of a AAA server group, via the <code>aaa-server server-tag [(interface_name)] host { server-ip | hostname } [key]</code> command. This will enter the host-specific AAA subconfiguration mode.</li> <li>Configure any remaining, host-specific parameters.</li> </ol> To **erase AAA configurations**, use the following commands: * **`clear config aaa-server`** — remove all **AAA server** configurations. * **`clear config aaa`** — remove all AAA-based **console authentication** configurations. To **view AAA configurations**, use the following commands: * **`show running-config aaa-server`** — view all configured AAA servers and host-specific parameters. * **`show running-config aaa`** — view all AAA-based **console authentication** configurations. #### Example ```pug ASA(config)# username Admin password class privilege 15 ASA(config)# show run username ! username Admin password ***** pbkdf2 privilege 15 ASA(config)# aaa-server TACACS-SVR protocol tacacs+ ASA(config-aaa-server-group)# aaa-server TACACS-SVR (DMZ) host 192.168.2.3 ASA(config-aaa-server-host)# exit ASA(config)# show run aaa-server ! aaa-server TACACS-SVR protocol tacacs+ ! aaa-server TACACS-SVR (DMZ) host 192.168.2.3 ASA(config)# ASA(config)# aaa authentication serial console TACACS-SVR LOCAL ASA(config)# aaa authentication ssh console TACACS-SVR LOCAL ASA(config)# show run aaa aaa authentication serial console TACACS-SVR LOCAL aaa authentication ssh console TACACS-SVR LOCAL ASA(config)# ``` # Modular Policy Framework The **Modular Policy Framework (MPF)** allows **granular classification** of traffic flows, which enables the application of different advanced policies to different flows. MPF is used with **hardware modules** to redirect traffic granularly from the ASA to the modules that use Cisco MPF. MPF can be used for advanced **application layer** inspection of traffic by classifying at **Layers 5-7**. MPF can also be used to implement **rate limiting** and **QoS**. Cisco MPF uses three configuration objects to define modular, object-oriented, hierarchical policies: 1. **Class Maps** — The class of traffic to be **filtered**. Creates a **Layer 3/4** class map that can contain multiple match criteria. 1. **Policy Maps** — The **action** that will be applied to matched traffic. Defines a policy for the traffic that applies to **Layers 3-7**. Policy maps can be assigned to **multiple class maps**. 1. **Service Policy** — The **interface-binding** configuration that applies a **policy-map** to an interface. There are four steps to configure MPF on an ASA: <ol class='step-list'> <li>Optionally, configure extended ACLs, to identify granular traffic, that will be specifically referenced in the class map.</li> <li>Configure the class map to identify traffic or reference an existing ACL.</li> <li>Configure a policy map to assign actions to those traffic classes.</li> <li>Configure a service policy to bind an interface to the policy map.</li> </ol> #### Example ```pug ASA(config)# access-list TFTP-TRAFFIC permit udp any any eq 69 ASA(config)# ASA(config)# class-map CLASS-TFTP ASA(config-cmap)# match access-list TFTP-TRAFFIC ASA(config-cmap)# exit ASA(config)# ASA(config)# policy-map POLICY-TFTP ASA(config-pmap)# class CLASS-TFTP ASA(config-pmap-c)# inspect tftp ASA(config-pmap-c)# exit ASA(config-pmap)# exit ASA(config)# ASA(config)# service-policy POLICY-TFTP global ASA(config)# ``` ## Class Map Configuration Class maps are configured to identify **Layer 3/4** traffic. To create a class map, use the <code>class-map name</code> global configuration command to enter the **class-map configuration** mode. The names **"class-default"** and any name that **begins with "_internal" or "_default"** are reserved. :::info A variation of the **class-map** command is used for **management traffic** that is destined for the ASA. In this case, use the <code>class-map type management name</code> command. ::: When configuring a class-map, always include a **description** explaining the **purpose** of the class map, by using the <code>description message</code> class-map configuration command. To identify traffic that the class-map should match, use <code>match any</code> to match all traffic or <code>match access-list acl-name</code> to match traffic specified by an extended access list. :::success Unless otherwise specified, only include **one match command** in the class map. ::: To **erase** **all** class map configurations, use the <code>clear config class-map</code> global configuration command. To **verify** class map configuration, use the <code>show run class-map</code> command. ### Inspection Defaults The ASA also automatically defines a **default Layer 3/4 class map** identified in the running configuration as <code>class-map inspection_default</code>. This class map identifies the **match default-inspection-traffic**, which sets default rules for **service-based packet inspection**. When used in a **policy map**, this class map ensures that the **correct inspection** is applied to each packet, based on the **destination port** of the traffic. ## Policy Configuration Policy maps are used to associate **class maps** with **actions**. Actions are applied to traffic **bidirectionally** or **unidirectionally** depending on the feature. There are several steps to configure a policy map: <ol class='step-list'> <li>Use the <code>policy-map name</code> global configuration command to enter policy-map configuration mode.</li> <li>Set a descriptive reminder of the policy's purpose via the <code>description message</code> policy-map configuration command.</li> <li>Specify one or more traffic classes to associate the policy with, using the <code>class class-map-name</code> command.</li> <li>Configure an action to be taken with all matched traffic via the <code>inspect protocol</code> command.</li> <li>Finally, bind the policy-map to an interface (or apply it globally) via the <code>policy-map name [ interface interface | global ]</code> global configuration command.</li> </ol> :::warning The **maximum number** of policy maps is **64**. However, there can be **multiple class maps** and **multiple actions** associated with each policy map. ::: **Additional actions** are available to the **policy-map configuration mode**, including: * <code>set connection</code> — Sets connection values. * <code>police</code> — Sets rate limits for the matched traffic classes. To verify the policy map configuration, use the <code>show run policy-map</code> command. To **erase all** configured policy maps, use the <code>clear config policy-map</code> command. #### Default Policy Map The **default ASA configuration** includes a **default policy map**, called the **global_policy**, which is configured to require inspections on all **default inspection traffic**. There can only be **one global policy**. Therefore, to alter the global policy, either directly edit or replace it. --- --- {%hackmd 7PGmjAHeTXak2VUM3iw5Wg %}