Overview of the Firewall Services Module

Although the FWSM has tremendous capabilities, recognize the limitations and avoid getting into a situation where the FWSM has been oversubscribed. For more information on ACL and ACE improvements using the 4.x code train, refer to Chapter 24, "FWSM 4.x Performance and Scalability Improvements."

Virtualization

Virtualization or multiple-context mode allows the FWSM to be logically separated into multiple unique firewall instances as shown in Figure 2-1. These individual instances or contexts have a unique set of policies, IP addressing, static routes, and configurations. Because each context is unique, using the same IP addresses is allowed. This provides tremendous flexibility when adding new services or customers that may need to be separated from other contexts because of a security policy or for management reasons.

Using virtualization, you can consolidate multiple firewall appliances into a single line-card on the host chassis. Considering that the FWSM supports up to 250 contexts, how much rack space, power, and cooling will that eliminate?

Many organizations are employing virtualization techniques, such as Multiprotocol Label Switching-Virtual Private Network (MPLS-VPN), Virtual Routing and Forwarding (VRF)-lite, and generic routing encapsulation (GRE), to logically separate applications, services, job functions, to provide a public transport, and so on. This gives them the advantage of not having to create a new physical infrastructure or manage complex access lists every time a function needs to be isolated from the others.

Virtualization techniques are not only being deployed in the campus and wide-area network (WAN), but also within the datacenter to logically isolate applications and services. Using the FWSM in this scenario is particularly advantageous because of the amount of space and power it saves.

Figure 2-1 Virtualization (Multiple-Context Mode)

FWSM

Context A: In Routed Mode

Context A: In Routed Mode

Context B: In Transparent Mode

Comparing the FWSM to Other Security Devices

You should consider several factors when choosing the appropriate device to provide firewall functionality. These factors include the applications and security policies that need to be supported, device capabilities, future feature requirements, longevity of the product, cost, reuse, familiarity with the equipment, operational integration, training, and so on. Addressing the technical aspect is as follows—you are on your own for the rest!

The FWSM, Internetwork Operating System Firewall (IOS FW), Private Internet Exchange (PIX), and Adaptive Security Appliance (ASA) all provide similar capabilities in the support of stateful application and protocol inspection, Network Address Translation (NAT) and Port Address Translation (PAT), routing, content filtering, and user authentication and authorization. The FWSM does not support Virtual Private Network (VPN) termination except for use in management, whereas the PIX, ASA, and IOS-based devices all have that capability.

Obviously, creating a feature list that is completely inclusive is beyond the scope of this book. The objective is to provide a general guideline for selecting the appropriate platform to match the solution.

Choosing the appropriate security device requires that you not only have a good understanding of the scope of the project but of the capabilities of the hardware, too. Keeping up to date on the technologies will definitely help you be successful.

IOS FW

Routers starting with the 800 series through the 7600 (SX code) and including the 7200 and 7300 series and the 6500 series switch support IOS FW.

NOTE Be sure to check the appropriate documentation for the specific hardware and software you plan to deploy.

IOS FW is usually deployed on branch office routers by customers that are looking for a one-box solution. IOS provides many other capabilities, such as voice gateways, GRE, Internet Protocol Security (IPsec), Advanced Encryption Standard (AES), Secure Sockets Layer (SSL), Virtual Private Network (VPN), Multiprotocol Label Switching (MPLS), extensive routing protocol support, and so on. By combining these additional features, routers running IOS FW provide incredible flexibility and the option to quickly add new services as business requirements change.

IOS FW is a general-purpose firewall and not as robust as the purpose-built FWSM; therefore, it cannot match the performance capabilities and features like stateful failover.

In addition to the firewall feature set, IOS provides incredible flexibility and should be kept in your arsenal to defend your network.

The origin of the FWSM is the PIX, which finds its roots in the Finesse operating system. Many similarities exist between the FWSM, PIX, and ASA, including inspection engines, configuration of access lists, privileged levels, interface security levels, and so on. The most significant differentiator besides the form factor is that the FWSM does not support VPN (IPsec, AES, and SSL) termination.

