How do I customize the HTTP proxy for outgoing connections?

Fireware/HTTP Proxy
This document applies to: Appliance Appliance Software versions Management Software versions Firebox X Core / Firebox X Core e-Series / Firebox X Peak / Firebox X Peak e-Series FIreware 8.3 / Fireware Pro 8.3 WatchGuard System Manager 8.3

Introduction
HTTP (Hypertext Transfer Protocol) is the primary protocol used to send and display files (text, graphic images, sound, video, and other multimedia files) on the Internet. HTTP introduces many security risks because of unpatched client operating systems and browsers, and misconfigured and unpatched servers. And, because HTTP is universal, everyone uses it. The HTTP proxy in Fireware is a powerful content filter that examines HTTP traffic to identify and block suspicious content. The HTTP proxy also works with optional Fireware services (WebBlocker, Gateway AntiVirus, and signaturebased Intrusion Prevention Service). It is easy to customize the HTTP proxy to your needs. You can configure it to: Allow only content that matches RFC specifications to act as a buffer between your web server and potentially harmful web clients. Restrict the content the Firebox allows into your network, based upon a fully qualified domain name, path name, file name, or extension as it appears in the URL. Examine HTTP headers to block unknown headers. Restrict the content the Firebox allows into your network based upon MIME type. Do a pattern match against the file header to block downloads of any file type, including client-side executable files such as Java; ActiveX; and Windows DLL, CAB, and executable files. Allow cookies only from domains you specify or that match patterns you specify. The HTTP proxy operates between the sending web server and your receiving web client. It processes the HTTP protocol line-by-line for any potentially harmful content before it sends it to an internal web client.

What is a Proxy Action?

A Proxy Action is a set of rules that tell the Firebox how to apply one of its proxies to traffic of a specific type. An HTTP Proxy Action tells the Firebox how to apply the HTTP proxy to HTTP traffic. One HTTP Proxy Action can be very different from another HTTP Proxy Action. Some of the differences can be different options selected or not selected, different patterns that each one looks for, and different types of content and headers that are allowed or denied.

How does the Firebox know which Proxy Action to use?

Traffic over a certain port is processed by a firewall policy if the policy controls that port, and if the source and destination IP addresses for the traffic flow match the From and To fields in the policy. You assign a Proxy Action to a proxy policy so that the Firebox knows how to apply the appropriate proxy for that type of traffic. Policy Manager can have more than one policy for web traffic. A very basic example is this: one HTTP policy controls HTTP traffic from a group of users with fewer privileges. This policy has the IP addresses of the less-privileged users computers in the From field. A second policy controls traffic from a more privileged group. The second policy has
1

How do I customize the HTTP proxy for outgoing connections?

the privileged users IP addresses in the From field. You assign one HTTP Proxy Action to the first policy and a different HTTP Proxy Action to the second policy. The Proxy Action you assign to the policy for the less privileged users has strict rules, designed to block more URLs and more content than the Proxy Action you apply to the policy for the more privileged users. You can create many Proxy Actions and use only some of them at a given time.

Predefined HTTP Proxy Actions

Two predefined HTTP Proxy Actions are included with the product. To see them, from Policy Manager, select Setup > Actions > Proxies:

The Proxy Actions window shows a list of all the predefined Proxy Actions in blue text. Any other Proxy Actions that you create would appear in black text.

The HTTP-Client and HTTP-Server Proxy Actions have the same categories and options available. The difference between them is the default settings used in each one: HTTP-Client protects the HTTP clients behind your Firebox. The defaults in this Proxy Action give a basic level of protection for users on your trusted and optional networks as they browse the web. HTTP-Server protects the HTTP servers behind your Firebox. By default, it allows most HTTP connections through to your public web server, but stops any attempts to put files on or delete files from your web server.

How do I customize the HTTP proxy for outgoing connections?

Note
This FAQ shows you how to customize the HTTP Client ruleset. It does not tell you how to customize the HTTP Server ruleset to protect a web server behind your Firebox.

Creating a Proxy Action

Because you cannot make changes to the predefined Proxy Actions, you will rarely use them directly. However, you can use the Clone button to make a copy of an existing Proxy Action. You can use this copy as a template to start a new Proxy Action that you can customize for your organization. To copy an existing Proxy Action, select the predefined HTTP-Client Proxy Action and click the Clone button.

Assigning a Proxy Action to a policy

To tell the Firebox to use a Proxy Action to examine traffic, you must associate the Proxy Action to a policy. You do this on the Properties tab of a policy.

Ruleset Categories
There are 14 ruleset categories in the HTTP-Client Proxy Action. Each category is discussed in detail in the following sections. The categories and their functions are the same for both HTTP-Client and HTTP-Server Proxy Actions, but the default rules are different. These rulesets are shown in the Categories list to the left of the HTTP Proxy Configuration dialog box.

Request rules and Response rules

In the first part of the HTTP Request/Response model, the client sends an HTTP request to the server. Because the request occurs first, the HTTP Request categories are the first line of defense that the proxy gives to the users behind your Firebox. The HTTP proxy has five categories of rules that tell the proxy how to process requests from clients.

How do I customize the HTTP proxy for outgoing connections?

There are also five categories for HTTP Responses. These categories tell the proxy how to handle responses from servers.

HTTP Request General Settings

Use these rules to control general HTTP parameters such as idle time-out, maximum URL length, range requests, and an important logging rule.

Idle timeout
This setting closes the TCP socket used for an HTTP session after the specified amount of time has passed since the last packet that used the TCP socket. Because every open TCP session uses a small amount of memory on the Firebox, and because browsers and servers do not always close HTTP sessions cleanly, this option is used to control performance. Recommendation: Keep this setting enabled to make sure that stale TCP connections are closed. This helps the Firebox save memory. You can lower the timeout to five minutes without problems.

