Chapter 6: Recording ASA Activity

.... update soon .....

-------------------------------------------------------------------------------------------------------------------

Chapter 6: Controlling Access Through the Firewall

Overview

Refer to the following sections for configuration information about these topics:

• 6-1: Routed and Transparent Firewall Modes— Discusses the two modes of firewall operation. Routed mode (the default) operates at Layer 3, while transparent mode operates at Layer 2. This section also covers the steps needed to configure transparent mode.

• 6-2: Address Translation— Presents the underlying Layer 3 address translation methods that occur during traffic inspection. This section covers the configuration steps needed to translate IP addresses from one firewall interface to another. Several different methods of address translation are possible, each of which is covered.

• 6-3: Controlling Access with Access Lists— Provides the steps you can use to configure object groups and access lists to define firewall policies.

• 6-4: Shunning Traffic— Presents a method that can be used to manually stop traffic to and from hosts immediately. This is particularly useful when a host is attacking others and needs to be stopped.

A firewall’s main function is to provide effective security between pairs of its interfaces. To do this, all of the traffic destined to pass through it must undergo a variety of operations, inspections, translations, filters, and special handling. You must configure each aspect of these actions in order to thoroughly enforce the security policies that apply to your network.

All of the features related to controlling user access through the firewall have been collected in this chapter. The size of the chapter is a testament to the broad range of security policy tools available to you, as a firewall administrator.

6-1: Routed and Transparent Firewall Modes

Traditionally, Cisco firewalls have operated by performing Layer 3 (IP address) operations. Naturally, the stateful inspection process can look at higher layers within the IP packets being examined. But the firewall itself has maintained its own interface IP addresses and acted as a router or gateway to the networks that connect to it. As well, all of the traffic inspection and forwarding decisions are based on Layer 3 (IP address) parameters. This is known as the routed firewall mode. Each firewall interface must be connected to a different IP subnet, and be assigned an IP address on that subnet. When a routed firewall is installed or inserted into a network for the first time, the network must become segmented across the firewall’s interfaces. For example, where a single IP subnet used to be, the inside and outside interfaces now form the boundary of two separate subnets.

This can make the installation difficult, as some readdressing must take place. The easiest approach is to keep the original IP addressing on the firewall’s inside interface, where the majority of protected hosts reside. The outside interface can take on an address from a new subnet that is shared between the firewall and the next-hop router. In other words, the outside of the firewall usually has a lesser number of directly connected hosts to readdress to a new subnet.

Routed firewalls can also participate in IP routing by using a dynamic routing protocol such as RIP or OSPF. The firewall can coexist with other routers in the network and maintain a dynamic routing table.

By default, the Adaptive Security Appliance (ASA) and Firewall Services Module (FWSM) platforms are configured for routed mode. You can configure IP addresses on the firewall interfaces, IP routing, and other Layer 3 features by following the guidelines found in Chapter 3, “Building Connectivity.”

Tip

You can see the current firewall mode by using the following command: Firewall# show firewall The result is either “Firewall mode: Router” or “Firewall mode: Transparent”. If you need to configure a firewall back to routed mode, use the following command: Firewall(config)# firewall router

A Cisco firewall can also be configured to operate in transparent firewall mode. The firewall appears to operate as a Layer 2 device, without becoming a router hop or a gateway to the connected networks. This is also known as a Layer 2 firewall or a stealth firewall, because its interfaces have no IP addresses and cannot be detected or manipulated. Only a single management address can be configured on the firewall.

As a Layer 2 device, a transparent mode firewall can be dropped or wedged into an existing network, separating the inside and outside without changing any existing IP addresses. This is commonly called bump-in-the-wire because the firewall does not break or segment the IP subnet along a wire—it more or less becomes part of the wire. This makes a new installation very straightforward.

Tip

