How do I customize the HTTP proxy for outgoing connections?
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
How do I customize the HTTP proxy
for outgoing connections?
Fireware/HTTP Proxy
This document applies to:
Appliance Firebox X Core / Firebox X Core e-Series / Firebox X Peak /
Firebox X Peak e-Series
Appliance Software versions FIreware 8.3 / Fireware Pro 8.3
Management Software versions 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 signature-
based 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 pro-
tocol 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 differ-
ent from another HTTP Proxy Action. Some of the differences can be different options selected or not selected, dif-
ferent 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 desti-
nation 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
1How 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 differ-
ent 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.
2How 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.
3How 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 serv-
ers.
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 perfor-
mance.
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/prod-
ucts 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.
4How 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 Anti-
Virus (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. Fire-
ware 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 enti-
ties. 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.
5How 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 cli-
ent 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 trans-
fers all packets it gets from the client to the other server, in a totally transparent manner, without regard to any con-
tent 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.
6How 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 version-
ing 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 Microsoft’s 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 Microsoft’s web
server (IIS).
• Outlook Express, when it is configured to get HTTP mail from Microsoft’s Hotmail and MSN Mail services.
• The popular web-based Concurrent Versions System (CVS) SubVersion.
When a user’s 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 0-
External 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 client’s 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 user’s 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
7How 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 file’s actual contents. In the Body Content Types
section you’ll 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 client’s 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 client’s
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 lan-
guage 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 header’s name and its value.
8How 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 for-
wards and avoid request loops. You can strip the Via header to protect client privacy.
The From header passes the user’s 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 con-
nections 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 client’s 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) formu-
lates 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 WWW-
Authenticate 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 Fire-
box. They tell the client that it can use Basic or Digest authentication to access the SOHO’s web interface:
WWW-Authenticate: Basic realm="WatchGuard SOHO 6 Configuration”
WWW-Authenticate: Digest realm="WatchGuard SOHO 6
Configuration",qop="auth",nonce="4d0ea81c998bd95d2f33ccd8d23b1daa23"
9How 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 applica-
tion.
BASIC
This is the least secure of all authentication methods. The user name and password are transferred without encryp-
tion. 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
user’s 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 user’s password, and to the same values the client
used to create the checksum, so it computes the checksum as well. If the server’s result for the checksum matches the
client’s result, the server knows the user has the correct password.
However, DIGEST does not guarantee message integrity. Even though the user’s password is never sent, man-in-the-
middle 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 authentica-
tion 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 user’s 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 termi-
nated. That makes it risky for external authentication to a proxy server, because if the proxy server is compromised
the user’s 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 IE’s 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 Microsoft’s 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-Authen-
ticate response header field and compares it to the rules here.
10How 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 client’s request is not stripped; the WWW-Authenticate header in the server’s 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 Prox-
yStrip: 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 cli-
ent. 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.
11How 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 Prox-
yStrip: 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-Ver-
sion: 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 associ-
ated 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
12How 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 computer’s operating system, and the client applica-
tion 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 plug-
in) 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 impor-
tant 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 Content-
Type 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 examin-
ing 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 check-
ing procedure.
Also, before the server even has a chance to send content, you can block requests for files with well-known file exten-
sions using the URL Paths ruleset in the HTTP Request section. Rules in this section prevent the server from even see-
ing 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.
13How 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 client’s 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 subdo-
main. For example if the cookie contains then the cookie is valid for any subdomain of
yahoo.com. If the cookie contains 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 han-
dled by the Firebox.
14How 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 case—identifying bytes can be anywhere in the file. The number of bytes into the file that the pat-
tern 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
15How do I customize the HTTP proxy for outgoing connections?
This site’s 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 Pontello’s 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 device’s 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 client’s 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 Proxy-
Deny: 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.
16How 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 doesn’t 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 down-
loaded 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 vio-
lates 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 non-
ASCII 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.
17How 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 here to mail the details of the block and
our IT department will look in to it.
When a user clicks on this link, the user’s 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 WatchGuard’s own development team. There are several categories of signatures, such as signatures that iden-
tify 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 Ser-
vices 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 client’s 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.
18You can also read
