Cisco PIX: Advanced Features and Attack Guards

This chapter is from the book

Cisco Secure PIX Firewalls

Learn More Buy

This chapter is from the book

This chapter is from the book 

Cisco Secure PIX Firewalls

Learn More Buy

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

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

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

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

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

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