URL length
Sets the maximum number of characters allowed in a URL. In this area of the proxy, URL includes anything in the web address after the top-level-domain, including the slash character, but not including the host name (the www.domain.com or the domain.com part of the web address). For example, the URL www.watchguard.com/products counts nine characters toward this limit because /products has nine characters. The default value of 2048 is usually enough for any URL requested by a computer behind your Firebox. A URL that is very long can indicate an attempt to compromise a web server. Recommendation: Because it is possible you can have infected web clients on the networks protected by the HTTP proxy, leave this setting enabled, with the default settings, to prevent attacks coming from your network.

Range requests
A range request is sometimes called a Partial GET. When a client wants a file from a web server, it can make a request for only a part of the file instead of the whole file. To do this, the client sends a Content-Range header with the HTTP request. There are two primary reasons why a client would do this: The client started to download a file but the download was interrupted for some reason. Usually when this happens the client has the partially downloaded file in a temp file in its local cache. To retrieve the rest of the file, the client issues a range request for only the part of the file it does not have, instead of downloading the entire file again. The client does not need the entire file.

How do I customize the HTTP proxy for outgoing connections?

Range requests introduce security risks. Malicious content can hide anywhere in a file and a range request makes it possible for any content to be split across range boundaries. The proxy can fail to see a pattern it is looking for when the file spans two GET operations. You can use the check box in this section to allow or deny range requests. If you have a subscription for Gateway AntiVirus (GAV) or the signature-based Intrusion Prevention System (IPS), and you enable either of those security services, Fireware denies range requests regardless of whether this check box is selected. Recommendation: Keep this check box cleared if the rules you make in the Body Content Types section of the proxy are designed to identify byte signatures deep in a file instead of just in the file header.

Summary log message

The Send a log message with summary information for each transaction check box makes Fireware send a log message for every HTTP request, and another log message whenever a connection closes. The second log message gives the total bytes transferred in the HTTP transaction. This check box affects what information the Historical Reports application can put into a report you run. Select this box if you want the reports you run to include information about HTTP traffic. If you do not select this box, the HTTP Detail and HTTP Summary sections of your Historical Report will be blank.

Note
This option creates a large number of log messages.

HTTP Request Request Methods

Similar to a command, an HTTP method is the type of action that the sender wants the receiver to respond to. Fireware supports all the methods defined in RFC 2616 except one.

OPTIONS
With this method, the client requests information about the types of communications and methods it can use with a resource on the server or with the server itself. This method introduces no security threats. Recommendation: It is safe to allow this method in an HTTP Proxy Action you use to protect clients.

GET
This is the method for retrieving resources from a web server. Recommendation: You must allow the GET method for HTTP to work.

HEAD
This method is very similar to the GET method except that HEAD method requests only HTTP headers, not body entities. A client often uses this method to discover if a resource is available, if it was recently modified, or the size of an entity. Recommendation: Allow this method for HTTP to work.

POST
A client uses this method to transfer user data to the server. In the POST request method, the data included after the POST method is always interpreted by the server in the context of some resource that already exists on the server. Examples include making a post to a news group, submitting data to a data-handling process on the server, or adding a new record to a database. Recommendation: The purpose of your HTTP Proxy Action will dictate if you allow this method. If you do not want clients to post any data to the server, configure the Proxy Action to not allow the POST method. This method generally does not introduce security risks. If you do not allow it, clients are not able to fill out forms on web sites.
5

How do I customize the HTTP proxy for outgoing connections?

PUT
The PUT method is similar to the POST method, but the data transferred to the server is treated as an independent entity. The server does not attempt to apply the request to any other resource or change the enclosed entity in any way. Most web servers do not allow the PUT method because of the security problems it introduces when a remote client can store files on the server. Recommendation: There is no risk to the client when it uses the PUT method. However, if you allow the PUT method, it is possible for a client to attempt a transfer of any data to the server. That includes sensitive information you may not want to go out to the Internet.

DELETE
This method lets a client send a request that the server delete an entity on the server. Most servers do not allow this method because of the security problems it introduces when a remote client can delete files on the server. Recommendation: There is no risk to the client when it uses the DELETE method. You can safely allow clients to use it, but servers usually do not allow it.

TRACE
This method is used only for debugging and diagnostics. It causes the server to send the exact message it received (including all HTTP headers and cookies) back to the client. This introduces a known security risk. There are many cross-domain browser vulnerabilities that can cause a client to get data from or send information to a third-party domain. When a malicious web site accepts the TRACE method from a client and exploits a cross-domain browser vulnerability at the same time, sensitive information can be exposed to the server by way of the data path between the client and a third-party domain. This called a cross-site tracing attack. Recommendation: The TRACE method is not allowed by default and you should not add it as an allowed method. The only exception is if you control both the client and the server, you are performing diagnostics for a short time, and you remove TRACE from the allowed methods when you finish the diagnostics.

CONNECT
The CONNECT method is not defined in the HTTP 1.1 specification. When a server accepts and processes the CONNECT method from a client, the server keeps the connection to the client and makes a second connection to another server that the client specifies, over some TCP port that the client specifies. After the CONNECT method is processed, the first server acts as a blind proxy (or forwarding agent) between the client and the other server. The server that receives the initial connection from the client simply transfers all packets it gets from the client to the other server, in a totally transparent manner, without regard to any content that it passes to the other endpoint. Responses that come from the other server are forwarded to the client in the same way. The client can request that the tunneled connection to the other server is over any TCP port, not just 80 or 443. Recommendation: Because the CONNECT method is not defined in the HTTP 1.1 specification, it is not supported. Although you can add CONNECT to the list of methods, the proxy generates a parsing error when it sees the request line. In the log message below, a client behind the Firebox configured the browser to use a publicly available proxy server for SSL, specifying port 80 for the proxy connection. The attempt to access the Wells Fargo online banking site was denied because the browser used an HTTP method (CONNECT) that the proxy does not support:
Deny [source-ip] [destination-ip] http/tcp 1687 80 1-Trusted 0-External ProxyDeny: HTTP Request line parse error (HTTP-proxy-02) src_ip_nat"[firebox-ip]" src_port_nat"11135" proxy_act"HTTP-Client" line"CONNECT online.wellsfargo.com:443 HTTP/1.1\x0d\x0a"