Cisco firewalls running PIX release 6.3 or earlier operate solely in the routed firewall mode. Beginning with FWSM 2.2(1) and PIX 7.0, you can configure a firewall to operate in either the routed or transparent firewall mode, but not both.

You can think of a transparent mode firewall as a type of transparent bridge, where packets are bridged from one interface to another based only on their MAC addresses. The firewall maintains a MAC address table from received packets, containing the source MAC address and the source interface. The firewall is able to forward a packet by knowing the location or the egress interface of the destination MAC address.

Figure 6-1 illustrates the transparent firewall process. Host A sends a packet to Host B. Notice that Hosts A and B are located on the same IP subnet. Their local-ip and foreign-ip addresses only designate that “local” is on the inside of the firewall and “foreign” is on the outside. When the firewall builds a conn table entry, the host addresses are shown in this fashion.

Figure 6-1: Transparent Firewall Operation

Tip

In transparent mode, a firewall can support only two interfaces—the inside and the outside. If your firewall supports more than two interfaces from a physical and licensing standpoint, you can assign the inside and outside to two interfaces arbitrarily. As soon as those interfaces are configured, the firewall does not permit a third interface to be configured. Some platforms also support a dedicated management interface, which can be used for all firewall management traffic. However, the management interface cannot be involved in accepting or inspecting user traffic. In multiple context mode, each context also has two interfaces (inside and outside). However, each context must use a pair of interfaces that is different than any other context. In other words, contexts cannot share inside and outside interfaces because of the bridging operation.

When a firewall enters transparent mode, it no longer supports or has a need for address translation. After all, that is a function based on having different IP subnets on different firewall interfaces. In transparent mode, both interfaces must share the same IP subnet. However, IP packets are still inspected without the Layer 2 limitation. Full extended access lists (IP protocol and port numbers) are used to evaluate traffic policies, and the firewall’s application inspection engines are able to interpret IP activity at any layer.

If a transparent firewall acts as a Layer 2 device, is it limited to only IP traffic? From a traffic inspection standpoint, it is; only IP traffic can be inspected and policies enforced. However, from a bridging perspective, the firewall can transparently bridge non-IP packets from one interface to another. This is done by configuring the permitted EtherTypes explicitly in a special interface access list.

A transparent firewall can also maintain an Address Resolution Protocol (ARP) table, where Media Access Control (MAC) and Internet Protocol (IP) addresses are associated as a pair. These are learned from ARP replies that are overheard on an interface. Normally, the ARP table is used only for management traffic to and from the transparent firewall, when the firewall itself needs to send packets to a destination.

You can configure the firewall to support ARP inspection, which can detect and prevent ARP spoofing. ARP requests and replies are forwarded through the firewall by default, as if the two firewall interfaces were bridged. This creates the potential for a malicious host to send spoofed ARP replies with its own MAC address. By doing so, the malicious host can advertise itself as a router’s IP address, causing other hosts to send their traffic to it instead of the router.

ARP inspection uses static ARP entries as the basis for its inspection process. The firewall examines each ARP reply packet it overhears and compares the source IP and MAC addresses, as well as the source interface, to known static entries in its own ARP table. If the ARP reply matches an existing entry, it is allowed to pass through the firewall. If any of its information conflicts with an existing entry, the firewall assumes the ARP reply contains spoofed addresses and drops the packet. If an existing ARP entry cannot be found, the firewall can be configured to transmit or drop the ARP reply packet.

Configuring a Transparent Firewall

Use the following steps to configure a firewall for transparent mode.

