Cisco PIX: Advanced Features and Attack Guards

This sample chapter from Cisco Secure PIX Firewalls introduces the concepts and configuration elements of the Cisco Secure PIX Firewall features necessary to securely handle multichannel TCP applications. You will learn about advanced protocol handling, multimedia support, and attack guards.

With only a few exceptions, advanced protocol handling is accomplished via a mechanism called a fixup protocol. The fixup protocol command operates not as a true proxy but as an application aware agent. In most cases, the fixup protocol acts by monitoring the control channel of an application to prevent protocol violations and enable the PIX to respond dynamically to a protocol's legitimate need to open an inbound connection securely by making a temporary exception in the ASA. When the exception is no longer needed, the fixup protocol closes it. Each new version of the PIX OS brings new and improved protocol handling. It is important to note that the PIX can only perform these operations on the fixups that are part of the PIX OS running on your PIX. Fixups are not user-definable or user-programmable. Fixups allow you to enable or disable processing for the supported protocols and determine what ports (standard or non-standard) to operate on.

The Need for Advanced Protocol Handling

Nearly every enterprise uses the Internet for business transactions. For these enterprises to keep their internal networks secure from potential threats from the Internet, they must implement firewalls to separate their trusted internal networks from the untrusted Internet. Even though firewalls help protect an enterprise's internal networks from external threats, implementation challenges have arisen as well.

• Some of the protocols and applications that enterprises used to communicate with outside resources prior to the installation of a firewall are now blocked by the firewall.

• Many popular protocols and applications negotiate connections to dynamically assign source or destination ports or IP addresses. To further complicate matters, some applications embed source or destination IP addressing information above the network layer (Layer 3).

A good firewall must inspect packets above the network layer and perform the following operations as required by the protocol or application:

• Securely open and close negotiated ports or IP addresses for legitimate client/server connections through the firewall.

• Use Network Address Translation (NAT)-relevant instances of IP addresses inside a packet.

• Use Port Address Translation (PAT)-relevant instances of ports inside a packet.

• Inspect packets for signs of malicious application misuse.

Through the use of the Cisco Secure PIX Firewall's fixup protocol protocol commands, you can provide secure passage for these applications.

The sections that follow explain how the specific fixup protocol protocol commands for Standard and Passive File Transfer Protocol (FTP), rsh (Remote Shell), and SQL*Net operate and how to configure them.

Standard Mode FTP

Standard mode FTP (also called classic mode FTP) uses two channels for communication. When a client behind a firewall initiates an FTP connection from their host, it opens a standard TCP channel from one of its high-order ports (TCP source port >1023) to destination TCP port 21 on the outside server. This connection is referred to as the control channel. When the client requests data from the server, it tells the server to send the data to a given high-order port. The server acknowledges the request and initiates an inbound connection from its own port 20 to the high-order port that the client requested. This connection is referred to as the data channel (port 20 FTP-DATA).

In the past, it was difficult to allow this inbound connection through the firewall to the requested port on the client without permanently opening port 20 connections from outside servers to inside clients for outbound FTP connections. This creates a huge potential vulnerability by allowing any inbound traffic from any host on the Internet with a TCP source port of 20, regardless of the intent!

Example 9-1 and Figure 9-1 demonstrate the TCP three-way handshake and the establishment of the FTP control channel (TCP port 21). Notice that in the second section of the trace, the FTP-DATA channel is initiated by the server 198.10.2.51 (ftp.cisco.com) with a source port of 20 and a random high port of 1066 (selected by the client).

Example 9-1 Sniffer Trace Illustrating Classic Mode FTP

#Setup connection to destination port 21 for control channel

[10.10.2.51] [198.133.219.27] TCP: D=21 S=1065 SYN SEQ=1763920874 LEN=0

[198.133.219.27] [10.10.2.51] TCP: D=1065 S=21 SYN ACK=1763920875 SEQ=2208726475 LEN=0

[10.10.2.51] [198.133.219.27] TCP: D=21 S=1065 ACK=2208726476

#FTP server negotiates FTP-DATA channel with TCP source port 20

[10.10.2.51] [198.133.219.27] FTP: C PORT=1065 LIST

[198.133.219.27] [10.10.2.51] TCP: D=1066 S=20 SYN SEQ=2209373687 LEN=0

[10.10.2.51] [198.133.219.27] TCP: D=20 S=1066 SYN ACK=2209373688 SEQ=1765279364 LEN=0

[198.133.219.27] [10.10.2.51] TCP: D=1065 S=21 ACK=1763920967

[198.133.219.27] [10.10.2.51] TCP: D=1066 S=20 ACK=1765279365

