Chapter 1 Getting Started With Cisco Firewalls.pdf

Chapter 1 Getting Started With Cisco Firewalls 1.1 User Interface This lesson describes the access modes and commands associated with the operation of Cisco ASA security appliances. We assume that you know how to connect to the appliance using a console cable (the blue flat cable with RJ-45 on one end, and DB-9 Serial on the other end) and a Terminal Emulation software (e.g HyperTerminal or Putty), and how to use basic Command Line Interface. 1.1.1 Security Appliance Access Modes A Cisco security appliance (PIX or ASA) has four main administrative access modes: Monitor Mode: Displays the monitor> prompt. A special mode that enables you to update the image over the network or to perform password recovery. While in the monitor mode, you can enter commands to specify the location of a TFTP server and the location of the software image or password recovery binary image file to download. You access this mode by pressing the “Break” or “ESC” keys immediately after powering up 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> This mode provides restricted view of the security appliance. You cannot configure anything from this mode. To get started with configuration, the first command you need to know is the enable command. Type enable and hit Enter. The initial password is empty, so hit Enter again to move on the next access mode (Privileged Mode). ciscoasa> enable Unprivileged Mode password: Enter a password here (initially its blank) ciscoasa# Privileged Mode Privileged Mode: Displays the # prompt. Enables you to change the current settings. Any unprivileged command also works in this mode. From this mode you can see the current configuration by using show running-config. Still, you cannot configure anything yet until you go to Configuration Mode. You access the Configuration Mode using the configure terminal command from the Privileged Mode. Enjoy 10 Configuration Mode: This mode displays the (config)# prompt. Enables you to change all system configuration settings. Use exit from each mode to return to the previous mode. ciscoasa> enable Unprivileged Mode password: Enter a password here (initially its blank) ciscoasa# configure terminal Privileged Mode ciscoasa(config)# Configuration Mode ciscoasa(config)# exit ciscoasa# exit Back to Privileged Mode ciscoasa> Back to Unprivileged Mode The (config)# mode is sometimes called Global Configuration Mode. Some configuration commands from this mode enter a command-specific mode and the prompt changes accordingly. For example the interface command enters interface configuration mode as shown below: ciscoasa(config)# interface GigabitEthernet0/1 ciscoasa(config-if)# Configure Interface specific parameters 1.2 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 first one (running-configuration) is the one currently running on the appliance, and its stored in the RAM of the firewall. You can view this configuration by typing (in Privileged Mode): ciscoasa# show running-config Enjoy 11 Any command that you enter in the firewall is directly written in the running-config and takes effect immediately. Since the running-config is written in the RAM memory, if the appliance loses power it will lose also any configuration changes that were not previously saved. 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. As mentioned above, the startup-configuration is the backup configuration of the running one. It is stored in Flash Memory, so it is not lost when the appliance is rebooted. Also, the startup configuration is the one which is loaded when the appliance boots-up. To view the stored startup configuration type show startup-config. 1.3 ASA Image Software Management The ASA image is basically the operating system of the appliance. It is like the IOS used in Cisco Routers. When we refer to ASA software version 8.x, 9.x etc we mean the version of the image software. The ASA image is a compressed binary file and it’s pre-installed on the flash of the device. The image gets decompressed into RAM when the appliance boots-up. For example an ASA image filename looks like “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: Step1: Setup a TFTP Server 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 Enjoy 12 Step2: Copy image file from TFTP to Flash of ASA ciscoasa# copy tftp flash Address or name of remote host []? 192.168.1.10 Source filename []?asa911-k8.bin Destination filename [asa911-k8.bin]? Hit Enter Accessing tftp://192.168.1.10/asa911-k8.bin ……. 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 1.4 Password Recovery Procedure If for any reason you are locked out of an ASA appliance and you don’t remember the password to log-in, then you need to follow the password recovery procedure below: Step1: Connect with a console cable to the ASA and power-cycle the device (switch it OFF and ON again) Step2: Press continuously the “ESC” key on your keyboard until the device gets into ROMMON mode. This mode shows the following prompt: rommon #1> Step3: 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. Current Configuration Register: 0x00000011 Configuration Summary: boot TFTP image, boot default image from Flash on netboot failure Do you wish to change this configuration? y/n [n]: n Enjoy 13 Step4: 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 Step5: Now the ASA will ignore its startup configuration and boot up without asking for a password. ciscoasa>enable Password: ciscoasa# Step6: Copy the startup configuration file into the running configuration. ciscoasa# copy startup-config running-config Destination filename [running-config]? Step7: Now configure a new privileged level password (enable password) and also reset the configuration register to its original value (0x01) ciscoasa#conf term ciscoasa(config)#enable password strongpass ciscoasa(config)# config-register 0x01 ciscoasa(config)# wr mem Step8: Reload the appliance. Now you should be able to log in with the new password. ciscoasa(config)# reload 1.5 Security Levels This lesson describes the security levels concept as used in the ASA firewall appliance. A Security Level is assigned to interfaces (either physical or logical sub-interfaces) and it is basically a number from 0 to 100 designating how trusted an interface is relative to another interface on the appliance. The higher the security level, the more trusted the interface (and hence the network connected behind it) is considered to be, relative to another interface. Since each firewall interface represents a specific network (or security zone), by using security levels we can assign ‘trust levels’ to our security zones. The primary rule for security levels is that an interface (or zone) with a Enjoy 14 higher security level can access an interface with a lower security level. On the other hand, an interface with a lower security level cannot access an interface with a higher security level, without the explicit permission of a security rule (Access Control List - ACL). 1.5.1 Security Level Examples 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 ‘Outside’ Interface of the firewall. It is the least trusted security level and must be assigned accordingly to the network (interface) that we don’t want it to have any access to our internal networks. This security level is usually assigned to the interface connected to the Internet. This means that every device connected to the Internet can not have access to any network behind the firewall, unless explicitly permitted by an 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 ‘Inside’ Interface of the firewall. It is the most trusted security level and must be assigned accordingly to the network (interface) that we want to apply the most protection from the security appliance. This security level is usually assigned to the interface connecting the Internal Corporate network behind it. Enjoy 15 The diagram above illustrates a typical example of security levels assignment in a network with an Inside, Outside, and DMZ zones. Throughout this book we will represent the Cisco Firewall with the “Electrical Diode” symbol. As you can see, the Internal Corporate Network is connected to the Interface with the highest security level (Interface G0/1 with Security Level 100) which is also named as ‘Inside’. The Interface name ‘Inside’ is given by default to the interface with the highest security level. Also, the INTERNET facing interface (G0/0) is named ‘Outside’ and is assigned a security level of 0. A Perimeter Zone (DMZ) is also created with a Security Level of 50. The Red Arrows in the diagram represent the flow of traffic. As you can see, the Inside Zone can access both DMZ and Outside Zones (Security Level 100 can access freely the Security Levels 50 and 0). The DMZ Zone can access only the Outside Zone (Security Level 50 can access Level 0), but not the Inside Zone. Lastly, the Outside Zone cannotaccess either the Inside or the DMZ zones. What is described in the example above is the default behavior of the Cisco ASA Firewalls. We can override the default behavior and allow access from Lower Security Levels to Higher Security Levels by using Static NAT (only if required) and Access Control Lists, as we will see in the next chapters of this book. Enjoy 16 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). If NAT-Control is enabled on the device, then there must be a nat/global translation pair between High-to-Low Security Level interfaces. NOTE: “global” command is not supported in ASA versions 8.3 and later (more on this later). Traffic from Lower Security Level to Higher Security Level: Drop ALL traffic unless specifically allowed by an ACL. If NAT-Control is enabled on the device (more on this later), then there must be a Static NAT between High-to-Low Security Level interfaces. 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). 1.6 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) By default there is no password for accessing the ASA firewall, so the first step before doing anything else is to configure a privileged level password, which will be needed to allow subsequent access to the appliance. Configure this under Configuration Mode: ciscoasa(config)# enable password mysecretpassword STEP2: Enable Remote Command Line Management You can access the security appliance remotely for Command Line Interface management (CLI) using either Telnet or SSH, and for Web-based graphical management using HTTPS (ASDM management). It is recommended to use SSH for CLI management since all communication with the firewall will be encrypted, compared with using Telnet which is not encrypted. To enable SSH on Enjoy 17 the firewall, we need first to create a username/password for authentication, then generate encryption keys (RSA keys), and also specify the IP address of the management host/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 STEP3: Configure a Firewall Hostname The default hostname for Cisco ASA appliances is ciscoasa, and for the Cisco PIX appliance is pixfirewall. It is advisable to configure a unique hostname for a new firewall so that you can differentiate it from other firewalls that you may have in the network. ciscoasa(config)# hostname NewYork-FW NewYork-FW(config)# Notice how the CLI prompt has changed to the new Hostname that you just configured. STEP4: Configure Interface Commands 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, Ethernet0/1 etc). The “Interface” command will put you into a special configuration mode for the interface you specify (interface configuration mode), and then allow you to configure other interface sub-commands inside the interface mode. For Cisco ASA 5505, the interface commands are configured under the “Interface Vlan x” mode. ciscoasa(config)# interface GigabitEthernet0/1 ciscoasa(config-if)# Configure Interface specific sub-commands For Cisco ASA 5505: ciscoasa(config)# interface Vlan [vlan number] ciscoasa(config-if)# Configure Interface specific sub-commands Enjoy 18 The absolutely necessary Interface Sub-commands that you need to configure in order for the interface to pass traffic are the following: o nameif “interface name”: Assigns a name to an interface o ip address “ip_address” “subnet_mask” : Assigns an IP address to the interface o security-level “number 0 to 100” : Assigns a security level to the interface o no shutdown : By default all interfaces are shut down, so enable them. The configuration snapshot below shows all necessary interface sub-commands: ciscoasa(config)# interface GigabitEthernet0/1 ciscoasa(config-if)# nameif inside ciscoasa(config-if)# ip address 10.0.0.1 255.255.255.0 ciscoasa(config-if)# security-level 100 By default “inside” interface is sec-level 100 ciscoasa(config-if)# no shutdown ciscoasa(config)# interface GigabitEthernet0/0 ciscoasa(config-if)# nameif outside ciscoasa(config-if)# ip address 10.1.1.1 255.255.255.0 ciscoasa(config-if)# security-level 0 By default “outside” interface is sec-level 0 ciscoasa(config-if)# no shutdown STEP5: Configure NAT Control as needed (This is for versions lower than 8.3) Another important configuration step is nat-control. NAT (Network Address Translation) was a mandatory configuration in older Cisco PIX firewalls (PIX version 6.x) but with ASA Firewalls it is not. Nat-Control (which is disabled by default) specifies whether or not the security appliance will enforce address hiding (i.e address translation) to ALL traffic passing from a high security level to a lower one. If you stay with the default configuration (i.e nat-control disabled), this will allow you to apply NAT (address hiding) to only selected traffic as you require. If you enable nat-control (using the command: asa(config)#nat-control ) then you MUST have a NAT rule for ALL traffic passing from a high security interface to a lower security interface. The NAT rule must match a corresponding “global” command (more on NAT later). With the default configuration (nat-control disabled) the ASA passes traffic between interfaces with no need to configure any NAT statements. You just need to have the proper Access Control Lists applied on each interface to enforce traffic flow policies. NOTE: From ASA version 8.3 and later, “nat-control” and “global” commands are no longer supported. Enjoy 19 STEP6: Configure routing Routing is an essential step to configure, otherwise the Firewall appliance will not know how to send traffic to its destination. In the example above we show only default and static routing although dynamic routing protocols (RIP, OSPF, EIGRP) can be configured also. My recommendation is to use only default or static routing and avoid dynamic protocols in small networks. However, dynamic routing protocols on the ASA are also useful in larger and complex networks. More on dynamic routing protocols 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 For the default route (usually towards the Internet), you set both the destination-ip-address and netmask to 0.0.0.0. Create also static routes to access specific known networks beyond the locally connected networks, as shown on the diagram above. Enjoy 20 The routing configuration concludes the “Minimum Mandatory” steps needed for the security appliance to become operational. Next we will get into more details for further configuration features that will enhance the security of the networks protected by the firewall. Chapter 2 Configuring Network Address Translation In this Chapter we will talk about a very important security mechanism that has to do with IP address translation (address hiding), its different types, and how the firewall appliance handles the translation mechanisms. From Cisco ASA version 8.3 and later, the Network Address Translation (NAT) configuration has been completely redesigned to allow for greater flexibility. In this Chapter we will describe Network Translation for versions prior to 8.3 and for versions 8.3 and later as well. NOTE: NAT configuration in ASA versions 9.x is the same as 8.3 and 8.4 versions. 2.1 Network Address Translation (NAT) Overview The depletion of the public IPv4 address space has forced the Internet Community to think about alternative ways of addressing networked hosts. NAT therefore was created to overcome these addressing problems that occurred with the expansion of the Internet. 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 figure below shows a basic topology with an “inside” network for which the ASA Firewall performs a NAT operation to translate the “inside” address into an “outside” address, thus hiding the internal IP range. Note that the translation is usually applied to the “source” IP address of the packets. Enjoy 22 The above is an example of dynamic NAT which is always used for OUTBOUND traffic, that is, traffic from an internal network (higher security level) towards an outside network (lower security level). In the figure above, traffic from the host with private IP address 192.168.1.1 is translated into a public, routable address, 100.1.1.2 in order to be routed towards the Internet. Now, the reply packets from the Internet back to our internal host will have as destination address the IP 100.1.1.2, for which the firewall already has a translation rule established. The firewall will then translate the public address 100.1.1.2 back into 192.168.1.1 and deliver it to the internal host. The “nat” and “global” commands work together (versions prior to 8.3) to create the translation rules which enable your internal network to use any IP addressing scheme and at the same time remain hidden from the outside world. Let’s see some terminology that will be used in this Chapter: Real IP address/Interface: The Real IP address is the address which is actually configured on the host (the untranslated address). From our example diagram above, the Real IP address is 192.168.1.1 and the Real Interface is the Inside ASA interface. Mapped IP address/Interface: The mapped IP address is the address that the Real address is translated to. From our example diagram above, the Mapped IP address is 100.1.1.2 and the Mapped Interface is 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 “nat” command defines which internal hosts will be translated, and the “global” command (ASA versions prior to 8.3) defines the address pool (mapped addresses) on the outgoing interface. Dynamic NAT is used for outbound communication only. 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 Real IP address and a Mapped IP address. The Real IP should be on a higher security interface and the Mapped IP on a lower security interface. With the appropriate Access Control List (ACL), static NAT allows hosts on a less secure interface (e.g Internet) to access hosts on a higher security interface (e.g Web Server on DMZ) without exposing the Enjoy 23 actual IP address of the host on the higher security interface. Static NAT is used for Bidirectional communication. Identity NAT: Identity NAT lets you translate a Real IP address to itself, essentially bypassing NAT. Identity NAT is usefull in VPN configuration where we need to exempt VPN traffic from the NAT operation. 2.1.1 Configuring Dynamic NAT Translation Cisco ASA Versions prior to 8.3 In this section we will describe Dynamic NAT translation with several scenarios. Dynamic NAT is implemented using a combination of two commands: “nat” and “global”. The Real IP network to be translated is defined by the “nat” command and the Mapped IP pool that will be used for translation is defined by the “global” command. The format of the “nat” and “global” commands as used in Dynamic NAT is shown below: ciscoasa(config)# nat (Real_interface_name) “nat-id” “internal network IP subnet” ciscoasa(config)# global (Mapped_interface_name) “nat-id” “external IP pool range” Cisco ASA Versions 8.3 and later In Cisco ASA version 8.3 (announced on March 8, 2010), the NAT configuration has been completely changed. The “nat-control”, “static” and “global” commands are not available anymore. Also, the new version’s syntax uses the “nat” command differently as we will describe below. If you are running a version prior to 8.3 (e.g 7.x, 8.0, 8.1, 8.2) and you want to upgrade to 8.3, then keep in mind that a memory upgrade is also required for models 5505, 5510, 5520, 5540. Also, after upgrading, there will be a migration of the old NAT statements to the new ones. In versions 8.3 and later (including 9.x versions), the ASA firewall implements NAT in two ways: “Network object NAT” “Twice NAT” Enjoy 24 Cisco recommends using “Network object NAT” instead of “Twice NAT” because is easier to configure and more reliable. Twice NAT on the other hand is more scalable and has some extra features but is more complex than network object NAT. In this Chapter we will focus only on Network Object NAT. 2.1.1.1 Network Object NAT Configuration Basically you configure NAT under a network object. The network object itself defines the Real IP address/subnetwhich is going to be translated. Also, inside the network object you configure the “nat” command which specifies a pair of interfaces between which the NAT will take place and the Mapped IP address pool. Step1: Create network objects to define the Real IP addresses and the Mapped IP addresses. The network objects can contain a single IP address (host), a network subnet, or a range of IP addresses. The network object which defines the Real IP addresses must contain also the “nat” statement. ciscoasa(config)# object network [obj-name] ciscoasa(config-network-object)# {host ip-addr | subnet net-addr net-mask | range ip1-ip2} Step2: Then we configure the “nat” statement inside the network object which defines the Real IP addresses. ciscoasa(config-network-object)# nat (real if , mapped if) dynamic [mapped-ip | mapped-obj] The “real if” and “mapped if” define the internal and external interfaces respectively between which the Dynamic NAT will take place. After the “dynamic” keyword, we use a mapped IP or a mapped network object which define the IP addresses that the real addresses will be translated to. In place of “real if” or “mapped if” we can use the keyword “any” to specify any interface. Enjoy 25 Scenario 1: Simple Dynamic Inside NAT Translation Cisco ASA Versions prior to 8.3 ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0 Inside net to be translated ciscoasa(config)# global (outside) 1 100.1.1.2-100.1.1.50 netmask 255.255.255.0 Outside pool In the scenario above the firewall will perform dynamic NAT to all inside hosts (192.168.1.0/24). The source IP addresses of outbound traffic from inside to outside will be translated into addresses from the Outside Global pool 100.1.1.2 up to 100.1.1.50. Notice the nat-id value (1). This number binds the nat command with the global command. Its importance will be clearer in our next scenarios. Also note the names “inside” and “outside” used in the nat and global commands. These names are the ones assigned under the interface configuration with the “nameif” command. Cisco ASA Versions 8.3 and later ciscoasa(config)# object network mapped_public_pool Create the Mapped addresses object ciscoasa(config-network-object)# range 100.1.1.2 100.1.1.50 Outside public pool ciscoasa(config)# object network my_internal_lan Create the Real IP addresses object ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 LAN to be translated ciscoasa(config-network-object)# nat (inside,outside) dynamic mapped_public_pool Enjoy 26 The example above will hide the internal subnet 192.168.1.0/24 behind a range of public outside addresses in the range 100.1.1.2 up to 100.1.1.50. The dynamic NAT translation will take place between inside and outside interfaces. NOTE:Because the internal network has more IP addresses than the Mapped Public Pool, we can use the outside interface IP as NAT fallback. After the mapped IP addresses are used up, then the IP address of the mapped interface (outside ASA interface) will be used. See below how to configure dynamic NAT fallback: ciscoasa(config)# object network my_internal_lan Create the Real IP addresses object ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 LAN to be translated ciscoasa(config-network-object)# nat (inside,outside) dynamic mapped_public_pool interface Use the “interface” keyword just after the “mapped_public_pool“ network object. Scenario 2: Dynamic NAT Translation of two internal networks Cisco ASA Versions prior to 8.3 Enjoy 27 ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0 First Internal Network ciscoasa(config)# nat (inside) 2 192.168.2.0 255.255.255.0 Second Internal Network ciscoasa(config)# global (outside) 1 100.1.1.2-100.1.1.50 netmask 255.255.255.0 ciscoasa(config)# global (outside) 2 100.1.1.51-100.1.1.100 netmask 255.255.255.0 The scenario here shows the importance of the nat-id parameter and how this is used to bind together a nat/global command pair. The nat-id (1) in the first nat command statement tells the firewall to translate the internal network 192.168.1.0/24 addresses into those in the mapped global IP pool containing the same nat-id (i.e 100.1.1.2 up to 100.1.1.50). Similarly, the nat-id (2) in the second nat statement tells the firewall to translate addresses for hosts in 192.168.2.0/24 to the addresses in the mapped global pool 2 with nat-id (2) (i.e 100.1.1.51 up to 100.1.1.100). Cisco ASA Version 8.3 and later Let’s see how to configure the scenario above with ASA version 8.3 or later. Hosts from internal network 192.168.1.0/24 will be translated to addresses from Outside IP pool 1 (100.1.1.2 up to 100.1.1.50) and hosts from internal network 192.168.2.0/24 will be translated to addresses from Outside IP pool 2 (100.1.1.51 up to 100.1.1.100). ciscoasa(config)# object network mapped_IP_pool_1 Create the Mapped 1 addresses object ciscoasa(config-network-object)# range 100.1.1.2 100.1.1.50 Outside IP pool 1 ciscoasa(config)# object network lan_1 ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 LAN1 to be translated ciscoasa(config-network-object)# nat (inside,outside) dynamic mapped_IP_pool_1 ciscoasa(config)# object network mapped_IP_pool_2 Create the Mapped 2 addresses object ciscoasa(config-network-object)# range 100.1.1.51 100.1.1.100 Outside IP pool 2 ciscoasa(config)# object network lan_2 ciscoasa(config-network-object)# subnet 192.168.2.0 255.255.255.0 LAN2 to be translated ciscoasa(config-network-object)# nat (inside,outside) dynamic mapped_IP_pool_2 Enjoy 28 Scenario 3: Dynamic NAT Translation with three interfaces Cisco ASA Versions prior to 8.3 ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0 Inside Subnet ciscoasa(config)# nat (DMZ) 1 172.16.1.0 255.255.255.0 DMZ Subnet ciscoasa(config)# global (outside) 1 100.1.1.1-100.1.1.254 netmask 255.255.255.0 ciscoasa(config)# global (DMZ) 1 172.16.1.100-172.16.1.254 netmask 255.255.255.0 In the scenario above, assume that “inside” interface has security level 100, “DMZ” interface has security level 50, and “outside” interface has security level 0. This means that “inside” hosts can initiate connections to lower security level interfaces (i.e to both “DMZ” and “outside”). Also, these security levels allow hosts on the DMZ interface to initiate connections towards the outside interface. Because both of the mapped pools (global commands) and the nat(inside) command use the same nat-id of 1, addresses for hosts on the inside network (192.168.1.0/24) can be translated to those in either mapped pool, depending on the direction of the traffic. Therefore, when hosts on the inside interface access hosts on the DMZ, the global(DMZ) command causes their source addresses to be translated to addresses in the range 172.16.1.100 – 172.16.1.254. Similarly, when inside hosts access hosts on the outside, the global (outside) command will cause their source addresses to be translated into the range 100.1.1.1 – 100.1.1.254. Enjoy 29 Moreover, the configuration above allows also hosts on the DMZ to use NAT when accessing outside hosts. The nat (DMZ) together with global (outside) commands will cause the source addresses of DMZ hosts (172.16.1.0/24) to be translated into the outside range 100.1.1.1 – 100.1.1.254. Monitoring NAT Translations The “ciscoasa# show xlate” command displays the contents of the NAT translation table. e.g Global 100.1.1.10 Local 192.168.1.10 The output above shows that a private local address 192.168.1.10 is assigned a global pool address of 100.1.1.10. Cisco ASA Version 8.3 and later For version 8.3 and later this scenario becomes more complicated to configure. We have three firewall network zones. Inside, DMZ, and Outside. Traffic from Inside going to DMZ network must be translated to Mapped IP Pool 172.16.1.100-254 and traffic from Inside going to Outside must be translated to Mapped IP Pool 100.1.1.1-254. Moreover, traffic from DMZ going to Outside must also be translated to outside Mapped IP Pool 100.1.1.1-254. Let’s first create the two network objects for the two Mapped IP pools. ciscoasa(config)# object network mapped_IP_pool_1 Create the Mapped 1 addresses object ciscoasa(config-network-object)# range 172.16.1.100 172.16.1.254 DMZ IP pool 1 ciscoasa(config)# object network mapped_IP_pool_2 Create the Mapped 2 addresses object ciscoasa(config-network-object)# range 100.1.1.1 100.1.1.254 Outside IP pool 2 Then create the network objects for the Real IP addresses. We will have to create a different object for the three traffic flows (inside_to_dmz, inside_to_outside, dmz_to_outside). ciscoasa(config)# object network inside_to_dmz translation when going from inside to dmz ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 ciscoasa(config-network-object)# nat (inside,dmz) dynamic mapped_IP_pool_1 Enjoy 30 ciscoasa(config)# object network inside_to_outside translation when going from in to out ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 ciscoasa(config-network-object)# nat (inside,outside) dynamic mapped_IP_pool_2 ciscoasa(config)# object network dmz_to_outside translation when going from dmz to outside ciscoasa(config-network-object)# subnet 172.16.1.0 255.255.255.0 ciscoasa(config-network-object)# nat (dmz,outside) dynamic mapped_IP_pool_2 2.1.2 Configuring Dynamic Port Address Translation (PAT) With Dynamic NAT we assume that we have a range (pool) of public addresses that we use to translate our internal network private addresses. In real situations, an enterprise receives only a limited number of public addresses from its ISP, whereas the number of internal private addresses is much bigger. This means that if we use Dynamic NAT in such a situation, the external public address pool (Mapped IP pool) will be depleted really fast when many internal hosts access the internet simultaneously. To overcome this problem, we can use a “many-to-one” address translation, called also Port Address Translation (PAT). Using PAT, multiple connections from different internal hosts can be multiplexed over a single global (public) IP address using different source port numbers. Let’s see an example below: Enjoy 31 Cisco ASA Versions prior to 8.3 ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0 Inside Subnet to use PAT ciscoasa(config)# global (outside) 1 100.1.1.2 netmask 255.255.255.255 Use a single global IP address for PAT In the example above, all internal private addresses (192.168.1.0/24) will use a single public IP address (100.1.1.2) with different source port numbers. For example, when host 192.168.1.1 connects on an Internet outside host, the firewall will translate its source address and port into 100.1.1.2 with source port 1024. Similarly, host 192.168.1.2 will be translated again into 100.1.1.2 but with a different source port (1025). The source ports are dynamically changed to a unique number greater than 1023. A single PAT address can support around 64,000 inside hosts. Monitoring PAT Translations The ciscoasa# show xlate command displays the contents of the PAT translation table. e.g PAT Global 100.1.1.2 (1024) Local 192.168.1.1 (4513) The output above shows that a connection from the private local address 192.168.1.1 with source port 4513 is translated into address 100.1.1.2 with source port 1024. The firewall keeps track of all NAT sessions using its xlate table, so that when a reply packet comes back from outside, the firewall will check its translation table to see which port number belongs to the particular reply packet in order to deliver it to the correct internal host. Enjoy 32 Cisco ASA Version 8.3 and later You can configure the single Mapped IP address either as a network object or within the “nat” statement. For example, assume that we want to hide our internal network 192.168.1.0/24 behind the public IP address 100.1.1.2. ciscoasa(config)# object network internal_lan ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 ciscoasa(config-network-object)# nat (inside,outside) dynamic 100.1.1.2 There are several different scenarios in which PAT can be used in a network. We will describe them next. Scenario 1: PAT using outside interface IP address Instead of configuring a specific IP address in the global command to be used for PAT (as the example above), we can specify the outside Interface as the PAT address. This scenario is important when our firewall obtains a dynamic public IP address from the Internet Service Provider (ISP), in which case we don’t know the exact address to configure it on the global command. Refer to the diagram below for a configuration example using DHCP outside address for PAT: Cisco ASA Versions prior to 8.3 ciscoasa(config)# interface G0/0 ciscoasa(config-if)# ip address dhcp setroute Get outside address and gateway from ISP ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0 Inside Subnet to use PAT ciscoasa(config)# global (outside) 1 interface Use the outside IP address for PAT Enjoy 33 The “ip address dhcp setroute” interface command configures the firewall to work as a DHCP client for the ISP and obtain a public address automatically. The “setroute” parameter tells the Cisco Firewall to set its default route using the default gateway value that the DHCP server provides. Do not configure a default route when using the setroute option. Cisco ASA Version 8.3 and later To use the outside ASA interface address to perform PAT in version 8.3 and later do the following: ciscoasa(config)# interface G0/0 ciscoasa(config-if)# ip address dhcp setroute Get outside address and gateway from ISP ciscoasa(config)# object network internal_lan ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 ciscoasa(config-network-object)# nat (inside,outside) dynamic interface Scenario 2: Mapping different internal subnets to different PAT addresses Cisco ASA Versions prior to 8.3 Using the nat-id parameter we can bind two or more nat/global statement pairs in order to map different internal network subnets to different PAT addresses, as shown in the diagram below: Enjoy 34 ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0 ciscoasa(config)# global (outside) 1 100.1.1.1 netmask 255.255.255.255 ciscoasa(config)# nat (inside) 2 192.168.2.0 255.255.255.0 ciscoasa(config)# global (outside) 2 100.1.1.2 netmask 255.255.255.255 Outbound connections from internal subnet 192.168.1.0/24 will seem to originate from address 100.1.1.1 and outbound connections from subnet 192.168.2.0/24 will seem to originate from address 100.1.1.2. Cisco ASA Version 8.3 and later In this scenario, internal network 192.168.1.0/24 will be hidden behind PAT address 100.1.1.1 and also internal network 192.168.2.0/24 will be hidden behind PAT address 100.1.1.2. ciscoasa(config)# object network internal_lan1 ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 ciscoasa(config-network-object)# nat (inside,outside) dynamic 100.1.1.1 ciscoasa(config)# object network internal_lan2 ciscoasa(config-network-object)# subnet 192.168.2.0 255.255.255.0 ciscoasa(config-network-object)# nat (inside,outside) dynamic 100.1.1.2 Enjoy 35 Scenario 3: Combining Dynamic NAT with PAT Translation We can use a pool of external public IP addresses for Dynamic NAT translation, and augment this pool with a single PAT address in case the addresses in the global pool are exhausted. Cisco ASA Versions prior to 8.3 ciscoasa(config)# nat (inside) 1 192.168.1.0 255.255.255.0 ciscoasa(config)# global (outside) 1 100.1.1.100-100.1.1.253 netmask 255.255.255.0 ciscoasa(config)# global (outside) 1 100.1.1.254 netmask 255.255.255.255 Outbound connections from the internal network 192.168.1.0/24 are assigned addresses from the range 100.1.1.100 up to 100.1.1.253. If the firewall assigns all addresses from its dynamic pool, it will overflow to its PAT address 100.1.1.254. Cisco ASA Version 8.3 and later The mapped IP pool 100.1.1.100-100.1.1.253 will be used for Dynamic NAT translation of the internal network 192.168.1.0/24. If the Mapped pool is exhausted, the single PAT address 100.1.1.254 will be used for translation. ciscoasa(config)# object network mapped_IP_pool ciscoasa(config-network-object)# range 100.1.1.100 100.1.1.253 ciscoasa(config)# object network PAT_IP ciscoasa(config-network-object)# host 100.1.1.254 ciscoasa(config)# object-group network nat_pat ciscoasa(config-network-object)# network-object object mapped_IP_pool ciscoasa(config-network-object)# network-object object PAT_IP ciscoasa(config)# object network internal_lan ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 ciscoasa(config-network-object)# nat (inside,outside) dynamic nat_pat 2.1.2.1 Per-Session PAT and Multi-Session PAT (For ASA 9.x and later) In ASA version 9.x, Port Address Translation (PAT) was enhanced with two types of PAT mechanisms: Per-session PAT and Multi-Session PAT. Per-Session PAT: This PAT mechanism is enabled by default for all TCP traffic and for UDP DNS Traffic. Per-Session PAT improves greatly the scalability of PAT because at the end of Enjoy 36 each per-session PAT connection, the ASA sends a reset and immediately removes the translation, thus tearing down the connection and hence freeing up resources on the device. For "hit-and-run" traffic, such as HTTP or HTTPS, the per-session feature is very efficient. However, for real time traffic (such as VoIP, H323, SIP etc) Per-Session PAT is not good. As we’ve said above, per-session PAT is enabled by default. The following PAT rules are configured by default: xlate per-session permit tcp any4 any4 xlate per-session permit tcp any4 any6 xlate per-session permit tcp any6 any4 xlate per-session permit tcp any6 any6 xlate per-session permit udp any4 any4 eq domain xlate per-session permit udp any4 any6 eq domain xlate per-session permit udp any6 any4 eq domain xlate per-session permit udp any6 any6 eq domain NOTE: In ASA version 9.x, the configuration keyword “any4” means ALL IPv4 traffic, and the keyword “any6” means ALL IPv6 traffic. If you use the keyword “any” it means ALL IPv4 andIPv6 traffic. Multi-Session PAT: Multi-session PAT, on the other hand, uses the PAT timeout, by default 30 seconds, before tearing down the translation and hence the connection. Multi Session PAT is useful for VoIP, H323, SIP and Skinny traffic. Therefore whenever you have this kind of traffic in your network it’s recommended to deny Per-Session PAT in order to use Multi-Session PAT. Example: Assume we have a VoIP server (or H323, SIP server etc) in our network (with IP 10.10.10.10) and we want to disable Per-Session PAT for this server. Here is how to do it below: ASA(config)# xlate per-session deny tcp any4 10.10.10.10 eq 1720 ASA(config)# xlate per-session deny udp any4 10.10.10.10 range 1718 1719 The above configuration creates a deny rule for H.323 traffic for server 10.10.10.10, so that it uses multi-session PAT. Enjoy 37 2.1.3 Configuring Static Address Translation (Static NAT) The two translation types that we’ve discussed in the previous sections (Dynamic NAT and PAT) are used for Outboundcommunication only (i.e from higher security level to lower security level). However, if an outside host (let’s say a host on the Internet) wants to initiate communication to an Internal host behind the firewall, this is not possible if we have only Dynamic NAT or PAT configured. This is very good in terms of security, but there are several cases that we must allow Inbound access as well (i.e access from lower security to higher security levels – Outside to Inside). To achieve this, we MUST use a Static NAT translation and also configure an appropriate Access Control List. Static NAT maps permanently a host address to a fixed global (outside) address. The most important reasons to use Static NAT are the following: We have an internal server with private IP address (e.g our company’s email or web server) that must always appear with a fixed public IP address on the Outside interface of the firewall. We want to allow hosts from the Outside (e.g Internet) to initiate connections to a local internal server (e.g our Web or email server). We want to use Port Redirection (more on this later). Static NAT in Cisco ASA Versions prior to 8.3 The command format of Static NAT is: ciscoasa(config)# static (real_interface_name , mapped_interface_name) “mapped_IP” “real_IP” netmask “subnet_mask” To configure static NAT we need to know the following parameters: 1. Between which two interfaces the translation will take place. The two interfaces are defined as the real_interface and the mapped_interface. The real interface (e.g DMZ interface or Inside interface) must have higher security level than the mapped interface (e.g Outside interface). 2. The real_IP address of the host (the IP actually configured on the Network Card of the host). 3. The mapped_IP (or translated) IP address of the host (i.e the address that the host will be known to the Outside networks). Enjoy 38 A little “catch” that you need to be careful with the static command is the following: when entering the interface names in the parenthesis, you enter the real_interface name firstfollowed by the mapped_interface name (see command format above). However, when you configure the IP addresses after the interface names, you enter the mapped_IP address firstfollowed by the real_IP address. Let’s see some example scenarios for making things clear: Scenario 1: Static NAT with a Web Server and Email Server on DMZ The network topology above is classic in many enterprises. Usually there is an Inside network on the firewall which hosts all internal employees’ computers, an Outside network that connects to the Internet, and there is also a Demilitarized Zone (DMZ) that hosts servers which should be accessible from the Internet (in our example, a Web Server and an email Server). In this scenario static NAT must be used for the DMZ servers so that their real private IP address is always translated to a fixed public IP address (10.0.0.1 translated to 100.1.1.1 and 10.0.0.2 translated to 100.1.1.2). Enjoy 39 In our scenario above we have the following: Real Interface name : DMZ Mapped Interface name: Outside Real IP addresses: 10.0.0.1 and 10.0.0.2 Mapped IP adresses: 100.1.1.1 and 100.1.1.2 Static NAT in Cisco ASA Versions prior to 8.3 Let’s see the configuration snapshot below: ciscoasa(config)# static (DMZ , outside) 100.1.1.1 10.0.0.1 netmask 255.255.255.255 ciscoasa(config)# static (DMZ , outside) 100.1.1.2 10.0.0.2 netmask 255.255.255.255 The above statements enable bi-directional communication for the web and email servers. Now Internet hosts can access our web and email servers via their public address 100.1.1.1 and 100.1.1.2 Of course an ACL is still needed on the outside interface to allow communication. Static NAT in Cisco ASA Version 8.3 and later Now let’s see how to configure the scenario above in ASA version 8.3 and later. Static NAT configuration uses the same concept as Dynamic NAT (i.e using network objects) but instead of using the keyword “dynamic” in the “nat” statement we use the keyword “static”. The command format of the “nat” statement for static NAT is: ciscoasa(config-network-object)# nat (real if , mapped if) static [mapped-ip | mapped-obj] To configure scenario 1 above in versions 8.3 and later execute the following commands: ciscoasa(config)# object network web_server_static ciscoasa(config-network-object)# host 10.0.0.1 Real IP of Web Server ciscoasa(config-network-object)# nat (DMZ , outside) static 100.1.1.1 Mapped IP ciscoasa(config)# object network email_server_static ciscoasa(config-network-object)# host 10.0.0.2 Real IP of Email Server ciscoasa(config-network-object)# nat (DMZ , outside) static 100.1.1.2 Mapped IP Enjoy 40 Scenario 2: Static NAT for a whole network range (Net Static) Cisco ASA Versions prior to 8.3 Instead of permanently translating single host addresses, we can create permanent address mappings to a whole subnet with just one command. Referring to the previous diagram in scenario 1 above, assume that we have a whole class C public address range 100.1.1.0/24. We can translate the whole DMZ range 10.0.0.0/24 to 100.1.1.0/24. ciscoasa(config)# static (DMZ , outside) 100.1.1.0 10.0.0.0 netmask 255.255.255.0 Any packet sourced from a server address on subnet 10.0.0.0/24 on the DMZ will be translated to a host address on the 100.1.1.0/24 subnet on the outside interface (e.g. host 10.0.0.20 will be translated to 100.1.1.20). Cisco ASA Version 8.3 and later To configure scenario 2 above (i.e static NAT of whole network) in versions 8.3 and later: ciscoasa(config)# object network mapped_static_range ciscoasa(config-network-object)# subnet 100.1.1.0 255.255.255.0 ciscoasa(config)# object network dmz_network ciscoasa(config-network-object)# subnet 10.0.0.0 255.255.255.0 DMZ subnet ciscoasa(config-network-object)# nat (DMZ , outside) static mapped_static_range Enjoy 41 Scenario 3: Static Port Address Translation (Port Redirection) A pretty common scenario is the one shown on the diagram above. Assume we have only one public IP address available (100.1.1.1) but we have two (or more) servers that we need to provide public access for. We know that our Web Server listens to port 80 and our email Server listens to port 25. All inbound traffic hitting address 100.1.1.1 port 80 will be redirected by the firewall to 10.0.0.1 port 80, and all traffic hitting address 100.1.1.1 port 25 will be redirected to 10.0.0.2 port 25. Cisco ASA Versions prior to 8.3 The command format for Port Redirection is the following: ciscoasa(config)# static (real_interface_name , mapped_interface_name) [tcp|udp] “mapped_IP” “mapped_port” “real_IP” “real_port” netmask “subnet_mask” For the network topology in our example scenario above, the port redirection commands are the following: ciscoasa(config)# static (DMZ , outside) tcp 100.1.1.1 80 10.0.0.1 80 netmask 255.255.255.255 ciscoasa(config)# static (DMZ , outside) tcp 100.1.1.1 25 10.0.0.2 25 netmask 255.255.255.255 Enjoy 42 Another popular case is to do port redirection using the outside interface. If for example the ASA receives IP address dynamically from the ISP (using DHCP on the outside), then the outside address is not known. So we can configure the ASA so that traffic hitting its outside interface on port 80 to be redirected to DMZ Web Server 10.0.0.1 and also traffic hitting its outside interface on port 25 to be redirected to DMZ Email Server 10.0.0.2. ciscoasa(config)# static (DMZ , outside) tcp interface 80 10.0.0.1 80 netmask 255.255.255.255 ciscoasa(config)# static (DMZ , outside) tcp interface 25 10.0.0.2 25 netmask 255.255.255.255 Now, what if we have two web servers that both listen to port 80? We can configure the firewall to redirect a different public mapped port (e.g. 8080 for example) to our second web server. We can use also the Port Redirection feature to translate a well-known port to a lesser-known port or vice-versa. This will help to increase security. For example you can tell your web users to connect to a lesser-known port 5265 and then translate them to the correct port 80 on the local network. Cisco ASA Version 8.3 and later To configure Port Redirection in version 8.3 and later (using the same diagram above): ciscoasa(config)# object network web_server_static ciscoasa(config-network-object)# host 10.0.0.1 ciscoasa(config-network-object)# nat (DMZ , outside) static 100.1.1.1 service tcp 80 80 ciscoasa(config)# object network email_server_static ciscoasa(config-network-object)# host 10.0.0.2 ciscoasa(config-network-object)# nat (DMZ , outside) static 100.1.1.1 service tcp 25 25 NOTES: The first port number (25 or 80) : This is the Real Port (actual port listening on the server) The second port number (25 or 80) : This is the Mapped Port (port visible from outside) Instead of using a mapped IP (e.g 100.1.1.1) you can use the keyword “interface”. Enjoy 43 2.1.4 Configuring Identity NAT Cisco ASA Versions prior to 8.3 It is worth mentioning another type of NAT mechanism called Identity NAT (or nat 0). If you enabled nat-control on your firewall, it is mandatory that all packets traversing the security appliance must match a translation rule (either nat/global or static nat rules). If we want to have some hosts (or whole networks) to pass through the firewall without translation, then the nat 0 command must be used. This creates a transparent mapping. If Identity NAT is used on an interface, IP addresses on this interface translate to themselves on all lower security interfaces. Assume that our DMZ network is assigned a public IP address range (100.1.1.0/24). This means that the servers located on the DMZ have public IP addresses configured on their Network Interface cards. Therefore, we don’t need to translate the DMZ real IP addresses into mapped global addresses. ciscoasa(config)# nat (DMZ) 0 100.1.1.0 255.255.255.0 Enjoy 44 You still need to have an ACL on the Outside interface in order to allow users from the internet to connect with the DMZ servers. Another way to configure Identity NAT is by using static NAT as shown below: ciscoasa(config)# static (DMZ , outside) 100.1.1.0 100.1.1.0 netmask 255.255.255.0 Cisco ASA Version 8.3 and later To configure Identity NAT in version 8.3 and later: ciscoasa(config)# object network identity_nat_range ciscoasa(config-network-object)# subnet 100.1.1.0 255.255.255.0 ciscoasa(config)# object network dmz_network ciscoasa(config-network-object)# subnet 100.1.1.0 255.255.255.0 ciscoasa(config-network-object)# nat (DMZ , outside) static identity_nat_range Another example with a single host: ciscoasa(config)# object network no_nat ciscoasa(config-network-object)# host 100.1.1.1 ciscoasa(config-network-object)# nat (DMZ , outside) static 100.1.1.1 2.1.4.1 Identity NAT Used for VPN Configurations Cisco ASA Versions prior to 8.3 One important issue to consider is the case of using NAT on the firewall when there is also IPSEC VPN configured. Because IPSEC does not work with NAT, we need to excludethe traffic to be encrypted by IPSEC from the NAT operation. We can use the “nat 0” command for this. Although we will see this technique in more detail later (in the IPSEC VPN Chapter), let’s talk briefly about it here. Enjoy 45 From example diagram above (which we will describe in more detail in a later Chapter), we need to establish a secure IPSEC VPN (Site-to-Site VPN) over the Internet between two internal LAN networks (LAN-1: 192.168.1.0/24 and LAN-2: 192.168.2.0/24). Both LAN1 and LAN2 will also have local Internet access. Therefore we need to configure Dynamic NAT on the ASA firewalls to allow the private LAN networks to access the Internet. However, traffic from LAN-1 to LAN-2 (and vice- versa) which will pass through the VPN tunnel, MUST be excluded from any NAT operation. To achieve the above, we must configure a “nat 0” command using an Access Control List: ASA 1: ASA-1(config)# access-list NONAT extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 ASA-1(config)# nat (inside) 0 access-list NONAT Exclude traffic from LAN1 to LAN2 from NAT operation ASA 2: ASA-2(config)# access-list NONAT extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0 ASA-2(config)# nat (inside) 0 access-list NONAT Exclude traffic from LAN2 to LAN1 from NAT operation Enjoy 46 Cisco ASA Version 8.3 and later To implement the functionality above in ASA version 8.3 and later, we must use the “Twice NAT” method, as shown below: ASA 1: ASA-1(config)# object network obj-local ASA-1(config-network-object)# subnet 192.168.1.0 255.255.255.0 ASA-1(config-network-object)# exit ASA-1(config)# object network obj-remote ASA-1(config-network-object)# subnet 192.168.2.0 255.255.255.0 ASA-1(config-network-object)# exit ASA-1(config)# nat (inside,outside) 1 source static obj-local obj-local destination static obj remote obj-remote ASA 2: ASA-2(config)# object network obj-local ASA-2(config-network-object)# subnet 192.168.2.0 255.255.255.0 ASA-2(config-network-object)# exit ASA-2(config)# object network obj-remote ASA-2(config-network-object)# subnet 192.168.1.0 255.255.255.0 ASA-2(config-network-object)# exit ASA-2(config)# nat (inside,outside) 1 source static obj-local obj-local destination static obj remote obj-remote hapter 3 Using Access Control Lists (ACL) In Chapter 2 we have described the Network Address Translation (NAT) security mechanism, which is one of the two major elements that an administrator needs to configure in order to enable communication through the firewall. The second major element needed to enable traffic flow communication is the Access Control mechanism, also called Access Control List (ACL). 3.1 ACL Overview The Access Control List, as the name implies, is a List of statements (called Access Control Entries) that permit or deny traffic from a source to a destination. After an ACL is configured, it is applied to an interface using the “access-group” command. If no ACL is applied to an interface, outbound access traffic (from inside to outside) is permitted by default, and inbound access traffic (from outside to inside) is denied by default. The ACL can be applied (using the access-group command) both to the “in” and “out” direction of the traffic with respect to the interface. The “in” direction of ACL controls traffic entering an interface, and the “out” direction of ACL controls traffic exiting an interface. In the diagram above, both ACLs shown (for Inbound and for Outbound Access) are applied to the “in” direction of Outside and Inside interfaces respectively. 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: Alwaysuse the Real IP address in the Access List when NAT is configured. Enjoy 48 ACLs are always checked beforetranslation is performed on the security appliance. ACLs, in addition to restricting traffic flow through the firewall, they can be used also as a traffic selection mechanism for applying several other actions to the selected traffic, such as encryption, translation, policing, Quality of Service etc. 3.2 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” “mask” [operator dest_port] 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). source_address mask: Specify the source IP address/network that the traffic originates. If it’s a single IP address, you can use the keyword “host” without a mask. You can also use the keyword “any” to specify any address. [operator source_port]: Specify the source port number of the originating traffic. The “operator” keyword can be “lt” (less than), “gt” (greater than), “eq” (equal), “Neq” (Not equal to), “range” (range of ports). If no source_port is specified, the firewall matches 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. Enjoy 49 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. Example2 ciscoasa(config)# access-list INSIDE_IN extended deny tcp 192.168.1.0 255.255.255.0 200.1.1.0 255.255.255.0 ciscoasa(config)# access-list INSIDE_IN extended deny tcp 192.168.1.0 255.255.255.0 host 210.1.1.1 eq 80 ciscoasa(config)# access-list INSIDE_IN extended permit ip any any ciscoasa(config)# access-group INSIDE_IN in interface inside The above example will deny ALL TCP traffic from our internal network 192.168.1.0/24 towards the external network 200.1.1.0/24. Also, it will deny HTTP traffic (port 80) from our internal network to the external host 210.1.1.1. All other traffic will be permitted from inside. Example3 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 above will allow ANY host on the Internet to access our Web Server host (100.1.1.1). For ASA versions prior to 8.3, the address 100.1.1.1 is the public global translated address of our Web server. Cisco ASA Version 8.3 and Later If the Web Server has a private IP configured on its interface (Real IP address), then for ASA versions 8.3 and later the command will be (assume private IP of Web Server is 192.168.1.1): ciscoasa(config)# access-list OUTSIDE_IN extended permit tcp any host 192.168.1.1 eq 80 ciscoasa(config)# access-group OUTSIDE_IN in interface outside Enjoy 50 3.2.1 Editing Access Control Lists As we have said above, an ACL consists of one or more Access Control Entries (ACEs) which are command lines with permit or deny statements. By default, when you add new ACE lines, these are appended to the end of the ACL. Also, you can delete or insert new ACE lines anywhere in the ACL by using 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. Example: Assume we have an ACL with name “INSIDE-IN”. We can see the line numbers in the ACL as shown below: ASA1# show access-list INSIDE-IN access-list INSIDE-IN; 3 elements; name hash: 0xf1656621 access-list INSIDE-IN line 1 extended deny tcp host 10.1.1.12 any eq www (hitcnt=12) 0x410c3b92 access-list INSIDE-IN line 2 extended deny tcp host 10.1.1.12 any eq https (hitcnt=5) 0xefe6d38a access-list INSIDE-IN line 3 extended permit ip any any (hitcnt=3791) 0xece2599d 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#conf t ASA1(config)# access-list INSIDE-IN line 3 extended deny tcp host 10.1.1.2 any eq smtp ASA1(config)# show access-list INSIDE-IN access-list INSIDE-IN; 4 elements; name hash: 0xf1656621 access-list INSIDE-IN line 1 extended deny tcp host 10.1.1.12 any eq www (hitcnt=12) 0x410c3b92 access-list INSIDE-IN line 2 extended deny tcp host 10.1.1.12 any eq https (hitcnt=5) 0xefe6d38a access-list INSIDE-IN line 3 extended deny tcp host 10.1.1.2 any eq smtp (hitcnt=0) 0xa0087167 access-list INSIDE-IN line 4 extended permit ip any any (hitcnt=3791) 0xece2599d 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 Enjoy 51 3.3 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. 3.3.1 Global Access Control List 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 ACL applied globally with the “access-group global” command applies a single set of global rules on all traffic, no matter which interface the traffic arrives at the security appliance. However, it affects only traffic in the ingress (input) direction (i.e into the interface). Example ! The configuration below will allow all internal hosts to access only the internal SMTP server (192.168.1.10) for sending emails and deny all other SMTP traffic from our internal network. ciscoasa(config)# access-list SMTP extended permit tcp any host 192.168.1.10 eq 25 ciscoasa(config)# access-list SMTP extended permit tcp host 192.168.1.10 any eq 25 ciscoasa(config)# access-list SMTP extended deny tcp any any eq 25 ciscoasa(config)# access-list SMTP extended permit ip any any ! 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) In Cisco ASA Version 9.x there were some changes in Access Control Lists regarding IPv4 and IPv6 traffic. Now, on the sameACL you can have both IPv4 and IPv6 addresses (as source and destination addresses on the ACL). Also, the “any” keyword in an ACL has a different meaning in version 9.x. Now, if you have the “any” keyword in an ACL entry in version 9.x and later, it represents “ALL IPv4 AND IPv6 addresses”. If Enjoy 52 you want to reference “all IPv4 addresses only” in an ACL, then you must use the keyword “any4”. Similarly, if you want to reference “all IPv6 addresses only”, then you must use the keyword “any6”. 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. Example: ! 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 3.4 Controlling Inbound and Outbound Traffic with ACLs A picture is a thousand words. Refer to the picture diagram below for the example scenarios that will follow. These examples will show you how to control Inbound and Outbound Traffic flow: Enjoy 53 Scenario 1: Allow Inbound Access to DMZ Servers For the Web and email Servers above, we have created static NAT mappings in order to translate their real private addresses into public addresses that are accessible from the Internet. In addition to the static NAT statements, we have to use also ACLs to allow the appropriate Inbound traffic towards our servers. Cisco ASA Version Prior to 8.3 ciscoasa(config)# static (DMZ , outside) 100.1.1.1 10.0.0.1 netmask 255.255.255.255 ciscoasa(config)# static (DMZ , outside) 100.1.1.2 10.0.0.2 netmask 255.255.255.255 ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any host 100.1.1.1 eq 80 ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any host 100.1.1.2 eq 25 ciscoasa(config)# access-group OUTSIDE-IN in interface outside ciscoasa(config)# access-list DMZ-IN extended deny ip any any log ciscoasa(config)# access-group DMZ-IN in interface DMZ As you can see from the ACL statements, we allow “any” traffic (i.e all internet traffic) to access the public IP addresses of our Web and email servers on the appropriate ports only (80 and 25). Also, all traffic originating from the DMZ servers is denied and logged using the DMZ-IN ACL. This is a good security practice to follow because if a DMZ server is compromised from outside, the attacker will not be able to access anything else from the DMZ zone. Cisco ASA Version 8.3 and later From Cisco ASA version 8.3 and later, you must specify the Real IP address in the ACL instead of the Mapped public IP address. From example above we have the following configuration: ! First create the static NAT translations ciscoasa(config)# object network web_server_static ciscoasa(config-network-object)# host 10.0.0.1 Real IP of Web Server ciscoasa(config-network-object)# nat (DMZ , outside) static 100.1.1.1 Mapped IP ciscoasa(config)# object network email_server_static ciscoasa(config-network-object)# host 10.0.0.2 Real IP of Email Server ciscoasa(config-network-object)# nat (DMZ , outside) static 100.1.1.2 Mapped IP Enjoy 54 ! Now allow only the absolutely necessary ports (80 and 25) from Internet ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any host 10.0.0.1 eq 80 ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any host 10.0.0.2 eq 25 ciscoasa(config)# 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 As we have mentioned earlier, ACLs, in addition to restricting traffic flow, they can be used also to identify traffic for applying other actions to it. For our diagram above, assume that we want to apply Identity NAT to our Inside network when this communicates with the DMZ. In other words, when hosts in network 192.168.1.0/24 initiate communication to network 10.0.0.0/24, then we don’t want to translate them. To disable NAT translation from a specific high security interface to a lower security interface, we can use the nat 0 command (Only in versions prior to 8.3). An ACL can be used together with the nat 0 command to identify which traffic flow will notbe translated. Cisco ASA Version Prior to 8.3 ciscoasa(config)# access-list NO-NAT extended permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.255.0 Match Traffic from Inside to DMZ ciscoasa(config)# nat (inside) 0 access-list NO-NAT Do not translate traffic matched by this 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). If we want to have bidirectional communication between Inside Network and DMZ, then we must configure Static NAT translation between the two networks. Specifically, we can create a static Identity NATof the Inside LAN (192.168.1.0/24) when communicating with DMZ. This means that source IP addresses of Inside LAN hosts will not be translated when communicating with DMZ Enjoy 55 (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 The above creates a Static Identity NAT of inside LAN (between inside and DMZ zones). The hosts in Inside Zone will not be translated when going to DMZ Zone. Moreover, this configuration will allow access from DMZ to Inside if needed. ! Now allow access from DMZ to Inside as needed. This access is controlled by “dmzin” ACL. ciscoasa(config)# access-list dmzin extended permit tcp host 10.0.0.2 host 192.168.1.3 eq 25 ciscoasa(config)# 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: ! Configure the static Identity NAT ciscoasa(config)# object network inside_identity_nat ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 ciscoasa(config)# object network inside_network ciscoasa(config-network-object)# subnet 192.168.1.0 255.255.255.0 Internal subnet ciscoasa(config-network-object)# nat (inside, DMZ) static inside_identity_nat ! Now allow access from DMZ to Inside as needed. This access is controlled by “dmzin” ACL. ciscoasa(config)# access-list dmzin extended permit tcp host 10.0.0.2 host 192.168.1.3 eq 25 ciscoasa(config)# access-group dmzin in interface DMZ Enjoy 56 Scenario 4: Apply Outbound Restrictions from Inside to DMZ Now, assume that users on the Inside network (192.168.1.0/24) are only allowed to access the email Server at port 25 on the DMZ (to retrieve email) but should not have any access to the rest of the DMZ network. All access however towards the Internet should be allowed. ciscoasa(config)# access-list INSIDE-IN extended permit tcp 192.168.1.0 255.255.255.0 host 10.0.0.2 eq 25 ciscoasa(config)# access-list INSIDE-IN extended deny ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.255.0 ciscoasa(config)# access-list INSIDE-IN extended permit ip 192.168.1.0 255.255.255.0 any ciscoasa(config)# access-group INSIDE-IN in interface inside 3.5 Configuring Object Groups for ACLs Imagine that you are responsible for a huge network with hundreds of hosts protected by a Cisco Firewall. Imagine also that your organization’s security policy dictates that there should be strict access control for all hosts in your network. Creating and maintaining Access Control Lists in such an environment could be a daunting task. Fortunately, Cisco introduced the object-group command which allows the firewall administrator to group together objects such as hosts, networks, ports etc. These object groups can then be used in an access-list command to reference all objects within the group. This helps to reduce multiple lines in the access list and makes ACL administration much easier. Also, any changes in hosts, ports etc are done inside the object-group and are automatically reflected in the access-list. 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. Enjoy 57 We will describe the first two types (Network and Service object groups) since they are the most important and popular types used in ACLs. 3.5.1 Network Object Groups The command format of the Network Object Group is the following: ciscoasa(config)# object-group network “group_name” First Define a name of the object group. This will put you in a subcommand mode (config-network) ciscoasa(config-network)# network-object host “ip_addr” Define a single Host ciscoasa(config-network)# network-object “net_addr netmask” Define a whole subnet ciscoasa(config-network)# exit ciscoasa(config)# Example: Create the Network Object Group: ciscoasa(config)# object-group network WEB_SRV ciscoasa(config-network)# network-object host 10.0.0.1 ciscoasa(config-network)# network-object host 10.0.0.2 ciscoasa(config)# object-group network DMZ_SUBNET ciscoasa(config-network)# 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 In the example above, we created a network object group (WEB_SRV) for our Web Servers (10.0.0.1 and 10.0.0.2). With a single ACL statement, we allowed TCP access from Outside towards this specific object-group for port 80. Notice that the network object-group in the access-list command is used in place of the destination address. It could be used also in place of the source address accordingly. 3.5.2 Service Object Groups The command format of the Service Object Group is the following: ciscoasa(config)# object-group service “group_name” {tcp | udp | tcp-udp} First Define a name of the obj. group and specify what kind of service ports will follow (tcp, udp or both) ciscoasa(config-service)# port-object {eq | range} “port_number” Define service ports ciscoasa(config-service)# exit ciscoasa(config)# Enjoy 58 Example: Create the Service Object Group: ciscoasa(config)# object-group service DMZ_SERVICES tcp ciscoasa(config-service)# port-object eq http ciscoasa(config-service)# port-object eq https ciscoasa(config-service)# port-object range 21 23 ciscoasa(config)# object-group network DMZ_SUBNET ciscoasa(config-network)# 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 above, assume that we have a DMZ network 10.0.0.0/24 hosting servers with tcp services of http, https, ftp (port 21), ssh (port 22) and telnet (port 23). For this scenario we created a DMZ network object group (DMZ_SUBNET) together with a 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. 3.6 Time Based Access Lists Another important feature of ACLs that is very useful is “Time-Based ACLs”. You can append to an ACL command a time-range period which means that this specific ACL entry will be valid only during the specified time-range. First you need to define the “time-range” and then use this time range on an ACL entry. Example1: 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 Enjoy 59 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. Example2: Assume we want to allow web access for a specific DMZ server in order to download security updates every Sunday between 08:00 – 11:00. For all other time the access to Internet will be blocked. 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 hapter 12 Routing Protocol Support Firstly you need to know that the ASA appliance is not a full-functioning router. However, it still has a routing table which is used to select the best path to reach a certain destination network. After all, if a packet successfully passes all firewall rules, it needs to be routed by the firewall to its destination. The Cisco ASA Firewall appliance supports both Static and Dynamic Routing. Three dynamic routing protocols are supported, namely RIP, OSPF, and EIGRP. It is highly recommended to prefer static routing configuration on the ASA firewall, instead of dynamic routing. This is because the usage of dynamic routing protocols might expose your internal network structure to the outside world. If you are not careful with dynamic routing configuration, it is possible to start advertising your internal network subnets to external untrusted networks, thus revealing your hidden networks to the outside world. However, there are situations where dynamic routing configuration is necessary. Such a case would be a large network in which the ASA firewall is located within the internal network campus or data center. In such a case, you will benefit from using a dynamic routing protocol on the ASA since you will not have to configure tons of static routes, and also you will not run into the risk of revealing any hidden subnets to untrusted networks (since the ASA is located deep inside the campus network). The following are some routing protocol best practices for the ASA: For small networks, use only static routes. Use a default static routepointing to the gateway connected to the outside interface (usually Internet), and also use static routes for internal networks which are more than one hop away (i.e not directly connected). Any network that is directlyconnected on an ASA interface DOES NOT need any static route configuration since the ASA firewall already knows how to reach this network. If the ASA is connected on the perimeter of the network (i.e border between trusted and untrusted networks), then configure a default route towards the outside untrusted zone, and then configure specific static routes towards the internal networks. If the ASA is located deep inside a large network campus with many internal network routes, then configure a dynamic routing protocol. Enjoy 188 12.1 Static Routing There are three types of static routes: Directly Connected Route Normal Static Route Default Route Directly Connected Route The Directly Connected Route is automaticallycreated in the ASA routing table when you configure an IP address on an appliance interface. For example, if you configure the IP address 192.168.1.10/24 on the inside interface of ASA, then a Directly Connected Route of 192.168.1.0 255.255.255.0 will be automatically created. Normal Static Route and Default Route For configuring a Normal Static Route and Default Static Route refer to the diagram below. A static route configuration on the ASA is like telling the appliance the following: “To send a packet to the specified network, give it to this router gateway”. Use the route command to enter either a static or default route. The command format is: ASA(config)# route [interface-name] [destination-network] [netmask] [gateway] Enjoy 189 [interface-name]: This is the ASA interface from which the packet will exit. [destination-network] [netmask]: This is the destination network/mask we want to reach [gateway]: Next hop device that ASA will send the packet to. Let’s see an example configuration below (refer to diagram above): ASA(config)# route outside 0.0.0.0 0.0.0.0 100.1.1.1 Default Route ASA(config)# route inside 192.168.2.0 255.255.255.0 192.168.1.1 Static Route. To reach network 192.168.2.0 send the packets to 192.168.1.1 For the default route (usually towards the Internet), you set both the destination-network and netmask to 0.0.0.0. All traffic for which the ASA has no route in its routing table will be sent to 100.1.1.1 (the gateway in the default route). To see what is included in the appliance’s routing table, use the “show route” command: ASA# show route S 0.0.0.0 0.0.0.0 [1/0] via 100.1.1.1, outside Default Static Route C 192.168.1.0 255.255.255.0 is directly connected, inside Connected Route C 100.1.1.0 255.255.255.0 is directly connected, outside Connected Route S 192.168.2.0 255.255.255.0 [1/0] via 192.168.1.1, inside Static Route 12.1.1 IPv6 Static Routing Configuring Default IPv6 Static Route ASA(config)# ipv6 route outside ::/0 3FFE:1100:0:CC00::1 The prefix ::/0 means any IP The above will send any traffic (::/0) that doesn’t match any other route to the default gateway IP which is 3FFE:1100:0:CC00::1 Configuring Static IPv6 Route ASA(config)# ipv6 route inside 7fff::0/32 2FFE:1120:0:CC00::2 The IPv6 network 7fff::0/32 is reachable via gateway 2FFE:1120:0:CC00::2 Enjoy 190 12.1.2 Static Route Tracking - Dual ISP Redundancy When you configure a static route on the security appliance, the route remains permanently in the routing table. The only way for the static route to get removed from the routing table is when the associated ASA interface goes physically down. In all other cases, such as for example when the remote default gateway goes down, the ASA will keep sending packets to its gateway router without knowing that it is actually down. From ASA version 7.2 and later, the Static Route Tracking feature was introduced. The ASA tracks the availability of static routes by sending ICMP echo request packets through the primary static route path and waits for replies. If the primary path is down, a secondary path is used. This feature is useful when you want to implement Dual-ISP redundancy, as we will see in the scenario below. In the network scenario above, interface Eth0/0 (outside) is connected to the Primary ISP and interface Eth0/1 (backup) is connected to the Secondary ISP. Two default static routes will be configured (one for each ISP) which will use the “track” feature. The primary ISP path will be tracked using ICMP echo requests. If an echo reply is not received within a predefined period, the secondary static route will be used. Note however that the scenario above is suitable only for outbound communication(that is, from the inside network towards the Internet). Enjoy 191 12.1.2.1 Configuring Static Route Tracking 1. Use the “sla monitor” command to specify the monitoring protocol (e.g ICMP), the target address to track (e.g ISP gateway router) and the tracking timers. 2. Use the “sla monitor schedule” command to schedule the monitoring process (usually the monitoring process is configured to run “forever” but duration and start times are configurable). 3. Define the primary static route to be tracked using the “route” command with the “track” option. 4. Define the backup static route and set its metric higher than the primary static route. Let’s see an example configuration below (related to the diagram shown above) ! Assume we have configured an interface named “outside” and another interface named “backup” ! Configure Port Address Translation (PAT) for internal network towards the Internet. ASA(config)# object network PAT_PRIMARY ASA(config-network-object)# subnet 192.168.1.0 255.255.255.0 ASA(config-network-object)# nat (inside,outside) dynamic interface ASA(config)# object network PAT_BACKUP ASA(config-network-object)# subnet 192.168.1.0 255.255.255.0 ASA(config-network-object)# nat (inside,backup) dynamic interface ! Now configure Route Tracking using SLA Monitor feature ASA(config)# sla monitor 100 Define SLA_ID 100 ASA(config-sla-monitor)# type echo protocol ipIcmpEcho 100.1.1.1 interface outside ASA(config-sla-monitor)# timeout 3000 Define timeout 3000 milliseconds (3 sec) ASA(config-sla-monitor)# frequency 5 track target 5 times ASA(config-sla-monitor)# exit ASA(config)# sla monitor schedule 100 life forever start-time now Schedule the monitoring process SLA_ID 100 to start now and run forever Enjoy 192 ASA(config)# track 10 rtr 100 reachability Associate a Track_ID 10 with the SLA_ID 100 ASA(config)# route outside 0.0.0.0 0.0.0.0 100.1.1.1 1 track 10 Associate the Track_ID 10 to the primary static route. Define also a metric 1 for this route. ASA(config)# route backup 0.0.0.0 0.0.0.0 200.2.2.2 254 Define the backup static route with a higher route metric of 254 In the scenario above, the firewall appliance will be tracking the primary ISP gateway router (100.1.1.1). If an echo reply is not received within 3 sec (timeout 3000 milliseconds) and the process is repeated 5 times (frequency 5), the primary default route is considered down and therefore the secondary backup route will be used. 12.2 Dynamic Routing using RIP RIP is one of the oldest dynamic routing protocols. Although it is not used a lot in modern networks, you still find it in some cases. Cisco ASA version 7.x supports RIP in a limited fashion. The ASA appliance (v7.x) can only accept RIP routes and optionally advertise a default route. However, it cannot receive RIP advertisements from one neighbor and then advertise these routes to another neighbor. From ASA version 8.x however, the security appliance supports full RIP functionality. Both RIPv1 and RIPv2 are supported. However, using RIPv1 is not recommended because it does not support routing updates authentication. 12.2.1 Configuring RIP Configuration of RIP on the ASA appliance is similar with a Cisco router. RIP is configured using the “router rip” Global Configuration command. RIP authentication security is configured under Interface Configuration. ASA(config)# router rip ASA(config-router)# network [network-subnet] network to advertise via RIP ASA(config-router)# version [1 | 2] select RIP version ASA(config-router)# default-information originate Inject a default route into the network Enjoy 193 ASA(config-router)# passive-interface [ASA interface name] disable RIP updates propagation on specified interface ASA(config-router)# no auto-summarize disable automatic route summarization The “no auto-summarize” command works only for RIPv2. It disables automatic route summarization to their network Class boundary. For example if you have a route 10.1.3.0/24 which you want to advertise via RIP, by default it will be advertised as 10.0.0.0/8 by the ASA. Using the “no auto-summarize” command, the route will be advertised as 10.1.3.0/24. Regarding RIP updates authentication, this is configured on a per Interface basis: ASA(config)# interface [interface number] ASA(config-if)# rip authentication mode [text | md5] I suggest to always use md5 auth. ASA(config-if)# rip authentication key [secret key] key-id [key ID number] Use the same secret authentication key to all neighbor devices running RIP. [secret key] can be up to 16 characters, and [key ID number] is a number between 0-255 The diagram below shows an example network topology with an ASA firewall running RIP within a network with other routers. Assume the ASA is located between the Campus Network and the Data Center Network. All router neighbors behind the inside interface are running RIP. Enjoy 194 Configuration Example: ASA(config)# route outside 0.0.0.0 0.0.0.0 192.168.2.2 ASA(config)# router rip ASA(config-router)# network 192.168.1.0 ASA(config-router)# version 2 ASA(config-router)# default-information originate ASA(config-router)# exit ASA(config)# interface GigabitEthernet0/1 ASA(config-if)# rip authentication mode md5 ASA(config-if)# rip authentication key somesecrethere key-id 10 12.3 Dynamic Routing using OSPF OSPF (Open Shortest Path First) is a dynamic routing protocol based on Link States rather than Distance Vectors (such as RIP) for optimal path selection. It is a much better and more scalable routing protocol compared to RIP, that’s why is widely used in large Enterprise networks. OSPF can be very complex and one can write a whole book for it. In this section I will keep OSPF discussion as brief as possible, and I will try to discuss features and scenarios that are most commonly used in real networks. Notes: 1. OSPFv2 supports IPv4 and OSPFv3 supports IPv6. 2. OPSFv3 supports IPv6 in ASA version 9.x and later. Enjoy 195 12.3.1 Configuring OSPFv2 OSPF is based on Areas. In brief, to configure OSPF you need to create an OSPF routing process (up to two routing processes can be configured on ASA), specify the IP network addresses associated with the routing process, and then assign area IDs associated with each IP network address. Similarly with RIPv2, we can also configure MD5 authentication for OSPF updates security. ASA(config)# router ospf [process ID] enable the ospf routing process ASA(config-router)# network [IP address] [subnet mask] area [area ID] IP network address to advertise via OSPF. This network address must belong in a specific OSPF Area Note that “subnet mask” above must be a normal subnet mask (such as 255.255.255.0) and NOT an inverse (wildcard) subnet mask like we use in Cisco routers (such as 0.0.0.255). To configure OSPF MD5 authentication, you need to enable authentication per Area (within the routing process) and also configure the MD5 authentication key under Interface configuration. ASA(config)# router ospf [process ID] ASA(config-router)# area [area ID] authentication message-digest Enable MD5 authentication in the specific Area ASA(config-router)# exit ASA(config)# interface [interface number] ASA(config-if)# ospf authentication message-digest ASA(config-if)# ospf message-digest-key [key ID] md5 [secret key] We will see two OSPF example scenarios which are commonly used in real implementations. The first example depicts a Cisco ASA within an Enterprise network working as an ABR (Area Border Router), and the second example shows an ASA firewall injecting a default route into the internal network via OSPF. Enjoy 196 Scenario 1: ASA working as OSPF ABR In the example above, the ASA5500 firewall is located between the Data Center and Campus Networks. All routers within the Data Center network are running OSPF in Area 0. On the other hand, all routers in Campus Network are running OSPF in Area 1. The ASA works as Area Border Router. We assume also that there is no NAT configured on the ASA (“no nat-control”). Firewall policies can be enforced using Access-Lists on both the Inside and Outside interfaces. Configuration Example: ASA(config)# router ospf 10 ASA(config-router)# network 192.168.1.0 255.255.255.0 area 0 ASA(config-router)# network 192.168.2.0 255.255.255.0 area 1 ASA(config-router)# area 0 authentication message-digest ASA(config-router)# area 1 authentication message-digest ASA(config-router)# exit ASA(config)# interface GigabitEthernet0/0 ASA(config-if)# ospf authentication message-digest ASA(config-if)# ospf message-digest-key 20 md5 somesecretkey ASA(config-if)# exit ASA(config)# interface GigabitEthernet0/1 ASA(config-if)# ospf authentication message-digest ASA(config-if)# ospf message-digest-key 20 md5 somesecretkey Enjoy 197 Scenario 2: ASA Injecting a default route in OSPF network In the example above, the ASA has a default route towards the Campus Network and injects this default route in the inside network (Data Center). This means that all routers within the Data Center network (which will be running OSPF in Area 0) will acquire a default route which will point to their next-hop closest to the ASA. Configuration Example: ASA(config)# route outside 0.0.0.0 0.0.0.0 192.168.2.2 ASA(config)# router ospf 10 ASA(config-router)# network 192.168.1.0 255.255.255.0 area 0 ASA(config-router)# default-information originate always Inject default route ASA(config-router)# area 0 authentication message-digest ASA(config-router)# exit ASA(config)# interface GigabitEthernet0/1 ASA(config-if)# ospf authentication message-digest ASA(config-if)# ospf message-digest-key 20 md5 somesecretkey ASA(config-if)# exit Enjoy 198 12.3.2 Configuring OSPFv3 (ASA Version 9.x and later) This is a new feature supported on ASA 9.x and later. We will see just the basic configuration which is different than the philosophy used in OPSFv2. Basically you need first to enable an OPSFv3 process and then configure a specific interface to run OSPFv3 (under interface config). As we’ve said before, OSPFv3 is used for distributing IPv6 routing information. ASA(config)# ipv6 router ospf 10 First enable an OSPFv3 routing process (10) ASA(config)# interface GigabitEthernet0/1 Run OPSFv3 under this interface ASA(config-if)# ipv6 ospf 10 area 0 This interface will be running OSPFv3 in Area 0 12.4 Dynamic Routing using EIGRP EIGRP is the enhanced version of the older IGRP. It is a Cisco proprietary protocol which runs only between Cisco devices. Support for EIGRP on Cisco ASA was included from version 8.0 and later. Although EIGRP is very easy to use and flexible, network designers and administrators hesitate to use it widely since it works only with Cisco equipment, so you are effectively dependent on a single vendor. I have not seen this protocol used a lot on Cisco ASA firewalls, so I will keep the discussion just to the basics. (Note: Currently, EIGRP on Cisco ASA does not support IPv6) 12.4.1 Configuring EIGRP EIGRP configuration on a Cisco ASA is very similar with a Cisco router. Basically you just enable the EIGRP process by assigning it an AS number, and then configure the IP network

Chapter 1 Getting Started With Cisco Firewalls.pdf

Document Details

Related

Full Transcript

Upgrade to continue