Other request methods

The HTTP 1.1 specification allows for extensions to the protocol, and there are extensions to HTTP that define other request methods. However, the HTTP proxy in Fireware does not support any request method that is not defined in RFC 2616.

How do I customize the HTTP proxy for outgoing connections?

The most common unsupported methods you will see are those used by the Distributed Authoring and Versioning protocol, also called WebDAV or DAV. It lets more than one person edit an entity on the web at the same time, while it keeps track of the versions of the entity. The WebDAV specification adds seven more request methods to the eight defined by HTTP 1.1, and an extension to WebDAV called Delta-V adds another 11 request methods to refine versioning control. Because these applications use the request methods in WebDAV, they will not work, or will only partially work through the HTTP proxy: Web-based mail systems based on Microsoft Exchange, especially Microsofts Outlook Web Access but also other customized Exchange-based webmail systems. The functionality of Internet Explorer differs from Mozilla-based browsers because there are some Microsoft-specific implementations of parts of WebDAV in Microsofts web server (IIS). Outlook Express, when it is configured to get HTTP mail from Microsofts Hotmail and MSN Mail services. The popular web-based Concurrent Versions System (CVS) SubVersion. When a users web browser tries to use one of the Web-DAV request methods, you will see a log message like this in Traffic Monitor:
Deny [source-ip] [destination-ip] http/tcp [source-port] [destination port 80] 1-Trusted 0External ProxyDeny: HTTP Request method unsupported (HTTP-01) src_ip_nat="[firebox-ip]" src_port_nat="[nat_port]" proxy_act="HTTP-Client" method="PROPFIND"

Note
The Policy Manager user interface lets you add other request methods to this area, but in Fireware versions 8.3 and previous, the only methods that the HTTP proxy allows are OPTIONS, GET, HEAD, POST, PUT, DELETE, and TRACE.

Rule match
All the rules that are pre-populated in the list are Exact Match rules. The list of exact matches includes HEAD, GET, POST, OPTIONS, PUT, and DELETE. If you add a rule in Simple View it is added as a Pattern Match.

Action to take
The proxy can take these actions when it sees an HTTP request method that matches a rule in your list: Allow: The proxy allows the method. Deny: The proxy denies the method and sends a message back to the client. You can customize this message in the Deny Message area of the HTTP proxy. Drop: The proxy drops the request and does not send a message back to the client. The Firebox sends only a TCP reset packet to the client. The clients browser might display The connection was reset or The page cannot be displayed but the browser does not tell the user why. Block: The proxy denies the method and puts the source of the request on the Auto-Blocked Sites list. If the user was on the Firebox Authenticated User list, the users IP address is removed from that list and the user is no longer authenticated. All traffic from an IP address on the Auto-Blocked Sites list is denied for the amount of time specified in Policy Manager at Setup > Intrusion Prevention > Blocked Sites, on the Auto-Blocked tab. Use this action only if you want to stop all traffic from the offender for this time.

Default action
The default action for a request method not on the list is Deny.

Alarm or log
By default the proxy does not send a log message for request methods in the rules list, but it does send a log message for methods not on the list.

HTTP Request - URL Paths

In this area of the Proxy Action you tell the Firebox to allow or deny connections based on the URL that the proxy sees in the HTTP request. When we talk of the URL in URL path, we mean the entire name of the resource, including the

How do I customize the HTTP proxy for outgoing connections?

domain name. For our example from the WatchGuard web site, URL in the URL path means www.watchguard.com/ support. Fireware compares the URL, including the entire domain name, with the rules you enter here.

Rule match
There are no rules pre-populated in the list. If you add a rule in Simple View it is added as a Pattern Match. You can use rules in this area of the proxy to block an entire domain or your rule can match a certain word or pattern.

Block a domain and paths in the domain

For example, to block any path in the www. myspace.comdomain, you can make a pattern-matching rule www.myspace.com*. That would match www.myspace.com, www.myspace.com/, www.myspace.com/register, and any other URL that starts with www.myspace.com. However if a user goes to http://myspace.com, such a rule would not match because the URL does not use the www subdomain. It would also not match invite.myspace.com or groups.myspace.com. You can place a wildcard in front to match the myspace.com domain and any subdomain, and a wildcard at the end to match any path in that domain. Then your pattern-matching rule would be *myspace.com*.

Block a file name extension

Another example is to make a rule to match any URL that contains the common three-character file extension for many Windows executable files, .exe. A simple pattern-match does this: *.exe matches any URL that ends with .exe and such a rule would match many HTTP requests for executable files with that file extension. Unfortunately, there is no guarantee that an executable file has this file extension. You can make a more positive identification of the contents of a file by making the proxy look at the files actual contents. In the Body Content Types section youll learn how.

Action to take
The actions for this area of the Proxy Action are the same as for the previous one with one addition: AV Scan This option is available only if you have a current license for Gateway AntiVirus. The response from this request will be scanned for viruses when the clients HTTP request matches a rule that uses AV Scan for the action. The Firebox does not send a message to the client if a connection is denied because of a virus signature match; it sends only a FIN packet to close the connection. Because the GAV engine does not cache data before sending it to clients, the end user may see a partially downloaded web document before the connection is terminated. Recommendation: Use URL Path rules to block requests you consider dangerous or unacceptable, such as the .exe example above. If you prevent requests, content you want to block never reaches the Firebox and the proxy does not have to spend resources scanning content. If you have a rule to deny a connection, use the Deny action to make the Firebox send a message to the clients browser. This is the only way the client can learn why the connection was denied. The user whose connection was denied can contact you for further investigation. Do not use the Block action unless you want to make sure the client can send no traffic at all after it violates the rule.

Default action
If a URL does not match any rule in the list, the connection is allowed.

Alarm or log
By default the proxy does not send a log message for any rules.

HTTP Request - Header Fields

HTTP uses headers in both requests and responses. This ruleset lets you allow or strip HTTP request headers. The browser uses request headers to send cookies to the server, to tell the server what version browser is in use, what language is preferred, and other information about what type of data the client will accept. The proxy checks all request headers against the rules you add. It looks at each headers name and its value.