[198.133.219.27] [10.10.2.51] FTP: R PORT=1065 150 ASCII mode data connection for /bin/ls.

[198.133.219.27] [10.10.2.51] FTP: R PORT=1066 Text Data

Figure 9-1 Standard Mode FTP Client/Server Transactions

The Cisco Secure PIX Firewall uses the fixup protocol ftp command to securely enable the exception required by the FTP-DATA connection. The Cisco Secure PIX Firewall handles FTP in the following manner for outbound and inbound connections:

• Outbound Connections—When the client requests data, the PIX Firewall opens a temporary inbound conduit to allow the data channel from the server. This conduit is torn down immediately after the data is sent.

• Inbound Connections—If a conduit exists allowing inbound connections to an FTP server, and if all outbound TCP traffic is implicitly allowed, no special handling is required because the server initiates the data channel from the inside.

  If a conduit exists allowing inbound FTP control connections to an FTP server, and if all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens a temporary conduit for the data channel from the server. This conduit is torn down after the data is sent.

Passive Mode FTP

Passive mode FTP also uses two channels for communications. The control channel works the same as in a standard FTP connection, but the data channel setup works differently. When requesting data from the server, the client asks the server if it accepts PASV connections. If the server accepts PASV connections, it sends the client a high-order port number to use for the data channel. The client then initiates the data connection from its own high-order port to the port that the server sent.

Because the client initiates both the command and data connections, early firewalls could easily support this without exposing inside clients to attack. Figure 9-2 shows transactions between the client and server with passive mode FTP. Most web browsers use passive mode FTP by default.

Figure 9-2 Passive Mode FTP Client/Server Transactions

For passive mode FTP traffic, the PIX Firewall behaves in the following manner for outbound and inbound PASV connections:

• Outbound PASV Connections—If all outbound TCP traffic is implicitly allowed, no special handling is required because the client initiates both the command and data channels from the inside.

  If all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens a temporary conduit for the data channel from the client. This conduit is torn down after the data is sent.

• Inbound PASV Connections—If a conduit exists allowing inbound FTP control connections to a PFTP server, the PIX Firewall opens a temporary inbound conduit for the data channel initiated by the client. This conduit is torn down after the data is sent.

fixup protocol FTP Command

The syntax of the fixup protocol ftp command is as follows:

where port[-port] is the single port or port range that the PIX Firewall will inspect for FTP connections.

By default, the fixup protocol ftp 21 command is enabled and the PIX Firewall inspects port 21 connections for FTP control traffic. If you have FTP servers using ports other than port 21, you need to use the fixup protocol ftp port-number command to have the PIX Firewall inspect these non-standard ports for FTP traffic. The strict option causes fixup protocol ftp to require that every FTP request be acknowledged before a new command is allowed and prevents web browsers from embedding commands in FTP requests. Any FTP packets containing embedded commands are dropped. Example 9-2 demonstrates the use of the fixup protocol ftp command and its no form to both configure and remove standard and non-standard ports for FTP.

Example 9-2 Configuring and Removing Standard and Non-standard Ports for FTP

pixfirewall#(config) fixup protocol ftp 2121

pixfirewall#(config) fixup protocol ftp 2001

pixfirewall#(config) no fixup protocol ftp 2121

pixfirewall#(config) no fixup protocol ftp 2001

The fixup protocol ftp command enables the PIX Firewall to perform the following operations for FTP traffic on the indicated port:

• Perform NAT or PAT in packet payload.

• Dynamically create conduits for FTP data connections.

• Log FTP commands (when syslog is enabled and the logging level is debug).

Use the no form of the command as indicated in Example 9-2 to disable the inspection of traffic on the indicated port for FTP connections. If the fixup protocol ftp command is not enabled for a given port, then

• Outbound standard FTP will not work properly on that port.

• Outbound passive FTP will work properly on that port as long as outbound traffic is not explicitly disallowed.

• Inbound standard FTP will work properly on that port if a conduit to the inside server exists.

• Inbound passive FTP will not work properly on that port.

Using the clear fixup protocol ftp command without any arguments causes the PIX Firewall to clear all previous fixup protocol ftp assignments and set port 21 back as the default.

Remote Shell (rsh)

The rsh daemon running on a UNIX or Windows host provides remote execution facilities with authentication based on privileged port numbers from trusted hosts. Typically, the daemon checks the requesting client's source IP address and source port. The source port should be in the range of 512–1023; otherwise the service should abort the connection.

A second connection is then created from the rsh daemon to the specified port on the client's machine for standard error output.

