Chapter 25
Understanding FWSM 4.x Routing and Feature Enhancements
Several significant additions to the 4.x code enhance routing and other features. Some of these additions include Enhanced Interior Gateway Routing Protocol (EIGRP) routing, route health injection, and some additional security features and application inspection enhancements.
Configuring EIGRP
EIGRP has been a long-awaited feature for the Firewall Services Module (FWSM). With EIGRP support, the FWSM can be integrated into an existing EIGRP network, minimizing the need to redistribute routing information into other routing protocols. This reduces the complexity of managing multiple routing processes and simplifies the network design, especially within the datacenter.
Redistribution of routes between routing protocols can be difficult because each routing protocol exercises different methods to classify routes (cost). For example, RIP uses hop-count, OSPF uses a metric (single value), and EIGRP uses bandwidth and delay by default. When routing information is exchanged, the methods used to classify them are also lost. Consequently, routing loops can easily occur if you redistribute a route into one process, change the cost, and inject the route back into the first routing process. Use caution if you find yourself in this situation.
EIGRP is supported only in single-context mode and allows only one single EIGRP routing process. Unlike Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), which cannot be enabled simultaneously, EIGRP and RIP or EIGRP and OSPF can be. Where additional security is required, when connecting to the Internet or other untrusted connections, an EIGRP process can be used on the inside and another routing process can be used on the outside.
NOTE | EIGRP is supported only in single-context mode. |
Using Figure 25-1, the following example shows how EIGRP is configured to exchange routing information with the local network and extend the default route learned from the OSPF process exchanged on the outside interface to the local network. In the event the router on the outside stops forwarding the default route to the FWSM, the FWSM will remove the route from the local routing table, consequently removing the default route in the local network.
Figure 25-1 EIGRP and OSPF Route Redistribution
To enhance the security for the routing information exchanged on the outside, OSPF Message Digest 5 (MD5) authentication has also been configured.
Example 25-1 shows the configuration of the FWSM (only the pertinent information is shown).
Example 25-1 EIGRP Route Redistribution
As the output from the show route command shows in Example 25-2, the FWSM has learned about the routes from the local network via EIGRP. These routes are denoted with the letter “D,” and the route from the outside has been learned via OSPF denoted with the letter “O.”
Example 25-2 EIGRP Redistributed Routes
The FWSM is exchanging routing information with the Multilayer Switch Feature Card (MSFC) associated with the inside interface, as the output from the show eigrp neighbors command reveals in Example 25-3.
Example 25-3 EIGRP Neighbors
The OSPF adjacency has been established with the router on the outside interface, as the output from the show ospf neighbor command reveals in Example 25-4.
Example 25-4 OSPF Neighbor
In Example 25-5, the last two lines from the show ospf interface command also indicate that the neighbor adjacency is using MD5.
Example 25-5 OSPF Interfaces
The challenges of complex redistribution scenarios from EIGRP to OSPF or RIP on adjacent routers are now eliminated with the capability of supporting EIGRP natively on the FWSM. Running EIGRP through the FWSM should be reserved for passing routing information internal to the network—for example, within the datacenter. This minimizes the impact of attacks targeting routing protocols.
The addition of EIGPR support makes the integration of the FWSM into networks taking advantage of the EIGRP routing protocol substantially easier, by not requiring the redistribution between routing protocols. When required, you still have the capability to redistribute routing information between routing protocols on the FWSM, but use caution that you do not cause a routing loop.
Configuring Route Health Injection
The FWSM has limited support for dynamic routing protocols when using “multiple-context” mode. Route Health Injection (RHI) has the capability of propagating routing information from individual contexts in routed-mode, including static routes, connected networks, and Network Address Translation (NAT) pools into the routing-engine on the host-chassis.
Because RHI has such a tight integration with the routing-engine, the minimum image needed on the Supervisor 720 and/or Supervisor 32 is 12.2(33)SXI.
RHI creates entries for static and directly connected routes in the MSFC.
Routes can be redistributed to any routing protocol: EIGRP, BGP, and so on.
RHI can also be used to advertise NAT pools into the MSFC.
RHI allows the FWSM to support more than one routing protocol in multi-context mode.
The following example shows how to propagate a default route into the routing-engine from a context on the FWSM.
Example 25-6 shows the configuration on the host-chassis.
Example 25-6 RHI MSFC Configuration
The firewall autostate command sends messages from the host-chassis to the FWSM regarding the state of the VLANs associated with the FWSM. When an interface is configured to be in the same VLAN as the FWSM, and in the event that physical interface transitions to a “down” state, information can be propagated to the FWSM, consequently “downing” the interface associated with the FWSM. When this happens, the RHI will no longer be propagated to the routing-engine on the host-chassis.
Example 25-7 shows the configuration of the context on the FWSM (only pertinent information is shown).
Example 25-7 RHI FWSM Configuration
Under the route-inject subsection, the redistribute command also offers another great feature. You can apply an access list to static routes, NAT pools, and connected networks redistributed to the routing-engine on the host-chassis, consequently providing very granular control over which routes are redistributed.
From the FWSM, using the show route-inject command, you can verify that the route is being propagated to the routing-engine on the host-chassis, as shown in Example 25-8.
Example 25-8 RHI on the FWSM
The host-chassis, using the show ip route command verifies that the route has been received, as shown in Example 25-9.
Example 25-9 RHI on the MSFC
You can see that this route shows up as “static”. Now it can be redistributed into a dynamic routing protocol. In Example 25-10, we are using EIGRP.
Example 25-10 Redistribution of RHI (Static) Routes on the MSFC
Downstream routers will now see that route in their local routing table, as shown in the output from the show ip route command in Example 25-11.
Example 25-11 Downstream RHI Routes
When the FWSM interface goes down, the static route being redistributed into the routing-engine on the host-chassis will be removed.
NOTE | The automatic route removal feature will not be available on the initial release of 4.01 but will be part of the first maintenance release (4.02). |
To really take advantage of the dynamic nature of RHI, only one interface should be assigned to the VLAN. In Example 25-11, interface FastEthernet1/1 is assigned to VLAN 20. In the event FastEthernet1/1 goes down, typically due to an upstream device or interface failure, the associated VLAN interface will also go down. If multiple interfaces have been assigned to the VLAN, all must go down to take down the interface of the FWSM. This completely nullifies the use for any type of dynamic changes.
Figure 25-2 shows a diagram of how RHI can be used.
Figure 25-2 RHI Usage
Although not really dynamic, it will automatically provide notification of the FWSM VLAN interface going down by removing the associated route. Something to be aware of is that it requires a physical failure. In the event the upstream had a Layer 3 problem, for example, the IP address changed, the VLAN interface would remain “up,” but traffic would drop because the next-hop would not be available. One other notable item is that the routes are not Virtual Routing and Forwarding (VRF) aware, meaning that it will not function with MPLS or VRF-lite (at least not using 4.01 code). Propagating routes from the FWSM to the routing-engine on the host-chassis will be placed in the “global” routing table.
NOTE | Removal of routes using RHI requires that the VLAN on the FWSM must be down. |
RHI helps to overcome the limitation that dynamic routing processes are not supported when the FWSM is operating the multi-context mode. Recognize that it requires a Layer 2 failure of the selected interface to retract routing information sent to the MSFC. Although some limitations exist, RHI is an excellent feature to have in your “tool kit.”
Understanding Application Support
The release of FWSM 4.01 code introduces a very powerful feature with regular expressions. Regular expressions allow you to match a variety of parameters using strings or variables that you assign. Also, four additional inspection engines have been added: DCEPRC, ESMTP, HTTP, and SIP.
NOTE | For more information on DCEPRC, ESMTP, HTTP, and SIP, read on! The topics are covered later in this chapter. |
Configuring Regular Expressions
If you have had an opportunity to work with Border Gateway Protocol (BGP), you may have been introduced to regular expressions. Regular expressions provide a way to match a group of characters using either an exact string match or by meta-characters that allow you to define a range, a character set, and so on. This feature can be used to match URL strings when inspecting HTTP traffic and perform an action based on a match, or perform an action on the traffic that does not match the regular expression.
The following configuration example shows how to implement regular expression matching. A client on the inside is connecting to a server on the outside. In this example, you will be inspecting the content for the permutation of the keyword “flash.” If the keyword is found, the connection will be reset.
Step 1 | The first step requires that you create a regular expression to match the specific content. Ensure that the regular expression command matches on the keywords of Flash, FLaSh, flASH, and so on: |
| regex URL_NOFLASH "[Ff][Ll][Aa][Ss][Hh]" |
Step 2 | Create and set a regular expression (regex) class map to match the regular expression (URL_NOFLASH): |
| class-map type regex match-any RESTRICTED_URL |
Step 3 | Add an inspection class map to match the previously created class map (RESTRICTED_URL): |
| class-map type inspect http match-all RESTRICTED_HTTP |
Step 4 | Add a policy map to search through the body of the HTTP string. The numeric value of 48 specifies how many characters to search through. The maximum length of the string can be from 1 to 4,294,967,295 characters. Longer search strings will impact the performance of the FWSM. When a match is found, using the class map RESTRICTED_HTTP, the action assigned is to reset and log the connection: |
| policy-map type inspect http HTTP_PMAP |
CAUTION | Longer search strings will impact the performance of the FWSM. |
Step 5 | Create and use a final policy map to match the policy map (HTTP_PMAP): |
| policy-map INSIDE_POLICY |
Step 6 | Apply the service policy to the interface: |
When a match is found, the following log message is generated: | |
| %FWSM-5-415006: HTTP - matched Class 23: RESTRICTED_HTTP in policy-map |
Figure 25-3 shows a screenshot of what the client’s experience would be with the service policy.
Figure 25-3 Regular Expression With the Service Policy
Figure 25-4 shows a screenshot of what the client’s experience would be without the service policy.
Figure 25-4 Regular Expression With the Service Policy
Notice now that the graphic has been removed from the display.
There is also a simple tool that you can use to test a regular expression from the command line. Use the following test command:
FWSM# test regex http://www.cIsCo123.com [Cc][Ii][Ss][Cc][Oo][0-9]
INFO: Regular expression match succeeded.
The first argument is the string, and the second argument is the match criteria. Notice that both upper and lowercase characters will match the string “cIsCo” but must be followed by a numeric value.
In the next example, the hyphen does not match a numeric value, consequently the match fails.
FWSM# test regex http://www.cIsCo-123.com [Cc][Ii][Ss][Cc][Oo][0-9]
INFO: Regular expression match failed.
Regular expressions are a very helpful tool that could be used to match on viruses, worms, questionable material, and so on. A maximum of 100 characters can be used in the regular expression; remember that implementing regular expressions will impact the performance of the FWSM.
Inspecting content within a packet and matching against a user defined regular expression is a very powerful feature. Because additional CPU cycles are required when you employ this feature, use caution that you do not overwhelm the processor on the FWSM. As an alternative to the FWSM for high-performance regular expression matching, consider using an Intrusion Prevention System (IPS).
Understanding Application Inspection Improvements
One of the primary functions of the FWSM is to provide application inspection, looking for protocol conformance, changing imbedded IP addressing, and so on. Increasing the capabilities of this feature only adds benefit to the services you are offering to your customers.
Domain Name Service (DNS) guard is a feature used when a client requests DNS information through the FWSM to a DNS server or servers. The default behavior of the FWSM is to allow only a single reply and drop any additional responses, consequently helping to prevent against DNS poisoning attacks. Although not recommended because of the possibility of exploiting the host, the FWSM can be configured to allow all responses using the following command:
FWSM/Context-A(config)# no dns-guard
As you may have noticed from the preceding command syntax, this command also works in multi-context mode.
Policy maps are covered in detail in Chapter 11, “Modular Policy,” but the introduction of 4.01 includes additional support/enhancements for inspection policy and/or class maps for the following applications:
• Distributed Computing Environment Remote Procedure Call (DCEPRC): A protocol used across multiple computers to distribute the load. Policy map inspection is the new addition to 4.01.
• Extended Simple Mail Transfer Protocol (ESMTP): Added extensions to SMTP. The 4.01 code added the capability for application support and the capability to define inspection policy maps that match traffic using regular expressions.
• HTTP: A protocol used generally to transfer information across the Internet.
• Session Initiation Protocol (SIP): A signaling protocol used for voice communications over IP.
The following options are available using policy maps with the previously listed protocols, as follows:
— drop: Drops all packets that match the defined pattern.
— drop-connection: Drops the packet and closes the connection.
— log: Sends a syslog message.
— mask: Masks that portion of the packet that has been matched.
— rate-limit: Limits the rate of received messages.
— reset: Drops the packet; closes and resets the connection.
— send-protocol-error: Sends an error message when the packet does not match the ESMTP protocol.
The capability added with policy maps for DCEPRC, ESMTP, HTTP, and SIP adds tremendous functionality for the inspection of these protocols. With the option to drop, drop-connection, log, mask, rate-limit, reset, and send-protocol-error, for many of these protocols, the functionality also significantly improves.
Additional Support for Simple Network Management Protocol Management Information Base
Simple Network Management Protocol (SNMP) is used to get specific information from a device or to send it information for the purposes of configuration changes. Because the FWSM is a security device, you cannot send it information, but you can gather information for keeping track of interface statistics, packet counts, and so on. There have been two additions to the Management Information Base (MIB):
• ACL entries and hit counters located under CISCO-IP-PROTOCOL-FILTER-MIB
• Address Resolution Protocol (ARP) table entries located under IP-MIB
Table 25-1 shows the MIB additions with definitions.
Table 25-1 FWSM 4.01 MIB Additions
When using SNMP, avoid using ansnmp walk. This process will start at the top of the MIB tree and get the statistics for each MIB, until it gets to the end of the tree. Because SNMP is not performed in hardware, this will put an undue burden on the FWSM.
NOTE | Gathering SNMP information from the FWSM will increase the load. Get only specific information when necessary. |
SNMP is a very valuable tool to gather statistics from the FWSM, and with the addition of ACL entries, ACL counters, and ARP table entries, it becomes an even better tool. Just remember not to overwhelm the FWSM with too many queries.
Miscellaneous Security Features
DHCP option 82 is typically used in service-provider networks. It adds location information that can be used to differentiate services between customers. A filtering enhancement was also added to support HTTPS with SmartFilter.
Dynamic Host Configuration Protocol Option 82
Option 82 provides location information from the Dynamic Host Configuration Protocol (DHCP) relay agent–in this case, the FWSM to the DHCP server. This information can be used to differentiate DHCP clients, consequently offering distinctive services on a client basis.
You can use two commands to enable DHCP relay. The first command specifies the DHCP server IP address and the interface where it is located. Optionally, the dhcprelay server ip_address command can be configured under the outgoing interface. The second line enables clients on the inside interface to send and receive DHCP information.
FWSM/Context-A(config)# dhcprelay server 10.20.100.25 Outside
FWSM/Context-A(config)# dhcprelay enable Inside
Option 82 can then be enabled on a specific interface, as shown by the following two commands:
FWSM/Context-A(config)# interface vlan vlan-number
FWSM/Context-A(config-if)# dhcprelay information trusted
Option 82 can also be enabled on all interfaces using the global command that follows:
FWSM/Context-A(config)# dhcprelay information trust-all
If you are currently using the FWSM as a DHCP relay agent, the addition of option 82 will be a simple addition. Also, when enabling option 82 globally, all interfaces are trusted except the interface that is configured as the dhcprelay (outgoing) interface.
DHCP option 82 adds location information to clients, which can be used to differentiate services. Although used primarily in service provider networks, it could all be used in enterprise networks to differentiate client services.
Smartfilter HTTPS Support
For those of you looking for HTTPS support from SmartFilter on the FWSM, it has now arrived with the introduction of 4.01. See Chapter 14, “Filtering,” for configuration details.
Summary
The release of 4.x adds some very significant enhancements. The addition of EIGRP now provides the capability to integrate a FWSM into an EIGRP network without having to redistribute routes into other routing protocols. RHI allows static routes, NAT pools, and connected routes to be propagated to the routing engine on the host-chassis dynamically. Regular expressions give you the opportunity to match traffic based on custom signatures. Application inspection improvements and SNMP additions, option 82 support, and filter enhancements, make the FWSM an even better option to secure your valuable assets.
References
RFC 1869–SMTP Service Extensions
RFC 2011–SNMPv2 Management Information Base for the Internet Protocol Using SMIv2
RFC 3046–DHCP Relay Agent Information Option 82