How do I customize the HTTP proxy for outgoing connections?

Rule match
By default, the Firebox uses pattern matching rules to strip Via and From headers, and allows all other headers. There is a rule for the Referer header but it is disabled. The Via header can be added to a client request by proxy servers to perform such operations as track message forwards and avoid request loops. You can strip the Via header to protect client privacy. The From header passes the users email address to the server. Most browsers today either do not support the From header, or they send an anonymous address such as IEuser@domain.com. The proxy strips the header by default so that email addresses cannot be used by bulk mailers. Clients use the Referer header to send the address (URI) of the resource from which this request-URI was obtained. In other words, sometimes when you click on a link, your browser sends information about the site you just came from. This lets the receiving server gather statistics, optimize caching, trace bad links, and so on. Some users feel it is a breach of privacy to tell any server what previous site referred the user to visit this site. Some sites do not allow connections if the Referer field is not present or if the referer is not a certain domain. In addition, many CGI scripts that run on the web server rely on the Referer header to make sure the HTTP request comes from a previously scripted event. This is becoming less common as web security professionals realize that the header is easily spoofed. Because stripping this header causes some connections to break, the rule is disabled by default. Recommendation: Keep the defaults unless you are familiar with the header you want to strip and know the consequences if you strip it. Most request headers the client sends are necessary for the server to know the intentions and the capabilities of the client.

Action to take
The actions to take when a header matches a rule include only Strip and Allow. You cannot use these rules to make the Firebox terminate a connection or to block a client or server if a header matches a rule.

Default action
The default action is to allow any request headers that do not match a rule in the list.

Alarm or log
No log messages are sent by default.

HTTP Request - Authorization

This ruleset determines the type of authentication mechanism clients can use when a web site asks the user for authorization. This is the popup that you see when prompted to log in to a secure site. When a clients HTTP request is for something that requires authorization, the web server starts the authentication process. It sends the client a 401 response (Unauthorized or Authentication Required), along with one or more WWW-Authenticate: headers. This header begins a challenge to the client to prove it is authorized to access the data. The user types a user name and password into the popup box, and the client application (the browser) formulates the response. The browser sends the credentials as part of an Authorization: request header in its next request. The first value in a WWW-Authenticate header tells the client which authentication method (or scheme) it can use. This value is the main item the proxy looks for when it checks this ruleset. The server can send more than one WWWAuthenticate header to indicate that it accepts more than one authentication type, and the client uses the strongest scheme it supports. The HTTP proxy looks at the authentication scheme listed in each WWW-Authenticate header to see which schemes your ruleset allows. Here is a typical set of WWW-Authenticate headers, from the web configuration pages of a WatchGuard SOHO 6 Firebox. They tell the client that it can use Basic or Digest authentication to access the SOHOs web interface:
WWW-Authenticate: Basic realm="WatchGuard SOHO 6 Configuration WWW-Authenticate: Digest realm="WatchGuard SOHO 6 Configuration",qop="auth",nonce="4d0ea81c998bd95d2f33ccd8d23b1daa23"

How do I customize the HTTP proxy for outgoing connections?

Authentication methods
The preconfigured HTTP Client proxy allows these authentication methods. Note that many web sites do not use any of the methods listed; instead, the method for encoding and transmitting credentials is coded into the web application.

BASIC
This is the least secure of all authentication methods. The user name and password are transferred without encryption. They are encoded with only Base64 encoding, which is easy to decode. Recommendation: Although BASIC authentication has been replaced by the more secure DIGEST method in many places, it is still used by some servers. Allow this scheme only after you seriously consider its risks.

DIGEST
DIGEST authentication is more secure than BASIC because the password is not sent. Instead, the browser takes the users password, together with several other unique values, to make a one-way cryptographic digest (also called a hash or a checksum) of all these values. The server has access to the users password, and to the same values the client used to create the checksum, so it computes the checksum as well. If the servers result for the checksum matches the clients result, the server knows the user has the correct password. However, DIGEST does not guarantee message integrity. Even though the users password is never sent, man-in-themiddle attacks are possible. Recommendation: Allow this common HTTP authentication method.

NTLM
NTLM HTTP authentication is a proprietary Microsoft implementation of HTTP authentication that allows clients to use their Windows credentials to access resources. For several years Internet Explorer was the only browser that could use it, but today Firefox, Netscape, and other browsers have NTLM functionality built in as well. The HTTP version of the NTLM protocol lets the client and the server negotiate to choose the most secure version that both can use. The server and client can also agree to use Kerberos, which provides solid security, through the HTTP NTLM authentication process. NTLM is often used to authenticate to a Windows-based proxy server, and is also used for direct authentication to some Windows web servers. It is considered to be weaker than DIGEST because in some cases the LAN Manager hash of the users password can be extracted from an exchange of Base64-encoded messages, and this hash is vulnerable to well-known cracking tools. In addition, NTLM is not a per-request authentication like BASIC and DIGEST. Instead, it is connection-oriented: once authenticated, a user is not asked for credentials again until the TCP session is terminated. That makes it risky for external authentication to a proxy server, because if the proxy server is compromised the users credentials can be reused to access other systems in the same Windows domain. Because of this, Internet Explorer by default restricts the use of NTLM to IEs Local Network zone only. NTLM does not work through some proxy servers for this reason and for other connection-related reasons. Recommendation: For the highest security, allow this authentication method only if you are confident that server and client will negotiate to use NTLMv2 or Kerberos for the HTTP authentication. (The proxy cannot determine which version of NTLM the client and server negotiate to use in the transaction; it can only allow or strip the WWW-Authenticate header if it indicates to use NTLM.)

Passport1.4
Passport is Microsofts proprietary authentication mechanism for central authentication of users. It is rarely used today.

Rule match
The rule for each authentication type is by default an exact match. The proxy looks at the value in any WWW-Authenticate response header field and compares it to the rules here.

10

How do I customize the HTTP proxy for outgoing connections?

