Foundation TopicsMultimedia Support on the Cisco PIX FirewallChapter 7, "Configuring Access," begins a discussion of some applications that require special handling by the Cisco PIX Firewall. Multimedia applications have special behaviors that require special handling by the PIX inspection feature.During normal mode of operation, multimedia application protocols open more than one communication channel and several data channels. For example, a client might transmit a request on Transmission Control Protocol (TCP), get responses on User Datagram Protocol (UDP), or use dynamic ports. The fixup protocol command is used to help the PIX Firewall identify such protocols so that it can perform inspections.Here are the multimedia applications supported by the PIX Firewall:
The PIX Firewall dynamically opens and closes UDP ports for secure multimedia connections. There is no need to open a range of ports, which creates a security risk, or to reconfigure any application clients.The PIX Firewall supports multimedia with or without Network Address Translation (NAT). Many firewalls that cannot support multimedia with NAT limit multimedia usage to only registered users or require exposure of inside Internet Protocol (IP) addresses to the Internet.Many popular multimedia applications use Real-Time Streaming Protocol (RTSP) or the H.323 suite protocol standard. Real-Time Streaming ProtocolRTSP, described in RFC 2326, controls the delivery of real-time data, such as audio and video. It is used for large-scale broadcasts and audio- or video-on-demand streaming. It supports applications such as Cisco IP/TV, RealNetworks RealAudio G2 Player, and Apple QuickTime 4 software.RTSP applications use port 554 with TCP (and rarely UDP) as a control channel. The TCP control channel is used to negotiate the two UDP data channels that are used to transmit audio/video traffic. RTSP does not typically deliver continuous data streams over the control channel, usually relying on a UDP-based data transport protocol such as standard Real-Time Transport Protocol (RTP) to open separate channels for data and for RTP Control Protocol (RTCP) messages. RTCP carries status and control information, and RTP carries the actual data.The fixup protocol command is used for RTSP connections to let the Cisco PIX Firewall do inspection. The fixup protocol rtsp command lets the PIX dynamically create conduits for RTSP UDP channels. For example, the standard RTSP port 554 is enabled by the following command:
Application Inspection Support for Voice over IPThe steady growth of Voice over IP (VoIP) technology has also seen the development of new standards. IP phones and devices, unlike their regular phone counterparts, are not fixed to a specific switch device, so they must contain processors that enable them to function and be intelligent on their own, independent from a central switching location. Regular phones are relatively inexpensive because they do not need to be complex; they are fixed to a specific switch at a central switching location. Why is this important to you? Well, you might be running a network that supports VoIP and would want a firewall that supports the different protocols that are involved with it. PIX Firewall Version 6.3 and later support application inspection of the major protocols and applications that provide VoIP services including the following, each of which is discussed in the following sections.
Computer Telephony Interface Quick Buffer EncodingThe Telephony Application Programming Interface (TAPI) and Java Telephony Application Programming Interface (JTAPI) are used by many Cisco VoIP applications. Cisco TAPI Service Provider (TSP) uses CTIQBE to communicate with Cisco CallManager. CTIQBE protocol is disabled by default. The fixup protocol ctiqbe 2748 command enables CTIQBE protocol inspection that supports NAT, Port Address Translation (PAT), and bidirectional NAT. This enables Cisco IP SoftPhone and other Cisco TAPI/JTAPI applications to work successfully with Cisco CallManager for call setup across the firewall.There are, however, instances when CTIQBE application inspection has limits or does not support some configuration types. CTIQBE application inspection does not support the following:
The following summarizes special considerations when using CTIQBE application inspection in specific scenarios:
H.323The H.323 collection of protocols collectively uses up to two TCP connections and four to six UDP connections. Most of the ports, with the exception of one TCP port, are negotiated just for that particular session. Figure 18-1 shows the H.323 protocols in relation to the Open System Interconnection (OSI) reference model. Figure 18-1. H.323 Protocols Mapped to the OSI Reference Model![]()
The content of the streams in H.323 is far more difficult for firewalls to understand than existing protocols because H.323 encodes packets using Abstract Syntax Notation (ASN.1).The H.323 control channel handles H.225 and H.245, and H.323 RAS. H.323 inspection uses the following ports: NotePAT support for H.323 is available in PIX Firewall Version 6.2 software. fixup protocol h323 CommandThe Cisco PIX Firewall inspects port 1720 (default) connections for H.323 traffic. If you need to change port 1720 because you have applications using H.323 on other ports, use the fixup command: Use the no form of this command to disable the inspection of traffic on the indicated port.An H.323 client might initially establish a TCP connection to an H.323 server using TCP port 1720 to request Q.931 call setup. The H.323 terminal supplies a port number to the client to use for an H.245 TCP connection.The two major functions of H.323 inspection are as follows:
Each UDP connection with a packet going through H.323 inspection is marked as an H.323 connection and times out with the H.323 timeout as configured by the administrator using the timeout command. To clear all previous fixup protocol h323 commands and reset port 1720 as the default, use the clear fixup protocol h323 command. Media Gateway Control ProtocolMGCP is a voice protocol that runs in conjunction with Signaling System 7 (SS7), an interoffice signaling protocol for circuit-switched services, and an IP protocol such as H.323 or SIP to bridge circuit-switched and packet networks. MGCP separates the signaling and call control from the media gateway. A media gateway is typically a network element that provides conversion between the audio signals carried on telephone circuits and the data packets carried over the Internet or over other packet networks, such as trunking gateways, residential gateways, and business gateways.Application inspection for MGCP is disabled by default. To use MGCP, you typically need to configure at least two ports: one on which the gateway receives commands and one for the port on which the call agent receives commands. Normally, a call agent will send commands to port 2427, whereas a gateway will send commands to port 2727.To enable MGCP application inspection for call agents and gateways using the default ports, enter the following commands: MGCP messages are transmitted over UDP. A response is sent back to the source address (IP address and UDP port number) of the command, but the response may not be sent from the same address to which the command was sent. Multiple MGCP call agents can be supported by the PIX Firewall. The mgcp call-agent command specifies a group of call agents that can manage one or more gateways. The mgcp command-queue command specifies the maximum number of MGCP commands that will be queued waiting for a response. The range of allowed values for the limit option is 1 to 4,294,967,295. The default is 200. The mgcp gateway command is used to specify which group of call agents are managing a particular gateway.Example 18-1 limits the MGCP command queue to 320 commands, allows call agents 10.1.1.30 and 10.1.1.35 to control gateway 10.1.2.20, and allows call agents 10.1.1.12 and 10.1.1.14 to control gateway 10.1.2.21. Example 18-1. Sample MGCP Configuration
Skinny Client Control ProtocolCisco IP Phones using SCCP can coexist in an H.323 environment. When used with Cisco CallManager, the SCCP client can interoperate with H.323-compliant terminals. Application layer functions in the PIX Firewall recognize SCCP Version 3.3. The functionality of the application layer software ensures that all SCCP signaling and media packets can traverse the firewall by providing NAT of the SCCP signaling packets.Application inspection for SCCP is enabled by default. You can use the fixup command to change the default port assignment for SCCP. The command syntax is as follows: To change the default port assignments from 2000, use the port option. Use the - port option to apply SCCP application inspection to a range of port numbers.Although the PIX Firewall does support PAT and NAT for SCCP, it does have limitations, including the following:
PIX Firewall does not support NAT or PAT of the file content transferred using Trivial File Transfer Protocol (TFTP), if the address of a Cisco CallManager server is configured for NAT or PAT to a different address or port and outside phones register to it using TFTP. Even though PIX Firewall does support NAT of TFTP messages and opens holes for the TFTP file to pass through the firewall, PIX Firewall cannot translate the Cisco CallManager IP address and port embedded in the Cisco IP Phone's configuration files that are transferred using TFTP during phone registration.NoteCisco IP Phones need to reregister with the Cisco CallManager to establish calls through the PIX Firewall if the clear xlate command is entered. This is because the xlates for the Cisco CallManager are permanently deleted. Session Initiation ProtocolSIP, RFC 2543, is a signaling protocol for Internet conferencing, telephony, presence, events notification, and instant messaging. SIP was developed in the mid-1990s by the Internet Engineering Task Force (IETF) as a real-time communication protocol for IP voice, and it has expanded into video and instant-messaging applications. SIP works with Session Description Protocol (SDP), RFC 2327, for call signaling. SDP specifies the ports for the media stream. Using SIP, the PIX Firewall can support any SIP VoIP gateways and VoIP proxy servers.To support SIP calls through the PIX Firewall, signaling messages for the media connection addresses, media ports, and embryonic connections for the media must be inspected, because although the signaling is sent over a well-known destination port (UDP/TCP 5060), the media streams are dynamically allocated. Also, SIP embeds IP addresses in the user data portion of the IP packet. SIP inspection applies NAT for these embedded IP addresses.Application inspection for SIP is enabled by default. You can use the fixup command to change the default TCP port assignment for SIP. The command syntax is as follows:
Attack GuardsHackers use several methods to cause network service disruption. Denial of service (DoS) is a popular way of causing network disruption. Cisco PIX Firewall has some attack mitigation features to combat against some of the following attacks:
Fragmentation Guard and Virtual ReassemblyBreaking a single IP datagram into two or more smaller IP datagrams is called IP fragmentation . DoS attacks overwhelm the host with fragmented IP datagrams. By using the fragment command on the PIX Firewall, you can prevent fragmented packets from traversing it. The IP Fragguard feature is enabled by default. To specify the maximum number of packets into which a full IP packet can be fragmented, use the following syntax: Setting the chain limit to 1 means that all packets must be whole; that is, unfragmented. The default is 24. The following example shows a configuration that prevents fragmented packets from entering on the outside interface: The Fragguard feature enforces the checks recommended by RFC 1858, with two additional security checks protecting against many IP fragment-style attacks such as teardrop:
Virtual reassembly is enabled by default. This feature uses syslog to log any fragment overlapping and small fragment offset anomalies. Here is an example of such a message:
Domain Name System GuardTo understand the DNS attack protection provided by Cisco PIX Firewall, it helps to understand how DNS can be exploited to cause a DoS attack. DNS queries are sent from the attacker to each of the DNS servers. These queries contain the target's spoofed address. The DNS servers respond to the small query with a large response. These responses are routed to the target, causing link congestion and possible denial of Internet connectivity.The port assignment for DNS cannot be configured on the Cisco PIX Firewall. DNS requires application inspection so that DNS queries will not be subject to generic UDP handling based on activity timeouts. The PIX allows only a single DNS response for outgoing DNS requests. The UDP connections associated with DNS queries and responses are torn down as soon as a reply to a DNS query is received, dropping all other responses and averting a DoS attack. This functionality is called DNS Guard . DNS Guard is enabled by default.DNS inspection performs two tasks:
Only forward lookups are translated using NAT, so pointer (PTR) records are not touched. DNS zone transfers can also trigger built-in intrusion detection signatures on the PIX Firewall.NoteA pointer record is also called a reverse record. A PTR record associates an IP address with a canonical name.Cisco PIX Firewall Version 6.2 introduces full support for NAT and PAT of DNS messages originating from either inside (more-secure) or outside (less-secure) interfaces. This means that if a client on an inside network requests DNS resolution of an inside address from a DNS server on an outside interface, the DNS A record is translated correctly. This also means that the use of the alias command is now unnecessary. Mail GuardAn SMTP server responds to client requests with numeric reply codes and optional human-readable strings. SMTP application inspection controls and reduces the commands that the user can use, as well as the messages the server returns. SMTP inspection performs three primary tasks:
By default, the Cisco PIX Firewall inspects port 25 connections for SMTP traffic. SMTP inspection monitors the command-response sequence for the following anomalous signatures:
The fixup command is used to change the default port assignment for SMTP. The command syntax is as follows: The fixup protocol smtp command enables the Mail Guard feature. This restricts mail servers to receiving only the seven commands defined in RFC 821 section 4.5.1 ( HELO, MAIL, RCPT, DATA, RSET, NOOP , and QUIT ). All other commands are rejected.The strict implementation of RFC 821 section 4.5.1 sometimes causes problems for mail servers that do not adhere to the standard. For example, Microsoft Exchange Server does not strictly comply with RFC 821 section 4.5.1 and uses extended SMTP commands such as EHLO . The Cisco PIX Firewall converts any such commands into NOOP commands, which, as specified by the RFC, forces SMTP servers to fall back to using minimal SMTP commands only. This might cause Microsoft Outlook clients and Exchange servers to function unpredictably when their connection passes through the PIX Firewall.Mail Guard, however, is not the magic bullet for all mail serverrelated attacks. It protects your mail server only from known attacks. Flood DefenderThe Flood Defender feature of PIX Firewall protects inside systems from a DoS attack that floods an interface with half-open TCP (embryonic) connections, otherwise known as SYN flooding . Creating a threshold for the number of embryonic connections or limiting the number of connections to the host mitigates such attacks. When the configured embryonic limit is reached, the PIX Firewall intercepts the SYN bound for the host and responds with a SYN/ACK on the host's behalf.You enable this feature by setting the emb-limit (maximum embryonic connections) option or max-conn (maximum connection) option on the nat and static commands. For example: This example sets the maximum connection to host 10.10.10.10 to 300 and sets the embryonic connection limit to 500,000.If you set max-conn too low, you deny legitimate user access, creating a denial of service for yourself. There is no magic number for the max-conn and emb-limit arguments because every network has a unique environment. The best number is one that does not negatively affect the network. You can observe the number of connections and embryonic connections to your host, before and after max-conn and emb-limit implementation, using the show local-host host-ip command.The static command with the maximum connection or embryonic connection arguments set mitigates inbound DoS. The nat command with the same arguments can prevent the users in your network from committing TCP SYN attacks on someone else. AAA FloodguardCisco PIX Firewall has a Floodguard feature that helps it monitor and recover resources tied up in the user authentication (auth) subsystem. As with DNS, the service of authentication is maliciously exploited to create a DoS attack. Authentication attacks are done on the premise that each authentication request has to be processed. Sending an enormous number of authentication requests bogs down the target's finite resources, forcing a shutdown in the worst case.When the Cisco PIX Firewall is inundated with authentication requests, it displays messages indicating that it is out of resources or out of TCP users. TCP user resources in different states are reclaimed in the following order depending on urgency:
PIX Firewall Intrusion Detection FeatureCisco PIX Firewall includes an IP-only intrusion detection feature. It provides visibility at network perimeters or for locations where additional security between network segments is required.The PIX IDS identifies more than 53 common attacks using signatures to detect patterns of misuse in network traffic. Traffic passing through the PIX Firewall can be identified to be audited, logged, and/or dropped.After it is configured, the IDS feature watches packets and sessions as they flow through the firewall, scanning each for a match with any of the IDS signatures. When suspicious activity is detected, the PIX Firewall responds immediately and can be configured to do the following:
Intrusion Detection ConfigurationAn audit policy (audit rule) defines the attributes of all signatures that can be applied to an interface, along with a set of actions. Using an audit policy can limit the traffic that is audited or specify actions to be taken when the signature matches. Each audit policy is identified by a name and can be defined for informational or attack signatures. Each interface can have two policiesone for informational signatures and one for attack signatures. If a policy is defined without actions, the configured default actions take effect. Each policy requires a different name.The ip audit command enables the IDS feature on the Cisco PIX Firewall. The ip audit command can be used to create a global audit policy or a per-interface policy.The global audit policy specifies the default actions to be taken when an attack or informational signature is matched.In all the ip audit commands, the action can be any combination of alarm, drop , and reset . If nothing is configured, the default action is alarm . The alarm option indicates that when a signature match is detected in a packet, the PIX Firewall reports the event to all configured syslog servers. The drop option drops the offending packet. The reset option drops the offending packet and closes the connection if it is part of an active connection.The syntax of the ip audit attack command is as follows: The syntax of the ip audit info command is as follows: Table 18-2 describes the complete command parameters for the ip audit command.
Table 18-3 describes the show commands used to verify the IP audit configuration.
Dynamic ShunningThe dynamic shunning functionality allows a Cisco PIX Firewall, when combined with a Cisco IDS 3.0 or later sensor that is configured appropriately, to respond dynamically to an attacking host by preventing new connections and disallowing packets from any existing connection. Just like a router, the IDS unit tells the PIX Firewall to stop any new connections and to time out existing connections with the sources of traffic that are determined to be malicious. The shun command applies a blocking function to the interface receiving the attack. Packets containing the IP source address of the attacking host are dropped and are logged until the blocking function is removed manually or by the Cisco Secure IDS master unit. The shun feature is disabled by the no shun command. The syntax for the shun command is as follows: NoteThe protocol parameter is optional and is either UDP or TCP when used.In the following example, the offending host (10.10.10.14) makes a connection with the victim (10.25.25.32) using TCP. The connection in the PIX Firewall connection table contains a line similar to the following: Applying the following shun command: deletes the connection from the PIX Firewall connection table and also prevents packets from 10.10.10.14 from going through the PIX Firewall. The offending host can be inside or outside the PIX Firewall.The application of the blocking function of the shun command does not require the specified host to be in active connection. Because the shun command is used to block attacks dynamically, it is not displayed in your PIX configuration. Shun statistics are available by using show commands, syslog messages, and PIX Device Manager (PDM) monitoring. The following is a sample output of the show shun command applied to the outside interface: Although the idea of dynamic shunning seems be an innovative way of dealing with offending hosts, it sometimes produces false positives that might cause a denial of service to legitimate users. This feature is available only on PIX Firewall Version 6.0(2) and later. ip verify reverse-path CommandThe ip verify reverse-path command is a security feature that does a route lookup based on the source address. Usually, the route lookup is based on the destination address. This is why it is called reverse path forwarding . With this command enabled, packets are dropped if no route is found for the packet or the route found does not match the interface on which the packet arrived. This command is disabled by default and provides Unicast Reverse Path Forwarding (Unicast RPF) functionality for the PIX Firewall.The ip verify reverse-path command provides both ingress and egress filtering. Ingress filtering checks inbound packets for IP source address integrity and is limited to addresses for networks in the enforcing entity's local routing table. If the incoming packet does not have a source address represented by a route, it is impossible to know whether the packet has arrived on the best possible path back to its origin. This is often the case when routing entities cannot maintain routes for every network.Egress filtering verifies that packets destined for hosts outside the managed domain have IP source addresses that can be verified by routes in the enforcing entity's local routing table. If an exiting packet does not arrive on the best return path back to the originator, the packet is dropped, and the activity is logged. Egress filtering prevents internal users from launching attacks using IP source addresses outside the local domain, because most attacks use IP spoofing to hide the identity of the attacking host. Egress filtering makes the task of tracing an attack's origin much easier. When employed, egress filtering enforces which IP source addresses are obtained from a valid pool of network addresses. Addresses are kept local to the enforcing entity and therefore are easily traceable.Unicast RPF is implemented as follows:
NoteBefore using this command, add static route command statements for every network that can be accessed on the interfaces you want to protect. Enable this command only if routing is fully specified. Otherwise, the Cisco PIX Firewall stops traffic on the interface you specify if routing is not in place.The following example protects traffic between the inside and outside interfaces and provides route command statements for two networks, 10.1.2.0 and 10.1.3.0, that connect to the inside interface by a hub: The ip verify reverse-path interface outside command protects the outside interface from network ingress attacks from the Internet, whereas the ip verify reverse-path interface inside command protects the inside interface from network egress attacks from users on the internal network.The clear ip verify command removes ip verify commands from the configuration. Unicast RPF is a unidirectional input function that screens inbound packets arriving on an interface. Outbound packets are not screened.Because of the danger of IP spoofing in the IP protocol, measures need to be taken to reduce this risk when possible. Unicast RPF, or reverse route lookup, prevents such manipulation under certain circumstances. ![]() |