1. Enter transparent firewall mode:

   Firewall(config)# firewall transparent
   

   By default, a firewall operates in the routed mode. You can use this command to initiate the transparent firewall mode. Transparent mode begins immediately and does not require a firewall reload.

   Because transparent and routed modes use different approaches to network security, the running configuration is cleared as soon as transparent mode begins. The idea is to enter transparent mode and build an appropriate configuration from scratch.

   For that reason, you should save the routed mode running configuration to Flash memory or to an external server. That way, you have a copy in case you need to revert back to routed mode or you need to refer to some portion of that configuration.

   You can always display the current firewall mode with the show firewall command. As an example, a firewall is configured for transparent mode in the following command sequence:

   Firewall# show firewall
   Firewall mode: Router
   Firewall# configure terminal
   
   Firewall(config)# firewall transparent
   Switched to transparent mode
   Firewall(config)# exit
   Firewall#
   
   Firewall# show firewall
   Firewall mode: Transparent
   Firewall#

2. Configure an interface

   In transparent mode, none of the firewall interfaces can support an IP address. You still have to configure the necessary interface media parameters (speed and duplex), any virtual LAN (VLAN) information, a logical name, and a security level. These parameters are configured in the following steps:

   1. Define a physical interface.

      FWSM	N/A
      ASA	Firewall(config)# interface hardware-id Firewall(config-if)# speed {auto| 10 | 100 | nonegotiate} Firewall(config-if)# duplex {auto| full | half} Firewall(config-if)# [no] shutdown

      Open table as spreadsheet

      The interface is referenced by its hardware-id, such as GigabitEthernet0 or Ethernet0. (The actual name is not case sensitive when you enter it.)

      You can set the interface speed with one of the auto (negotiate the speed; the default), 10 (10 Mbps only), 100 (100 Mbps only), or nonegotiate (fiber optic interfaces only) keywords. The duplex mode can be set using one of the following keywords: auto (autonegotiate; the default), full (full-duplex only), or half (half-duplex only).

      By default, interfaces are administratively shut down with the shutdown command. You can enable an interface by using the no shutdown interface configuration command.

   2. Define a VLAN interface.

      FWSM	Firewall(config)# interface vlan vlan_id
      ASA	Firewall(config)# interface hardware_id[.subinterface] Firewall(config-subif)# vlan vlan_id

      Open table as spreadsheet

      On a FWSM platform, VLAN interfaces are inherent, as it has no physical interfaces at all. Only the VLAN number vlan_id needs to be provided.

      On an ASA, logical VLAN interfaces must be carried over a physical trunk interface, identified as hardware-id (GigabitEthernet0, for example). A subinterface number is added to the physical interface name to create the logical interface. This is an arbitrary number that must be unique for each logical interface. The VLAN number is specified as vlan-id in a separate vlan subinterface configuration command.

      Packets being sent out a logical VLAN interface are tagged with the VLAN number as they enter the physical trunk link. The VLAN number tag is stripped off at the far end of the trunk, and the packets are placed onto the corresponding VLAN. The same process occurs when packets are sent toward the firewall on a VLAN.

      The trunk encapsulation used is always IEEE 802.1Q, and the tagging encapsulation and unencapsulation are automatically handled at each end of the trunk. Make sure the far end switch is configured to trunk unconditionally.

   3. Name the interface and assign a security level.

      FWSM	Firewall(config)# nameif vlan-id if_name securitylevel
      ASA	Firewall(config-if)# nameif if_name Firewall(config-if)# security-level level

      Open table as spreadsheet

      On a FWSM platform, the interface is identified by its vlan-id (vlan5 for example; the word vlan is always present). If multiple security context mode is being used, the vlan-id could be an arbitrary name that has been mapped to the context by the allocate-interface command in the system execution space.

      The interface is given the arbitrary name if_name (1 to 48 characters) that other firewall commands can use to refer to it. For example, you could name an interface as “inside”, “outside”, or something completely different.

      A security level is also assigned to the interface as a level (a number 0 to 100, from lowest to highest). On a FWSM, the level must be given immediately following the security keyword, as in security level. Security levels 0 and 100 are reserved for the “outside” and “inside” interfaces, respectively. Other perimeter interfaces should have levels between 1 and 99.

      As an example, the outside interface could be configured as follows:

      FWSM	Firewall(config)# nameif vlan10 outside security0
      ASA	Firewall(config)# interface gigabitethernet0 Firewall(config-if)# nameif outside Firewall(config-if)# security-level 0

      Open table as spreadsheet

      Tip

      Security levels are only used to determine how the firewall inspects and handles traffic. For example, traffic passing from a higher security interface toward a lower one is assumed to be going toward a less secure area. Therefore, it is forwarded with less stringent policies and traffic coming in toward a higher security area. In addition, firewall interfaces must have different security levels, unless the same-security-traffic permit inter-interface global configuration command has been used.