Action to take
The proxy can take one of two possible actions when a rule matches: Allow the authentication scheme or Strip it. You cannot use these rules to make the Firebox block a site or terminate a connection. Note the clients request is not stripped; the WWW-Authenticate header in the servers response is stripped. If you have a rule to strip a certain authentication scheme, the proxy strips any WWW-Authenticate response header sent by the server that has that authentication scheme as the value. Remember that a server can send more than one WWW-Authenticate header to indicate it accepts multiple schemes. If your proxy rules strip BASIC but allow DIGEST, and the server accepts both authentication schemes, the client is forced to use the stronger DIGEST scheme because it never knows that the server accepts the BASIC method. The BASIC method is stripped, so the client does not see it as a possible authentication scheme to use. This protects your network from information disclosure from older browsers that do not support DIGEST.

Default action
The default action is to Strip.

Alarm or log
By default, a header that is stripped because it does not match a rule causes a log message. Here is an example log message:
[date] [time] Allow [source-ip] [destination-ip] http/tcp 3082 80 1-Trusted 0-External ProxyStrip: HTTP Header auth scheme match (HTTP-proxy-02) src_ip_nat="[firebox external ip]" src_port_nat="[nat_port]" proxy_act="HTTP-Client.1" rule_name="Digest" scheme="Digest"

When there is no rule to allow the authentication scheme, the HTTP proxy sends the HTTP Deny message to the client. In this case the reason that Fireware uses for the %(reason)% variable in the deny message is: all proposed authentication schemes denied.

HTTP Response - General Settings

Use this ruleset to configure these basic HTTP response parameters. If you set any of these values to 0, the Firebox ignores the option.

Idle Timeout
Amount of time the proxy waits for a response from the server after the client issues a request. Recommendation: Keep this setting enabled to make sure stale TCP connections are closed. This helps the Firebox conserve memory.

Set the maximum line length

Total length of one line in an HTTP response line or header. The default is 4096 bytes. Recommendation: Keep this at the default setting. A long unterminated line can be an attempt to exploit a buffer overflow.

Set the maximum total length

HTTP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. This setting sets the maximum total length of a response line or a header field. Recommendation: HTTP does not set any line length limitations. The limit in Fireware defaults to 16384 bytes, even when you do not select the check box to activate this setting. Leave this setting at the default to protect against possible exploits.

HTTP Response - Header Fields

This ruleset controls which HTTP response header fields the Firebox allows. Some HTTP headers are critical for proper operation of the HTTP protocol. The current HTTP 1.1 specification defines about 50 different header fields. The HTTP proxy allows most of these by default and strips all others.

11

How do I customize the HTTP proxy for outgoing connections?

Rule match
By default there are 49 rules to allow the most common header fields. These rules are all pattern matching rules. Each rule matches a header field name only, and allows any value for the header. If you add a rule to allow or deny a header, by default it is a pattern-matching rule. You can switch to Advanced View if you need to make a more complex rule that matches a header field only if it matches certain values.

Action to take
A rule here can be set to Allow a header or to Strip it. You cannot use these rules to make the Firebox block a site or terminate a connection.

Default action
By default, any header that does not match a rule is stripped.

Alarm or log
By default, a header that is stripped because it does not match a rule causes a log message. Here is an example log message:
[date] [time] Allow [source-ip] [destination-ip] http/tcp 3082 80 1-Trusted 0-External ProxyStrip: HTTP Header match (HTTP-proxy-02) src_ip_nat="[firebox external ip]" src_port_nat="[nat_port]" proxy_act="HTTP-Client.1" rule_name="Default" header="X-AspNet-Version: 1.1.4322\x0d\x0a"

Recommendation: It is generally good security practice to deny everything except what you specifically deem to be safe. The headers in the default list are generally needed for the HTTP protocol to operate and are safe to allow. Because it is difficult to find the purpose for many custom headers, we suggest you leave the default Strip rule for headers that are not specifically allowed. If the amount of logging generated by the default Strip action is excessive, turn off logging for the default Strip rule. It is possible that you can have a connection problem when a response header is stripped and the header is not one of those that are allowed by default. If you suspect that a problem is caused by a stripped response header, turn this logging back on.

HTTP Response - Content Types (MIME Types)

This ruleset lets you allow or deny content based on the Content-Type header associated with an HTTP message. The content type of an HTTP message body is also called the MIME type. MIME is a standard for representing arbitrary binary content in Internet messages. When a web server sends content in response to a GET request, the content in the message body is always preceded by one or more headers. The Content-Type header is one of the headers that can precede the message body. This header tells the client application (normally this is the web browser) how to interpret the HTTP message body.

Format of the Content-Type header