The rsh daemon then validates the host/client name by checking the /etc/hosts.equiv and ~/.rhosts files. If the check fails, the connection is aborted and a diagnostic message is returned.

Figure 9-3 shows transactions between the client and server for rsh.

The fixup protocol rsh command enables the PIX Firewall to secure rsh requests in the following manner:

• Outbound connections—When standard error messages are sent from the server, the PIX Firewall opens a temporary inbound conduit for this channel. This conduit is torn down once it is no longer needed.

• Inbound connections—If a conduit exists allowing inbound connections to an rsh server, and if all outbound TCP traffic is implicitly allowed, no special handling is required because the server initiates the standard error channel from the inside.

  If a conduit exists allowing inbound connections to an rsh server, and if all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens a temporary conduit for the standard error channel from the server. This conduit is torn down after the messages are sent.

Figure 9-3 rsh Client/Server Transactions

fixup protocol rsh Command

The syntax of the fixup protocol rsh command is as follows:

where port[-port] is the single port or port range that the PIX Firewall will inspect for rsh connections.

By default, the PIX Firewall inspects port 514 connections for rsh traffic. If you have rsh servers using ports other than port 514, use the fixup protocol rsh command as shown in Example 9-3 to instruct the PIX Firewall to inspect these other ports for rsh traffic.

Example 9-3 Configuring and Removing Standard and Non-Standard Ports for RSH

pixfirewall#(config) fixup protocol rsh 514

pixfirewall#(config) fixup protocol rsh 5141

pixfirewall#(config) no fixup protocol rsh 514

pixfirewall#(config) no fixup protocol rsh 5141

The fixup protocol rsh command enables the PIX Firewall to dynamically create conduits for rsh standard error connections for rsh traffic on the indicated port.

Use the no form of the command to disable the inspection of traffic on the indicated port for rsh connections.

If the fixup protocol rsh command is not enabled for a given port, then

• Outbound rsh will not work properly on that port.

• Inbound rsh will work properly on that port if a conduit to the inside server exists.

Using the clear fixup protocol rsh command without any arguments causes the PIX Firewall to clear all previous fixup protocol rsh assignments and set port 514 back as the default.

SQL*Net

SQL*Net is used to query remote SQL databases. Although the protocol was written by Oracle for Oracle databases, it works equally well to query the SQL databases of other vendors. The main issue to consider when securing SQL*Net is that while it only uses one TCP port for communications, that port can be redirected to a different port and, even more commonly, to a different secondary server altogether. When a client starts an SQL*Net connection, it opens a standard TCP channel from one of its high-order ports to port 1521 on the server. The server then proceeds to redirect the client to a different port or IP address. The client tears down the initial TCP connection and establishes the second connection using the redirected port.

Figure 9-4 illustrates transactions between the client and the server for SQL*Net connections.

Figure 9-4 SQL*Net Client/Server Transactions

For SQL*Net traffic, the PIX Firewall behaves in the following manner:

• Outbound connections—If all outbound TCP traffic is implicitly allowed, no special handling is required because the client initiates all TCP connections from the inside.

  If all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens a conduit for the redirected channel between the server and the client.

• Inbound connections—If a conduit exists allowing inbound SQL*Net connections to an SQL*Net server, the PIX Firewall opens an inbound conduit for the redirected channel.

fixup protocol sqlnet Command

The syntax of the fixup protocol sqlnet command is as follows:

fixup protocol sqlnet port [-port ]
no fixup protocol sqlnet port [-port ]
clear fixup protocol sqlnet

where port[-port] is a single port or port range that the PIX Firewall will inspect for SQL*Net connections.

By default, the PIX Firewall inspects port 1521 connections for SQL*Net traffic. If you have SQL*Net servers using ports other than port 1521, use the fixup protocol sqlnet command as illustrated in Example 9-4 to instruct the PIX Firewall to inspect these other ports for SQL*Net traffic.

Example 9-4 Adding and Removing Standard and Non-standard Ports for SQL*NET

pixfirewall#(config) fixup protocol sqlnet 1521

pixfirewall#(config) fixup protocol sqlnet 66

pixfirewall#(config) no fixup protocol sqlnet 1521

pixfirewall#(config) no fixup protocol sqlnet 66

The fixup protocol sqlnet command causes the PIX Firewall to do the following for SQL*Net traffic on the indicated port:

• Perform NAT in packet payload.

• Dynamically create conduits for SQL*Net redirected connections.

Use the no form of the command to disable the inspection of traffic on the indicated port for SQL*Net connections. If the fixup protocol sqlnet command is not enabled for a given port, then the following will occur:

• Outbound SQL*Net will work properly on that port as long as outbound traffic is not explicitly disallowed.

• Inbound passive SQL*Net will not work properly on that port.

Using the clear fixup protocol sqlnet command without any arguments causes the PIX Firewall to clear all previous fixup protocol sqlnet assignments and set port 1521 back as the default.

Multimedia Support

This section discusses multimedia: advantages and supported applications, H.323 support, and important multimedia configuration considerations.

Multimedia applications present a particularly daunting challenge to a firewall, as clients may transmit requests on TCP, get responses on UDP or TCP, use dynamic ports, may use the same port for source and destination, and so on. Every application behaves in a different way. Implementing support for all multimedia applications using a single secure method is very difficult.

Two examples of multimedia client applications are as follows:

• RealAudio clients send the originating connection request to TCP port 7070. The RealAudio server replies with multiple UDP streams anywhere from UDP port 6970 through 7170 on the client machine.

• The CUseeMe client sends the originating request from TCP port 7649 to TCP port 7648. The CUseeMe datagram is unique in that it includes the legitimate IP address in the header as well as in the payload and sends responses from UDP port 7648 to UDP port 7648.

The Cisco Secure PIX Firewall dynamically opens and closes UDP ports for secure multimedia connections. This significantly reduces the security risk posed by opening a large range of ports and mitigates the need to reconfigure application clients.

Also, the PIX Firewall supports multimedia with or without NAT. Firewalls that cannot support multimedia with NAT limit multimedia usage to registered users only or require exposing inside IP addresses to the Internet. Lack of NAT support for multimedia often forces multimedia vendors to join proprietary alliances with firewall vendors to accomplish compatibility for their applications.

Real Time Streaming Protocol (RTSP)

The Real Time Streaming Protocol (RTSP), described in RFC 2326, is a real-time audio and video delivery protocol used by many popular multimedia applications. It uses one TCP channel and sometimes two additional UDP channels. RTSP applications use the well-known port 554, usually TCP and rarely UDP. RFC 2326 requires only TCP so the PIX Firewall only supports TCP. This TCP channel is the control channel and is used to negotiate the other two UDP channels depending on the transport mode that is configured on the client.

The first UDP channel is the data connection and may use one of the following transport modes:

• Real-Time Transport Protocol (RTP)

• Real Data Transport Protocol (RDT) (developed by RealNetworks, Inc.)

The second UDP channel is another control channel, and it may use one of the following modes:

• RTP Control Protocol (RTCP)

• UDP Resend

RTSP also supports a TCP-only mode. This mode contains only one TCP connection, which is used as the control and data channels. Because this mode contains only one constant standard TCP connection, no special handling by the PIX Firewall is required.

The following RTSP applications are supported by the PIX Firewall:

• Cisco IP/TV
• Apple QuickTime 4
• RealNetworks
• RealAudio
• RealPlayer
• RealServer

Note that RDT Multicast mode is not supported.

RTP Mode

In standard RTP mode, the following three channels are used by RTSP:

• TCP control channel—Standard TCP connection initiated from the client to the server.

• RTP data channel—Simplex (unidirectional) UDP session used for media delivery using the RTP packet format from the server to the client. The client's port is always an even-numbered port.

• RTCP reports—Duplex (bi-directional) UDP session used to provide synchronization information to the client and packet-loss information to the server. The RTCP port is always the next consecutive port from the RTP data port.

Figure 9-5 illustrates the communication between client and server in standard RTP mode for RTSP.

Figure 9-5 Standard RTP Mode Client/Server Transactions

For standard RTP mode RTSP traffic, the PIX Firewall behaves in the following manner:

• Outbound connections—After the client and the server negotiate the transport mode and the ports to use for the sessions, the PIX Firewall opens temporary inbound conduits for the RTP data channel and RTCP report channel from the server.

• Inbound connections—If a conduit exists allowing inbound RTSP connections to an RTSP server, and if all outbound UDP traffic is implicitly allowed, no special handling is required, since the server initiates the data and report channel from the inside.

  If a conduit exists allowing inbound RTSP connections to an RTSP server, and if all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens temporary conduits for the data and report channels from the server.

RealNetworks' RDT Mode

In RealNetworks' RDT mode, the following three channels are used by RTSP:

• A TCP control channel—Standard TCP connection initiated from the client to the server.

• A UDP data channel—Simplex (unidirectional) UDP session used for media delivery using the standard UDP packet format from the server to the client.

• A UDP resend—Simplex (unidirectional) UDP session used for the client to request that the server resend lost data packets.

