Denial of Service
This section of SmartDefense deals with some common Denial of Service (DoS) attacks that are used to crash the target machine. These particular attacks are able to crash systems by sending illegal packets (packets that do not conform to the RFC standard for the specific protocol) that the receiving system is unable to process correctly.
There is very little to configure in this section (see Figure 11.6); your only decision is which attacks you want SmartDefense to watch for.You can disable checking for any individual attack by removing the check mark next to the attack name. For the attacks that you do want to defend against, you have the option of selecting what action should be taken when an offending packet is detected.
Figure 11.6 Denial of Service Category Settings
If, in your environment, you are constantly under a range of attacks and you do not want to be alerted every time the attack happens, you can use the Accumulate successive events feature available on the main Denial of Service category menu, which is also shown in Figure 11.6. If you select the Accumulate successive events option, you will need to select the alert you would like to receive when a certain threshold of events has been reached. There is also an Advanced button where you select how many events will trigger the selected action. The settings here are exactly the same as the ones available for the other attacks under the Successive Events category in the configuration tree, and these advanced settings are covered in the "Successive Events" section.
Tools & Traps
Review of Alerts
All of the actions available for use in SmartDefense (some are shown in Figure 11.6) are user configurable. If you want to change the parameters for a specific alert, you do so in the global properties of your security policy under Logs and Alerts | Alert Commands.
You need to configure most of the alerts before you can do anything useful with them. FireWall-1 contains an internal_sendmail command that you can use to generate SMTP mail messages and send them through a designated SMTP server, and an internal_snmp_trap command that generates and sends an SNMP trap message to the configured destination (by default, local host). These scripts are only accessible from within FireWall-1, and cannot be accessed from the command line of the management server or enforcement point.
You can configure the internal_sendmail command with additional parameters to allow the mail to be properly formatted for transit through your network. Many mail servers are configured to reject messages with a blank sender field, or they will only permit mail from specific e-mail addresses. These options are configured by adding additional tags to the internal_sendmail command. The format of this command is as follows:
![tmp9-55_thumb[2]](http://what-when-how.com/wp-content/uploads/2012/03/tmp955_thumb2.jpg "tmp9-55_thumb[2]")
Here is a description of each option in this command string:
■ mail_server The IP address or hostname of your SMTP gateway that will be forwarding the generated e-mail message to the proper destination. This option is required, because internal_ sendmail does not perform the DNS lookups to deliver the SMTP message itself.
■ sender_address The e-mail address that will be listed as the sender of the e-mail message. This option is not required, but you can use it if your SMTP gateway requires a valid e-mail address before relaying SMTP messages, or if you want firewall messages sent from a certain e-mail address.
■ subject The subject message that you want in the generated e-mail message. The subject cannot contain any spaces, unless you enclose the entire subject in quotation marks, such as "Firewall Alert Message".
■ recipient_address The e-mail address that the e-mail message will be sent to. You must define at least one recipient (otherwise, what is the point of sending an e-mail?), and you can separate multiple e-mail address with spaces.
The body of the e-mail message is determined by FireWall-1 depending on what alert triggered the action. This cannot be changed, as the only configurable options available are used to facilitate proper delivery of the e-mail alert messages.
Teardrop
In the case that an IP datagram is larger than the maximum allowed packet size in a network, the packet can be fragmented into smaller pieces so it can pass through that network. Within the IP protocol header is a flag that specifies that more fragments are coming, and a field that contains an offset value.The offset value informs the receiving device at what position in the data stream to place the data in packet. The Teardrop attack exploits this feature of the IP protocol by sending packet fragments that overlap with each other. This is done by setting the offset value to something closer to the beginning of the packet than where the previous packet ended, meaning the server thinks there are two different sets of data that belong in the same exact place in the data stream. This condition should not occur under normal circumstances, and many operating systems were unable to handle the overlapping fragments, which caused the machine to crash.
Enabling this option does not provide any extra protection against this attack because FireWall-1 already does strict sanity checking of fragmented packets (which is covered in the next section). Illegal packets will automatically be dropped, and a fragmentation error log entry will be created. Even though you are already protected from this attack, it was added to SmartDefense so that you can specify a different action for the Teardrop attack than for other fragmentation errors. For example, you may want to receive e-mail alerts when someone has launched this attack against you, but do not want to receive an e-mail for every fragmentation error that is encountered.
Ping of Death
The Ping of Death is another Denial of Service attack that functions by breaking the rules defined for an IP packet.This particular attack consists of a machine sending an ICMP echo request that is larger than the maximum IP datagram size.This can be accomplished by sending IP fragments to the destination machine that, when combined, add up to more that 65,535 bytes. As the fragments are being reassembled into memory, packet buffer will overflow, which can cause unpredictable results ranging from no effect to a system crash.
As with the Teardrop DoS attack, this attack will be prevented regardless of how you configure this option, but you have the ability to specify a different action for this specific attack than when other packet sanity checks fail.
LAND
The LAND Denial of Service attack confuses the target machine by sending a spoofed TCP packet with the SYN flag set, and the source and destination address and port numbers are exactly the same. The target machine will interpret this packet as a TCP session that is being initiated from itself. At the time that this vulnerability was discovered, most operating systems did not know how to handle this condition and would crash or reboot.
Although this attack will normally be countered by the anti-spoofing configuration on your gateways, you can still defend against this DoS attack even if you have decided not to perform anti-spoofing at your enforcement points.
IP and ICMP
This section of SmartDefense deals with IP- and ICMP-based attacks and requires even less configuration than the Denial of Service category.This is because most of these options cannot be disabled.You will notice that the check boxes next to the Fragment Sanity Check and the Packet Sanity check are grayed out and locked in the "checked" position. There is one available option under Packet Sanity called Enable relaxed UDP length verification, which is shown in Figure 11.7.This option will prevent the enforcement point from imposing such strict checks on the length field in the UDP packet header. This option may be needed because not all applications calculate the UDP length field in the same manner, and the firewall will drop some of these packets because it thinks the length is incorrect. Removing the check mark from this option will offer a little more protection, but if you use applications that don’t calculate the length field correctly (from FireWall-1′s perspective), you will need to leave this option enabled.
Figure 11.7 IP and ICMP Options
The other configurable option in the IP and ICMP Configuration Tree is Max Ping Size.To configure this option, select Max Ping Size in the configuration tree, and modify the Ping Size field to specify the maximum number of bytes that will be allowed in a ping.
Fragment Sanity Check
This feature of SmartDefense cannot be disabled, but is listed here to let you decide how you want the firewall to respond to problems detected by the strict fragment sanity check that is performed. Some firewalls and IDS systems will not detect an attack if it is fragmented into smaller pieces. This happens because each packet is inspected individually as it passes through the device, and a fragment of the attacker’s data won’t be recognized as an attack.To avoid this problem, FireWall-1 collects all fragments and checks the reassembled packet before passing the information to the destination.
Packet Sanity
Again, this is an option that cannot be disabled, and it’s only in SmartDefense so that you can choose what action should be taken when a packet fails this check. This is a sanity check on all information in the packet at layer 3 and layer 4.This sanity check looks for a wide range of problems in the packet structure, such as the following:
■ Invalid packet length
■ Invalid header length
■ Improper TCP flags
■ Use of IP options
If any information in the packet is inconsistent with the state of the communication or the data within the packet, the firewall will drop the packet. This check also prevents the Options section of the IP header from being used. IP options can be configured to do such things as supply routing information telling intermediate routing devices how the packet should be routed, or to record route information as the packet traverses the network. These options can be useful tools for troubleshooting, but they also give an attacker the ability to bypass security measures, so they are not allowed through the enforcement points.
Max Ping Size
This feature of SmartDefense is designed to drop echo requests if they are larger than the specified amount in this section.You can set the maximum byte size that you want to allow from an ICMP echo request. If an echo request is larger than the byte count configured in this section, the packet will be dropped and the specified action will be taken. When choosing what action you want performed, keep in mind that the action will be taken for each ICMP packet that is dropped. This check is performed before the packet is checked against the rule base, so you will receive alerts for pings that are too big, even if no ICMP is allowed through the gateway.
This feature was not designed to combat the Ping of Death attack, which creates an illegal size packet, but instead limits the amount of data that can be sent in a correctly sized echo request. Large echo requests are not usually needed for troubleshooting and can easily cause congestion on links that are already near capacity. For this reason, you may want to keep your allowed echo request size low.
Warning
The default setting for Max Ping Size is 64 bytes. If your security policy allows pings into your network, keep in mind that this option, at its default setting, will prevent certain devices from being able to ping. For example, Cisco routers use a default ping size of 100 bytes, so while a Microsoft Windows workstation will be able to ping through your enforcement point, the Cisco router would not.
Keep in mind when you are choosing your max ping size and action method that every ping larger than your threshold will be considered an attack. For example, if you configure SmartDefense to send you an e-mail if someone exceeds the max ping size, you will receive an e-mail for each individual oversized ping that is received; if you receive 1,000 oversized pings, you will receive 1,000 e-mails.
TCP
This section of SmartDefense contains categories of attacks that attempt to exploit the TCP protocol, such as out of sequence packets, invalid session requests and excessively small fragment sizes. No options are available for the TCP category itself; all configuration is on the individual object within the TCP tree.