3. Configure a management address:

   Firewall(config)# ip address ip_address subnet_mask
   

   The firewall can support only a single IP address for management purposes. The address is not bound to an interface, as in routed mode. Rather, it is assigned to the firewall itself, accessible from either of the bridged interfaces.

   The management address is used for all types of firewall management traffic, such as Telnet, SSH, HTTP, SNMP, Syslog, TFTP, FTP, and so on.

   Tip

   A transparent firewall can also support multiple security contexts. In that case, interface IP addresses must be configured from the respective context. The system execution space uses the admin context interfaces and IP addresses for its management traffic.

4. (Optional) Configure routing information for management purposes:

   Firewall(config)# route if_name foreign_network foreign_mask gateway [metric]

   You can configure a static route to allow the firewall to send management traffic to addresses that are not on the local IP subnet. Dynamic routing protocols are not supported in the transparent firewall mode.

   The remote network can be found on the firewall interface named if_name (outside, for example), and has network address foreign_network and subnet mask foreign_mask. The next-hop router address is given as gateway. You can also specify a distance metric, which is the number of router hops until the gateway is reached. If you omit the metric, it defaults to one hop.

   You can repeat this command to define other stable, static routes.

   You do not have to configure a static route for the subnet directly connected to the firewall interfaces. However, you should define one static route as a default route toward the outside public network. For that, use 0 for the foreign_network and foreign_mask values. If you have other IP subnets active on the inside of the firewall, you need to define static routes for each of them.

   As an example, a firewall is located on the network 10.1.0.0 255.255.0.0. Its next-hop router on the outside interface is 10.1.1.1. A router exists at 10.1.1.2 on the inside of the firewall, where subnets 192.168.1.0/24 and 192.168.100.0/24 can be found. The following commands can be used to configure this routing information on a transparent firewall:

   Firewall(config)# route outside 0 0 10.1.1.1 1
   Firewall(config)# route inside 192.168.1.0 255.255.255.0 10.1.1.2 1
   Firewall(config)# route inside 192.168.100.0 255.255.255.0 10.1.1.2 1
   

5. (Optional) Manipulate the MAC address learning process:

   By default, a firewall learns MAC addresses as they are received on any interface. You can use the following commands to display the current MAC address learning state and the current MAC address table entries, respectively:

   Firewall# show mac-learn
   Firewall# show mac-address-table [count] [static] [if_name]

   You can specify a single interface as if_name on an ASA or as interface if_name on a FWSM platform.

   As an example, the following output indicates that MAC address learning is enabled on both firewall interfaces, and the MAC address table has been populated with a few entries:

   Firewall# show mac-learn
   interface                         mac learn
   -------------------------------------------
   outside                          enabled
   inside                           enabled
   Firewall#
   Firewall# show mac-address-table
   interface     mac  address        type       Age(min)
   ------------------------------------------------------------------
   outside       00a0.c900.0201      dynamic    5
   inside        0050.e2c6.f680      dynamic    4
   outside       0008.20f7.fbfc      dynamic    4
   Firewall#

   You can use any of the following steps to modify the MAC address learning process:

   1. (Optional) Set the MAC address table aging time:

      Firewall(config)# mac-address-table aging-time minutes
      

      As new addresses are learned, they are placed in the MAC address table. If no traffic is seen to include a MAC address that is already in the table, that entry is aged out and removed after minutes (5 to 720 minutes, default 5).

   2. (Optional) Define a static MAC address table entry:

      Firewall(config)# mac-address-table static if_name mac_address
      

      You might define a static entry for a MAC address that can never be learned. This might occur if a host or server always listens to traffic using one MAC address and transmits using another. In that case, the transmit address can be learned, while the receiver address cannot.

      After a static entry is configured, the firewall always expects that MAC address to be found on the specified interface. If the same MAC address appears on a different firewall interface, the firewall drops those packets.

      As an example, the following commands configure two static entries in the MAC address table:

      Firewall(config)# mac-address-table static inside 0006.5b02.a841
      Firewall(config)# mac-address-table static outside 0040.9646.6cf6
      

   3. (Optional) Disable MAC address learning on an interface:

      Firewall(config)# mac-learn if_name disable
      

      By default, MAC address learning is enabled on every firewall interface. You can disable it on a firewall interface named if_name (outside, for example) so that only static MAC address table entries are used during a packet forwarding operation.

      This might be handy in a scenario where you want to keep tight control over the MAC addresses that can be learned dynamically. However, static entries would need to be added for each new host, increasing the amount of firewall administration needed.