The value for the Content-Type header has a well-defined structure: a main media type (such as text, image, or audio), followed by a slash /, followed by a subtype. You can use a wildcard character (*) to match any subtype of the given type. For example, text/* matches any one of over 20 subtypes such as text/html or text/plain. Similarly, image/* matches any content type that indicates any image type, such as image/.gif or image/jpeg.

About application/octet-stream
This is the default, generic content type a server assigns to a file when the server has no other content type associated with it, when the server is not configured correctly, when the application the server is running is coded poorly, or when the application developer did not assign one. In some situations you may need to allow this content type. For example, many Microsoft Windows Update files have application/octet-stream for the content type. If you must allow this content type, it is highly recommended that you use the AV Scan action for this content type. (A license is required for this add-on service.)

About missing content types

12

How do I customize the HTTP proxy for outgoing connections?

Sometimes a server is so badly misconfigured that no Content-Type header precedes the message body at all. Or, the Content-Type header is present but the value is null (blank). The (none) rule in the default HTTP-Client proxy is a blank rule to match the null content type. It is not enabled by default. You must switch to Advanced View to enable it.

How the client uses the Content-Type header

Some operating systems use the Content-Type and some use internal file type definitions to determine what to do with a file. Browsers and other applications can also ignore MIME types and use other methods to render or run files. Depending on the value of the Content-Type header, the client computers operating system, and the client application that requested the data, the client can: Render the content as a web page in a browser Call a plug-in (such as the Adobe Acrobat Reader plug-in or the Apple QuickTime or Windows Media Player plugin) to help render the content in a browser Prompt the user to save the file to disk Call a different application to open the file Tell the client application to do other things Although HTTP shares many properties with the MIME specification, it is not a MIME-compliant protocol. It is important to understand the limitations of the Content-Type header: The Content-Type header is an optional header. It is not required by the HTTP specifications, but it is helpful enough to client applications that most message bodies have one. Some message bodies do not have a preceding Content-Type header at all. To allow content that has no ContentType header, enable the none rule (see the About missing content types section above). The Content-Type header can be incorrect. It can use the wrong value for the actual content because of server coding errors and misspellings. The value for the header can be null (empty). The header value can be intentionally spoofed in an attempt to deceive a client and trick it into running a vulnerable application.

Rule match
The proxy gives you a list of many predefined MIME types from which to select, or you can make your own rules. To see the predefined list, click the Predefined button when you have this ruleset in simple view. By default, the Firebox allows some safe content types. It denies all other MIME content types, including data that has no specified content type. Some Firebox administrators use a simple wildcard pattern such as * or */* to allow all MIME types, or they set the None Matched rule to Allow. Instead of filtering for MIME types, they rely on two other rulesets to protect clients: They use the URL Paths ruleset in the HTTP Request area to block requests for possibly malicious files. They make rules to match familiar three-character file extensions, and use a Deny action to block access to those paths. They make rules in the Body Content Types ruleset to match byte strings for risky content. The primary reason Firebox administrators choose this strategy is the large number of MIME types that must be allowed for normal business operations. However, because the proxy checks the Content-Type header before examining the entity for Body Content (byte string matching; see the Body Content section below), filtering on MIME type can reduce the load on your Firebox by stopping content before it gets to the Body Content part of the proxy checking procedure. Also, before the server even has a chance to send content, you can block requests for files with well-known file extensions using the URL Paths ruleset in the HTTP Request section. Rules in this section prevent the server from even seeing a request, so content never reaches the Firebox.

Action to take
A rule here can be set to Allow a header or to Strip it. You cannot use these rules to make the Firebox block a site or terminate a connection.

13

How do I customize the HTTP proxy for outgoing connections?

Default action
By default the HTTP proxy uses the Deny action to deny any content identified by a Content-Type header that is not on the list.

Alarm or log
Here is a typical log message for content that was denied. The rule_name="Default" at the end means that there was no rule for this MIME type, so the default action applied. The content type is at the end of the log message so you can easily make a rule to allow it if this meets your needs. Note that the quotation marks are not part of the content type. To allow the content type in this example, add a rule for application/x-javascript, not application/x-javascript.
[date] [time] Allow [source-ip] [destination-ip] http/tcp 3082 80 1-Trusted 0-External ProxyDeny: HTTP Header content type match (HTTP-proxy-02) src_ip_nat="[firebox external ip]" src_port_nat="[nat_port]" proxy_act="HTTP-Client.1" rule_name="Default" content_type="application/x-javascript"

Recommendation: Filtering by content type can be an effective tool, but you should not use it as the only part of your users defense on the web. The HTTP proxy offers additional defense-in-depth mechanisms that augment content-type checking. Use the layers of the proxy to your advantage by making rules in the URL Paths ruleset (see the HTTP Request area of the proxy, above) to block requests for common file extensions of files you want to block. When a request is blocked by the Firebox, there is no chance for the server to respond with dangerous content.

HTTP Response - Cookies

Web servers use the response header Set-Cookie: to put a cookie on the clients computer. When the client makes an HTTP request after this, and the request is for something in the same domain, the client sends an HTTP request header Cookie: to give the server the cookie for this domain. Like all HTTP headers, Set-Cookie has a header field name [Set-Cookie], a colon [:], and the contents of the cookie. The contents of one cookie can include several values and sub-values, separated by commas and semicolons. The HTTP proxy looks at one value in the cookie to match the rules in this ruleset: the domain from which the cookie came. Here is an example Set-Cookie response header:
Set-Cookie: PRpb=yhoomy; domain=ads.pointroll.com; path=/; expires=Fri, 01-Jan-2010 00:00:00 GMT;

Rule match
There are no rules in the default HTTP Client proxy action because by default all cookies are allowed. A rule that you add to your proxy action matches a domain name. Every cookie has a string that starts with domain= . The value after the equal sign tells what domain the cookie can be used for. Sometimes it is an absolute fully-qualified domain name, such as yahoo.com (indicating that the cookie is valid only for the main yahoo domain), or it can begin with a dot to indicate that the cookie pertains to any subdomain. For example if the cookie contains <domain=.yahoo.com> then the cookie is valid for any subdomain of yahoo.com. If the cookie contains <domain=my.yahoo.com> then the cookie is valid only for that part of the yahoo domain (the my.yahoo.com domain is for users that create personalized yahoo pages). To match a cookie with a leading dot for any subdomain, use a rule that begins with the asterisk (*) wildcard. For example, to block cookies from hitbox.com or any of its subdomains, make the rule *hitbox.com.

Action to take
You can select to Strip cookies from a certain domain or you can Allow them. You cannot use these rules to make the Firebox block a site or terminate a connection.

Default action
The default rule is to allow all cookies. If your proxy action has no rules in this area, and you turn on logging for the None Matched (or Default) Allow rule, you can see all the cookies that web servers send to your users.

Alarm or log
No log messages are sent by default. You can turn on logging for the None Matched rule to see all the cookies handled by the Firebox.
14

How do I customize the HTTP proxy for outgoing connections?

Recommendation: Read the two-part LiveSecurity article Fireware vs. the Cookie Monster, contributed by David Piscitello: Part 1: https://www.watchguard.com/archive/showhtml.asp?pack=35469 Part 2: https://www.watchguard.com/archive/showhtml.asp?pack=35518 In this series, Mr. Piscitello examines the type of information that cookies collect and how it can be used against you or your organization. The series also offers strategies to help you decide which cookies to block.

HTTP Response - Body Content Types

