Guards

The various guards on the PIX are designed to protect against specific types of network attacks. These guards act as an additional layer of defense to protect the network on top of the basic PIX Firewall features already enabled on the firewall.

Basically, four special features called guards are available in PIX:

Flood Guard

This feature is used to mitigate the danger of a denial of service (DoS) attack using AAA login attempts. This feature limits the number of failed AAA authentication attempts to make such attacks more difficult to stage. This feature is on by default.

Frag Guard

This feature allows control over the PIX's tolerance and treatment of fragmented packets. PIX restricts the number of fragments that are headed for a host protected by the PIX to 100 full fragments per second. Also, by default the PIX code does not allow an IP packet to be fragmented into more than 24 fragments. In addition, PIX restricts fragments that arrive without a proper header from being forwarded to hosts behind it. These measures allow fragmentation attacks in which the attacker sends a large number of fragments to an end host to be avoided. These attacks are very resource-consumptive, because the end host has to allocate a significant amount of resources to reassembling the packets, especially if they are out of sequence.

IP fragments also do not contain the TCP or UDP port information that PIX needs to perform its various PAT functions. Consequently, PIX has no way to switch a fragmented packet through it, because it does not know which xlate to use to switch it. Also, PIX cannot create an xlate for packets going from high-security to low-security interfaces, because there is no port information to work from.

An obvious solution is to reassemble all pertinent IP fragments into an IP packet and then switch it. However, full reassembly is expensive in term of buffer space reservation, which needs to be done to put the fragments together. Buffer space needs to be allocated to recreate the original packet after all the fragments have arrived and are ready to be coalesced. This buffer space is in addition to the buffer space needed to simply store the fragments as they arrive. The firewall has to wait for the last fragment to arrive.

To minimize buffer preallocation, a reassembly mechanism known as virtual reassembly is used. With virtual reassembly, fragments are not combined, so no buffer preallocation is needed. However, to provide the benefits of full reassembly, each fragment set is verified for integrity, such as the header information and various fragment attacks, and is tagged with the transport header information. In this manner, without allocating any significant buffer resources, the fragments are switched through the PIX port address translation mechanism based on the tagged information. It is not a requirement for the first fragment containing the port information to arrive first on the PIX Firewall. However, the PIX Firewall does not forward the packet to the next-hop box until all the packet's fragments have arrived at it and have been verified and tagged with the transport information contained in the initial fragment.

NOTE ICMP packets are still reassembled in full rather than being virtually reassembled.

PIX also allows the use of the fragment command to allow various parameters for fragmentation to be configured. This is especially useful in environments where fragmentation for legitimate reasons is very likely. An example of such an environment is an NFS environment. See the PIX command reference for the 6.1 code for details on this command.

PIX Firewall versions before 5.1.4 required that the fragments be received in sequence, with the fragment containing the header arriving first. In Linux-based environments, this behavior can be catastrophic. Therefore, it should be disabled pending a review of the operating conditions of the servers and applications. The Linux OS, if it must fragment packets, has a habit of delivering them in reverse order. This is perfectly acceptable in TCP/IP, but the PIX with frag guard enabled used to drop any fragmented packets that arrived out of order, effectively dropping all fragmented traffic in a Linux environment. Similar problems occurred if PIX Firewall was used as a tunnel for FDDI packets between routers. Consequently, this requirement was removed from 5.1.4 code onward.

Mail Guard

The mail guard feature is used to make sure that only a minimal set of seven SMTP commands can be sent to a mail server sitting behind the PIX Firewall. This helps prevent attacks on the mail server. The seven commands from RFC 821 are HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT. The PIX Firewall intercepts the rest of the commands, such as KILL and WIZ, and responds with an OK. This lulls an attacker using these commands into believing that the mail server is receiving these commands and acknowledging them. You enable this feature using the fixup protocol smtp 25 command in the newer PIX versions. The use of this command also alleviates the need for having a mail relay on the edge of the network.

Although this PIX feature is very useful in stopping certain types of SMTP attacks launched using a set of commands other than the seven just listed, this behavior can be very disruptive for certain mail server environments such as ones that use Microsoft Exchange, which uses ESMTP. Therefore, you should use this PIX feature with care and turn it off if absolutely necessary.

DNS Guard

DNS guard is a feature used in the PIX to stop DNS-based DoS attacks. DNS DoS attacks occur when an attacker poses as a DNS server to which a DNS resolution request has been sent and then floods the user requesting the DNS resolution with DNS responses. PIX mitigates these types of attacks by doing the following:

• PIX does not allow more than one DNS response from any DNS server.

• If a client queries more than one DNS server, as soon as PIX sees one of them respond to a DNS request, it closes the hole it opened (the access list hole plus the xlate) to allow responses from the other DNS servers.

0 0

Post a comment