6. (Optional) Use ARP inspection

   1. Add a static ARP entry:

      Firewall(config)# arp if_name ip_address mac_address
      

      The IP address will be associated with the MAC address (dotted triplet nnnn.nnnn.nnnn format). These are expected to be found on the firewall interface named if_name (outside, for example).

      Static ARP entries never age out. To clear a static ARP entry, repeat the command by beginning with the no keyword.

      Tip

      The arp command syntax also includes an optional alias keyword. In routed firewall mode, this makes the firewall use proxy ARP when it gets an ARP request for that address, rather than forward the request on through to the actual target. In transparent mode, this keyword has no effect. The firewall will not interact with other hosts using Layer 3 mechanisms, so proxy ARP is not possible.

      As an example, the following commands configure static ARP entries in preparation for ARP inspection:

      Firewall(config)# arp inside 192.168.198.199 0006.5b02.a841
      Firewall(config)# arp outside 172.21.4.9 0040.9646.6cf6
      

   2. Enable ARP inspection on an interface:

      Firewall(config)# arp-inspection if_name enable [flood | no-flood]

      By default, ARP inspection is disabled on all firewall interfaces. When enabled, ARP replies received on the interface named if_name (outside for example) are inspected and matched against known static ARP entries. One of the following actions is taken:

      • If the MAC address and the IP address are both found in the ARP table in a single entry, the ARP reply must be valid and is allowed to pass through the firewall.

      • If either the MAC address or the IP address is found in the ARP table, but not both in a single entry, the ARP reply contains invalid or spoofed information. Therefore, it is dropped and not forwarded through the firewall.

      • If neither MAC nor IP address is found in the ARP table, you can select the action as one of: flood (forward or flood the ARP packet out the other firewall interface so it can reach its destination) or no-flood (drop the ARP packet without forwarding it). By default, the flood action is assumed.

   Tip

   ARP inspection is only effective in handling ARP packets that need to traverse the firewall. In other words, the ARP requester and responder are located on different firewall interfaces. If both hosts are located on the same firewall interface, the ARP reply can be answered directly without having to pass through the firewall.

   You can display the ARP inspection status on each interface with the following command:

   Firewall# show arp-inspection
   

   For example, the firewall in the following output has ARP inspection enabled on both interfaces, but only the inside interface is configured to flood unknown ARP replies:

   Firewall# show arp-inspection
   interface                arp-inspection         miss
   ----------------------------------------------------
   outside                  enabled                no-flood
   inside                   enabled                flood
   Firewall#

   Tip

   If you are having trouble getting ARP inspection to work properly, make sure that all of the addresses involved in ARP requests and replies are configured as static ARP entries. If the firewall receives an ARP packet and finds a corresponding entry in its ARP table that was learned dynamically, the ARP packet is dropped. Only static ARP entries are used with ARP inspection. For example, ARP inspection has been enabled on the outside interface of a firewall. The firewall has already learned the MAC and IP addresses for a router on the outside, and has created a dynamic ARP entry for it. When the router sends an ARP reply toward the outside firewall interface, ARP inspection rejects it. The following syslog output is generated when this happens: %ASA-3-322002: ARP inspection check failed for arp response received from host 0008.20f7.fbfc on interface outside. This host is advertising MAC Address 0008.20f7.fbfc for IP Address 192.168.93.129, which is dynamically bound to MAC Address 0008.20f7.fbfc Firewall# show arp outside 192.168.93.129 0008.20f7.fbfc outside 192.168.93.130 0008.20f7.fb00 inside 192.168.93.134 0050.e2c6.f680 Firewall# Although it looks like everything matches up with the outside host’s addresses, the problem is that the ARP entry was dynamically learned and created.

