The Firebox proxy also demands that the server respond with a correct URI and content-type header with each URI returned to the requesting client. This is not an issue except when requesting data from some misconfigured Web servers or some custom services that use malformed HTTP-like request/responses to transfer data to clients.

To add the HTTP proxy, click the + in policy manager to add a service, expand the Proxy services, and doubleclick "HTTP" under the proxies folder, accept the default service name by clicking OK and you will be displayed the incoming properties. 

Unless you are hosting an HTTP server behind your Firebox you can leave this as "Enabled and Denied".  If you are hosting a HTTP server and are in routed mode with just a private network behind the Firebox, set this to "Enabled and Allowed" and in the "To:" field, click ADD, then click the NAT button and select the external IP and the private internal IP it maps to. 

The outgoing tab will already be set to allow ANY to ANY for outgoing connections, so unless you want to restrict outgoing traffic by IP address you should leave this at ANY to ANY.

Next click on the Properties tab.

Next click the Settings button to adjust the content filtering.

It is recommended you use the above settings unless you are familiar with the needs of your users.  If you don't allow these, you may unintentionally block your users from needed access to sites.  Below is an explanation of these options by WatchGuard.

Options on the Settings tab:

Remove client connection info

When Web clients make Web requests to servers, there are several items sent besides the actual URI requested. The operating system, browser type, referring URI, and possible intermediate proxies are also sent. The "Remove client connection info" option filters out the referring URI, the intermediate proxy information, and the client's email address (if present). The specific headers that are stripped with this option are the Via, From, and Referer [sic].

Here are paraphrased definitions of these headers (From RFC 2616, section 14):

The Via general-header field must be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 [9] and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.

The From request-header field, if given, SHOULD contain an Internet e-mail address for the human user who controls the requesting user agent. The address SHOULD be machine-usable, as defined by "mailbox" in RFC 822 [9] as updated by RFC 1123 [8]:

The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard. [Internet Explorer violates this.]

The following is a sample GET request from an Internet Explorer client with Windows 2000:

GET / HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Host: www.mydomain.com

Connection: Keep-Alive

Remove Cookies

HTTP "Cookies" are small bits of alphanumeric text that can be set by Web servers on Web clients. Cookies serve mostly benign purposes, like keeping track of what page a particular client is on, so that a certain other page can be sent in sequence. Some network use policies prohibit the acceptance of cookies however, and the Firebox can block these. A Web server may send a Set-cookie header in ANY HTTP response, and this is stored by the Web browser. These cookies are then sent back to the Web server in subsequent HTTP requests to that same domain. This option instructs the HTTP proxy on the Firebox to remove any HTTP headers that have to do with cookies.

Deny submissions

Browser HTTP requests fall into two main categories. GET and POST operations. GET operations are used to request specific URIs (e.g., graphics, html data, flash data). Several GETs are usually issued by client computers for a single page, because Web pages usually contain many separate elements all formatted together to form a seamless, single page for the end user.

POST operations are used when a Web user fills out a form on a Web page. Many Web pages ask for information from end users (e.g., location, email address, company name). If this is enabled, then the POST operations will be denied from the Firebox to external Web servers, so your users will be unable to fill out forms on Web pages.

Deny Java applets

If this option is enabled, HTTP server responses that come back with a content type of application/java or application/x-javascript will be denied. The Firebox also will not allow HTTP downloads of ZIP files because the browser can unzip these in real time and execute them. Byte compiled java applets will be identified by file fingerprinting. If this fingerprint is present in the beginning of the data stream, the data will be denied. The Firebox uses this fingerprint signature to detect precomplied Java applets:

0xcafebabe (in hexadecimal)

Deny ActiveX applets

Because ActiveX controls are always in-line HTML, the Firebox uses these fingerprints to detect them, much like the Java detection:

MSCF\000\000\000\000

0x5a4d00900003000000040000ffff0000

Remove unknown headers

This option will deny HTTP response headers from Web servers that are not defined in RFC 2616. For more information, see:

      http://www.ietf.org/rfc/rfc2616.txt 

Log accounting/auditing information

This option adds detailed accounting and auditing information to the log files. It increases the amount of data available to the Historical Reports module for auditing information. For more information, see the section of the Historical Reports chapter in the Firebox System User Guide.

Idle timeout

This setting controls how long the Firebox HTTP proxy will wait for the Web client, after initiating the TCP connection, to request something from the outside Web server. It also controls how long the Firebox HTTP proxy will wait for the Web server to send the Web page that was requested. The default is 600 seconds (10 minutes) which can safely be reduced in almost all cases.

Use caching proxy server

This option enables the Firebox to forward HTTP requests to a caching proxy server. This greatly speeds operations and reduces the load on the external Internet connection if there are Web sites often visited by your company. All Firebox proxy and WebBlocker rules that are in place still have the same effect.

The Firebox communicates with proxy servers exactly the same way that clients reform Web requests what the browser is configured for doing this. Instead of a GET request from the Firebox to the Internet looking like this:

GET / HTTP/1.1

It ends up looking like this, and the request is sent to the proxy server instead:

GET www.mydomain.com / HTTP/1.1

The proxy server then forwards this request to the Web server mentioned in the GET request. Most proxy implementations work fine like this, and are compatible with the Firebox.

Next click the Safe Content tab.

MIME type content filtering

The Firebox HTTP proxy is able to filter Web requests for harmful content based on MIME types identified by the sending Web server.

The MIME content type filtering relies on the remote web server sending a correct Content Type header to the Web browser. Some web serves fail to send this content type header information completely, and these servers will not be allowed through the HTTP-Proxy when this filtering is activated.

Safe Content tab - Allow only safe content types:

When sending most types of data over HTTP, the sending Web server will generally tag a MIME type on the response. This MIME type is contained in the HTTP header on the data stream before the data is sent. See the section in Content Type problems is the HTTP troubleshooting FAQ on the support Web site for more information on exactly how this data is sent:

Troubleshooting HTTP Proxy Web access problems

This MIME type is generally sent along with the file so that the Web browser can interpret and/or save the file properly. The list of allowed MIME types, by default, is  restrictive to a point where users cannot download anything from the web.  If you choose to activate this option you will have to add entries to this list for all web content to be allowed.  Be advised there are thousands of MIME types.

Deny unsafe path patterns:

This checks requested URL's and will deny a connection based on what is sent.  For example in the above setting, if you request a URL such as http://www.watchguard.com/downloadme.exe to download an executable (.exe) file it will be denied.  This can be effectively be used to deny unsafe downloads as often a popup will start this download and they user may not stop to notice what is going on.  But beware if your users need to download .exe files because it will stop them from doing so.

This completes the HTTP proxy setup.  Unless you have purchased Webblocker these are the only tabs needed and displayed to configure the HTTP proxy.  If you are configuring Webblocker you can go to the Webblocker Configuration page.