This section contains the attacks that exploit vulnerabilities in the HTTP protocol. Most of these features are designed to filter malformed requests that usually are not seen in a valid HTTP stream by checking for excessive field lengths and abnormal characters. In addition, Check Point has added a new feature that scans for HTTP worms and prevents them from reaching your servers.
One of the newer and more devastating variety of attacks to come about recently is HTTP worms, such as Code Red and Nimda. A HTTP worm is a virus that self-propagates, among other ways, though HTTP protocol to infect other Web servers.These worms exploit vulnerabilities in Web servers that allow the worm to load itself into the running memory of the target machine. Once in memory, it will start scanning other IP addresses in an attempt to spread onto more machines. Usually just the traffic load of thousands of machines scanning for vulnerable hosts is enough to slow down Internet traffic across the globe, not even considering other damages the payload can cause. Because these worms communicate over standard HTTP traffic streams (TCP port 80) you cannot protect yourself against these attacks with rules in your rule base, because there is no way to differentiate valid Web traffic and the worm at layer 4 or below.
To combat these worms, Check Point has designed a scanning process that reads the HTTP protocol data and searches for specific patterns before deciding to allow the packet.The worm catcher comes with some predefined worm definitions and is updated with new patterns when performing a SmartDefense update. In addition, you can also manually add new patterns using standard regular expressions. This topic gives only brief coverage on writing regular expressions, because an entire topic could be (and is) dedicated to the topic.
Tools and Traps
Regular Expressions are an extremely flexible method of performing pattern matching and are implemented in many tools and programming languages. This section is meant to be a (very) brief overview of regular expressions. If you would like to learn more, you can find a multitude of introduction pages with a simple Web search.
In Regular Expressions, most characters will match themselves, meaning the expression "abc" will only match the exact phrase "abc". Some characters, however, have special purposes when matching characters. For example, the * character is a wildcard used to match any number of the preceding character. If you want to match the actual character instead of its special meaning, you must precede the character with a backslash ( \ ), so your expression would contain \* if you wanted to match the asterisk character, and \\ if you wanted to match a backslash. Here is a list of some special characters:
The use of regular expressions makes the worm catcher an extremely powerful tool. The ability to manually add new worm definitions means that you can filter HTTP packets based on any data pattern that you can describe with a regular expression.You will also be able to protect yourself against future HTTP worms without having purchased the SmartDefense subscription service, if you don’t mind taking the time to research the infectious data stream and writing a regular expression to describe it.
The worm catcher is an independent process from the HTTP Security Server, so you can use the feature without invoking the HTTP Security Server on connections.
The worm catcher is a kernel-level process and should not cause any significant performance impacts when enabled. Even so, thorough testing is recommended before enabling the feature in a production environment.
First, let’s take a look at the attack signature for the Code Red worm. Code Red spread by overflowing an unchecked buffer that could be accessed by calling an Internet Data Administration (.ida) file. Data can be passed to an .ida file by following the file with a question mark (?) and then the data you wish to pass to the server. For example, the HTTP header "GET /default.ida?abcdefg" will send "abcdefg" to the default.ida script.
The pattern that is used to prevent the Code Red worm in the worm catcher is "\.ida\?", which is shown in Figure 11.19. Because both "." and "?" are special characters that have other meanings in a regular expression, they must be preceded with the \ character to let the worm catcher know that you want to match the actual characters.This regular expression looks for the string ".ida?" and will drop any requests with this pattern. Notice that this will prevent any files with the .ida extension from being called, so if you use these files, you will want to disable this worm check and make sure that your Web server is patched against this vulnerability.You could also try to rewrite the regular expression to look for a more specific match that will not trigger every time someone accesses your Web site.
Figure 11.19 General HTTP Worm Catcher
The signature for the Nimda worm tries to access either cmd.exe or root.exe through an HTTP request. In order to prevent a request with either "cmd.exe" or "root.exe" in the data stream, the logical OR operation ( | ) needs to be used.The regular expression for the Nimda worm is "(cmd\.exe)|(root\.exe)", as shown in Figure 11.19.The parentheses are control characters that group everything listed between them. The two sets are separated by the logical OR operation, and as mentioned in the last worm signature, the period character must be preceded by a backslash if you want to match a period (instead of any character). So, the regular expression is written to drop any HTTP request that contains "cmd.exe" or "root.exe" in the request.
As of FP3, when you enable the General HTTP Worm Catcher, all active connections through the firewall will be broken when you push policy.
HTTP Security Servers
The options in this section are a part of the HTTP security server and will only apply when the HTTP Security Server is invoked for a connection. As with the FTP Security Server, you can choose to apply these settings to all HTTP traffic (port 80 only), or only to connections that use HTTP resources.The additional settings in this configuration tree allow you to set limits on some of the HTTP protocol information that passes between client and server.
One section, shown in Figure 11.20, is dedicated to setting limits on the HTTP header sizes and URL lengths.These features are used as general protection against buffer overflows because you can prevent URLs and headers from being long enough to overflow unchecked buffers. When you type a URL into your Web browser, it will initiate a TCP session to the destination server and send the HTTP GET request along with some HTTP headers that describe what sorts of data types and encoding types that browser will accept, as well as send some other general information such as browser type. In return, the client will receive response headers that give additional information to the client, such as Web server software and the encoding and content type of the data that is being returned. As a general sanity check you can prevent excessively long URL requests and header lengths. In addition you can limit the number of headers that are sent by either the client or server. By default, the maximum number of headers is set to 500, which should be a sufficiently high number to identify an attack since most pages won’t return more than 10 headers. Also, the default settings prevent more than 2 kB of data in the URL request, but do not set any limits on how long each individual header can be. These settings are all configurable to allow you to define your own parameters for normal HTTP traffic.
Two other options that are available and enabled by default are called ASCII Only Request Headers and ASCII Only Response Headers. These two options will restrict the header data to contain only printable ASCII characters. Some buffer overflow attacks use the header fields to store the payload information that is supposed to be written to memory, and limiting the header fields to containing only ASCII characters will prevent binary code from being stored in the header fields. Although both of these options apply to the HTTP headers, they were separated into two separate options so you could enforce this check on the client’s request headers only, the server’s response headers only, or both request and response headers.
Figure 11.20 HTTP Format Sizes
SMTP Security Server
As with the other security servers, you have the option to use the security server for all SMTP traffic, or for only the SMTP resources defined in the rule base.
More than likely you do not want to enable the SMTP security server for all connections, because your enforcement point will act as an open relay to anyone on the Internet. This can cause your IP to get added to an open relay blacklist, which can prevent you from sending e-mail to domains that block SMTP traffic from sites on the blacklist. If you want to use the SMTP security server features, you should create a SMTP resource with *@mydomain.com in the Recipient field of the Match tab. You can then add this resource to the rules where you would like to use the SMTP security server.
There are two categories under the SMTP security server. SMTP Content deals with the content in the actual SMTP commands that are passed between a client and server.The Mail and Recipient Content category scans the SMTP data that is passed as the body of an e-mail message. These two categories are covered in more detail in the following sections.
The SMTP content category provides security options that attempt to identify attack attempts by watching the commands that are passed between client and server.
When the security server intercepts SMTP traffic passing through the firewall, it is basically acting as an SMTP relay.You have the option of making FireWall-1 add a "Received by" header to the body of the message when it relays mail by selecting the Add "received" header when forwarding mail option. If you uncheck this option, no additional lines will be added, although the next SMTP server’s received header will state that the e-mail was received from the enforcement point, instead of the previous SMTP server, so the SMTP security server will not be entirely transparent.
You can also set the SMTP Security Server to watch for "bad" SMTP commands. There are two different types of bad commands, from SmartDefense’s point of view, and you can define thresholds for both kinds of bad commands. One type of bad command are the ones that have no effect when they are used. Only a certain number of commands are needed to send an e-mail, such as MAIL FROM:, RCPT TO:, and DATA, and other commands, such as NOOP (No Operation), do nothing but keep the TCP session from timing out.You can configure a maximum number of "no effect" commands that are allowed before the session is terminated.
The other type of "bad" commands are those that are not known to the security server.The security server is aware of all RFC standard commands, so it is unlikely that another SMTP server will be sending illegal commands.The logic behind this feature is that if more than a small number of "no effect" or unknown commands are sent to the server, the e-mail is not likely being delivered by an SMTP daemon, but an attacker snooping around your server.These features should keep an attacker from snooping around too much, and they can create a log entry when the session is terminated.
All of the options discussed in this section are shown in Figure 11.21. Also, notice that there isn’t an Action field defined in this section, so your only choice is to log the dropped connections.You cannot send any other form of alert when this type of attack is detected.