Getting Started With Cisco Firewalls
User Interface
This lesson covers the access modes and commands for operating Cisco ASA security appliances It is assumed that you are familiar with connecting to the appliance via a console cable, specifically the blue flat cable with an RJ-45 connector on one end and a DB-9 Serial connector on the other Additionally, you should know how to use Terminal Emulation software such as HyperTerminal or Putty, as well as the basic Command Line Interface.
A Cisco security appliance (PIX or ASA) has four main administrative access modes:
Monitor Mode allows users to access a prompt that facilitates network image updates and password recovery By entering commands in this mode, you can designate the TFTP server's location and specify the software image or password recovery binary file to download To enter Monitor Mode, simply press the “Break” or “ESC” keys right after powering on the appliance.
Unprivileged Mode: Displays the > prompt Available when you first access the appliance
If the appliance is a Cisco PIX 500 series, the prompt for unprivileged mode is pixfirewall> and if the appliance is the new Cisco ASA 5500 Series, the prompt is ciscoasa>
The restricted view mode of the security appliance does not allow any configuration changes To begin configuring, use the "enable" command and press Enter Since the initial password is blank, simply press Enter again to access Privileged Mode The sequence is as follows: type "enable" in Unprivileged Mode, leave the password field empty, and you'll enter Privileged Mode.
In Privileged Mode, indicated by the # prompt, users can view and change current settings while still executing unprivileged commands To see the current configuration, the command "show running-config" can be utilized However, to make any actual configurations, one must enter Configuration Mode by using the "configure terminal" command from Privileged Mode.
In Configuration Mode, indicated by the (config)# prompt, you can modify all system configuration settings To navigate back to the previous mode, use the exit command Begin in Unprivileged Mode by entering the command "enable" and providing the initial blank password From there, switch to Privileged Mode with "configure terminal," which leads you to Configuration Mode You can return to Privileged Mode by typing "exit," and subsequently, go back to Unprivileged Mode by entering "exit" again.
Global Configuration Mode, often referred to as (config)# mode, allows users to enter command-specific modes where the prompt changes to reflect the current context For instance, executing the interface command transitions to interface configuration mode, as demonstrated by the prompt changing to ciscoasa(config-if)#, enabling the configuration of interface-specific parameters.
File Management
This lesson describes the file management system in the security appliance Each ASA device contains flash memory and also RAM which is used to store the currently running configuration
1.2.1 Viewing and saving your configuration
There are two configuration instances in the Cisco security appliances:
running-configuration (stored in RAM)
startup-configuration (stored in Flash)
The running configuration, stored in the firewall's RAM, represents the current settings of the appliance To view this configuration, enter the command "show running-config" in Privileged Mode.
Commands entered in the firewall are immediately applied to the running-config, which is stored in RAM If the appliance loses power, any unsaved configuration changes will be lost.
To save the currently running configuration, use the command: ciscoasa# copy run start or ciscoasa# write memory
The above two commands copy the running-config into the startup-config
The startup configuration serves as a backup of the running configuration and is stored in Flash Memory, ensuring it remains intact during reboots This configuration is loaded each time the appliance powers on To view the saved startup configuration, use the command "show startup-config."
ASA Image Software Management
The ASA image serves as the operating system for the appliance, similar to the IOS utilized in Cisco routers When discussing ASA software versions such as 8.x or 9.x, we are specifically referring to the version of this image software.
The ASA image is a binary file that is compressed and pre-installed on the device's flash memory Upon booting, this image is decompressed into RAM An example of an ASA image filename is "asa911-k8.bin."
In order to copy a new image file to the ASA (e.g for upgrading the existing software version), follow the steps below:
First copy the ASA image file on a TFTP server computer Assume that we have already a TFTP server located on the inside network with IP address 192.168.1.10
Step2: Copy image file from TFTP to Flash of ASA ciscoasa# copy tftp flash
Address or name of remote host []? 192.168.1.10
Destination filename [asa911-k8.bin]? Hit Enter
Step3: Set the new image file as boot system file ciscoasa#config term ciscoasa(config)# boot system flash:/asa911-k8.bin ciscoasa(config)# write memory
After rebooting the appliance, the new software image will be asa911-k8.bin
Password Recovery Procedure
If you find yourself locked out of an ASA appliance due to a forgotten password, you can regain access by following the password recovery procedure outlined below.
Connect with a console cable to the ASA and power-cycle the device (switch it OFF and ON again)
Press continuously the “ESC” key on your keyboard until the device gets into ROMMON mode This mode shows the following prompt: rommon #1>
Now we need to change the “configuration register” which is a special register controlling how the device boots up etc rommon #1>confreg
The security appliance displays the current configuration register value, and asks if you want to change the value Answer no when prompt
Configuration Summary: boot TFTP image, boot default image from Flash on netboot failure
Do you wish to change this configuration? y/n [n]: n
Now we must manually change the confreg value to 0x41 which means that the appliance will ignore the startup-configuration when booting Then, reboot the appliance rommon #2>confreg 0x41 rommon #3>boot
Now the ASA will ignore its startup configuration and boot up without asking for a password ciscoasa>enable
Copy the startup configuration file into the running configuration ciscoasa# copy startup-config running-config
Destination filename [running-config]?
To enhance security, configure a new privileged level password by entering the command `enable password strongpass` in the terminal Additionally, reset the configuration register to its original value of `0x01` using the command `config-register 0x01` Finally, save the changes by executing `wr mem`.
Reload the appliance Now you should be able to log in with the new password ciscoasa(config)# reload
Security Levels
This lesson describes the security levels concept as used in the ASA firewall appliance
A Security Level, ranging from 0 to 100, is assigned to both physical and logical sub-interfaces, indicating the trustworthiness of one interface in relation to another on a network appliance Higher security levels signify greater trust, allowing interfaces with elevated levels to access those with lower levels Conversely, lower security level interfaces are restricted from accessing higher-level interfaces unless explicitly permitted by a security rule, such as an Access Control List (ACL) This system enables the assignment of 'trust levels' to security zones, enhancing network security management.
Let us see some examples of security levels below:
Security Level 0: This is the lowest security level and it is assigned by default to the
The 'Outside' interface of a firewall represents the lowest level of security and is designated for the network that should not access internal systems Typically assigned to the interface linked to the Internet, this security level ensures that any device connected to the Internet is denied access to internal networks behind the firewall unless explicitly allowed by an Access Control List (ACL) rule.
Security Levels 1 to 99: These security levels can be assigned to perimeter security zones (e.g DMZ Zone, Management Zone, Database Servers Zone etc)
Security Level 100: This is the highest security level and it is assigned by default to the
The 'Inside' interface of a firewall represents the highest level of security and should be assigned to the network interface that requires the strongest protection from the security appliance Typically, this security level is designated for the interface that connects to the internal corporate network, ensuring robust defense for sensitive data and resources.
The diagram above depicts a standard security level assignment in a network featuring Inside, Outside, and DMZ zones In this book, we will consistently refer to the Cisco Firewall for network security management.
The "Electrical Diode" symbol illustrates a network configuration where the Internal Corporate Network connects to the highest security level interface, labeled 'Inside' (G0/1, Security Level 100) The INTERNET-facing interface, known as 'Outside' (G0/0), has a security level of 0 Additionally, a Perimeter Zone (DMZ) is established with a security level of 50 Traffic flow is indicated by red arrows, showing that the Inside Zone can access both the DMZ and Outside Zones, while the DMZ can only access the Outside Zone Importantly, the Outside Zone is restricted from accessing the Inside or DMZ zones.
The default behavior of Cisco ASA Firewalls restricts access from lower security levels to higher security levels However, this can be modified by implementing Static NAT and Access Control Lists, as will be discussed in the upcoming chapters.
1.5.2 Rules for Traffic Flow between Security Levels
Traffic from Higher Security Level to Lower Security Level: Allow ALL traffic originating from the higher Security Level unless specifically restricted by an Access Control List (ACL)
When NAT-Control is activated on a device, a NAT/global translation pair is required between interfaces with High-to-Low Security Levels It is important to note that the "global" command is not supported in ASA versions 8.3 and later.
To enhance network security, it is essential to block all traffic from lower security levels to higher security levels unless explicitly permitted by an Access Control List (ACL) Additionally, if NAT-Control is activated on the device, a Static NAT configuration is required for communication between interfaces of high and low security levels.
Traffic between interfaces with same Security Level: By default this is not allowed, unless you configure the same-security-traffic permit inter-interface command (ASA version 7.2 and later).
Basic Firewall Configuration
The following configuration commands constitute the basic steps for setting up the security appliance from the ground up:
STEP1: Configure a privileged level password (enable password)
To enhance security, it's essential to set a privileged level password for the ASA firewall, as there is no default password This configuration is done in Configuration Mode using the command: ciscoasa(config)# enable password mysecretpassword.
STEP2: Enable Remote Command Line Management
Access the security appliance remotely for Command Line Interface (CLI) management via Telnet or SSH, and for web-based graphical management using HTTPS (ASDM management) It is advisable to use SSH for CLI management due to its encrypted communication, unlike Telnet, which lacks encryption To enable SSH on the firewall, create a username and password for authentication, generate RSA encryption keys, and specify the IP address of the management host or network.
! Create a username “ciscoadmin” with password “adminpassword” and use this LOCAL username to
!authenticate for SSH connections Privilege 15 is the highest privilege level for a user ciscoasa(config)#username ciscoadmin password adminpassword privilege 15 ciscoasa(config)#aaa authentication ssh console LOCAL
! Generate a 1024 bit RSA key pair for the firewall which is required for SSH ciscoasa(config)# crypto key generate rsa modulus 1024
Keypair generation process begin Please wait ciscoasa(config)#
! Specify the hosts allowed to connect to the security appliance ciscoasa(config)#ssh 10.1.1.1 255.255.255.255 inside ciscoasa(config)#ssh 200.200.200.1 255.255.255.255 outside
The default hostname for Cisco ASA appliances is "ciscoasa," while for Cisco PIX appliances, it is "pixfirewall." To effectively manage your network, it's recommended to assign a unique hostname to each new firewall For example, you can configure a Cisco ASA firewall with the command: ciscoasa(config)# hostname NewYork-FW.
Notice how the CLI prompt has changed to the new Hostname that you just configured
The Cisco ASA interfaces are numbered as GigabitEthernet0/0, GigabitEthernet0/1,
GigabitEthernet0/2 etc (for Cisco ASA 5510 model, the interfaces are numbered as Etherne0/0,
To configure interface settings on a Cisco ASA 5505, use the "Interface" command followed by the specific interface designation, such as "interface GigabitEthernet0/1." This command enters interface configuration mode, allowing you to apply various sub-commands specific to that interface For VLAN configurations, use the "Interface Vlan x" mode to manage the settings effectively.
For Cisco ASA 5505: ciscoasa(config)# interface Vlan [vlan number] ciscoasa(config-if)# Configure Interface specific sub-commands
To configure an interface for traffic passing, you must use essential sub-commands: first, assign a name to the interface with the command "nameif 'interface name'"; second, set the interface's IP address using "ip address 'ip_address' 'subnet_mask'"; third, define the security level with "security-level 'number 0 to 100'"; and finally, enable the interface by executing "no shutdown," as all interfaces are disabled by default.
The configuration snapshot illustrates the essential interface sub-commands for a Cisco ASA device To set up the "inside" interface, use the command `interface GigabitEthernet0/1`, assign it a name with `nameif inside`, and configure the IP address as `ip address 10.0.0.1 255.255.255.0`, ensuring a default security level of 100 with `security-level 100` Activate the interface with `no shutdown` For the "outside" interface, execute `interface GigabitEthernet0/0`, name it using `nameif outside`, and set the IP address to `ip address 10.1.1.1 255.255.255.0`, which has a default security level of 0 via `security-level 0`, followed by activating it with `no shutdown`.
STEP5: Configure NAT Control as needed (This is for versions lower than 8.3)
One crucial configuration step in ASA firewalls is nat-control, which is disabled by default Unlike older Cisco PIX firewalls, where NAT was mandatory, ASA firewalls allow for more flexibility When nat-control is disabled, NAT (address translation) is applied only to selected traffic moving from a high security level to a lower one However, if nat-control is enabled using the command `asa(config)#nat-control`, a NAT rule must be established for all traffic between high and low security interfaces, corresponding to a "global" command With nat-control disabled, the ASA facilitates traffic flow without requiring NAT statements, relying instead on properly configured Access Control Lists on each interface.
NOTE: From ASA version 8.3 and later, “nat-control” and “global” commands are no longer supported
Routing is crucial for configuring a Firewall appliance, as it determines how traffic is directed to its destination While this article focuses on default and static routing, dynamic routing protocols like RIP, OSPF, and EIGRP can also be implemented For small networks, it is advisable to stick with default or static routing, while dynamic protocols can be beneficial in larger, more complex networks Further discussion on dynamic routing protocols will be provided in a later chapter.
Use the route command to enter either a static or default route for an interface The command format is: ciscoasa(config)# route “ interface-name ” “ destination-ip-address ” “ netmask ” “ gateway” ’
Let’s see an example configuration below: ciscoasa(config)# route outside 0.0.0.0 0.0.0.0 100.1.1.1 Default Route ciscoasa(config)# route inside 192.168.2.0 255.255.255.0 192.168.1.1 Static Route required on ASA to reach network 192.168.2.0 via gateway 192.168.1.1
To configure the default route, set both the destination IP address and netmask to 0.0.0.0, typically directing traffic towards the Internet Additionally, establish static routes to reach specific known networks beyond your local connections, as illustrated in the accompanying diagram.
The routing configuration outlines the essential steps required for the security appliance to operate effectively Following this, we will explore additional configuration features that will further strengthen the security of networks safeguarded by the firewall.
Configuring Network Address Translation
Network Address Translation (NAT) Overview
The exhaustion of the public IPv4 address space has prompted the Internet community to explore alternative methods for addressing networked hosts As a solution to the addressing challenges arising from the Internet's expansion, Network Address Translation (NAT) was developed to effectively manage and alleviate these issues.
Some of the advantages of using NAT in IP networks are the following:
NAT helps to mitigate global public IP address depletion
Networks can use the RFC 1918 private address space internally
NAT increases security by hiding the internal network topology and addressing
The diagram illustrates a fundamental network topology where the ASA Firewall conducts a NAT operation to convert the internal "inside" IP addresses into external "outside" addresses, effectively concealing the internal IP range It is important to note that this translation typically targets the source IP address of the packets.
Dynamic NAT is primarily utilized for outbound traffic, allowing data to flow from a higher-security internal network to a lower-security external network.
Traffic originating from the private IP address 192.168.1.1 is converted to the public IP address 100.1.1.2 for Internet routing When response packets return from the Internet, they are directed to the public IP 100.1.1.2, for which the firewall has a predefined translation rule The firewall then translates this public address back to the private IP 192.168.1.1, ensuring the packets reach the intended internal host.
Global commands (versions prior to 8.3) collaborate to establish translation rules that allow your internal network to utilize any IP addressing scheme while remaining concealed from external access.
Let’s see some terminology that will be used in this Chapter:
The Real IP address refers to the actual address configured on a host, known as the untranslated address In our example, the Real IP address is 192.168.1.1, and the corresponding Real Interface is the Inside ASA interface.
The mapped IP address is the address to which the real address is translated, as illustrated in our example diagram, where the mapped IP address is 100.1.1.2, corresponding to the Outside ASA interface.
Cisco ASA firewalls support four types of address translations:
Dynamic NAT translation: Translates source addresses on higher security interfaces into a range (or pool) of IP addresses on a less secure interface, for outbound connections The
The "nat" command specifies the internal hosts eligible for translation, while the "global" command (for ASA versions before 8.3) designates the address pool for outgoing interfaces Dynamic NAT is exclusively utilized for outbound communications.
Dynamic Port Address Translation (PAT): This is also called “Many-to-One”
Translation A group of Real IP addresses are mapped to a Single IP address using a unique source port of that address
Static NAT translation: Provides a permanent, one-to-one address mapping between a
A Real IP address should be placed on a higher security interface, while a Mapped IP address is assigned to a lower security interface By implementing a suitable Access Control List (ACL), static NAT facilitates access for hosts on less secure interfaces, such as the Internet, to communicate with hosts on more secure interfaces, like a Web Server in a DMZ, without revealing the actual Real IP address This configuration enables bidirectional communication, enhancing security while maintaining connectivity.
Identity NAT allows for the translation of a Real IP address to itself, effectively bypassing Network Address Translation (NAT) This feature is particularly useful in VPN configurations, as it enables the exemption of VPN traffic from NAT operations.
Cisco ASA Versions prior to 8.3
Dynamic NAT translation is implemented using the "nat" and "global" commands, which define the Real IP network and the Mapped IP pool, respectively The "nat" command specifies the internal network IP subnet, while the "global" command outlines the external IP pool range The command format for configuring Dynamic NAT is as follows: ciscoasa(config)# nat (Real_interface_name) "nat-id" "internal network IP subnet" and ciscoasa(config)# global (Mapped_interface_name) "nat-id" "external IP pool range."
Cisco ASA Versions 8.3 and later
Cisco ASA version 8.3, released on March 8, 2010, introduces a complete overhaul of the NAT configuration, eliminating the previous “nat-control,” “static,” and “global” commands The new syntax utilizes the “nat” command differently, which will be detailed further Users upgrading from earlier versions, such as 7.x, 8.0, 8.1, or 8.2, should note that a memory upgrade is necessary for models 5505, 5510, 5520, and 5540 Additionally, the upgrade process includes migrating old NAT statements to the new configuration format.
In versions 8.3 and later (including 9.x versions), the ASA firewall implements NAT in two ways:
Cisco advises opting for "Network Object NAT" over "Twice NAT" due to its simplicity in configuration and increased reliability While Twice NAT offers greater scalability and additional features, it is more complex to implement This chapter will concentrate solely on Network Object NAT.
To configure NAT, you need to set it up under a network object that specifies the real IP address or subnet for translation Additionally, the network object allows you to configure the necessary settings for the NAT process.
“nat” command which specifies a pair of interfaces between which the NAT will take place and the Mapped IP address pool
To effectively manage IP addresses, create network objects that define both Real IP addresses and Mapped IP addresses These network objects can represent a single IP address (host), a network subnet, or a range of IP addresses It is essential that the network object for Real IP addresses includes the "nat" statement Use the following command in Cisco ASA configuration: `ciscoasa(config)# object network [obj-name]` followed by `ciscoasa(config-network-object)# {host ip-addr | subnet net-addr net-mask | range ip1-ip2 }`.
Using Access Control Lists (ACL)
ACL Overview
An Access Control List (ACL) consists of Access Control Entries that either permit or deny traffic between a source and a destination Once configured, an ACL is applied to an interface using the “access-group” command By default, if no ACL is applied, outbound traffic is allowed while inbound traffic is blocked ACLs can be implemented for both inbound and outbound traffic, with the "in" direction governing traffic entering the interface and the "out" direction managing traffic exiting In the provided diagram, ACLs for inbound and outbound access are applied to the respective "in" directions of the Outside and Inside interfaces.
The following are guidelines for designing and implementing ACLs:
For Outbound Traffic (Higher to Lower Security Levels), the source address argument of an ACL entry is the actual real address of the host or network
For Inbound Traffic (Lower to Higher Security Levels), the destination address argument of an ACL entry is the translated Mapped IP address (For ASA versions prior to 8.3)
In ASA Version 8.3 and later: Always use the Real IP address in the Access List when NAT is configured
ACLs are always checked before translation is performed on the security appliance
Access Control Lists (ACLs) not only limit traffic flow through firewalls but also serve as a mechanism for traffic selection, enabling the implementation of various actions such as encryption, translation, policing, and Quality of Service (QoS).
ACL Configuration
The command format of an Access Control List is the following: ciscoasa(config)# access-list “ access_list_name” [line line_number ] [extended]
{ deny | permit } protocol “source_address” “ mask” [operator source_port] “dest_address”
The command format of an Access-Group command used to apply an ACL is the following: ciscoasa(config)# access-group “ access_list_name” [in|out] interface “ interface_name ”
Let’s see all the elements of the ACL command below:
access_list_name : Give a descriptive name of the specific ACL The same name is used in the access-group command
line line_number : Each ACL entry has its own line number
extended: Use this when you specify both source and destination addresses in the ACL
deny|permit : Specify whether the specific traffic is permitted or denied
protocol: Specify here the traffic protocol (IP, TCP, UDP etc)
To define the source address mask, indicate the originating source IP address or network for the traffic For a single IP address, use the term "host" without a mask Alternatively, the keyword "any" can be utilized to represent any address.
[operator source_port]: Specify the source port number of the originating traffic The
The "operator" keyword includes options such as "lt" for less than, "gt" for greater than, "eq" for equal, "Neq" for not equal to, and "range" for specifying a range of ports If a source_port is not defined, the firewall will match all ports.
dest_address mask: This is the destination IP address/network that the source address requires access to You can use also the “host” or “any” keywords
[operator dest_port]: Specify the destination port number that the source traffic requires access to The “operator” keyword can be “lt” (less than), “gt” (greater than), “eq” (equal),
“Neq” (Not equal to), “range” (range of ports) If no dest-port is specified, the firewall matches all ports
The ACL examples below will give us a better picture of the command format:
Example1 ciscoasa(config)# access-list DMZ_IN extended permit ip any any ciscoasa(config)# access-group DMZ_IN in interface DMZ
The above will allow ALL traffic from DMZ network to go through the firewall
In a Cisco ASA configuration, the command `access-list INSIDE_IN extended deny tcp 192.168.1.0 255.255.255.0 200.1.1.0 255.255.255.0` is used to block TCP traffic from the specified internal subnet to the external subnet Additionally, the command `access-list INSIDE_IN extended deny tcp 192.168.1.0 255.255.255.0 host 210.1.1.1 eq 80` restricts access to a specific external host on port 80 Finally, the command `access-list INSIDE_IN extended permit ip any any` allows all other IP traffic, and `access-group INSIDE_IN in interface inside` applies the access list to the inside interface of the firewall.
This configuration blocks all TCP traffic from the internal network 192.168.1.0/24 to the external network 200.1.1.0/24, as well as HTTP traffic on port 80 directed towards the external host 210.1.1.1, while allowing all other types of traffic from the internal network.
Cisco ASA Version prior to 8.3 ciscoasa(config)# access-list OUTSIDE_IN extended permit tcp any host 100.1.1.1 eq 80 ciscoasa(config)# access-group OUTSIDE_IN in interface outside
The ACL configuration enables unrestricted access to our Web Server host (100.1.1.1) from any Internet host For ASA versions earlier than 8.3, the address 100.1.1.1 serves as the public global translated address of our Web server.
Cisco ASA Version 8.3 and Later
To configure access for a web server with a private IP address on ASA versions 8.3 and later, use the command: `access-list OUTSIDE_IN extended permit tcp any host 192.168.1.1 eq 80` followed by `access-group OUTSIDE_IN in interface outside` This allows TCP traffic on port 80 to reach the web server with the private IP address of 192.168.1.1.
An Access Control List (ACL) is composed of multiple Access Control Entries (ACEs), which are command lines that include permit or deny statements When new ACE lines are added, they are typically appended to the end of the ACL However, you can also delete or insert ACE lines at any position within the ACL by utilizing the "line" parameter in the access-list command.
You can see the line numbers of each ACE entry by using the “show access-list [name]” command
Assume we have an ACL with name “INSIDE-IN” We can see the line numbers in the ACL as shown below:
The access-list named INSIDE-IN contains three elements, with the first line denying TCP traffic from the host 10.1.1.12 to any destination on port 80 (HTTP), which has not been hit, while the second line denies TCP traffic from the same host to any destination on port 443 (HTTPS), having been hit five times The third line permits all IP traffic from any source to any destination, indicating a more open policy for general traffic.
As shown from the command output above, we have 3 lines in the ACL
Now, let’s say we want to insert a new ACE entry between lines 2 and 3 of the ACL above:
ASA1(config)# access-list INSIDE-IN line 3 extended deny tcp host 10.1.1.2 any eq smtp
The access-list named INSIDE-IN contains four elements, with the first line denying TCP traffic from the host 10.1.1.12 to any destination on port 80 (HTTP), which has not been hit The second line also denies TCP traffic from the same host to any destination on port 443 (HTTPS), with five recorded hits The third line denies TCP traffic from host 10.1.1.2 to any destination on port 25 (SMTP), which has not been hit either Finally, the fourth line permits all IP traffic from any source to any destination, with 791 recorded hits.
As you can see from the output above, a new ACE entry has been inserted at line 3 and the previous
“line 3” entry has become “line 4”
In order to delete a specific ACE entry, just use the “no” keyword in front of the ACE entry:
ASA1(config)# no access-list INSIDE-IN extended deny tcp host 10.1.1.12 any eq www
New ACL Features in ASA 8.3 and Later
In ASA versions 8.3 and later there have been a few important new features regarding Access Control Lists We will see them below
As we’ve seen above, ACLs are applied on interfaces using the “access-group” command.
In newer ASA versions (8.3 and later) you can also apply an ACL globally as following: ciscoasa(config)# access-group “ access_list_name” global
An Access Control List (ACL) configured with the "access-group global" command enforces a uniform set of global rules on all incoming traffic to a security appliance, regardless of the interface it enters through Importantly, this ACL only impacts traffic in the ingress direction, meaning it applies solely to data entering the interface.
To configure your network for secure email communication, allow all internal hosts to access only the internal SMTP server at 192.168.1.10 for sending emails while blocking all other SMTP traffic This can be achieved by implementing the following Cisco ASA access control list (ACL) commands: first, permit TCP traffic from any host to the SMTP server on port 25, then permit TCP traffic from the SMTP server to any host on the same port Next, deny all other TCP traffic on port 25 from any source to ensure that only the designated SMTP server is used for email transmission Finally, permit all other IP traffic to maintain general network functionality.
! Apply the rules above globally no matter from which interface the traffic comes from Useful when we have many interfaces on the ASA ciscoasa(config)# access-group SMTP global
3.3.2 ACL Changes in ASA Versions 9.x (9.0, 9.1 and later)
Cisco ASA Version 9.x introduced significant updates to Access Control Lists (ACLs), allowing for the inclusion of both IPv4 and IPv6 addresses as source and destination addresses within the same ACL.
In version 9.x and later of ACL, the keyword "any" signifies "ALL IPv4 AND IPv6 addresses." To specify "all IPv4 addresses only," use the keyword "any4," while "any6" should be used to denote "all IPv6 addresses only."
If you are migrating from version 8.x and you had a keyword “any” in your ACL configuration, this will be changed to “any4” in the new configuration running under version 9.x
! The rule below will allow only IPv4 traffic to access host 10.1.1.1 from the Internet
ASA(config)# access-list OUTSIDE extended permit ip any4 host 10.1.1.1
ASA(config)# access-group OUTSIDE in interface outside
Controlling Inbound and Outbound Traffic with ACLs
A picture is worth a thousand words; refer to the diagram below for examples that illustrate how to effectively manage Inbound and Outbound Traffic flow.
Scenario 1: Allow Inbound Access to DMZ Servers
We have established static NAT mappings for our web and email servers to convert their private addresses into public addresses that can be accessed from the Internet Additionally, we implemented ACLs to permit the necessary inbound traffic to reach our servers.
To configure Cisco ASA versions prior to 8.3, use the following commands: first, create static mappings from the DMZ to the outside interface by entering `static (DMZ, outside) 100.1.1.1 10.0.0.1 netmask 255.255.255.255` and `static (DMZ, outside) 100.1.1.2 10.0.0.2 netmask 255.255.255.255` Next, permit TCP traffic to the mapped hosts by executing `access-list OUTSIDE-IN extended permit tcp any host 100.1.1.1 eq 80` and `access-list OUTSIDE-IN extended permit tcp any host 100.1.1.2 eq 25` Apply the access list to the outside interface with `access-group OUTSIDE-IN in interface outside` Finally, deny all IP traffic from any source to the DMZ with `access-list DMZ-IN extended deny ip any any log` and enforce this rule using `access-group DMZ-IN in interface DMZ`.
Our ACL statements permit all internet traffic to access the public IP addresses of our web and email servers exclusively on ports 80 and 25 Additionally, traffic from DMZ servers is denied and logged through the DMZ-IN ACL, enhancing security This practice ensures that if a DMZ server is compromised, attackers cannot access other resources within the DMZ zone, thereby protecting the network.
Cisco ASA Version 8.3 and later
Starting from Cisco ASA version 8.3, it is essential to use the Real IP address in the Access Control List (ACL) instead of the Mapped public IP address.
To configure static NAT translations on a Cisco ASA, first create a network object for the web server by entering the command `object network web_server_static` and specifying the real IP address with `host 10.0.0.1` Then, map this IP to the external address using `nat (DMZ, outside) static 100.1.1.1` Similarly, for the email server, create another network object with `object network email_server_static`, set its real IP with `host 10.0.0.2`, and map it to the external IP using `nat (DMZ, outside) static 100.1.1.2`.
To enhance security, configure your Cisco ASA to permit only essential ports from the Internet Use the command `access-list OUTSIDE-IN extended permit tcp any host 10.0.0.1 eq 80` to allow HTTP traffic on port 80, and `access-list OUTSIDE-IN extended permit tcp any host 10.0.0.2 eq 25` to permit SMTP traffic on port 25 Finally, apply the access list to the outside interface with `access-group OUTSIDE-IN in interface outside`.
Notice that we have used the Real IP addresses (10.0.0.1 and 10.0.0.2) in the access list entry and NOT the mapped public IP addresses
Scenario 2: Apply Identity NAT (nat 0) to Inside Network when accessing DMZ
Access Control Lists (ACLs) not only regulate traffic flow but can also identify specific traffic for additional actions For instance, in a scenario where the Inside network (192.168.1.0/24) communicates with the DMZ (10.0.0.0/24), we may want to prevent NAT translation for this communication To achieve this, the nat 0 command can be utilized to disable NAT translation from a high security interface to a lower security interface, applicable only in versions prior to 8.3 By combining an ACL with the nat 0 command, we can effectively specify which traffic should remain untransformed.
In Cisco ASA versions prior to 8.3, you can configure a no-NAT access list to permit traffic from the internal network (192.168.1.0/24) to the DMZ (10.0.0.0/24) using the command `access-list NO-NAT extended permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.255.0` To ensure that this traffic is not translated, apply the no-NAT configuration with the command `nat (inside) 0 access-list NO-NAT`.
ACL ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0 ciscoasa(config)# global (outside) 1 interface Use PAT when going from Inside to Outside
The configuration above applies for versions prior to 8.3 The next scenario is much more popular, so let’s proceed with this
Scenario 3: Bidirectional Communication between Inside and DMZ Networks
The previous scenario 2 above works only for traffic going from Inside to DMZ (and not vice-versa)
To enable bidirectional communication between the Inside Network and the DMZ, it is essential to configure Static NAT translation By implementing a static Identity NAT for the Inside LAN (192.168.1.0/24), the source IP addresses of hosts within the Inside LAN will remain unchanged when communicating with the DMZ.
(Identity NAT) Since we will use static mapping, this will allow also access from DMZ to Inside (controlled by an ACL ofcourse)
Referring again to the previous diagram in scenario 1 above, we will create a Static Identity NAT of Inside LAN Let’s see the commands needed for this scenario:
Cisco ASA Version Prior to 8.3 ciscoasa(config)# static (inside , DMZ) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
This configuration establishes a Static Identity NAT between the inside LAN and DMZ zones, ensuring that hosts in the Inside Zone remain untranslated when accessing the DMZ Zone Additionally, it permits access from the DMZ to the Inside Zone when necessary.
To enable necessary access from the DMZ to the internal network, the "dmzin" access control list (ACL) must be configured This involves permitting TCP traffic from the host with the IP address 10.0.0.2 to the host at 192.168.1.3 on port 25 The configuration commands are as follows: `access-list dmzin extended permit tcp host 10.0.0.2 host 192.168.1.3 eq 25` and `access-group dmzin in interface DMZ`.
The ACL “dmzin” will allow access from DMZ host 10.0.0.2 to Inside host 192.168.1.3 port 25
Cisco ASA Versions 8.3 and later
To configure scenario 3 above in versions 8.3 and later:
To configure static Identity NAT on a Cisco ASA, first create a network object for the internal subnet using the command `object network inside_identity_nat` followed by defining the subnet with `subnet 192.168.1.0 255.255.255.0` Next, create another network object for the internal network with `object network inside_network` and the same subnet definition Finally, apply the static NAT by executing `nat (inside, DMZ) static inside_identity_nat`.
To enable necessary access from the DMZ to the internal network, configure the "dmzin" access control list (ACL) on the Cisco ASA Use the command `access-list dmzin extended permit tcp host 10.0.0.2 host 192.168.1.3 eq 25` to permit TCP traffic from the specified host in the DMZ to the internal host Finally, apply the ACL to the DMZ interface with the command `access-group dmzin in interface DMZ`.
Scenario 4: Apply Outbound Restrictions from Inside to DMZ
To restrict access for users on the Inside network (192.168.1.0/24), configure the Cisco ASA to allow only email retrieval from the DMZ email server at port 25 while denying access to the rest of the DMZ The necessary commands include creating an access-list named INSIDE-IN that permits TCP traffic from the Inside network to the email server at 10.0.0.2 on port 25, denies all other IP traffic from the Inside network to the DMZ, and permits all traffic from the Inside network to the Internet Finally, apply the access-group INSIDE-IN to the inside interface to enforce these rules.
Configuring Object Groups for ACLs
Managing a large network with hundreds of hosts secured by a Cisco Firewall requires strict access control in accordance with your organization's security policy However, the creation and maintenance of Access Control Lists (ACLs) in such a complex environment can be a challenging endeavor.
Cisco's object-group command simplifies firewall administration by allowing administrators to group hosts, networks, and ports into object groups These groups can be referenced in access-list commands, significantly reducing the number of lines needed in the access list and streamlining ACL management Additionally, any updates to hosts or ports within the object group are automatically updated in the access list, enhancing efficiency and ease of maintenance.
There are six types of object groups:
Network: Used to group together hosts or subnets
Service: Used to group TCP or UDP port numbers
Protocol: Used to group protocols
ICMP-type: Used to group ICMP message types
User: Creates Local User Groups (used in Identity Firewall feature)
Security object group (Version 9.x): Used with Cisco TrustSec
We will describe the first two types (Network and Service object groups) since they are the most important and popular types used in ACLs
To create a Network Object Group on a Cisco ASA device, use the command format: `ciscoasa(config)# object-group network "group_name"` to define the group's name, which will switch you to subcommand mode (config-network) In this mode, you can define a single host with `ciscoasa(config-network)# network-object host "ip_addr"` or specify an entire subnet using `ciscoasa(config-network)# network-object "net_addr netmask"` Once you have finished defining the objects, exit the subcommand mode by typing `ciscoasa(config-network)# exit` and return to the main configuration mode with `ciscoasa(config)#`.
To create a network object group in Cisco ASA, use the command `object-group network WEB_SRV` followed by adding individual hosts with `network-object host 10.0.0.1` and `network-object host 10.0.0.2` Additionally, establish another object group named `DMZ_SUBNET` by executing `object-group network DMZ_SUBNET` and defining the subnet with `network-object 10.0.0.0 255.255.255.0`.
Using the object group with an ACL: ciscoasa(config)# access-list OUT-IN extended permit tcp any object-group WEB_SRV eq 80
We created a network object group named WEB_SRV for our Web Servers (10.0.0.1 and 10.0.0.2), allowing TCP access from Outside to this object group on port 80 with a single ACL statement The network object group can be utilized in the access-list command as a substitute for the destination address, and it can also replace the source address when necessary.
To create a Service Object Group on a Cisco ASA, use the command format: `ciscoasa(config)# object-group service "group_name" {tcp | udp | tcp-udp}` to define the group name and the type of service ports (TCP, UDP, or both) Next, specify the service ports with the command: `ciscoasa(config-service)# port-object {eq | range} "port_number"` Finally, exit the configuration mode with `ciscoasa(config-service)# exit` followed by `ciscoasa(config)#`.
To configure a service object group on a Cisco ASA, use the command `object-group service DMZ_SERVICES tcp` followed by defining the specific ports with `port-object eq http`, `port-object eq https`, and `port-object range 21 23` Additionally, create a network object group named `DMZ_SUBNET` using the command `object-group network DMZ_SUBNET`, and specify the network range with `network-object 10.0.0.0 255.255.255.0`.
Using the object group with an ACL: ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any object-group
DMZ_SUBNET object-group DMZ_SERVICES
In our example, we have a DMZ network with the IP range 10.0.0.0/24, which hosts servers providing TCP services such as HTTP, HTTPS, FTP (port 21), SSH (port 22), and Telnet (port 23) To manage this setup efficiently, we created a DMZ network object group called DMZ_SUBNET, along with a corresponding service object group.
(DMZ_SERVICES) The DMZ_SUBNET group is used in place of the destination address, and the DMZ_SERVICES group is used in place of the destination port.
Time Based Access Lists
Time-Based ACLs are a valuable feature that allows you to specify a time-range for ACL entries, ensuring they are only active during designated periods To implement this, you first define the time-range and then apply it to the relevant ACL entry.
Assume we want to restrict web access for the Internal network during working hours from 09:00 to 17:00
Step1: Define the time-range period
You can use absolute time ranges (such as January 1 to January 20) or periodic ranges (such as weekdays or every Sunday for example)
ASA1(config)# time-range workhours
ASA1(config-time-range)# periodic weekdays 09:00 to 17:00
ASA1(config-time-range)# exit
Step2: Create an ACL which will use the time range above
ASA1(config)# access-list INSIDE-IN extended deny tcp any any eq www time-range workhours
ASA1(config)#access-list INSIDE-IN extended permit ip any any
ASA1(config)# access-group INSIDE-IN in interface inside
From the configuration above, if a user tries to access the web and the time-range is within the
“workhours” period, then the first ACL entry will be enabled and therefore the user will be blocked
If the time-range is outside the “workhours” period then the first ACL entry will be disabled and therefore the second ACL entry will permit the traffic
To enable web access for a designated DMZ server to download security updates every Sunday from 08:00 to 11:00, internet access will be restricted outside of this timeframe.
ASA1(config)# time-range updatehours
ASA1(config-time-range)# periodic Sunday 08:00 to 11:00
ASA1(config-time-range)# exit
ASA1(config)#access-list DMZ-IN extended permit ip host 10.1.1.1 any time-range updatehours
ASA1(config)# access-list DMZ-IN extended deny ip any any
ASA1(config)# access-group DMZ-IN in interface DMZ