CISCO FIREWALLS

One of the most powerful tools in the arsenal of a network administrator that helps in protecting the IT infrastructure is a firewall. Firewalling technology was developed at the early stages of the modern Internet, when the increasing need for security was realized. The first firewalls analyzed bypassing traffic and made their decisions based on the source and destination addresses specified in the data packets. Since then, the happy times of tricking dumb firewalls with IP spoofing have passed, and, a step behind the attackers , the firewalls have developed into three distinct types, as we can categorize them today:

• Packet-filtering firewalls

• Stateful packet-filtering firewalls

• Proxy-filtering firewalls and application-level gateways

Packet-Filtering Firewalls

A packet-filtering firewall analyzes the network traffic at the transport layer, matching packet headers against a predetermined set of rules. In the Cisco world, packet-filtering firewalls are represented by simple and extended IOS Access Control Lists (ACLs).

While the standard Cisco ACLs are source or destination IP-based, the extended ACLs examine the following packet header fields:

• Source IP address

• Destination IP address

• Network protocol used

• Transmission Control Protocol/ User Datagram Protocol (TCP/UDP) source port or Internet Control Message Protocol (ICMP) message type

• TCP/UDP destination port or ICMP message type

In addition, basic TCP flag examination can be done using the "established" ACL option, which restricts TCP traffic in one direction by letting the packets through only if ACK or RST flags are set. Thus, SYN packets would be dropped and initiation of TCP connections from the outside becomes impossible . The established option in extended Cisco ACLs should not be confused with stateful packet filtering; in addition, an attacker with a clue can easily bypass the protection offered by this option by spoofing TCP flags. However, a proper stateful firewall will not fall to such an attack.

The most common action Cisco ACLs can perform is either to accept, deny, or forward the packet. If needed, the action taken can be logged locally or remotely. Dynamic Cisco ACLs allow additional ACL entries to be logged once a user is authenticated to the router, thus allowing user rather than IP and port-based filtering. The authentication can be done against a local username/password credentials database or employing RADIUS or Terminal Access Controller Access Control System (TACACS+) server. While this may sound like a great and flexible feature, take care that the user authentication is done via a secure protocol such as SSHv2. As a rule of a thumb, router Telnet access from any outside hosts must be strictly prohibited .

Another enhancement available for standard and extended Cisco ACLs is time-based ACLs. Time-based ACLs are supported on all Cisco IOS platforms and permit changes to the network access based upon the time of day, day of week, or both. For example, a bunch of time-based ACLs can be written to block common instant messenger ports during workday hours, so that users are able to chat only after or before work and during weekends.

The downsides of using a simple ACL-based packet-filtering firewall are listed here:

• Unauthorized packets can get through the ACL under certain conditions.

• Fragmented packets may also pass through the firewall under certain conditions.

• It is difficult to manage large sets of ACLs on multiple routers.

• The support for dynamic/multiport protocols such as H.323 or active FTP is poor.

All IOS versions for both Cisco routers and Route Switch Modules (RSMs) for the Catalyst switches support packet filtering, and this support can be very helpful in some cases. An important example of such a case is restricting the administrative access to the router or switch to a defined set of internal IP addresses. Nevertheless, we strongly suggest using reflexive access lists and upgrading your IOS to the CBAC-supporting versions where possible.

Stateful Packet-Filtering Firewalls

The firewall with stateful packet-inspection ability creates a table with state information about every established connection. Such table usually includes information on the following:

• Source and destination IP address

• Network protocol

• TCP/UDP source and destination port

• TCP sequencing information

• Extra flags for TCP/UDP connections

As soon as an established connection is successfully initiated through the firewall, a corresponding object is created. Therefore, all following packets are compared against the object values stored in the state table, and if the firewall sees the packet as a match, the packet is viewed as a part of an existing connection. On the other hand, if the packet is not found to be a part of an existing connection, the firewall passes it for further inspection against set ACLs and behaves as a standard packet filter.

The cons of stateful packet filtering include the following:

• Slower performance as compared to simple packet filters

• Increased requirements to the router processing power and memory

• Poor support for dynamic/multiport protocols unless the layers above the transport layer are also analyzed

All Cisco PIX firewalls support stateful packet inspection, while employing proxy services to handle dynamic protocols. CBAC-supporting code trains that have o or o3 identifiers are also state-aware and capable of higher layer analysis for passing through dynamic protocol traffic. Reflexive access lists supported by all IOS versions do provide stateful firewalling; however, the mechanisms for dynamic protocols filtering are completely absent, and you will have to bypass this problem laterally (for example, by using passive FTP only). This may force you to use simple packet filtering instead of the reflexive lists or upgrade your IOS to include CBAC support. As we already mentioned, the latter option is preferable.