Figure 9-6 illustrates the communication between client and server in RealNetworks' RDT mode for RTSP.

For RealNetworks' RDT mode RTSP traffic, the PIX Firewall will behave in the following manner:

• Outbound connections—If outbound UDP traffic is implicitly allowed, and after the client and the server negotiate the transport mode and the ports to use for the session, the PIX Firewall opens a temporary inbound conduit for the UDP data channel from the server.

  If outbound UDP traffic is not implicitly allowed, and after the client and the server negotiate the transport mode and the ports to use for the session, the PIX Firewall opens a temporary inbound conduit for the UDP data channel from the server and a temporary outbound conduit for the UDP resend channel from the client.

• Inbound connections—If a conduit exists allowing inbound RTSP connections to an RTSP server, and if all outbound UDP traffic is implicitly allowed, the PIX Firewall opens a temporary outbound conduit for the UDP data channel from the server.

  If a conduit exists allowing inbound connections to an RTSP server, and if all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens temporary conduits for the UDP data and UDP resend channels from the server and client, respectively.

Figure 9-6 RealNetworks' RDT Mode Client/Server Transactions

By default, the PIX Firewall does not inspect any ports for RTSP connections. To enable the PIX Firewall to inspect specific ports for RTSP traffic, such as the standard port 554, use the fixup protocol rtsp command.

The fixup protocol rtsp command enables the PIX Firewall to dynamically create conduits for RTSP UDP channels for RTSP traffic on the indicated port. The syntax of the fixup protocol rtsp command is as follows:

fixup protocol rtsp port [-port ]
no fixup protocol rtsp port [-port ]
clear fixup protocol rtsp

where port[-port] is the single port or port range that the PIX Firewall will inspect for RTSP connections.

Use the no form of the command as shown in Example 9-5 to disable inspection of traffic on the indicated port for RTSP connections. If the fixup protocol rtsp command is not enabled for a given port, then neither inbound nor outbound RTSP will work properly on that port.

Example 9-5 Adding and Deleting Standard and Non-standard Ports for RTSP

pixfirewall#(config) fixup protocol rtsp 554

pixfirewall#(config) fixup protocol rtsp 8554-8574

pixfirewall#(config) no fixup protocol rtsp 554

pixfirewall#(config) no fixup protocol rtsp 8554-8574

Using the clear fixup protocol rtsp command without any arguments causes the PIX Firewall to clear all previous fixup protocol rtsp assignments.

H.323

H.323 is more complicated than other protocols because it uses two TCP connections and several UDP sessions for a single "call." (Only one of the TCP connections goes to a well-known port; all the other ports are negotiated and thus temporary.) Furthermore, the content of the streams is far more difficult for firewalls to understand than existing protocols, because H.323 encodes packets using Abstract Syntax Notation (ASN.1).

Other protocols and standards supported within H.323 are

• H.225-Registration, Admission, and Status (RAS)

• H.225-Call Signaling

• H.245-Control Signaling

• TPKT Header

• Q.931 Messages

• Abstract Syntax Notation (ASN.1) (PIX Firewall 5.2)

Supported H.323 versions are as follows:

• H.323 v1

• H.323 v2 (PIX Firewall 5.2)

PIX Firewall supported H.323 applications include

• Cisco Multimedia Conference Manager

• Microsoft NetMeeting

• Intel Video Phone

• CUseeMe Networks

  • MeetingPoint

  • CUseeMe Pro

• VocalTec

  • Internet Phone

  • Gatekeeper

fixup protocol h323 Command

By default, the PIX Firewall inspects port 1720 connections for H.323 traffic. If you have H.323 servers operating on ports other than port 1720, use the fixup protocol h323 command to have the PIX Firewall inspect those non-standard ports for H.323 traffic. The syntax of the fixup protocol h323 command is as follows:

fixup protocol h323 port [-port ]
no fixup protocol h323 port [-port ]
clear fixup protocol h323

where port[-port] is a single port or port range that the PIX Firewall will inspect for H.323 connections.

Example 9-6 demonstrates the typical use of the fixup protocol h323 command and its no form to add and delete standard and non-standard ports for H.323 traffic.

Example 9-6 Adding and Deleting Standard and Non-standard Ports for H.323

pixfirewall(config)# fixup protocol h323 1720

pixfirewall(config)# fixup protocol h323 7720-7740

pixfirewall(config)# no fixup protocol h323 1720

pixfirewall(config)# no fixup protocol h323 7720-7740

The fixup protocol h323 command causes the PIX Firewall to do the following for H.323 traffic on the indicated port:

• Perform NAT in packet payload.

• Dynamically create conduits for TCP or UDP channels.

Use the no form of the command to disable the inspection of traffic on the indicated port for H.323 connections. If the fixup protocol h323 command is not enabled for a given port, then neither outbound nor inbound H.323 will work properly on that port.

Using the clear fixup protocol h323 command without any arguments causes the PIX Firewall to clear all previous fixup protocol h323 assignments and set port 1720 back as the default.

Attack Guards

This section discusses the Attack Guards features put in place to mitigate attacks via e-mail; Domain Name System (DNS); fragmentation; authentication, authorization, and accounting (AAA); and SYN flooding.

MailGuard

MailGuard provides a mechanism to safeguard Simple Mail Transfer Protocol (SMTP) connections from the outside to an e-mail server. MailGuard allows a mail server to be deployed on a network protected by the PIX without it being exposed to known security problems with certain mail server implementations. Bearing this in mind, Cisco recommends placing mail servers on a DMZ interface and not on the inside network.

Only the SMTP commands specified in RFC 821 section 4.5.1 are allowed on a mail server. These are: HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT. When the PIX Firewall observes an SMTP command not in the preceding list, the PIX Firewall proxies a response of "500 command unrecognized" to the remote device and drops the packet before it reaches the protected mail server.

MailGuard isn't a panacea. While it proxies connections, limits the types of SMTP messages that reach your mail server, and hides the SMTP banner that indicates the type and version of the protected mail server, MailGuard can't protect your mail server from all known attacks. Even protected by MailGuard, your mail server needs to be properly configured and patched against known threats.

Also, certain configurations of Microsoft Exchange Server require the use of commands not allowed by MailGuard. In this scenario, MailGuard must be disabled using the no fixup protocol smtp 25 command.

By default, the PIX Firewall inspects port 25 connections for SMTP traffic. If you have SMTP servers using ports other than port 25, you must use the fixup protocol smtp port-number command to have the PIX Firewall inspect these other ports for SMTP traffic. The syntax of the fixup protocol smtp command is as follows:

fixup protocol smtp port [-port ]
no fixup protocol smtp port [-port ]
clear fixup protocol smtp

where port[-port] is a single port or port range that the PIX Firewall will inspect for SMTP connections.

Use the no form of the command to disable the inspection of traffic on the indicated port for SMTP connections. If the fixup protocol smtp command is not enabled for a given port, then potential mail server vulnerabilities are exposed. Example 9-7 illustrates configuration and removal of the MailGuard feature with standard and non-standard ports.

Using the clear fixup protocol smtp command without any arguments causes the PIX Firewall to clear all previous fixup protocol smtp assignments and set port 25 back as the default.

Example 9-7 Adding and Deleting Standard and Non-standard Ports for Mail Guard

pixfirewall(config)# fixup protocol smtp 25

pixfirewall(config)# fixup protocol smtp 2525

pixfirewall(config)# no fixup protocol smtp 25

pixfirewall(config)# no fixup protocol smtp 2525

DNS Guard

DNS Guard identifies an outbound DNS query request and allows only a single DNS response back to the sender. A host may query several servers for a response in case the first server is slow in responding; however, only the first answer to the specific question will be allowed back in. All the additional answers from other servers are dropped. After the client issues a DNS request, a dynamic conduit allows UDP packets to return from the DNS server. The default UDP timer expires in two minutes. Because DNS is frequently attacked, leaving the conduit open for two minutes creates an unnecessary risk. DNS Guard is enabled by default and cannot be configured or disabled. DNS Guard performs the following actions:

• Automatically tears down the UDP conduit on the PIX Firewall as soon as the DNS response is received. It doesn't wait for the default UDP timer to close the session.

• Prevents against UDP session hijacking and denial of service (DoS) attacks.

Figure 9-7 illustrates the PIX's involvement in DNS queries.

Figure 9-7 DNS Guard

Fragmentation Guard

Use the sysopt security fragguard command to enable the Fragmentation Guard (FragGuard) feature. This feature enforces two additional security checks on IP packets in addition to the security checks recommended by RFC 1858 against the many IP fragment-style attacks: teardrop, land, and so on. The first security check requires that each non-initial IP fragment be associated with an already-seen valid initial IP fragment. As of PIX OS version 5.1, an initial fragment is not required. This is because fragments may arrive out of order. For the second security check, IP fragments are rated 100 full IP fragmented packets per second to each internal host. This means the PIX can process 1200 packet fragments a second. The FragGuard feature operates on all interfaces in the PIX Firewall and cannot be selectively enabled or disabled by interface.