7. Configure interface access lists.

   Before traffic can be forwarded through the firewall, make sure to configure the appropriate security policies by applying an access list to each interface. Access lists are covered in detail in Section 6-3, “Controlling Access with Access Lists.”

8. Configure a forwarding policy for non-IP protocols.

   1. Define an access list:

      FWSM	Firewall(config)# access-list acl_id ethertype {permit | deny} {unicast | multicast | broadcast | ethertype}
      ASA	Firewall(config)# access-list acl_id ethertype {permit | deny} {any | bpdu | ipx | mpls-unicast | mpls-multicast | ethertype}

      Open table as spreadsheet

      By default, only IP packets are allowed to pass through a firewall (providing the packets are permitted by the various inspection processes). You can create an access list that defines a policy on whether non-IP protocols can be forwarded through the firewall.

      This command defines an Access Control Entry (ACE) for the access list named acl_id. You can permit or deny the EtherType that is specified. There is always an implicit deny all ACE at the end of every access list. Therefore, all non-IP EtherTypes are dropped unless they are explicitly permitted in an access list.

      The EtherType value can be one of the following: any (any non-IP packet), bpdu (bridge protocol data units, used for Spanning Tree Protocol operation), ipx (Novell IPX, 0x8137 and 0x8138), mpls-unicast (MPLS unicast, 0x8847), or mpls-multicast (MPLS multicast, 0x8848). You can also specify a numeric ethertype value, which is a 16-bit hex number greater than 0x600.

      Tip

      Well-known EtherType values are assigned and maintained by the IEEE. You can search or download the most current list of values at standards.ieee.org/regauth/ethertype/index.shtml. Many other values are not publicly registered, and are not shown in that listing.

      You can repeat the access-list acl_id ethertype command to add more EtherTypes to be permitted or denied.

   2. Apply the EtherType access list to an interface:

      Firewall(config)# access-group acl_id {in | out} interface if_name
      

      The EtherType access list named acl_id is applied to the firewall interface named if_name (outside, for example). Generally this should be done in the in (inbound) direction, as the EtherType should be evaluated as packets are received, before being inspected.

      You can apply one EtherType access list and one extended IP access list to the same interface.

Tip

A Cisco firewall can inspect only IP packets; no inspection is possible for non-IP EtherTypes. This means you have to explicitly permit those EtherTypes in an access list and apply the list to both the inbound and outbound interfaces in the inbound direction. For example, the following commands configure a firewall to permit IEEE 802.1d Spanning Tree BPDU and Novell IPX traffic, while denying all other non-IP packets. The access list is applied to the inbound direction on both sides of the firewall, allowing bidirectional forwarding. Firewall(config)# access-list MyEthertypes ethertype permit bpdu Firewall(config)# access-list MyEthertypes ethertype permit ipx Firewall(config)# access-group MyEthertypes interface in outside Firewall(config)# access-group MyEthertypes interface in inside