Proxy Filters

Proxy-filter firewalls examine packets further at the application layer. Apparently, such a firewall acts as an ultimate bastion host: a connection is first established from the client to the firewalling device, and then the device itself establishes another connection to the final destination. Often, the user is required to authenticate to the firewall first, and a different set of ACLs is applied on a per-user or group basis. A certain type of proxy filter does not require the initiating client to have specific support for the proxy-optional requirements; instead, the firewall transparently intercepts the session and creates two unique sessions. Due to their ability to make intelligent decisions based on the payload of the packet, such firewalls can perform a conversion functionfor example, removing malicious ActiveX or Java content and filter prohibited information of a pornographic or political nature, as Cisco PIX firewalls can do in concert with content filtering software, such as WebSense. Since the thorough inspection of all bypassing traffic puts very high demands on the firewall hardware, it is a common practice to separate the function of proxy filtering from a PIX firewall to a standalone proxy server.

The cons of proxy filtering include the following:

• Slowest performance as compared to other firewall types

• Highest hardware requirements

• Complexity of the protocol-proxy development and support

• Limited availability of the supported protocols

• High cost

• The possibility of the proxy itself being vulnerable to application layer attacks

PIXOS-based firewalls have a limited support for proxy-like filtering configured via the fixup commands. A fixup command can be used to change the default port assignments or to enable or disable content-based inspection for the protocols and applications shown in the following table.

Computer Telephony Interface Quick Buffer Encoding (CTIQBEdisabled by default)	DNS
Encapsulating Security Payload-Internet Key Exchange (ESP-IKEdisabled by default)	FTP
H.323	HTTP
Telephony API Internet Locator Service (ILS)	Media Gateway Control Protocol (MGCPdisabled by default)
Point-to-Point Tunneling Protocol (PPTP disabled by default)	Remote Shell Protocol (RSH)
Real-Time Streaming Protocol (RTSP)	Session Initiation Protocol (SIP)
Cisco Skinny Client Control Protocol (SCCP)	Simple Mail Transport Protocol (SMTP)
SQL*Net	Trivial File Transfer Protocol (TFTP)

Note 

Many of the protocols listed are dynamic in nature and would not function through PIX unless an appropriate fixup command is applied.

The great "digital wall of China" is the most known example of a gigantic distributed content-filtering proxy firewall rumored to be based on the Cisco PIX and WebSense content-filtering technology.

CBAC IOS Firewall also offers support of higher layer protocol inspection via the ip inspect commandalas, the list of supported protocols is not as extensive when compared to PIX. These protocols include the following:

CUSeeMe	FTP
H.323	HTTP
SQL*Net	StreamWorks
TFTP	VDOLive

Additionally, IOS Firewall supports Java blocking (not to be confused with Java filtering) and TCP Intercept, a configurable SYN flood protecting feature.

PIX Firewall Failover

One of the attractive features of the PIX firewall solution from Cisco is the high capacity for redundancy achieved through the failover function. Two devices are required, so if one fails another takes over its functions. The first PIX performing the actual firewalling function is called the primary , while the secondary firewall is waiting in standby mode. The devices are connected with a special failover cable, one end of which is marked "Primary" while the other is marked "Secondary" (what a surprise!). Note that the polarity of the cable is of particular importance, since the cable determines the primary and secondary devices. So if you mistakenly plug the primary end of the failover cable into the secondary device, the secondary failover device will overwrite the working config of the primary device with its blank alternative.

The failover process involves the full replica of the state of the primary device being continuously mirrored to the second one. This includes the same model number and PIXOS version, same number of interfaces and amount of memory installed, and, worst of all, the exact same licenses. The replication happens after boot of the standby device, and then as the commands are entered on the console of the primary device they are sent over the cable to the secondary firewall. Additionally, you can initiate the failover replication by issuing the write standby command. As the configuration replication is done via the serial cable with a limited throughput, the time it takes to replicate configuration may be rather long, largely dependent on the size of your configuration file.

The PIXes exchange the following set of messages over the failover cable:

• Keepalive (Hello)

• State (Active/Standby)

• Network link status

• MAC address exchange

• Configuration replication

Due to the stateful nature of some Internet protocols and the fact that PIX apparently stores the connection state information, two failover scenarios may be configured:

• Dry failover Occurs when the active firewalling function is transferred from the primary device to the secondary and all information about the active connections is lost. As a result, clients must initiate new connections through the firewall. The state data is impossible to synchronize in real time due to the speed limitation of the failover cable.