FragGuard and Virtual Reassembly

The following virtual reassembly features are new in version 5.1:

• Version 5.1 enhances IP fragment protection and performs full reassembly of all ICMP error messages and virtual reassembly of the remaining IP fragments that are routed through the PIX Firewall. The previous restriction with the FragGuard feature that the initial fragment must arrive first has been lifted.

• A new teardrop syslog message has been added to notify of any fragment overlapping and small fragment offset anomalies.

• Syslog message, %PIX-2-106020: Deny IP teardrop fragment (size = num, offset = num) from IP_addr to IP_addr was added in this release to log teardrop.c attacks. This message occurs when the PIX Firewall discards an IP packet with a teardrop signature with either a small offset or fragment overlapping. You should treat this event as a hostile attempt to circumvent the PIX Firewall or the Cisco Secure Intrusion Detection System.

• IP packets fragmented into more than 12 elements cannot pass through the PIX Firewall. Twelve is the maximum number of 1500 byte fragments required to assemble a 16 KB payload. 16,384 bytes is the maximum IP MTU for Token Ring.

The PIX Firewall uses the sysopt security fragguard command to enforce the security policy determined by an access-list permit or access-list deny command to permit or deny packets through the PIX Firewall. The sysopt security fragguard command is disabled by default. The syntax for the sysopt security fragguard command is as follows:

This command has no arguments.

AAA Floodguard

While using AAA with the PIX to identify, authorize, and monitor your users helps mitigate the problem of unauthorized access to information resources, it also provides a hacker with an opportunity for mischief. If all connections must be authenticated, what would happen if someone forged so many authentication requests that the PIX's AAA resources were overwhelmed? Denial of service!

The floodguard command allows you to automatically reclaim PIX Firewall resources if the user authentication (uauth) subsystem runs out of resources. If an inbound or outbound uauth connection is being attacked or overused, the PIX actively reclaims TCP user resources. When resources are depleted, the PIX Firewall lists messages indicating that it is out of resources or out of TCP users. If the PIX Firewall uauth subsystem is depleted, TCP user resources in different states are reclaimed depending on urgency in the following order:

1. Timewait
2. FinWait
3. Embryonic
4. Idle

The floodguard command is enabled by default.

The syntax of the floodguard command is as follows:

where enable enables the AAA Floodguard and disable disables the AAA Floodguard.

SYN Floodguard

SYN flood attacks, also known as TCP flood or half-open connections attacks, are common DoS attacks perpetrated against IP servers. SYN flood attacks are perpetrated as follows:

1. The attacker spoofs a nonexistent source IP address or IP addresses and floods the target with SYN packets pretending to come from the spoofed host(s).

2. SYN packets to a host are the first step in the three-way handshake of a TCP-type connection; therefore, the target responds as expected with SYN-ACK packets destined to the spoofed host or hosts.

3. Because these SYN-ACK packets are sent to hosts that do not exist, the target waits for the corresponding ACK packets that never show up. This causes the target to overflow its port buffer with embryonic or half-open connections and stop responding to legitimate requests.

Figure 9-8 illustrates this type of attack.

Figure 9-8 SYN Flood Attack

To protect internal hosts against DoS attacks, use the static command to limit the number of embryonic connections allowed to the server. Use the em_limit argument to limit the number of embryonic or half-open connections that the server or servers you are trying to protect can handle without being attacked by a DoS.

In version 5.2 of the PIX OS the TCP Intercept feature was added to the SYN Floodguard. The TCP Intercept feature improves the embryonic connection response of the PIX Firewall. When the number of embryonic connections exceeds the configured threshold, the PIX Firewall intercepts and proxies new connections.

Prior to version 5.2, the PIX did not allow new connections after the embryonic connection threshold was exceeded. While it protected the internal host from having all of its TCP connection slots filled, it still resulted in DoS.

This feature requires no change to the PIX Firewall command set, only that the embryonic connection limit on the static command has a new behavior.

The syntax used in the static command for enabling the SYN Floodguard is as follows:

Table 9-1 provides descriptions for the static command arguments.

Table 9-1 static Command Arguments

Argument	Description
internal_if_name	The internal network interface name.
external_if_name	The external network interface name.
global_ip	The global IP address for an outside interface. This address cannot be a PAT IP address.
local_ip	The local IP address on an inside network.
network_mask	The network mask for the global_ip and local_ip.
max_conns	The maximum connections permitted to the local_ip. The default = 0 (unlimited).
em_limit	The maximum embryonic connection permitted to the local_ip. The default = 0 (unlimited).

