The HTTP Security Server

Of all the Security Servers in FireWall-1, the HTTP Security Server is used most often. Because the HTTP Security Server can be used with both CVP and UFP, I will cover how to set up both types of Content Security.

The HTTP Security Server is enabled when the following situations are true.

• There is a line that permits in.ahttpd to start up in $FWDIR/conf/fwauthd.conf. This is normally present by default.

• A resource is used in your security policy or in a rule that involves User Authentication for HTTP.

Refer to Chapter 8 for information on authentication. Defining resources is first discussed in the Filtering HTTP without a UFP or CVP Server subsection. The proper line for the HTTP Security Server in $FWDIR/conf/fwauthd.conf should have no comment symbol (#) at the beginning of the line and should look like this:

80      fwssd        in.ahttpd       wait    0

The first argument is the port on which the HTTP Security Server runs (port 80). The second argument states that it uses the binary fwssd to run the Security Server. The third argument specifies which server it will be. In this case, it is the HTTP Security Server (i.e., in.ahttpd). The fourth argument, which is usually wait, is used to indicate one of two things: which port it listens on (if greater than or equal to zero) or how many instances of the server to run (if negative). I discuss the latter point in the Performance Tuning section later in this chapter. The only time you want the Security Server listening on a particular port is when users will use the firewall as a nontransparent proxy for HTTP. If this line is not present or is commented out, the HTTP Security Server will not run, and any process that relies on it will fail.

Filtering HTTP without a UFP or CVP Server

FireWall-1 has some rudimentary filtering features that can be used without a UFP or CVP server. These features should be used only for the most basic of filtering needs. Anything too complex should be done with a UFP or CVP server.

You can use these filtering features by creating URI resources. From SmartDashboard/Policy Editor, select Manage, then choose Resources or click on the icon in the objects tree, right-click on URI, and select New URI. Next, select New, and then choose URI. You are presented with the window shown in Figure 9.1.

You can set the following properties on the General tab.

Name: In this field, enter the name of the resource (must be unique).

Comment: Enter any information you like in this field.

Color: Select a color to represent the resource.

Use this resource to: This choice allows you to determine the resource's primary goal: logging URLs that users access (Optimize URL logging) or providing content security (Enforce URI capabilities, which also logs URLs that people access). The latter relies on the HTTP Security Server; the former operates directly in the kernel and thus is faster. In NG with Application Intelligence, this tab also presents the option Enhance UFP performance. This allows you to move UFP functions into the kernel module to increase performance but prevents you from using UFP caching (explained later in this chapter), CVP, or authentication. It also removes the ability to perform certain HTTP protocol checks, such as validating HTTP methods and content length.

Connection Methods: In this section of the tab you can specify when this resource is applied. Transparent means that the user will use the service normally, and FireWall-1 will transparently intercept the communication. Proxy means that this resource is applied when people specify the firewall as the proxy in their browser. Tunneling is used when FireWall-1 (defined as the proxy to the client's Web browser) cannot examine the content of the request, only the hostname and port number. An example of this is HTTPS. Only the hostname and port number are sent in cleartext; the rest of the content is encrypted. The hostname and port number are the only specifications that can be filtered on using the Tunneling connection method. If Tunneling is specified, all Content Security options in the URI specification are disabled.

URI Match Specification Type: This option specifies how you define this resource: as type Wildcards, File (which requires that you create a URI file), or UFP. The first two methods are discussed later in this subsection. The last method is discussed in the UFP with the HTTP Security Server subsection.

Exception Track: Here you can specify how to log anything this resource acts upon.

After setting these properties, you must then specify which URLs to filter by clicking on the Match tab. Figure 9.2 shows how it looks when the Wildcards option is selected on the General tab.

You can configure the following parameters.

Schemes: This parameter matches the different protocols you can use through the HTTP Security Server. It is relevant only if the firewall is specified as the proxy for these protocols. Normally, it is safe to just select the http checkbox.

Methods: This parameter specifies methods for HTTP. GET is used when you request a particular page (or element on a page); POST is used when sending data to a Web site (filling out forms and so on); HEAD is usually used by caching servers and Web browsers to determine whether or not an element has changed (and thus to decide whether or not to download it); PUT is a less commonly used method for uploading files via HTTP. If another method is required, you can specify it in the Other field. To allow any method, use * in the Other field.

Host, Path, Query: These fields break down the various parts of the URL into filterable components. For example, in the URL http://www.phoneboy.com/search/wwwwais/wwwwais.cgi?keywords=content+security, the host part of the URL is www.phoneboy.com, the path is /search/wwwwais/wwwwais.cgi, and the query is basically everything else (usually for CGI scripts such as search engines). You can filter on any part of the URL.

If you selected the File option under URI Match Specification Type on the General tab to create a resource of type File (i.e., to filter URIs based on a file) rather than Wildcards, the Match tab shown in Figure 9.3 appears.

A URI specification file is a series of lines in the following format:

ip-addr    /path    0

ip-addr is the IP address of the Web server you want to match against. For sites that resolve to multiple IP addresses, you need to list each one specifically. You can also use fully qualified domain names in this file, though it requires that DNS be enabled and configured on the firewall. /path is optional. If you want to restrict a certain subdirectory of a site (or a certain URL), enter it here. 0 (or any hexadecimal number) is required at the end of each line.

Here is a sample file:

10.0.146.201 0
10.251.29.12 0
10.91.182.100 /support.d 0
10.184.151.198 /support 0

There must also be a blank line at the end of the file. Once you have created this file, click the Import button and specify the path to this file on your SmartConsole system. It will then be uploaded to your management console.

You then need to specify the action to take if this resource matches, so click the Action tab (see Figure 9.4).

On this tab, you can configure the following parameters.

Replacement URI: If the rulebase action this resource is used in is dropped or rejected, the user should be redirected to this URL. This could, for instance, be a policy document telling people the rules and regulations of Web usage.

HTML Weeding: In this section of the tab you can select which tags to strip out if the action is accepted. The HTTP Security Server does not really strip them but rather comments out the offending HTML so that the tags are not active when downloaded. A user could theoretically save the HTML and reload a modified, local copy.

Block JAVA Code: FireWall-1 can block the download of any Java code if you select this checkbox. It does not match JavaScript, which is done with the HTML Weeding option Strip Script Tags.

Figure 9.5 shows the CVP tab, where you can specify whether or not this resource will enforce virus scanning and the parameters that control how it is done.

This tab includes the following options.

Use CVP: Enable the use of CVP in this resource. If this property is unchecked, all other fields on this screen will be greyed out.

CVP server: Select an OPSEC Application server that has CVP in it. I will show how these are defined in the CVP with the HTTP Security Server subsection.

CVP server is allowed to modify content: This allows the CVP server to attempt to disinfect a file that has a virus. If this option is not checked and the content is determined to have a virus, the communication will be rejected.

Send HTTP Headers/requests to CVP server: These options allow the CVP server to make security or filtering decisions based on data contained in the HTTP request headers.

Send only unsafe file types to CVP server: This option was introduced in NG with Application Intelligence. Normally, FireWall-1 sends all traffic through the CVP server. If this option is enabled, FireWall-1 inspects the content of the traffic to determine whether it is a kind of file that may contain a virus?FireWall-1 does not trust file extensions or MIME types for these checks. Graphic or movie files are considered "safe" and thus are not sent to the CVP server. Executable and Microsoft Office documents are sent to the CVP server for virus scanning.

Return data after content is approved: Data is sent to the CVP server for approval. Only after all the data has been received and scanned is it sent back from the CVP server. The problem with this option is that with large files on slow links, this can cause the client connection with the server to take a very long time before any data is returned. The client may time out in this case.

Return data before content is approved: This allows the CVP server to scan and correct content "on the fly." This option solves the problem of transferring large files over slow links, but it may mean the client receives part of a file that the CVP server will ultimately reject because, for instance, it finds a virus it cannot disinfect.

Figure 9.6 shows the SOAP tab, which is relevant only when using Wildcard URI types and NG FP3 and later. This allows you to filter and/or log Simple Object Access Protocol (SOAP) requests over HTTP. You may either allow all SOAP requests or filter for specific ones.

The schemes you can select are defined in files in $FWDIR/conf/XML on the management console. There are several files in this directory (scheme1 through scheme10) where you can define specific sets of allowed SOAP requests. The files must contain entries of the following format:

namespace       method

For example:

http://tempuri.org/message/ EchoString
http://tempuri.org/message/ SubtractNumbers

You can then use this resource in a rule, as shown in Figure 9.7.

UFP with the HTTP Security Server

The UFP server is a third-party application that should be run on a different platform from the firewall. A variety of UFP servers available for FireWall-1 run on Windows or Solaris. I will not cover their setup in this book. It is sufficient to say that once they are set up correctly, FireWall-1 can then communicate with them on TCP port 18182.

To configure UFP to work with FireWall-1 and the HTTP Security Server, perform the following steps.

Let's assume you have created a workstation object named babyike where the UFP server is installed. In SmartDashboard/Policy Editor, do one of the following.

• Select Manage and then choose OPSEC Applications.

• Click on the following icon in the objects tree: . Then right-click on OPSEC Application, and select New OPSEC Application.

Figure 9.8 shows the resulting screen.

The General tab contains the following options.

Name: Enter the name of the resource (must be unique).

Comment: In this field, you can add a note about this OPSEC Application server.

Color: Select whichever color you would like.

Host: This is the workstation object on which the UFP server is running.

Application properties: In this section of the tab, select the vendor of the application, the product, and the version as appropriate. If your vendor isn't listed, you may want to select User defined. In this case, make sure that UFP is checked under Server Entities.

Secure Internal Communication: In FireWall-1 NG FP1 and later, SIC is used to authenticate communications with third-party OPSEC applications. This is where you configure the one-time password used during the initial certificate exchange. Additional steps will need to be performed in your OPSEC application to perform this exchange.

Figure 9.9 shows the UFP properties described below.

Service: This field specifies the service used to communicate with this server. Normally, this should be FW1_ufp (TCP port 18182).

Dictionary: The information in this section is used to validate the connection to your UFP server. Categories are shown if a connection can be successfully established. You can choose the actual categories that are allowed or disallowed in the individual URI resource.

Use early versions compatibility mode: In FireWall-1 4.1, authentication between the UFP server and the firewall module uses something other than SIC. In these cases, check this option and select the appropriate authentication method.

After setting these properties, you can create your URI resource. For this example, the resource is called uri-filter. The URI resource needs to be of type UFP.

Next, go to the Match tab, select the UFP Server websense, and select the Blocked category, as shown in Figure 9.10.

This tab contains the following options.

UFP server: Specify the OPSEC Application object you created that defines the UFP server.

UFP caching control: This option will be explained in the UFP Caching subsection later in this chapter.

Categories: Specify the categories on the UFP server to which this URI will apply. For Websense servers, this should be Blocked.

Ignore UFP server after connection failure: FireWall-1 will continually connect to the UFP server. If for some reason the UFP server fails to respond in a timely fashion, this option allows you to specify whether to "fail closed" (i.e., keep trying to connect to the UFP server until successful, meanwhile blocking all HTTP traffic) or "fail open" (i.e., after the specified amount of time, ignore the UFP server and do not categorize the traffic). You can specify the number of failures permitted and the amount of time between each communication attempt before it ignores the UFP server.

If you wanted to, you could go to the Action tab and specify other filtering options, but instead, for this example, let's move on to create the rules to block Web sites that Websense has been configured to block (see Figure 9.11).

The first rule is created by using the Add with Resource option for the Service column, selecting http, and then selecting uri-filter. This rule catches all Websense-filtered URLs. The second rule permits URLs that are not filtered by Websense. This second rule is necessary to allow access to all URLs except those prohibited by Websense.

CVP with the HTTP Security Server

The CVP server is a third-party application that should be run on a different platform from the firewall. A variety of CVP servers available for FireWall-1 run on Windows or Solaris. I will not attempt to cover their setup in this book. It is sufficient to say that once they are set up correctly, FireWall-1 can then communicate with them on TCP port 18181.

To configure CVP to work with FireWall-1 and the HTTP Security Server, perform the following steps.

As in the UFP example above, let's assume you have created a workstation object named babyike where the CVP server is installed. In SmartDashboard/Policy Editor, do one of the following.

• Select Manage and then choose OPSEC Applications.

• Click on the following icon in the objects tree: . Then right-click on OPSEC Application, and select New OPSEC Application.

A screen similar to Figure 9.8 (shown earlier) appears. For this example, the OPSEC Application object is named f-secure-cvp.

Since a CVP server is being defined, choose the relevant options for CVP?choose the correct CVP server information or select User defined in the Vendor field, and make sure CVP is checked under Server Entities. Also define SIC, if relevant.

Figure 9.12 shows the CVP Options tab.

The properties are listed below.

Service: Select the service used to communicate with this server. Normally, this should be FW1_cvp (TCP port 18181).

Use early versions compatibility mode: In FireWall-1 4.1, authentication between the CVP server and the firewall module uses something other than SIC. In these cases, check this option and select the appropriate authentication method.

You then need to create a resource that performs CVP. Create a new resource called virusscan (see Figure 9.13), which matches all URIs and performs virus scanning.

The Match tab, shown in Figure 9.14, shows the settings used to make this resource match all URLs.

The CVP tab, shown in Figure 9.15, is where you define which CVP resource to apply. You then need to add this resource to a rule. You can combine it with the UFP example so that both URLs and content are filtered (see Figure 9.16).

Frequently Asked Questions about the HTTP Security Server

To keep all the information about a particular Security Server together, I provide a corresponding FAQs subsection at the end of each Security Server section.

9.1 Can I Filter HTTP on Other Ports (e.g., Port 81)?

There are five steps necessary to enable filtering on other ports.

Creating the service is straightforward. Create a new service of type TCP. Set the Protocol Type to HTTP and the port as necessary (e.g., port 81). If you add a resource by right-clicking in the Service part of a rule, you can associate a resource with the new service you created (e.g., http81). If you filter with wildcard resources, you need to enter the host part of the URL as host:port. For example, to match all, instead of entering *, you need to type it as *:*. If you do not do this, your resource will fail. To reconfigure $FWDIR/conf/fwauthd.conf, you need to add a line to this file for each unusual port you want to filter on. For port 81, for instance, the line would read as follows:

81  fwssd    in.ahttpd    wait    0

Reinstall the security policy, and bounce the firewall after making these changes (cprestart).

9.2 Can the HTTP Security Server Forward Requests to a Caching Proxy Server?

Yes, but only if your clients are configured to use the firewall as their proxy server. Set the Use Next Proxy setting in your gateway object definition, Authentication frame.

9.3 Why Do I Get the Error "Request to Proxy Other Than Next Proxy Resource http://proxy.foo.com" When Filtering Traffic to a Proxy Server?

Set the Use Next Proxy setting in your gateway object definition, Authentication frame, to point at the proxy server. This setting only allows you to filter traffic to one HTTP proxy server.

9.4 How Do I Redirect People to a Usage Policy Page?

The assumption here is that end users are redirected to a policy page only when they try to access a site that is against the usage policy. You can take one of two approaches.

• Create a resource that matches the sites you do not want to allow access to. Use this resource in a rule as shown earlier in the chapter, setting the replacement URL accordingly in this resource.

• Create a resource that matches the sites you want to allow access to. If you want to then redirect users to a policy page when they try to load a page they are not allowed to access, use the matchall resource and set the replacement URL accordingly. If you want to allow users access to only the sites matched by the resource allowedsites and deny access to everything else (via a matchall resource), the rules would look like those shown in Figure 9.16.

NOTE!

If you use the replacement URL in conjunction with User Authentication and a user is redirected to a policy page, the user will get FireWall-1's Authentication Failed page with a link to the redirected page.

9.5 How Do I Prevent People from Downloading Files or Accessing Streaming Media via HTTP?

You can use the HTTP Security Server to deal with both of these issues. If you have CVP, you may be able to use the CVP server to screen out those MIME types. If you are not using a CVP server, you can do this with a wildcard URI. In the Path section of the Match tab, you can specify all file extensions that you do not want people to download.

• To block Real Audio/Real Video, enter *.{ ra,ram,rm,rv}.

• To block most downloads, enter *.{ exe,zip,com,bat,sit,tar,tgz,tar.gz,lha,rar,r0+}.

You would then create a rule that uses this resource and denies access to anything matching this resource. Place this rule before your other rules that permit HTTP.

WARNING!

Attempting to filter based on file extension or even MIME type is futile. There are plenty of ways to get around these filters by using different extensions or different MIME types, which are merely suggestions for how the file should be treated. In order to filter out all the files you don't want, you will likely filter some files that you do want (throwing the baby out with the bath water).

9.6 Can I Allow Certain Users to Download Files Provided They Authenticate?

In order for this to work correctly, all users need to authenticate, even to use normal HTTP. The rules to do this are shown in Figure 9.17.

Once a packet potentially matches a User Authentication rule?that is, the source, destination, and service match what is specified in the rule?the least restrictive rule in the rulebase is the one that will actually apply. Therefore, it is important to place the rule that denies access to downloads before the rule that allows everyone to use HTTP.

9.7 How Can I Set Up FireWall-1 to Support Content Security for Outbound HTTPS?

Due to the nature of HTTPS, it is possible to authenticate or provide Content Security for HTTPS only when the client specifies the firewall as the proxy for HTTPS. Some other steps must be performed as well.

First, ensure the following line exists in $FWDIR/conf/fwauthd.conf:

443   fwssd   in.ahttpd   wait   0

If this line does not exist or it is commented out, add/uncomment it, and bounce FireWall-1. Second, modify the predefined service HTTPS. Change the protocol type from None to http. You can then use HTTPS for authentication or Content Security as appropriate provided the client is configured to use the firewall as a proxy for HTTPS requests.

9.8 Can I Block the Use of KaZaA, Instant Messages, and Other Applications That Can Tunnel over HTTP?

These applications are difficult to filter because they can use legitimate HTTP requests. However, a closer inspection of these HTTP request headers reveals telltale traces of what kinds of applications they are. FireWall-1 NG FP3 and later have a way to filter this traffic by using the HTTP Security Server and some properties that you need to add manually to $FWDIR/conf/objects_5_0.C on the management console. (See FAQ 4.2 in Chapter 4 for caveats on editing this file.)

The following example shows patterns that block KaZaA and Gnutella. Several other patterns may also already exist in your objects_5_0.C file.

 (firewall_properties:
:fields (

   ...

       :http_header_detection (
              :http_detect_header_pattern_mode (true)
              :http_detect_header_pattern_log (alert)
               :http_header_names (
                      : (
                              :match_string (X-kazaa)
                              :regular_exp (X-Kazaa)
                        )
               )
               :http_header_names_values (
                      : (
                              :match_string (Server)
                              :regular_exp ([kK]a[zZ]a[aA])
                      )
                      : (
                              :match_string (Host)
                              :regular_exp ([kK]azaa)
                      )
                      : (
                              :match_string (User-Agent)
                              :regular_exp ([gG]nu)
                      )
                     )
)

The properties used in these patterns are described below.

http_detect_header_pattern_mode: This property determines whether or not header detection is enabled. By default, it is false. To enable header detection, set this property to true.

http_detect_header_pattern_log: This one determines what kind of log to generate when one of the defined patterns is detected. Valid values are none (log nothing), log (generate a log entry), and alert (generate an alert).

http_header_names: This property specifies the header names to watch for. Each header you wish to filter has a stanza with two elements: match_string (simply for your reference, not actually used by FireWall-1) and regular_exp (to specify the regular expression that matches the desired header).

http_header_names_values: Similar to the previous one, but with this property you can look for a header that has a specific value, as specified in match_string. If this header is found, the specified regular_exp is compared against the header's value.

Once you have added these patterns, you need to use the HTTP Security Server to perform this filtering. This can be done with a simple matchall resource. For Gnutella specifically, you need to add GNUTELLA* to the match field of the resource and make sure the resource is used in a drop or reject rule.

9.9 Why Do I Have Problems Accessing Some Sites When the HTTP Security Server Is Enabled?

This happens because the HTTP Security Server requires tweaking to access many popular sites. Table 9.2 shows the various firewall_properties tweaks you can perform by using dbedit on the management server or by manually editing the objects_5_0.C file (see FAQ 4.2 for details).

http_cvp_allow_chunked
http_weeding_allow_chunked
http_block_java_allow_chunked
http_allow_ranges

http_disable_content_enc
http_disable_content_type
http_allow_ranges

http_max_url_length
http_max_header_length

http_check_request_validity
http_check_response_validity

9.10 How Can I Permit Schemes Other Than FTP and HTTP through the HTTP Security Server?

Enable the following properties by modifying the appropriate firewall_properties section in objects_5_0.C:

:http_allow_double_slash (true)
:http_use_default_schemes (true)

The first property enables the HTTP Security Server to accept double slashes (//) in a substring of a URL. In order to allow this, the Security Server defines a set of schemes that it will accept, which is what the second property covers.

The default set includes prospero, gopher, telnet, finger, mailto, http, news, nntp, wais, file, and ftp. You may also define new schemes to add to this set. This requires manual editing of objects_5_0.C. For example, to add the schemes fish and trouble to the permitted list, add the following code to the firewall_properties section of objects_5_0.C. (Note that the colons are needed.)

:scheme (
        : ("fish:")
        : ("trouble:")
)

9.11 How Can I Customize the Error Messages Given by the HTTP Security Server?

On the firewall module, edit the file $FWDIR/conf/cspc/cspc.en_us. This enables you to modify just about any message that any of the Security Servers generate. Some common messages to edit include:

• "FW-1 at host"

• "Failed to connect to the WWW server"

• "Unknown WWW server"

Each line in $FWDIR/conf/cspc/cspc.en_us is of the following format:

IDENTIFIER     size    string

IDENTIFIER is a unique string that identifies the message to FireWall-1. Do not change this. size is the maximum number of characters the message can be. Do not change this either. string is the actual string that FireWall-1 will display. It may contain some special words surrounded by # signs, such as #host# or #html#.

For the three examples listed above, the lines look like this:

CPSC_HTTP_FW_AT_HOST         1024    "FW-1 at #host#:"
CPSC_HTTP_CONN_FAIL_ERR      1024    "\n#local_host# Failed
to connect to the #.40server#."
CPSC_HTTP_UNKNOWN_SERVER_ERR 1024    "\n#local_host# Unknown
 WWW server."

These lines could be changed so they read:

CPSC_HTTP_FW_AT_HOST         1024    "Message from firewall:"
CPSC_HTTP_CONN_FAIL_ERR      1024    "\n#local_host# Failed
to connect to the #.40server#. This may be a transient
problem, in which case simply reloading the page will work.
If this problem persists, it may be a problem with the
remote server."
CPSC_HTTP_UNKNOWN_SERVER_ERR 1024    "\n#local_host# Unknown
WWW server. This could mean you typed an incorrect URL or
there was a problem looking up the site in DNS. If the URL
is correct and the problem persists, contact your
administrator."

Performance Tuning the HTTP Security Server

One of the most common complaints about Content Security is performance. This is partially the result of the HTTP Security Server running in user space, versus the kernel space where much of FireWall-1 lives. Some of the performance issues can be overcome by tuning the platform on which the HTTP Security Server is running. However, there are some inherent limitations in the Security Servers in terms of the number of users who can go through a single system because Content Security overall requires significantly more resources than simply passing traffic. Personally, I would not use the HTTP Security Server for more than 1,000 users. Check Point has always claimed it is making strides in this area, and the company has increased performance in some circumstances by moving stuff to the kernel. However, I continually hear complaints from administrators who attempt to implement the HTTP Security Server in a large enterprise setting and end up doing something else.

In this subsection, I talk about what you need to do to improve performance of the Security Servers, which will increase the efficiency of the HTTP Security Servers. You should also apply the general performance-tuning suggestions in Appendix E.

Increasing the Number of Allowed Entries in proxied_conns

By default, the number of entries in proxied_conns (a table that stores connections via the Security Servers) is 25,000. For best performance, you should modify this number to twice the number of connections you actually expect to handle. In $FWDIR/lib/table.def on the management console, modify the following line:

proxied_conns = dynamic expires AUTH_TIMEOUT kbuf 4;

To modify the line to support 50,000 connections, for example, make it read:

proxied_conns = dynamic limit 50000 expires AUTH_TIMEOUT kbuf 4;

Increasing the HTTP Buffer Size

The default size is 4,096 bytes. It can be increased to a maximum of 32,768. A larger buffer size means fewer system calls; however, each connection will take up that much more memory, so there is a trade-off. See Table 9.2 in FAQ 9.9 for the property that sets the buffer size.

Increasing the Number of Security Server Instances

It's usually necessary to increase the number of Security Server instances for the HTTP Security Server, but you can do it for any Security Server. If you have multiple processors on your firewall, increasing the number of instances allows you to take advantage of these processors. You can use this trick if you are using a single processor system, too.

To increase the number of instances for any Security Server, you need to modify its line in the $FWDIR/conf/fwauthd.conf file, which has the following format:

<listen-port><binary><daemon-name>wait -<instances>

For example, if you want to run four instances of in.ahttpd, which will all listen on port 80, the corresponding line should look like this:

80     fwssd     in.ahttpd     wait     -4

Connections from the same HTTP client will always be directed to the same daemon within the authenticated session timeout. Connections begin to use alternate daemons only after the previous daemon fills up. All connections from a client will always be handled by the same daemon.

UFP Caching

When an HTTP request is made, the IP address of the destination is checked against the cache. If the IP address is in the cache, the category associated with that IP address is used. If it is not in the cache, the HTTP Security Server sends the request to the UFP server, which returns the appropriate category information and is then cached. Caching can be controlled by FireWall-1 or by the UFP server. Check Point recommends the latter method, which is thought to be more accurate.

If FireWall-1 controls the caching, FireWall-1 uses two methods to update the cache.

• One-request method: FireWall-1 takes the information returned by the UFP server and writes it to the cache.

• Two-request method: FireWall-1 makes a second request to the UFP server to determine whether the IP address of the site could match multiple categories. Only if the entire site uses the same category is the data written to the cache.

The one-request method is more aggressive in caching at the expense of cache integrity. The two-request method is slower, but the cache integrity is significantly improved.

Where the UFP server controls the caching, information necessary to update the cache is returned with each request looked up.

To enable UFP caching, create a URI resource, or edit an existing one. Go to the Match tab and enable the caching accordingly. Use the new URI resource in a rule.

Kernel URL Logging

Kernel URL logging allows you to log URLs without having to divert the connection to the HTTP Security Server. This improves overall performance in these situations. Kernel URL logging is enabled in a resource on the General tab by selecting Optimize URL logging (see Figure 9.1 earlier in this chapter). This resource cannot also be used for Content Security or URL filtering.

Adding More Memory, Physical and Virtual

The HTTP Security Server requires lots of memory, especially when it is busy. I have personally witnessed a busy in.ahttpd process on a Nokia platform handling just 1,024 concurrent connections require as much as 87MB of memory! Memory usage for in.ahttpd has proven to be similar on other platforms. The more physical memory you have, the better. Also, your swap size should be fixed (preferably on a dedicated device) and should be twice the size of the amount of physical memory you have.

NOTE!

On a Nokia platform that was running a version of IPSO prior to 3.4 and then upgraded, the system will have a swap partition size of only 256MB. For systems newly installed with IPSO 3.4 and later, the swap partition was increased to the lesser of a quarter of the overall available disk space or 1GB. A fresh reinstallation of IPSO from boot manager or boot floppy is required to obtain this larger swap size.

Adjusting File Descriptors Globally and Per Process

On a UNIX platform, there is a limit to the number of file descriptors available both to a specific process and globally. When started, in.ahttpd attempts to reserve the maximum number of file descriptors allowed by the operating system. On Solaris, this is 1,024. On IPSO, this is 2,048. Windows NT does not have this issue.

An HTTP connection going through the Security Server requires two sockets: one for the connection from the client and one for the client to the server. Each socket requires a file descriptor. A limit of 2,048 file descriptors means that fewer than 1,024 concurrent active connections can go through each instance of the in.ahttpd daemon. Other things like logging require file descriptors as well. When the maximum number of file descriptors has been reached, a "Too many open files" error is entered in $FWDIR/log/ahttpd.elg.

Allowing each in.ahttpd daemon to handle more than 1,024 concurrent connections is not recommended. Another factor to consider is the amount of memory that each process requires. Recall that earlier I stated that an instance of in.ahttpd handling 1,024 connections took 87MB of memory. Limiting the file descriptors to 1,024 (thus 512 connections per process) reduces the memory utilization to 47MB. The more concurrent connections each process can handle, the larger the process will get. In some cases, it might actually be better to decrease the number of file descriptors and increase the number of processes running.

On IPSO, the number of file descriptors allowed is limited by two kernel variables: kern:maxfiles (global limit) and kern:maxfilesperproc (per-process limit). The limits are 8,096 and 2,048, respectively. To modify these values, use the ipsctl command:

# ipsctl -w kern:maxfiles 4X
# ipsctl -w kern:maxfilesperproc X

X is the number you want to modify these values to; 4X means four times the value you choose for X. Because these values are set to their defaults at boot time, you need to add these commands to /var/etc/rc.local so they are changed at each startup.

On Solaris, add the following line to /etc/system and reboot:

set rlim_fd_max = X

On Linux, you need to do two things. In /etc/security/limits.conf, add the following lines:

* soft nofile 1024
* hard nofile X

These lines allow users to set their own file descriptor limits on login. You also need to change the system-wide limits by executing the following commands. (Add these to a startup script to be done on each reboot.)

# echo X >/proc/sys/fs/file-max
# echo 3X >/proc/sys/fs/inode-max

Troubleshooting Issues with the HTTP Security Server

Many of the following issues also apply to authentication because Security Servers are used for authentication. In this subsection, I talk about how to resolve common problems with the HTTP Security Server. A separate section on gathering debug information from Security Servers (Debugging the Security Servers) appears later in this chapter.

9.12 The HTTP Security Server Won't Work

A Security Server cannot share the same port as another application. For example, if you are using the HTTP Security Server bound to a specific port (say, port 80) and you have something else bound to that port (such as Voyager on a Nokia platform), one of the services must be moved.

9.13 My Users See the Error Message "FW-1 at Kyle: Unknown WWW Server"

This message could mean a few different things.

• The URL typed was incorrect.

• The firewall is not configured to use DNS for name resolution. The HTTP Security Server requires that the firewall be configured to use DNS.

• FireWall-1 timed out when it attempted to look up the name for the site.

• Your DNS server is configured to cache negative responses to DNS requests so that the same request is not made again. The client may also be running a name service?caching daemon that does something similar. You may want to consider disabling these features or setting the timeouts sufficiently high so that proper time is given to resolve the DNS queries.

If desired, you can change the error message text as described in FAQ 9.11.

9.14 My Users See the Error Message "Failed to Connect to WWW Server"

There are two possible reasons for this message.

• Connection to the site timed out or was refused at the remote end. In this case, you can usually do a refresh and the page will load correctly.

• The remote site either has a missing or inconsistent reverse DNS entry for its IP address.

Check Point considers the latter a security risk and does not allow these sites to be contacted through the HTTP Security Server. Check Point also does not allow you to turn off this feature. You have the following workaround options.

• Contact the administrators of the remote site in question to ask them to fix the site's reverse DNS entry.

• Add an entry in your firewall's local host file, and have the system resolve against the host file first.

• Exclude the site in question from going through the Security Server by adding a rule above your Security Server rule that permits normal HTTP to the site.

If desired, you can change the error message text as described in FAQ 9.11.

9.15 I Have Problems When I Try to Use Internet Explorer (or Other Browsers That Support HTTP 1.1) through FireWall-1

To solve this issue, enable the following properties as described in FAQ 9.9 (Table 9.2).

:http_cvp_allow_chunked (true)
:http_weeding_allow_chunked (true)
:http_block_java_allow_chunked (true)
:http_allow_ranges (true)
:http_force_down_to_10 (true)
:http_sup_continue (true)
:http_avoid_keep_alive (true)

9.16 I Can't Access Certain Web Sites through the HTTP Security Server

Various sites have issues when they are accessed via the HTTP Security Server. If you've enabled the properties suggested previously and are still having problems, do not use the HTTP Security Server for these sites. Place a rule that permits access to these sites above any rule that uses the HTTP Security Server.

9.17 The Memory Usage of in.ahttpd Keeps Growing

In just about every version of the HTTP Security Server that I've seen, heavy use of the HTTP Security Server seems to cause the process to grow without bounds until the system crashes. This and performance issues are the reasons I hesitate to recommend that large sites use the HTTP Security Server. You may have to write a script to monitor in.ahttpd's memory usage and kill this process when it grows beyond a certain limit (25MB is the limit several of my customers have used).