If you are considering a PIX today, a better solution would be the next-generation appliance, the ASA.

In addition to the capabilities of the PIX, the ASA also has the capacity of supporting the Advanced Inspection and Prevention Security Services Module (AIP-SSM). This is an inline Intrusion Protection System (IPS) used to detect and drop malicious traffic. The Content Security and Control Security Services Module (CSC-SSM) is the other module supported in the ASA. It provides antivirus, antispyware, antispam, antiphishing, and file and URL blocking, as well as URL and content filtering.

Placement of the ASA is generally at the network edge in small, medium, and large network deployments. With its integrated capabilities, it makes an excellent security device for protecting services such as e-mail servers, web servers, user traffic, and so on.

With the integration of the FWSM in the 6500 or 7600, locating these device within the datacenter or protecting resources internal to the network is very common.

Taking a holistic approach to firewall security and leveraging the capabilities of the IOS FW, PIX, ASA, and FWSM provide a defense-in-depth security strategy. A complete defense-in-depth strategy is beyond the scope of this book. For additional information on the Security Architecture for Enterprise (SAFE) documentation, go to http:// www.cisco.com/go/safe.

Hardware Architecture

The architecture of the FWSM consists of four major components: Network Processors (NP) 1A (NP1A) and 1B (NP1B), Network Processor 2 (NP2), and the Processor running the FWSM code (FWSM-complex).

The FWSM is connected to the backplane of the 6500 or 7600 through a full-duplex 6-gigabit EtherChannel (GEC), totaling 12 gigabits of bandwidth using marketing math. A 3 Gb connection is established to NP1A and also to NP1B from the backplane.

One item of consideration is the use of GEC to load-share traffic. The GEC load-sharing algorithm by default for non-IP traffic is an exclusive-OR (XOR) of the source and destination Media Access Control (MAC) addresses, and for IP traffic it is an XOR of the source and destination IP addresses. This will cause the traffic flow from a single source to a single destination to use only one of the gigabit connections. If you are testing performance numbers, recognize that you will need multiple source/destination pairs for traffic to load-share across the GEC.

To determine how the EtherChannel is configured, use the show etherchannel load-balance module command as shown in Example 2-1.

Example 2-1 Determining EtherChannel Configuration

6500# show etherchannel load-balance module module-number EtherChannel Load-Balancing Configuration: src-dst-ip mpls label-ip

EtherChannel Load-Balancing Addresses Used Per-Protocol: Non-IP: Source XOR Destination MAC address IPv4: Source XOR Destination IP address IPv6: Source XOR Destination IP address MPLS: Label or IP

NP1A and NP1B can handle 3 million packets per second and perform Layer 2 checking by verifying that the destination of the frame is either the MAC address of the FWSM or a broadcast/multicast address. They also verify whether the destination IP address of the packet is associated with the FWSM.

Routing protocol packets and any non-Transmission Control Protocol (TCP)/User Datagram Protocol (UDP)/ICMP traffic will be sent to the FWSM-complex. A session lookup is done on TCP/UDP/ICMP traffic, and if session information is not available, one of four of the following will occur:

• If the packet is not a TCP Synchronize Sequence Number (SYN) (the first packet in the TCP 3-way handshake), it will be dropped.

• If the packet is UDP or TCP SYN, send it to NP2.

If the packet is ICMP, verify against ACL or permit ICMP statement.

• If the packet is routing information, send it to FWSM-complex.

• If the packet is a fragment, send it to the virtual reassembly process on NP1A/B.

• Control messages are also sent to NP2.

If the session information is available, take the following action:

• If the packet requires "protocol-inspection," send it to the FWSM-complex.

• If the packet is network management associated with the FWSM, send it to NP2.

• If the packet is a fragment, send it to the virtual reassembly process on NP1A/B.

