Similar to SSL/TLS, you can either completely offload compression to FortiWeb to save resources on your web servers, or temporarily decompress only as needed to scan and/or modify traffic that has already been compressed by your web servers.
If necessary, you can exempt HTTP Host: names and URLs from compression or decompression by FortiWeb. Generally, if a specific web server already applies compression, and if a specific response never needs to be scanned, compressed, or rewritten, it should be exempt from compression/decompression by FortiWeb.
|
|
If compressed, a request or response usually cannot be scanned, rewritten, or otherwise modified by FortiWeb. If you exempt vulnerable URLs, this will compromise the security of your network. |
1. Go to Application Delivery > Compression > Exclusion Rule.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
2. Click Create New.
A dialog appears.
3. In Name, type a name that can be referenced by other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.
4. Click OK.
5. Click Create New.
A dialog appears.
6. Enable Host Status to require that the Host: field of the HTTP request match a protected host names entry in order to match the exclusion.
Also configure Host.
7. From the Host drop-down list, select which protected host entry that the Host: field of the HTTP request must be in to match the exclusion.
This option is available only if Host Status is enabled.
8. In Request URL, type the exact URL of the page to use in the exclusion.
The URL must begin with a slash ( / ). The URL must not include the domain or IP address.
9. Click OK.
10. Include the exception in a compression or decompression policy (see Configuring compression offloading or Configuring temporary decompression for scanning & rewriting).
Most web servers can be configured to compress files when responding to a request. Compressed files often reduce bandwidth, and can result in faster delivery time to clients. (Modern browsers automatically decompress files before displaying the web pages.)
To successfully decompress and read the response, clients use the corresponding decompression algorithm. Web servers include an HTTP header such as:
to indicate which algorithm was used to compress the HTTP body:
^_<8B>^H^H+h,M^@^Cimage.png^@<EC><FC>St<AE>K<D4><EF><8B><C6>^\1G<AC>^Q<DB>
<U+0588>Fl۶m۶m۶m<DB>^Y<D1>N<E6><9C><DF>^<AB><B5>sq<CE><D5><D9><FB>b<A5><B5>\<BC><EF><F3>T/<F5><AA><EA><BF>^?<F5>$DZR^X^F
^C
^@^@^@揈<80>,^@^@ <EF><D7><EF>6^D<D8><D7>7<F3><E1><F5>^B^@^@x^@^?^D<F8><E4><9D>
(content truncated)
If want to gain the benefits that compression offers, but do not want to configure it on your web servers, you can offload compression to FortiWeb instead.
|
If your web servers are starved for CPU cycles and RAM, offloading compression from your web servers to FortiWeb can alleviate that bottleneck and improve performance. |
Based upon the HTTP Content-Type: headers that you select (which correspond to Internet file type/MIME type categories such as images and XML), FortiWeb will compress matching responses. The total size of a large web page with lengthy JavaScripts and CSS, while in transit, could be many times smaller.
|
The maximum pre-compressed file size that FortiWeb can compress is 128 KB. Files larger than that limit will be transmitted without compression. |
For example, a typical web page is comprised of several responses, such as an HTML document:
perhaps several images:
Content-Type: image/png
Content-Type: text/javascript
If your protected web servers do not already apply compression, and you configure a compression policy for text/html and text/javascript, those typically lengthy and repetitive text-based documents can be efficiently compressed into much smaller responses. If bandwidth between server and client is the performance bottleneck, this could improve performance dramatically.
Not all HTTP clients support compression: RPC clients, for example, transmit binary data and do not support compression. For those host names and/or URLs, you should create exceptions.
1. Before you configure file compression, configure the exceptions, if any. See Configuring compression/decompression exemptions.
2. Go to Application Delivery > Compression > File Compress Policy.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
3. Click Create New.
A dialog appears.
4. In Name, type a name that can be referenced by other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.
5. From Exclusion URL, you can select an existing exclusion. (See Configuring compression/decompression exemptions.)
Optionally, select an exclusion and click the Detail link. The exclusion dialog appears. You can view and edit the exclusion. Use the browser Back button to return.
6. Click OK.
7. To add or remove a content type, click Add Content Type.
A dialog appears.
8. In the Content Types list, select the content types that you want to compress, then click the right arrow (->) to move them to the Allow Types list.
For external JavaScripts, content type strings vary. If you are unsure of the content type string, for maximum coverage, select all JavaScript content type strings. However, due to wide browser compatibility, despite its current deprecated status, many web servers use text/javascript.
|
|
These apply compression only to JavaScripts that are external to a web page — that is, not directly embedded in a <script> tag or inline in the HTML document itself, but instead included via reference to a JavaScript file, such as <script src="/nav/menu.js">, and therefore are contained in a separate HTTP response from the HTML document. Likewise, selecting the text/css content type for compression will only compress external CSS. It will not compress CSS embedded directly within the HTML file. (Embedded CSS or JavaScript are governed by Content-Type: text/html instead.) |
9. Click OK.
10. To apply the compression policy, select it in an inline protection profile used by a server policy (see Configuring a protection profile for inline topologies).
Similar to SSL/TLS inspection, in order for some features to function, you must configure the appliance for compression inspection, or to decompress and then re-compress traffic.
If the HTTP body is compressed, FortiWeb cannot parse it for rewriting, nor scan for potential problems such as a data leak or virus. Traffic that is encrypted and/or compressed is not a normalized stream. Bodies of compressed responses effectively have low-grade encryption: they are not in clear text, and therefore do not match signatures, and cannot be rewritten.
How, then, can you scan or rewrite compressed traffic?
If your protected web servers compress files themselves (i.e. compression has not been offloaded to FortiWeb), configure a FortiWeb decompression policy.
You can configure FortiWeb to temporarily decompress the body of a response based on its file type, which is specified by the HTTP Content‑Type: header. The appliance can then inspect the traffic. After, if there is no policy-violating content nor rewriting required, the FortiWeb appliance will allow the compressed version of the response to pass. Otherwise, if modification is required, FortiWeb will modify the response before re-compressing it and passing it to the client.
|
|
The maximum compressed file size that FortiWeb can decompress is configured in Maximum Antivirus Buffer Size. By default, files larger than that limit are passed along without scanning or modification. This could allow malware to reach your web servers, and cause HTTP body rewriting to fail. If you prefer to block requests greater than this buffer size, configure Body Length. To be sure that it will not disrupt normal traffic, first configure Action to be Alert. If no problems occur, switch it to Alert & Deny. |
|
|
The response headers must include Content-Encoding: gzip in order to match the decompression policy. Other compression algorithms are not currently supported. |
1. Configure your web servers to compress their responses.
2. Before you configure the decompression policy, configure the exceptions, if any, that you want it to include. See Configuring compression/decompression exemptions.
3. Go to Application Delivery > Compression > File Uncompress Policy.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
4. Click Create New.
A dialog appears.
5. In Name, type a name that can be referenced by other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.
6. Click OK.
7. From Exclusion URL, you can select an existing exclusion. (See Configuring compression/decompression exemptions.)
Optionally, select an exclusion and click the Detail link. The exclusion dialog appears. You can view and edit the exclusion. Use the browser Back button to return.
8. To add or remove a content type, click Add Content Type.
A dialog appears.
9. In the Content Types list, select the content types that you want to decompress, then click the right arrow (->) to move them to the Allow Types list.
For external JavaScripts, content type strings vary. If you are unsure of the content type string, for maximum coverage, select all JavaScript content type strings. However, due to wide browser compatibility, despite its current deprecated status, many web servers use text/javascript.
10. Click OK.
11. To apply a decompression policy, select it in an inline or offline protection profile used by a server policy (see Configuring a protection profile for inline topologies or Configuring a protection profile for an out-of-band topology or asynchronous mode of operation).