Attack Guards

Attack Guards

Attack guards enable the PIX firewall to monitor and reject requests or messages sent to commonly used applications or protocols. These requests and messages have been discovered and identified by hackers as a potential means to cause some form of harm to a computer or network. Over the life of the Internet, hackers have tended to focus on applications and protocols that have been readily accepted by the public; if a hacker can find a security hole or possible weakness in a widely used protocol or application, he could have the power to compromise several other systems across the Internet. For example, if a hacker found a security hole in a basic email request, he could exploit that hole on not one but thousands of servers.

Several attack guards are provided on the PIX firewall that help prevent hackers from taking advantage of known security holes. Although the guards use different commands to enable and disable them, they all help protect your environment from malicious attacks.

Table 9.1 lists the attack guards covered in this chapter and the commands that enable them.

Table 9.1. Attack Guards and Commands

Guard	Command
DNS Guard	None; it's enabled by default and cannot be turned off.
Mail Guard	Use the fixup protocol smtp 25 command.
Fragmentation Guard	Use the sysopt security fragguard command.
Syn Guard	Use the max connections and embryonic connections parameters of the static and nat commands.
AAA Floodguard	Use the floodguard enable command.

DNS Guard

Clients send UDP requests to resolve names , such as www.examcram.com , to an IP address before actually traveling to the Web site. This is called domain name resolution and is performed on domain name service (DNS) servers. These DNS servers maintain zones of name spaces that contain the actual name-to-IP-address mappings for the computers the client is looking for. A client might send out several UDP requests to resolve one name. Recall that with UDP traffic, the PIX uses an idle timer to monitor whether there is traffic passing between two computers. If the timer expires before any traffic has passed, the connection is assumed to be ended and the connection slot entry is removed from the connection table. Because DNS requests use UDP, a dynamic opening is created in the PIX firewall for 2 minutes to allow the return UDP traffic. If a response from a DNS server is received in 1 second, the opening created normally doesn't close until the 2-minute idle timer has expired . This leaves an open hole through which hackers can send attacks using a method called hijacking .

DNS Guard prevents DoS and UDP session hijacking by closing the UDP port after the first received DNS response.

The DNS Guard feature in the PIX firewall helps prevent hijacking by closing the dynamically opened port immediately after the first DNS response.

The DNS Guard feature is enabled by default and cannot be disabled.

Mail Guard

The Mail Guard feature is used to protect Simple Mail Transfer Protocol (SMTP) servers from known potentially harmful security problems. The guard performs application inspection using fixup protocols as discussed in Chapter 8, "Advanced Protocol Handling and PIX Firewall Features."

The fixup protocol smtp command provides a function known as Mail Guard which inspects SMTP traffic and allows only the seven commands defined in RFC 821 section 4.5.1 to pass. These commands are DATA , HELO , MAIL , NOOP , QUIT , RCPT , and RSET . All other commands result in a 500 command unrecognized response to the client and a discarding of the packet before the SMTP server ever receives it.

By default, fixup protocol smtp command is enabled for port 25. The commands shown here display how to enable and disable this guard using the fixup protocol commands:

 pixfirewall(config)# fixup protocol smtp 25 

or

 pixfirewall(config)# no fixup protocol smtp 25 

If the SMTP Mail Guard is turned off or disabled, hackers can send attachments to your email servers with unsecure email commands.

Fragmentation Guard

One form of attack committed by hackers uses packets that are broken down into hundreds and thousands of IP fragments. These fragments , when assembled , can amount to absolutely nothing or be harmless. More seriously, they can reassemble into a packet that causes another attack. The fragmented packets require resources to assemble back together and can cause a DoS if too many of them are allowed to reach the targeted devices.

The PIX firewall provides a guard against receiving too many fragmented packets by following the RFC 1858 recommendation. The guard allows only 100 fragments per internal destination host per second. Also, the guard expects to receive the first fragment before receiving other fragments. For example, if the middle fragment is received first, the packets are dropped.

To configure the Frag Guard, a system option command, sysopt , is necessary. This guard is disabled by default but can be enabled by using the following command:

 pixfirewall(config)#sysopt security fragguard 