• Perform a packet rewrite and if necessary, modify TCP information and checksum (TCP protocol-inspection), execute NAT/PAT rewrite, add Layer 2 information, and send it to the host-chassis. Any traffic that follows this flow is said to be in the "fast or accelerated path."

NP2 can sustain 100K new connections per second. It also matches against ACL entries, performs route lookup, maintains the AAA cache, TCP intercept, Reverse Path Forwarding (RPF) checks, and translation address pool allocation. Traffic that follows this flow is in the "session management path."

Packets received from NP1A/B that can be processed on the NP2 will be returned to NP1A/ B. Packet forwarding is based on the following criteria:

• If the packet is part of an existing session, TCP intercept, AAA updates, and so on are performed.

• If the packet has no session (TCP SYN, UDP, ICMP echo request), ACL checking, Destination Network Address Translation (DNAT), RPF check, route lookup to determine destination interface security level, and address pool allocation are performed. If it passes the previous checks, connection state information is built on NP1A/B (fast path) and if not, the packet is dropped.

• If the packet is destined for the FWSM-complex, a congestion control check is done to verify that the load of the FWSM-complex is able to handle the additional information, and if appropriate it's forwarded; otherwise, the packet is dropped.

The FWSM-complex performs Layer 7 protocol inspection, maintains routing information and neighbor adjacencies, and handles failover and the management interface. Because this is the software component of the FWSM, performance is dependent on the configuration and traffic patterns. Any processing done in the FWSM complex is in the "control plane or slow path."

NOTE Traffic processed on NP1A or NP1B is considered "fast path." Traffic processed on NP2 is considered the session management path," and traffic processed on the FWSM-complex is "slow path."

Figure 2-2 shows a block diagram of the FWSM hardware. NP1A and NP1B are connected to the backplane of the 6500 via a 6-gigabit EtherChannel. They have connections to NP2 and the shared bus for all the processors. NP2 and the FWSM complex share a local bus.

Figure 2-2 FWSM Hardware Architecture

Figure 2-2 FWSM Hardware Architecture

From a hardware perspective, the FWSM is a fairly complex animal. Understanding the packet flow through the FWSM and where each function is applied will give you a better understanding on where to place the FWSM in your network and help you to troubleshoot problems much faster.

Software Architecture

The other component to any computer-based system is the software. No matter how sophisticated your hardware may be, if it does not have an operating system, it is probably good only as a heater or paperweight.

Fortunately, the FWSM has lots of features that you can take advantage of and many "nerd knobs" that you can tweak. Understanding how the software handles traffic is fundamental, and you should spend a considerable amount of time in the next section to become very familiar with the software characteristics.

Input packets are first checked for fragmentation and, if required, will be reassembled before delivering to the "Mgmt/Routing" decision process. This process determines if the packet is routing information or is a management packet, such as telnet, SSH, or Hypertext Transfer Protocol Secure (HTTPS). If the packet matches this criterion and passes the interface ACL, it is sent to the session management process and handled accordingly.

If not, the third decision process (TCP/UDP/ICMP) separates non-TCP/UDP/ICMP packets from those requiring Destination Network Address Translation (DNAT), RPF check, and address pool allocation. An ACL check is also performed to validate the packet.

If the packet is part of an existing session, it is directed to the NAT process and sent out; otherwise, an ACL check is performed and if necessary the protocol-inspection process. The protocol-inspection process, previously known as the "fixup" protocol, inspects and modifies packets that require special attention, such as the following:

• Computer Telephony Integration Quick Buffer Encoding (CTIQBE): CTIQBE is a Cisco proprietary VoIP protocol used for Telephony Application Programming Interface (TAPI) and Java Telephony Application Programming Interface (JTAPI) to communicate with Call Manager.

• Domain Name System (DNS): DNS is used to convert a hostname or domain name into an IP address.

• File Transfer Protocol (FTP): FTP is a communication protocol used for exchanging files between computers.