This ruleset gives you control of the actual content in the body of an HTTP response. The proxy compares the raw content of the response body to see if it matches any rules here. This is one of the most powerful parts of the HTTP proxy because it lets you allow or deny content based on the actual byte stream of the response body. The proxy looks at the data stream byte-by-byte. The rules you make here can match part of the byte stream in its hexadecimal representation. If the part of the stream you want to match can be represented as ASCII text, your rule can match ASCII characters.

What is body content?

An HTTP message is essentially some headers, followed by the message body. Many users think of the HTTP message body as only the web page that the browser renders. However, HTTP allows for transporting any kind of content, not just content that the browser can display. If the client can make a GET request for a file, and the web server has the file, any type of file can be transferred.

What is raw, actual content?

This is the binary representation or the byte-by-byte representation of the data. Because the HTTP proxy examines a byte at a time, it is more efficient to look at the hexadecimal representation of the data stream.

What does a rule try to match?

The purpose of a rule in this section of the proxy is to find a sequence of bytes that will always be in an entity you want to identify. A pattern like this is often called a sequence of magic bytes, after the UNIX file named magic. The UNIX magic file refers to magic numbers instead of magic bytes, but the concept is the same a sequence of bytes that is the same for any file of the same type. For example, not all Windows executable files are identical, but most all Windows executable files begin with the same sequence of bytes: 0x4D5A (in hexadecimal) or MZ (in ASCII). This pattern of bytes that is common to all files of the same type is often called a file header. The word header is used because with many files, the pattern that identifies the file is at or near the very beginning of the file. This is usually but not always the caseidentifying bytes can be anywhere in the file. The number of bytes into the file that the pattern starts is called the offset. Additionally, a file can be edited in its raw form using a tool called a hex editor to put something else at the beginning of the file in an attempt to fool utilities that scan files. [reference URL: http:// www.securityelf.org/magicbyte.html]

Does the pattern have to be a hexadecimal pattern?

No. Because each character in the ASCII character set can be represented by a two-digit hexadecimal sequence from 00 through 7F, many byte signatures can be represented as ASCII text. In many cases, the byte string that positively identifies the file type is readable as text if you open the file in a text editor.

Where can I find byte patterns to use in my rules?

Here are a few good resources: For a searchable database of many file types, go here: http://filext.com/ The filext.com site also has an FAQ on how you can look in to a file with a binary file viewer to see the hexadecimal structure of the file: http://filext.com/info/showthread.php?t=21 For a useful utility that identifies files, and a collection of over 2,000 file type definitions with byte signatures, go here: http://mark0.net/soft-trid-e.html

15

How do I customize the HTTP proxy for outgoing connections?

This sites collection of file type definitions is not searchable, but you can download the collection of definitions to use with the TrID utility. You use Marco Pontellos TrID utility to identify an unknown file. The Fireware Board in the WatchGuard User Forum includes a conference for users to share Body Content Type rules they have created. Registration at the WatchGuard User Forum is easy. Go here: http://www.watchguard.com/forum The WatchGuard User Forum is a community of WatchGuard users helping other users. The Forum is separated into different boards, one for each type of Firebox WatchGuard sells. Each board is further divided into conferences, covering every aspect of that devices operation.

Rule match
By default, the Firebox is configured to deny Java applets, Zip archives, Windows EXE/DLL files, and Windows CAB files.

Actions to take
The proxy can take these actions when it sees an HTTP message body that matches a rule: Allow: The HTTP response continues to flow to the client. Deny: The proxy denies the method and sends a message back to the client. You can customize this message in the Deny Message area of the HTTP proxy. Drop: The proxy immediately drops the connection. No message is sent to the source of the HTTP response. Block: The proxy denies the method and puts the source of the response on the Auto-Blocked Sites list. AV Scan: This option is available only if you have a current license for Gateway AntiVirus. The response from this request will be scanned for viruses when the clients HTTP request matches a rule that uses AV Scan for the action.

Default action
By default, HTTP message bodies that do not match a rule here are allowed.

Alarm or log
Here is an example log message from a user trying to download a Windows executable file. The download was denied by the default Windows EXE/DLL Body Content Type rule:
[date] [time] Deny [source-ip] [destination-ip] http/tcp 3082 80 1-Trusted 0-External ProxyDeny: HTTP Body content type match (HTTP-proxy-02) src_ip_nat="[firebox external ip]" src_port_nat="[nat_port]" proxy_act="HTTP-Client.1" rule_name="Windows EXE/DLL"

AntiVirus
If some content is successfully scanned and no virus is found, the Firebox takes no action, the proxy lets the response through, and the client is not aware that a scan was performed. When the AV scanning engine looks at some content, two circumstances can trigger the proxy to take action: A virus is detected The Firebox AV Scan engine found a match on the list of viruses. An error occurs The most common reason an error occurs during scanning is that the content is inside a compressed file that is password-protected. The scan engine recognizes archived files and it can decompress archives, but it cannot decompress an archive that requires a password to decompress it.

Actions to take
Allow: The HTTP response continues to flow to the client. Drop: The proxy immediately drops the connection. No message is sent to the source of the HTTP response. Block: The proxy denies the method and it puts the source of the response on the Auto-Blocked Sites list. All traffic from an IP address on the Auto-Blocked Sites list is denied for the amount of time specified in Policy Manager at Setup > Intrusion Prevention > Blocked Sites, on the Auto-Blocked tab. Use this action only if you want to stop all traffic from the offending site for this time. The default action for both items in this section is Drop.

16

How do I customize the HTTP proxy for outgoing connections?

Note
When the Firebox drops the HTTP response, it is likely you will continue to see log messages for some time after the Drop event, as the source continues to send the rest of the response. You can recognize these denied responses because the source port is the same port used for the original client-server socket. Most often, this is port 80 with HTTP.

Why doesnt the client get a message in the browser when AV scan finds a virus?
The AV scanning engine for HTTP is an inline engine; it is not a store-and-forward engine. Because in-line scanning does not cache the data before it sends packets to the client, the HTTP proxy cannot replace the partially downloaded entity (web document or file) with a customized proxy deny message to notify the user that a virus was found (or that an error occurred).

Deny Message
The ruleset lets you customize the deny message that a client sees in the browser when a request or a response violates any rule in your Proxy Action that has its action set to Deny.

Note
The Firebox sends the message only when something triggers a rule that has action set to Deny. A rule set to Block, Strip, or Drop does not cause the proxy to send this message.

These rulesets in an HTTP Proxy Action can have rules with action set to Deny: Request Methods ruleset in the HTTP Request section URL Paths ruleset in the HTTP Request section Content Types ruleset in the HTTP Response section Body Content Types ruleset in the HTTP Response section Intrusion Prevention ruleset in the next section (A license is required to use the Intrusion Prevention System)

Tips on writing the Deny message

Although this FAQ does not include basic information on HTML, here are some rules and tips: Use only US-ASCII characters in the message. (This is true for every configuration parameter in the Firebox XML configuration file.) The first lines in the message should be HTTP headers that the browser needs to interpret the message body. For example, use a Content-type header with a charset declaration that tells the browser to render the message body with the UTF-8 character set. This character encoding lets you use the Unicode representation of non-ASCII characters. For more information about using Unicode in your deny message to make the browser show nonASCII characters, see the FAQs at: https://www.watchguard.com/support/fireware_howto/ Immediately after the HTTP headers in your message, add a blank line. This tells the browser that there are no more headers and the subsequent text is the message body. These system variables are available to put in the Deny message:
%(transaction)%

Puts Request or Response to show which part of the transaction caused the packet to be denied.
%(reason)%

Puts the reason the Firebox denied the content.

%(method)%

Puts the request method from the denied request.

%(url-host)%

Puts the server host name from the denied URL. If no host name was included, the IP address of the server is given.
17

How do I customize the HTTP proxy for outgoing connections?

%(url-path)%

Puts the path component of the denied URL. You can use any standard HTML tags, including meta-tags. For example, use an href tag that uses mailto: to include a link in the page that users can click to mail you the reason that something was denied. A line like this in your message does this:
Click <a href="mailto:IT-dept@domain.com?subject=I got blocked!&body=Here are the details for the Firebox blocking me: %0A%0 A%(transaction)% %0A %(reason)% %0A Method=%(method)% %0A Host=%(url-host)% %0A Path=%(url-path)%">here</a> to mail the details of the block and our IT department will look in to it.

When a user clicks on this link, the users email client starts a new message to the address after the mailto: link with the subject line and message body filled in.

Intrusion Prevention
Use the Intrusion Prevention ruleset to enable the Intrusion Prevention Service to monitor HTTP client connections to look for signatures that match those in the Intrusion Prevention Service database. (You must purchase a license for the optional Intrusion Prevention Service.) The Intrusion Prevention System compares HTTP requests, responses, and message body content against a database of signatures that your Firebox downloads periodically. The signatures come from various open-source resources and from WatchGuards own development team. There are several categories of signatures, such as signatures that identify instant messaging applications, spyware, attempts to exploit known vulnerabilities in popular programs, and backdoor trojan programs. To see the list of signatures, connect to Firebox System Manager, click the Security Services tab, and then click the Show button in the Intrusion Prevention box.

Rule match
You cannot make any rules of your own in this ruleset. Instead, you select the check boxes for the signature categories you want the Firebox to look for. Make sure you select the appropriate signature set for the purpose of your HTTP Proxy Action. On the General tab: Select the Server check box if you use this HTTP Proxy Action to protect a web server behind your Firebox Select the Client check box if you use this HTTP Proxy Action to protect clients behind your Firebox.

Actions to take
The proxy can take these actions when the Intrusion Prevention System is triggered by a signature match: Allow: The proxy allows the connection. Deny: The proxy denies the connection and sends a message back to the client. You can customize this message in the Deny Message area of the HTTP proxy. The %(reason)% variable that shows in a deny message is:
Reason: IPS matched signature id='[signature id number]'

Drop: The proxy drops the connection and does not send a message back to the client. The Firebox sends only a TCP reset packet to the client. The clients browser might display The connection was reset or The page cannot be displayed but the browser does not tell the user why. Block: The proxy denies the method and puts the source of the response on the Auto-Blocked Sites list. All traffic from an IP address on the Auto-Blocked Sites list is denied for the amount of time specified in Policy Manager at Setup > Intrusion Prevention > Blocked Sites, on the Auto-Blocked tab. Use this action only if you want to stop all traffic from the offending site for this time.

Default actions for different categories

By default, the proxy uses these actions: Deny for signature matches in the High and Medium Severity categories, for IM signatures, and for P2P signatures. Allow for signature matches in the Low Severity category. Drop for signatures that match anything in the Spyware category.
18

How do I customize the HTTP proxy for outgoing connections?

Alarm or log
Here is a typical log message from an Intrusion Prevention System event:
[date] [time] Deny [source-ip] [destination-ip] http/tcp 3082 80 1-Trusted 0-External ProxyDeny: HTTP Header IPS match (HTTP-proxy_out-00) proxy_act="HTTP-Client.2" ips_msg="WEB-IIS directory traversal attempt(Bugtraq-1806,CVE-2000-0884,Nessus-10537)" signature_cat="httprequest-server" signature_id="35033"

Proxy and AV Alarms

The Proxy Alarm ruleset lets you define the type of alarm that is sent any time a notification is triggered by an HTTPClient ruleset. There are only two boxes in this area of the HTTP proxy: Send SNMP Trap and Send Notification. There is more information in the User Guide about configuring SNMP and Firebox notifications.

Was this document helpful? Please send your feedback to faq@watchguard.com.

SUPPORT:

COPYRIGHT 2006 WatchGuard Technologies, Inc. All rights reserved. WatchGuard, the WatchGuard logo, Firebox, Core, and Fireware are registered trademarks or trademarks of www.watchguard.com/support WatchGuard Technologies, Inc. in the United States and/or other countries. U.S. and Canada +877.232.3531 All Other Countries +1.206.613.0456

19