Setting the max_conns and em_limit arguments should not be taken lightly. If you set the limit too high, you risk overloading the IP stack of your statically translated host and falling victim to a DoS attack. If the limits are set too low, there is the risk of denying service to legitimate users. Example 9-9 demonstrates setting the maximum connection and embryonic connection limits on two hosts. The command shown in Example 9-9 is for illustration purposes only and should not be arbitrarily used. While no firm guidelines exist for setting these limits, the general rule is to set the em-limit and max_conn parameters to a value that won't have a negative impact on the host. Contact the company that wrote the IP stack of your hosts for information on the maximum number of TCP connection slots available and set the em_limit lower than the maximum.

The show local-host command assists you in characterizing your "normal" load on a statically translated host, both before and after setting limits.

The show local-host command shows you the current number of connections and embryonic connections against any limit you have set using the static command.

Example 9-8 shows sample output from the show local-host command, indicating that this host has no embryonic connection limit set.

Example 9-8 show local-hosts Command Output

show local-host 10.1.1.15

local host: <10.1.1.15>, conn(s)/limit = 2/0, embryonic(s)/limit = 0/0

Xlate(s):

PAT Global 172.16.3.200(1024) Local 10.1.1.15(55812)

PAT Global 172.16.3.200(1025) Local 10.1.1.15(56836)

PAT Global 172.16.3.200(1026) Local 10.1.1.15(57092)

PAT Global 172.16.3.200(1027) Local 10.1.1.15(56324)

PAT Global 172.16.3.200(1028) Local 10.1.1.15(7104)

Conn(s):

TCP out 192.150.49.10:23 in 10.1.1.15:1246 idle 0:00:20 Bytes 449 flags UIO

TCP out 192.150.49.10:21 in 10.1.1.15:1247 idle 0:00:10 Bytes 359 flags UIO

The Xlate(s) field describes the translation slot information and the Conn(s) field provides connection state information.

Example 9-9 demonstrates how you would configure maximum connections and embryonic connection limits to statically translated hosts.

Example 9-9 Configuring Maximum Connections and Embryonic Connection Limits to Statically Translated Hosts

pixfirewall(config)# static (inside, outside) 200.100.1.10 10.100.1.10

netmask 255.255.255.255 1000 1500

pixfirewall(config)# static (inside, outside) 200.100.1.15 10.100.1.10

netmask 255.255.255.255 2000 2500

In order to protect external hosts against DoS attacks and to limit the number of embryonic connections allowed to the server, use the nat command. Use the em_limit argument to limit the number of embryonic or half-open connections that the server or servers you are trying to protect can handle without being attacked by a DoS.

The syntax used in the nat command for enabling the SYN Floodguard is as follows:

Table 9-2 provides descriptions for the nat command arguments.

Table 9-2 nat Command Arguments

Argument	Description
if_name	The internal network interface name.
nat_id	A number used for matching with a corresponding global pool of IP addressees. The matching global pool must use the same nat_id.
local_ip	The internal IP address or networks that will be translated to a global pool of IP addresses.
netmask	The network mask for the local_ip.
max_conns	The maximum connections permitted to hosts accessed from local_ip. The default = 0 (unlimited).
em_limit	The maximum embryonic connection permitted to hosts accessed from local_ip. The default = 0 (unlimited).

Setting the maximum connection and embryonic connection limits on outbound traffic must be considered carefully. If you set the limit too high, you risk giving individuals in your organization the ability to perpetrate a DoS attack. If the limits are set too low, there is the risk of denying service to legitimate internal users. Example 9-10 demonstrates how to set the maximum connection and embryonic connection limits for the Inside and DMZ interfaces. The DMZ interface uses much lower limits due to the low number of connections initiated from that interface

Example 9-10 Configuring Maximum Connections and Embryonic Connection Limits to Protect Against Initiating DoS Attacks

pixfirewall(config)# nat (inside) 1 0.0.0.0 0.0.0.0 5000 5000

pixfirewall(config)# nat (dmz) 1 0.0.0.0 0.0.0.0 500 500

Summary

This section summarizes the key points in this chapter.

• The PIX offers an application-aware feature called a fixup protocol to enable the PIX to respond to the needs of complex mutlichannel applications by monitoring their control channels and dynamically opening and closing ports as needed by the protocol being monitored.

• The PIX is able to securely handle the popular RTSP and H.323 multimedia protocols.

• The PIX also features attack guards to mitigate threats to e-mail servers, DNS responses, fragmentation attacks, and certain types of DoS attacks.

Review Questions

To test what you have learned in this chapter, answer the following questions and then refer to Appendix F for the answers.