• General Packet Radio Service (GPRS) Tunneling Protocol (GTP): This is used to carry signaling and user traffic between nodes.

• H.323: H.323 is the International Telecommunications Union (ITU) recommended method for multimedia communication.

• Hypertext Transfer Protocol (HTTP): HTTP is a protocol used for the transfer of information.

• Internet Control Message Protocol (ICMP): ICMP is used to exchange control, error, and information messages.

• Internet Locator Service (ILS): ILS is used to support Microsoft NetMeeting clients.

• Media Gateway Control Protocol (MGCP): MGCP is used for signaling and control in VoIP applications.

• Network Basic Input/Output System (NetBIOS): NetBIOS is a mechanism used for computers to communicate within the same Layer 2 network.

• Point-to-Point Tunneling Protocol (PPTP): PPTP is a tunneling protocol used to extend Point-to-Point (PPP) sessions across an IP network.

• Remote Shell (RSH): RSH is a UNIX command used to remotely execute commands.

• Real-Time Streaming Protocol (RTSP): RTSP is used to control data delivery of real-time traffic.

• Session Initiation Protocol (SIP): SIP is a signaling protocol used for multimedia sessions.

• Skinny Call Control Protocol (SCCP): SCCP is a Cisco proprietary protocol used for communication in VoIP applications.

• Simple Mail Transfer Protocol (SMTP)/ Extended Simple Mail Transfer Protocol (ESMTP): These two protocols are used for the sending and receiving of e-mail messages.

• Simple Network Management Protocol (SNMP): SNMP is a protocol used to manage and monitor network devices.

• Structured Query Language SQL*Net/Net8: These are used in client/server applications for database access.

• Sun's Remote Procedure Call (SunRPC): SunRPC is a function that allows a procedure to be run on another computer; it was developed by Sun Microsystems.

• Trivial File Transfer Protocol (TFTP): TFTP is a mechanism to transfer information.

• X Display Manager Control Protocol (XDMCP): XDMCP is used to set up X sessions with remote systems.

These applications either have embedded IP addresses in the data portion of the packet, open secondary channels, or require additional inspection of the data portion of the packet. Unless the firewall is aware of these "special applications," they may not work properly or may allow unnecessary access to applications.

As you might have noticed from the flow, packets that are part of an existing session are not checked by an ACL. What this means from an implementation perspective is that if you allow traffic to pass from one interface to another, it will be initially checked by an ACL, but the return traffic now part of a session will not be checked. Remember this aspect when allowing access to services or applications.

You can place these services on a specific interface and create a static entry that allows traffic from a lower interface (in regard to the security level, see Chapter 4, "Understanding Security Levels," for details) to a higher interface (in regard to the security level, which is where the services are located) without creating any ACL on the higher-level interface. Traffic will return because of the established session. Recognize also that traffic will not be allowed to initiate from the higher-level interface without an ACL. This function enhances the security of those devices by minimizing any carbon-based (human) configuration errors and not allowing someone with access to one of these devices to establish outbound connections for illegitimate purposes.

Figure 2-3 shows an overview of the decision process, which should help you understand the flow.

An ACL is still required when going from a higher-level interface to a lower-level interface. The point is that traffic matches an existing session first.

With an understanding of how, through which components, and in what order traffic passes through the FWSM, you will substantially increase your success in design, implementation, and troubleshooting.

Summary

The FWSM is a firewall line-card hosted in a 6500 series switch or 7600 series router chassis. It uses a 6-gigabit EtherChannel to connect to the host-chassis backplane, eliminating the need for any external connections. You can leverage your investment in hardware by virtualizing up to 250 firewall instances, reducing the number of appliances, saving rack space, and minimizing heating and cooling. Understanding the hardware and software capabilities is paramount to a successful implementation.

This page intentionally left blank

Chapter

Continue reading here: Understanding Security Levels

Was this article helpful?