• Stateful failover Occurs similarly to dry failover, with one exception: the connection table information is continuously mirrored, so the secondary device, upon becoming active, is able to recognize previously established sessions. The connection table synchronization is usually performed via a 100 Mbps connection established between both devices. The higher-end PIXes, such as the 535, have firewalling throughput of several gigabits of traffic, so it is recommended that you use a gigabit interface for state table synchronization, since a 100 Mbps interface may easily be brought down to its full capacity while trying to maintain the session states at such speeds.

When a failed primary device resumes its normal operation, the active secondary device does not automatically return the active firewalling function; there is no reason for this since the devices are identical. You must force the units to switch back to their original roles using the failover active command on the primary firewall and the no failover active command on the secondary unit. Such process is called failback .

The following situations will trigger the failover operation:

• Manual role switch with standby active command

• Active unit network card status down

• Three concurrent hello replies not received over the failover cable

• Memory exhaustion on the active unit for 15 seconds

Types of Cisco Firewall Hardware

Hardware Cisco firewalls come as standalone devices (PIX) and firewall modules for routers and switches (Firewall Services Module, or FWSM). The Cisco PIX device family ranges from compact, plug-and-play desktop firewalls for small office/home office (SOHO)such as PIX 501to modular, carrier-class gigabit firewalls for large corporations and ISP environments (see Table 2-2).

Table 2-2: Cisco PIX Firewalls

Cisco PIX Model	501	506	506E	515	515E	520	525	535
Max throughput Mbps	60	10	100	120	188	370	330	1024
Max simultaneous sessions				125000		250000	280000	500000
Max interfaces				6		6	8	10
Failover	No	No	No	Yes	Yes	Yes	Yes	Yes
Environment	SOHO		Small		Medium		Enterprise	Enterprise
user			Branch		Branch		Branch	HQ

When selecting routers with the IOS Firewall feature set, follow the general Cisco network guidelines on router deployment for different network sizes. Cisco 800 and SOHO 90 routers are recommended for telecommuters and small businesses; and Cisco 1700 series are for small, Cisco 2600-2800 for medium, and Cisco 3700 for large corporate branches. Various Cisco 7000 routers are to be deployed at the large enterprise edges, headquarters, and data centers. The IOS CBAC firewall performance for SOHO routers is 10 Mbps, small branch routers is 20 Mbps, medium-size branch routers is 50 to 55 Mbps, and enterprise branch routers is 200 Mbps. For the high-end modular routers such as Cisco 7600, we advise installation of FWSM firewall modules, whose unparalleled throughput/performance was discussed in Chapter 1. The very same modules can be used to turn Catalyst 6500 switches into very high throughput enterprise or ISP firewalls.

Another Cisco device (though not strictly a firewall) to be considered for deployment at the core layer is Cisco Guard XT 5650. Cisco Guard XT 5650 is a DDoS mitigation appliance for large enterprises or government organizations for whom access to the Internet is mission-critical. XT 5650 possesses two Gigabit Ethernet interfaces for gigabit traffic processing, and multiple XT 5650 appliances can be deployed for multigigabit rates support. Cisco Guard XT 5650 was designed to work together with the Cisco Traffic Anomaly Detector XT 5600, as described later in the "Cisco Secure IDS and Attack Prevention" section. When a DDoS attack is detected , Cisco Guard XT 5650 diverts malicious traffic for inspection and separates "bad" flows from legitimate transactions. Packets identified as harmful are removed, and legitimate traffic is forwarded to its original destination; thus, no disruption of service availability occurs. The way the router- on-a-stick , Linux-based, Juniper routerfriendly Cisco Guard XT 5650 manages traffic diversion and forwarding without creating routing loops is truly fascinating and involves the Border Gateway Protocol (BGP), policy routing, tunneling, and VPN route forwarding.

Note 

While we can't spare the time and space to describe Cisco Guard XT 5650 here, we suggest you consult the information on the Web at http://www.cisco.com/en/US/products/ps5894/index.html as bedtime reading on Cisco security.

All Cisco firewalls listed here support detailed local and centralized logging of the attack events when the log option is added to the ACLs written. However, ACLs cannot reflect all possible attacks against your network, since their operation is generally limited to Open System Interconnection (OSI) layers below Layer 5. To be sure that no suspicious activity that is directed at or is internal to the network you manage goes unmentioned and unpunished, deploy and configure a specialized distributed IDS such as the Cisco Secure IDS, outlined in the next section. PIX firewalls can also be used as IDS sensors integrated into the Cisco Secure IDS infrastructure.