The show sysopt command displays a list of all the system options configured. The following example displays an output of the default system options on a PIX with the Frag Guard enabled:

 pixfirewall(config)# show sysopt sysopt security fragguard no sysopt connection timewait sysopt connection tcpmss 1380 sysopt connection tcpmss minimum 0 no sysopt nodnsalias inbound no sysopt nodnsalias outbound no sysopt radius ignore-secret no sysopt uauth allow-http-cache no sysopt connection permit-ipsec no sysopt connection permit-pptp no sysopt connection permit-l2tp no sysopt ipsec pl-compatible no sysopt route dnat 

SYN Floodguard

The SYN Floodguard protects hosts from TCP SYN attacks. TCP requires a three-way handshake to make a connection; therefore, hackers can exploit this technology by sending hundreds or thousands of SYN requests with no intention of ever responding to them. For example, when a host receives a SYN request, it responds with a SYN/ACK. Then, the host waits for a final acknowledgement from the initiating host. If that initiating host (the hacker) never responds with the final ACK, the internal host is left tied up waiting for the return ACK. In the end, the internal host could be left hanging with thousands of half-open connections ”commonly called embryonic connections ”which could cause a DoS attack on the host by consuming all available memory resources for each connection.

The PIX firewall implements protection against TCP SYN attacks with two main parameters at the end of the static and nat commands. These parameters are max connections and embryonic limit . The following are the static and nat commands with these parameters:

 Pixfirewall(config)# [no] static [(internal_if_name, external_if_name)]                {<global_ip>interface} <local_ip> [dns] [netmask <mask>]                [<  max_conns  > [<  emb_limit  > [<norandomseq>]]] Pixfirewall(config)# [no] nat [(<if_name>)] <nat_id> <local_ip> [<mask>                [dns] [outside] [<  max_conns  > [  emb_limit  >                 [<norandomseq>]]]] 

The maximum number of connections defines the number of connections allowed to a host. If the number is exceeded, all future connections above this number are dropped. A value of states that an unlimited number of connections is allowed.

The embryonic connections parameter dictates not the number of connections, but the number of half-open connections allowed to an internal host. If a host reaches this embryonic limit, the PIX performs a function called TCP intercept.

TCP intercept doesn't actually send the three-way handshake to the internal host, nor does it absolutely block the request. Instead, it performs a special trick on behalf of the internal host. The PIX performs the three-way handshake with the external host in an attempt to determine whether the external host's intentions are genuine . If the three-way handshake turns out to be successful and not a dead embryonic connection, the PIX contacts the internal host to bind it with the external host, thus establishing a valid connection. If the connection turns out to be a dead embryonic connection, nothing is lost; the PIX drops it and the internal host was never actually bothered with the request.

Embryonic connections are half-open three-way handshake connections that could be left open intentionally by a hacker. If the embryonic limit is reached, TCP intercept on the PIX handles any new handshakes until they are proven to be valid requests.

The following is an example of setting the maximum number of connections to 500 and the maximum number of embryonic connections to 400. This would enable the host to receive only 400 embryonic connections before TCP intercept would start to be performed by the PIX:

 Pixfirewall(config)# static (inside, outside) 169.254.8.1 192.168.1.11                 netmask 255.255.255.255 500 400 

The embryonic limit should be set a little lower than what the internal server can actually handle so you never overload the internal servers.

AAA floodguard

The PIX can use triple-A services known as AAA to authenticate, authorize, and accounting. AAA is discussed in more detail in later chapters. AAA is a way to authenticate and authorize user access across the firewall. However, it provides an avenue for hackers to attack a system. If a hacker tries to overwhelm the system with too many authentication requests, a DoS attack on the PIX could occur.

The floodguard command is used to automatically reclaim PIX resources from other services to prevent DoS attacks on user authentications. The PIX monitors the uauth connections. If there are too many for it to handle, it drops other resources in an attempt to maintain all the uauth connections. This list displays the order in which the PIX drops or shuts down the four resources:

1. Timewait

2. FinWait

3. Embryonic

4. Idle

By default, the floodguard command is enabled. This example displays the floodguard enable and show commands:

 pixfirewall(config)# floodguard enable pixfirewall(config)# pixfirewall(config)# show flood floodguard enable 

The AAA floodguard is sometimes called flood defender by Cisco.