Basic Operation

The Alert Logic Managed Web Application Firewall (WAF) Basic Operation page includes the following sections. Click on the link to go to the corresponding section to learn more:

To go to the previous section, see Policy. To go to the next section, see Protocol Restrictions .

To access the Policy page in the WAF management interface:

  1. On the left panel, under Services, click Websites.
  2. On the Websites page, click the website you want to manage.
  3. Under WAF, click Policy.

If you want to see all the settings on the Policy page, on the upper-right corner, change the Display preset to Advance.

To save configuration changes or edits you make to any features and options, you must click Save on the lower-right of the section or page where you are making changes. Click apply changes on the upper-left corner of the page, and then click OK. Your changes will not be stored if you do not properly save your changes.

WAF operating mode definitions

Operating modes are sets of configurations defining what violations to block and what violations to just log. Two configurable and one non-configurable presets are available.

Protect: The protect mode preset by default blocks and logs all violations according to the access policy.
Detect: In the default detect mode preset, only logging occurs and no blocking protection is activated. Blocking protection that may occur in protect mode is logged and available for review in the deny log. Operating in the default detect mode is comparable to an intrusion detection system; it detects and logs activities but does not protect or prevent policy violations.
Pass: In pass mode, all requests are passed through the website proxy. No requests are blocked and no logging is performed. As no filters are active in pass mode, it is not configurable.

For each violation, WAF can be configured to either block and log or just log.

Adaptive Protect Mode

Adaptive Protect Mode is a dynamic security feature designed to enhance the protection of web applications by adjusting the operating mode based on the trustworthiness of connections. This mode ensures that only connections with downgraded trust levels are blocked, while legitimate traffic is monitored and logged, maintaining a balance between security and usability.

Key Features

  • Connection Trust Levels: Connections are assigned trust levels (Low, Medium, and High). When a connection's trust level is downgraded, it triggers violations that result in blocking. Normal connections that trigger violations without intending to attack the web application are only logged.

  • Configuration: Adaptive Protect Mode is configured in the WAF operating mode definitions and can be set to Low, Medium, or High. For example, when set to Low, only connections downgraded to the lowest trust level are blocked when triggering violations.

  • Effectiveness: This mode is only effective when the website security profiles are flagged as tuned, meaning no unwanted violation detections are observed.

How It Works

  • Trust Level Assignment: Each connection to the web application is evaluated and assigned a trust level based on its behavior and characteristics.

  • Violation Detection: Connections that trigger security violations are assessed to determine if they are legitimate or potentially harmful.

  • Dynamic Adjustment: Connections with downgraded trust levels are blocked, while normal connections are logged for monitoring purposes.

Adaptive Protect Mode balances availability with the protection of confidentiality and integrity. By not blocking connections until they are proven bad, this mode minimizes the risk of false positives, ensuring that legitimate traffic is not unnecessarily disrupted. However, this approach also means increased requirements for keeping the protected application secure and updated. Regular updates and vigilant security practices are essential to ensure that the application remains protected against evolving threats.

Violations

Content violations

Path unknown No policy rules allow the path segment of the URL, either because it does not match a positive policy rule or because it matches a negative policy rule - a signature.
Path denied The path is explicitly denied by an URL blocking policy rule.
Query unknown No positive policy rules match the name of the request parameter.
Query illegal No policy rules allow the value of the request parameter, either because it does not match a positive policy rule or because it matches a negative policy rule - a signature.
Session validation failed The request session ID is not valid, either because the session token has been tampered with or hijacked.
Form validation failed The form submitted cannot be verified as having been issued by the web application in a response to a request from the current user session. This is an indication of a CSRF attack.
Session expired The request session has exceeded the idle expiration threshold configured in WAF for the web application.
Malformed XML Submitted XML request is malformed and hence cannot be parsed and validated.
Multiple encoded request The request contains elements that are encoded more than twice or it contains elements that are encoded using %u-encoding.
Authorization failed User is not authorized to access requested resource.
Header unknown Request header not RFC 2616 compliant.
Header illegal Header value failed strict validation.
Header validation failed Header value failed pragmatic validation.
Output illegal Server response contains illegal string.
Virtual Patch Request content triggered a virtual patch rule.
File contains illegal Upload file contains prohibited or malicious content.
File name not allowed Upload filename violates security policy or contains dangerous characters.
Blacklisted source IP Traffic detected from explicitly blacklisted IP address.
CAPTCHA enabled for source IP Challenge activated for suspicious IP address.
CAPTCHA disabled for source IP Challenge deactivated for validated IP address.
Unauthorized Bot or Client Session Session violated a bot and client automation management unauth rule.
Amomalous Bot or Client Session Session violated a session anomaly detection or bot and client automation management anomaly rule.
Unauthorized Charges Client Protection - Unauthorized changes to inline or external active content detected client side.

Protocol violations

HTTP Protocol version HTTP protocol version not allowed.
Method illegal HTTP method not allowed.
Missing hostname Request does not specify host name.
Invalid hostname Not website proxy is configured for the requested host name.
Request line maximum length Entire request line (URI?query) exceeds allowed maximum length.
Request path maximum length Request path exceeds allowed maximum length.
Query string maximum length Request query exceeds allowed maximum length.
Content type not enabled Request content type is supported but not enabled.
Header name length Header name exceeds allowed maximum length.
Header value length Header value exceeds allowed maximum length.
Maximum number of headers Header number exceeds allowed maximum.
Upload attempt Upload attempted but upload not allowed.
Payload length exceeded POST payload exceeds allowed maximum size.
Maximum number of upload files Number of files to upload in a request exceeds allowed maximum.
Total upload size Total size of upload files in request exceeds allowed maximum.
Maximum file size Size of a single upload file exceeds allowed maximum.
Cookie version not allowed Request cookie version not allowed.
Maximum number of cookies Number of cookies in request exceeds allowed maximum.
Cookie name length Name of a cookie exceeds allowed maximum length.
Cookie value length Value of a cookie exceeds allowed maximum length.
Maximum number of GET parameters GET parameter number exceeds allowed maximum.
GET parameter name length GET parameter name exceeds allowed maximum length.
GET parameter value length GET parameter value exceeds allowed maximum length.
GET parameter combined length Combined length of GET parameter name and value exceeds allowed maximum length.
Maximum number of POST parameters POST parameter number exceeds allowed maximum.
POST parameter name length POST parameter name exceeds allowed maximum length.
POST parameter value length POST parameter value exceeds allowed maximum length.
POST parameter combined length Combined length of POST parameter name and value exceeds allowed maximum length.
Generic protocol violation Protocol violations like missing content length or content type headers for POST requests.
General request violation Other generic violations.
Backend server error Backend server returned an error
XML payload illegal Injection or DoS indicators found in XML payload
Illegal %u encoding Non-standard Unicode encoding using %u format that is disallowed by policy
Illegal or malformed Unicode Request contains improperly formatted Unicode sequences that violate encoding standard

Request parsing

For WAF to parse requests as close as possible to the way the target application/web server technology does, it is important to configure web application behavior.

Delimiters

According to the official RFC, query part of a URL is delimited by ? and parameter part by &. Some web applications do not honor this delimiter and use different delimiters. Possible delimiters are: ";?:@&+$,". Several delimiters are separated by a space.

You cannot reuse a delimiter characters across the three delimiter categories.

Query delimiter(s)

Input field

Characters used for delimiting query part of the URL.

Valid input

Characters: ;?:@&+$,

Several delimiters are separated by a space.

Input example

? - /somepage.jsp?par1=val1&par2=val2

Default value

?

Parameter delimiter(s)

Input field

Characters used for delimiting parameters in the URL.

Valid input

Characters: ;?:@&+$,

Several delimiters are separated by a space.

Input example

& - /somepage.jsp?par1=val1&par2=val2

Default value

&

URL session id delimiter(s)

Input field

Characters used for delimiting URL based session identfiiers from the rest of the query.

Valid input

Characters: ;?:@&+$,

Several delimiters are separated by a space.

Input example

; - /somepage.jsp;jsessionid=longidstring?par1=val1&par2=val2

Default value

;

Do not change these delimiters unless you are absolutely certain that you know the consequences.

Response encoding

When output rewriting or CSRF protection is enabled, WAF must know the character set for the pages served by the web application/server to rewrite pages correctly. WAF tries to read the character set in use from the Content-Type header in the web server response. However, if the header does not specify a character set WAF defaults to the configured charset.

Response charset default

Input field

Default character set used for encoding served pages if none specified by backend server.

Valid input

Character set as defined in the response server header Content-Type or in the META tag content-type in the response body of pages served by the backend web server.

Examples:

Meta tag: <meta http-equiv="content-type" content="text/html; charset=UTF-8"> - UTF-8

Header: Content-Type: text/html; charset=iso-8859-1 - iso-8859-1

Input example

utf8

iso-8859-1

shift_jis

Default value

utf8

Content type - POST requests

These options are all related to parsing and validation of POST requests.

Guess Content-Type

Check box

Inspect payload of POST requests to guess content type if Content-Type header not present.

Default: <disabled>
Validate multipart/form-data request format

Check box

When parsing, multipart form data requires that the payload is formatted correctly.

If enabled, requests that does not validate correctly will be denied.

Default: <disabled>
Block on multipart/form-data request parsing errors

Check box

When parsing, multipart form data blocks recoverable request parsing errors like missing data caused by content-length being too small.

If enabled, requests that that does not parse correctly are blocked.

It is highly recommended that this setting is enabled as disabling it introduces the risk of attacks bypassing the WAF filter.

Default: <enabled>

Case sensitivity

Some web systems match requests case sensitive and some do not. When web systems are not case sensitive it is not uncommon that samples of requests are presented in different case combinations.

To avoid requests to resources with different case being learned as different requests, case sensitivity can be disabled.

Enable case sensitivity

Check box

Enable / disable case sensitivity matching.

Some web systems match requests case sensitive and some do not. When web systems are not case sensitive it is not uncommon that samples of requests are presented in different case combinations.

If enabled, WAF will match case sensitive.

Default: <disabled>

Regular expression engine

Two configuration options for handling regular expressions are available:

  • RE2 Engine Only: Require all configured regular expressions to be compliant with the RE2 regular expression engine.

  • Allow PCRE Fallback: Allow configured regular expressions to not be RE2 compliant and revert to the PCRE regular expression engine when required.

RE2 Engine Only

Selecting the RE2 Engine Only option ensures that all regular expressions are processed using the RE2 regex engine. This choice offers several significant advantages and is strongly recommended for the following reasons:

  • Performance and Predictability: RE2 is designed to run in linear time, meaning its performance is predictable and consistent. This prevents the risk of exponential time complexity that can lead to performance degradation and potential Denial of Service (DoS) attacks.

  • Security: By using RE2 exclusively, you minimize the risk of DoS attacks caused by complex regular expressions. RE2's linear time complexity ensures that even intricate patterns are processed efficiently without consuming excessive resources.

  • Simplicity: RE2 does not support features like backreferences and lookaround assertions, simplifying the regular expression syntax and reducing the likelihood of errors or vulnerabilities.

  • Compliance Enforcement: When the RE2 Engine Only option is selected, any regular expressions that are not RE2 compliant cannot be saved. This ensures that all regex used within the WAF adhere to the performance and security standards set by RE2.

Allow PCRE Fallback

While the Allow PCRE Fallback option provides greater flexibility by allowing the use of the PCRE regex engine for regular expressions that are not compliant with RE2, it comes with significant drawbacks and is generally discouraged:

  • Increased Complexity: PCRE supports a wide range of features, including backreferences and lookaround assertions. While this makes PCRE more powerful, it also increases the complexity of regular expressions, which can be harder to optimize and maintain.

  • Resource Intensive: PCRE can be more resource-intensive due to its extensive feature set. This may require more memory and processing power, potentially impacting the overall performance of the web application firewall.

  • DoS Susceptibility: PCRE can exhibit exponential time complexity in certain cases, especially when using advanced features. This makes it susceptible to DoS attacks if an attacker crafts a malicious regular expression designed to consume excessive resources. Allowing PCRE fallback increases the requirements for keeping the protected application secure and updated. Regular updates and vigilant security practices are essential to ensure that the application remains protected against evolving threats.

Regular Expressions in Fortra WAF

It is important to note that all regular expressions provided with Fortra WAF are RE2 compliant. The Allow PCRE Fallback option thus only applies to user-configured regular expressions. However, some regex processing involves concatenating user-configured regular expressions with those included with the WAF. In such cases, if the user-configured regular expressions are not RE2 compliant, the core regex processing may revert to PCRE. This can introduce the aforementioned complexities and potential vulnerabilities associated with PCRE.

RE2 Engine Only is strongly recommended

When configuring Fortra WAF, it is strongly recommended to select the RE2 Engine Only option to prioritize performance, security, and simplicity. This option is ideal for environments where predictable performance and resistance to DoS attacks are critical. The Allow PCRE Fallback option should only be considered if necessary for complex pattern matching, and with a clear understanding of the increased complexity and resource requirements involved.

Request header re-writing

WAF allows for re-writing or removing arbitrary request header values using regular expressions for matching the value to re-write.

Enable header re-writing

Select or clear the checkbox to enable or disable request header rewriting.

Rewriting rules

Each rewriting rule consists of a header name, an action, a regular expression to match the value, and a literal string to replace the matched value with.

Header

Input field

Header name to match preserving case.

Valid input

A HTTP header with correct case

Example

X-Json-Header

Valid input

A triplet in the format: Header_field::match_regular_expression::subst_value.

match_regular_expression is a regular expression matching the substring in the header value to replace with subst_value.

Escape meta characters (.*+?()[]-|^$\) with \ to match literally.

Input examples
Rewriting Referer field value

substitute https with http

Referer::^https::http

Rewriting X-Forwarded-For ip address

X-Forwarded-For::10\.10\.10\.10::192.168.0.11

Default value

none

Action

Drop-down list

Replace: Replace matched string

Strip: Remove matched string
Search for

Input field

Regular expression search pattern

Valid input

Regular expression with meta characters (.*+?(){}[]-|^$\) escaped as required if literal match is intended

Example

Matching key name in {"somekey":"somevalue"}

\{"somekey"

Replace with

Input field

String to replace with

Example

{"newkey"

Attack class criticality

For each attack class in the list define the criticality level.

Attack class
  • Drop-down lists: SQL injection
  • XPath injection
  • SSI injection
  • OS commanding
  • XSSPath traversal
  • Enumeration
  • Format string
  • Buffer overflow
  • DoS attempt
  • Worm probe, and more

Select a criticality level for the attack class.

Valid input

Options from the drop-down list:

  • Critical

  • High

  • Medium

  • Low

  • None

Default value

Attack class dependent.

Source IP tracking and access control

Source IP tracking and blocking adds IP sources exceeding a certain risk level to summary database. This allows for tracking attacker activity across the websites configured in WAF. The Dashboard Deny Log Interactive List and the global Attack Source Auto Blocking are both based on the information collected when this feature is enabled.

Track violating IPs across websites

Enable IP source tracking

Check box

Enable / disable IP source tracking.

Tracked IPs will feed into the blacklisting controls and, if enabled, IPs exceeding limits will be blocked.

Default: <enabled>
Risk level

Drop-down list

Sets the risk level above which the source IP is tracked and added to the global database.

Valid input

Options from the drop-down list

Critical, High, Medium, Low, None

Default value

<High>

Immediate blacklisting

When a request is denied at the application level, instead of just stopping the request the source IP can be blacklisted forcing the attacker to change IP address or to find another target.

Enable IP source immediate blocking

Check box

Enable / disable IP source immediate blocking.

Default: <disabled>
Risk level

Drop-down list

Sets the risk level above which the source IP is immediately blocked.

When the IP is blocked, the attacker will not be able to access the website from that source IP for a duration configured in Attack source auto blocking.

Valid input

Options from the drop-down list

Critical, High, Medium, Low, None

Default value

<High>

Layer 7 source IP blocking

If application layer source IP blocking is enabled, when running behind a layer 7 proxy that otherwise would hide the client source IP, client source IPs are extracted from the X-Forwarded-For header and source IP based blocking controls are enforced at layer 7 instead of at the network layer.

Layer 7 source IP blocking

Check box

Enable / disable Layer 7 source IP blocking.

Note that this feature has to be enabled at the global level. If this is not the case, this will be indicated in the field label.

Default: <disabled>

External notification

Alerts and summary

Syslog alerts

Enable sending of alerts to syslog server. Only alerts with priority above or equal to the configured threshold are sent. Alerts are sent to Local3 facility.

To have attack alerts sent to an external syslog server configure threshold level and server address in System->Configuration.

Enable alerts to syslog

Check box + Drop-down list

Enable or disable sending of alerts to syslog server.

When enabled, the drop-down menu Syslog criticality threshold specifies the lowest informational level (priority) for which alerts will be sent to the syslog server.

Valid input

Options from the drop-down list:

  • LOG_CRIT

  • LOG_ERR

  • LOG_WARNING

  • LOG_NOTICE

  • LOG_INFO

  • LOG_DEBUG

Default value

Disabled - LOG_WARNING

Email alerts

Enable sending of alerts by email. Only alerts with priority above or equal to the configured threshold are sent.

Enable email alerts

Check box + Drop-down list

Enable or disable sending of email alerts.

When enabled, the drop-down menu Instant email criticality threshold specifies the lowest informational level (priority) for which alerts will be sent.

Valid input

Options from the drop-down list:

  • LOG_CRIT

  • LOG_ERR

  • LOG_WARNING

  • LOG_NOTICE

  • LOG_INFO

  • LOG_DEBUG

Default value

Enabled - LOG_ERR

The email address is the contact email specified in System->Configuration.

Attack class criticality to log priority mapping

For each criticality level set the corresponding log priority (informational level).

Criticality level

Drop-down lists (Critical, High, Medium, Low, None)

Select a log priority level for each criticality level.

Valid input

Options from the drop-down list:

  • LOG_ALERT

  • LOG_CRIT

  • LOG_ERR

  • LOG_WARNING

  • LOG_NOTICE

  • LOG_INFO

  • LOG_DEBUG

Default value

  • Critical -> LOG_CRIT

  • High -> LOG_ERROR

  • Medium -> LOG_WARNING

  • Low -> LOG_NOTICE

  • None -> LOG_INFO

Deny log settings

Policy violations

Enable/disabled support for logging of blocked requests.

When a request fails the defined access policy for a given proxy, WAF will block the request.

Enable logging for normal/filtered requests

Check box

Enable / disable logging for normal/filtered requests.

If enabled, WAF will log blocked requests for normal/filtered end-user traffic.

Default: <enabled>
Do not log bypassed requests from trusted clients

Check box

Disable logging of bypassed requests (that would have been blocked) from trusted clients.

If selected, WAF will not log requests that are violating the policy but are bypassed because the source IP is in the trusted clients list of the website proxy and HTTP blocking bypass is enabled for trusted clients.

Default: <disabled>
Do not log blocked requests from trusted clients

Check box

Disable logging of blocked requests from trusted clients.

If checked, WAF will not log requests that get blocked if the source IP is in the trusted clients list of the website proxy.

It is not recommended to disable logging of blocked requests unless there is a good reason for it. If for example some kind of monitoring software is used to regularly verify that specific requests are being blocked it could be desirable not to have these requests logged in order to prevent the log from being filled with these (known) requests.

Default: <disabled>
Do not log GeoIP violations

Check box

Disable logging of GeoIP violations.

Broken requests

Enable/disable logging of broken requests.

Broken requests are either requests resulting from broken internal or external links. Broken bot requests are requests originating from bots not adhering to standards.

Enable logging of broken links

Check box

Enable / disable logging of referred requests (requests with a referrer header) allowed by the policy but resulting in a 404 not found error from the web server.

Default: <disabled>
Enable logging of webserver 404 not found

Check box

Enable / disable logging of requests allowed by the policy but resulting in a 404 not found error from the web server.

Default: <disabled>
Enable logging of broken bot requests

Check box

Enable / disable logging of requests classified as broken bot requests.

Default: <disabled>

Log data masking

In order to avoid compromising confidential data like for instance payment card numbers (along with other payment card data like control code and expiration date) ending up in the deny log it is possible to configure log data masking policies based on regular expressions.

Enable rewriting of logged querys

Select or clear the check box Enable rewriting of logged querys to enable this feature.

Name

This is an informal field allowing for assigning a human readable name to the rewrite policy rule.

Valid input

Any text string

Input example

  • Payment Card

  • SSN

Default value

Payment card

Search for

A regular expression matching the string to replace.

Valid input

A regular expression.

Input example

  • (?:\d{4}[\-\x20]?){2}\d{4,5}[\-\x20]?(?:\d{2,4})? - matches most payment card numbers

  • \d{3}-\d{2}-\d{4} - matches US Social Security Number strings, no validation of the value.

Default value

(?:\d{4}[\-\x20]?){2}\d{4,5}[\-\x20]?(?:\d{2,4})?

Notice the use of backslash ("\") in the examples above to escape the metacharacter ".". Without escaping the "." it will be interpreted as a metacharacter matching any character resulting in the regular expression also matching strings like xxxyhost2xxx4tld and xxxhost_xxx_tld (a.o.).

The regular expressions matches case insensitive in a repetitive fashion meaning that if more than one instance of the search pattern is present in the string they will all be replaced.

Replace with

A string to replace with

Valid input

Any text string gramatically equal to the data being matched but with no semantic meaning (in order to mask the information in the string being matched).

Input example

  • 9999-9999-9999-9999

  • 999-99-9999

Default value

9999-9999-9999-9999

The log data input policy rules rewrites all data being handled by the website proxy log subsystem. This includes data for the Learner. Therefore do not rewrite a payment card number to something like MASKED_PAN as this will result in the Learner wrongfully selecting the class alphanum for payment card input which will not match payment card numbers with "-" (dash) or " " (space) in. Instead rewrite to something similar like in the examples above.

The default rule that matches most standard credit card numbers is always on in order to reduce the risk of payment card from inadvertently being transmitted to the Alert Logic backend with deny log information.

Access log settings

When access logging is enabled all requests to the website are logged.

The access log is generated on a per day basis and closed logs are made available for download.

Access log format

Drop-down list

Select the format for the access log.

Valid input

Options from the drop-down list

Web Application Firewall Common, Common Log Format, Common Log Format with Virtual Host, NCSA extended/combined, Custom

Default value

<Web Security Manager Common>

When the Custom is selected, the input field below the drop-down becomes active and allows for specifying a custom log format.

Custom format

Input field

Define a custom log format.

Valid input

A sequence of the input fields below separated by space.

Input example

remote_addr time_local request status body_bytes_sent referer

Default value

remote_addr remote_logname remote_user time_local request status body_bytes_sent referer user_agent cookie roundtrip

Add roundtrip time and cache info to access log format

Check box

Enable / disable additional proxy specific log fields.

If enabled, WAF will add roundtrip time and "served from cache flag" to the selected log format.

Default: <disabled>

Getting/viewing the access log files

When log files are available for download, the file name is an active link. To download an access log file click on the file name.

When remote backup is enabled, the latest access log file made available for download will be compressed (using gzip) and copied to the remote backup destination along with the backup of the system configuration.

Access log formats

WAF supports a number of standard access log formats suitable for importing into log-analysis tools. For plain access logging the WAF format is the most condensed.

Alert Logic Managed Web Application Firewall (WAF) Common

The WAF Common log format is a condensed version of the Common log format (below). It contains only basic HTTP access information and the time field is kept in Unix epoch format to save time and space.

Source IP The client source IP address.
Time Time the request was received (UNIX timestamp)
Request First line of request
Server response code Web server server response code - i.e. 200
Response size Size of response in bytes, excluding HTTP headers
Response time The time taken to serve the request, in microseconds
Cached response Is response served from cache or not (1=yes, 0=no)

 Common Log Format

The Common log format contains only basic HTTP access information.

Source IP The client source IP address.
Remote logname N/A - will contain a dash, included for compatibility.
Remote user N/A - will contain a dash, included for compatibility.
Time Time the request was received (standard english format)
Request First line of request
Server response code Web server server response code - i.e. 200
Response size Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-' rather than a 0 when no bytes are sent.

Common Log Format with Virtual Host

The Common log format contains only basic HTTP access information with the addition of canonical name of the Virtual Host serving the request.

Virtual Host The canonical ServerName of the server serving the request.
Source IP The client source IP address.
Remote logname N/A - will contain a dash, included for compatibility.
Remote user N/A - will contain a dash, included for compatibility.
Time Time the request was received (standard english format)
Request First line of request
Server response code Web server server response code - i.e. 200
Response size Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-' rather than a 0 when no bytes are sent.

 NCSA extended/combined

The NCSA extended/combined format contains the same information as the Common log format plus two additional fields: the referral field and the user_agent field. This log format is also called Apache Combined log format.

Source IP The client source IP address.
Remote logname N/A - will contain a dash, included for compatibility.
Remote user N/A - will contain a dash, included for compatibility.
Time Time the request was received (standard english format)
Request First line of request
Server response code Web server server response code - i.e. 200
Response size Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-' rather than a 0 when no bytes are sent.
Referrer The content of the request header "Referer".
User-Agent The content of the request header "User-Agent".

 Custom format

The custom log format allows for specifying custom log formats by entering log format field names separated by space. The field names below are available.

Source IP remote_addr The client source IP address.
Remote logname remote_logname N/A - will contain a dash, included for compatibility.
Remote user remote_user N/A - will contain a dash, included for compatibility.
Time time_local Time the request was received (standard english format)
Request request First line of request
Server response code status Web server server response code - i.e. 200
Response size body_bytes_sent Size of response in bytes, excluding HTTP headers. In CLF format, i.e. a '-' rather than a 0 when no bytes are sent.
Referrer referer The content of the request header "Referer".
User-Agent user_agent The content of the request header "User-Agent".
Cookie cookie The content of the request header "Cookie".
Response time roundtrip The time taken to serve the request, in microseconds.
UNIX timestamp timestamp Time the request was received (UNIX timestamp).
Cached response cache Is response served from cache or not (1=yes, 0=no).
Bytes Sent bytes_sent The number of bytes sent to the client.
Real Server real_server The real server that handled the request, often used in load balancing scenarios.
Real Status real_status The actual status code returned by the upstream server.
Real Response Time real_response_time The time taken by the upstream server to process the request and send a response.
SSL Client Serial ssl_client_serial The serial number of the client certificate for an established SSL connection.
Gzip Ratio gzip_ratio The compression ratio achieved by the gzip module, calculated as the ratio between the original and compressed response sizes.
Time ISO8601 time_iso8601 The current time in ISO 8601 format, which is a standard date and time format.
Response Content Type response_content_type The Content-Type of the response sent to the client.
Server Port server_port The port of the server that accepted the request.
Request Length request_length The length of the request, including the request line, headers, and request body.
Backend Address backend_addr The address of the backend server that handled the request.
Remote Port remote_port The port of the client that sent the request.
Request URI request_uri The full original request URI as received from the client.
Host Host The value of the Host header in the request.
Scheme Scheme The scheme (protocol) used in the request, such as http or https.
WSM Remote Address wsm_remote_addr Same as remote_addr. The client source IP address.
SSL Cipher ssl_cipher The cipher suite used for the SSL connection.
SSL Protocol ssl_protocol The protocol used for the SSL connection, such as TLSv1.2 or TLSv1.3.
URI uri The current URI in the request, which may be different from the original request URI if internal redirects have occurred.

Additional fields

If "Add roundtrip time and cache info to access log format" is enabled, the fields below will be added to the selected log format.

Response time The time taken to serve the request, in microseconds
Cached response Is response served from cache or not (1=yes, 0=no)

Response inspection

Response inspection in Fortra WAF is designed to detect anomalies and indicators of compromise in responses from protected web applications. This section explains how response inspection works and the additional security measures it includes.

How Response Inspection Works

Scope of Inspection

  • Response inspection is only applicable to violations that are not blocked by the WAF. Blocked requests do not generate responses from the backend server.

  • Only responses from requests that trigger a violation in the WAF are inspected.

Baseline Creation:

  • When response inspection is enabled, the WAF builds a baseline of server responses. These responses are grouped by the type of request, such as .php, .asp, .html, .css, or no extension.

  • For each response group, the WAF calculates statistics for several dimensions:

    • Response header size

    • Response body size

    • Request time

    • Response time

    • Ratio of text to code: Text refers to the content presented to the user, while code includes HTML tags, JavaScript, styles, etc.

    • Maximum text chunk: This is the longest string of user-facing text uninterrupted by HTML tags.

  • The baseline data for each group is reported in websites > Learning > Response data.

Anomaly Detection

  • Once the baseline is established, the WAF quantifies responses to non-blocked violations in the same manner.

  • Each dimension of these responses is compared to the baseline for the corresponding response group.

  • A Z Score is calculated for each dimension. The Z Score measures how much a response deviates from the baseline.

Flagging Anomalies

  • If the Z Score for any dimension exceeds the configured limit, the response is flagged as an anomaly.

  • The severity of the logged violation is then upgraded, indicating a higher level of concern and prompting further investigation.

Additional Security Measures

In addition to anomaly detection, the WAF also runs signatures to look for indicators of compromise. These include:

  • Known database error strings: The WAF scans responses for strings that indicate database errors, which could be a sign of SQL injection attacks.

  • Patterns from known files: The WAF looks for patterns from known sensitive files, such as /etc/passwd, which could indicate unauthorized access attempts.

  • Cross-Site Scripting (XSS) Indicators: Specifically, for XSS, the WAF checks if indicators detected in the request are repeated in the response. This helps identify if an XSS attack is being reflected back to the user.

Understanding Z Score

A Z Score is a statistical measurement that describes a value's relationship to the mean of a group of values. It is expressed in terms of standard deviations from the mean. In the context of Fortra WAF's response inspection:

  • Calculation: The Z Score is calculated for each dimension (e.g., response header size, response time) by comparing the observed value to the baseline mean and dividing by the standard deviation.

  • Interpretation: A high Z Score indicates that the observed value deviates significantly from the baseline, suggesting an anomaly. If the Z Score for any dimension exceeds the configured limit, the response is flagged as an anomaly.

Response Inspection Configuration

Enable response inspection to start baselining and inspecting server responses.

Extensionless maximum URL path depth

The Extensionless maximum URL path depth configuration option sets the "cut off" to differentiate between applications and input parameters (URL path parameters) in natural URL applications. This setting helps the WAF distinguish between the structural components of a URL and the parameters passed to the application, ensuring accurate analysis and detection of anomalies. By setting an appropriate depth, administrators can ensure that the WAF correctly identifies and processes URLs, enhancing the effectiveness of response inspection.

Baseline dimensions

For each dimension, a Z Score limit is set to determine when a response should be flagged as an anomaly. The Z Score limits can be configured based on the desired sensitivity of the anomaly detection.

  • Z Score of 3: This corresponds to a probability of approximately 0.13%. This means that there is a 0.13% chance that a response will deviate from the baseline by this amount or more due to random variation. Setting the Z Score limit to 3 is suitable for detecting significant anomalies while minimizing false positives.

  • Z Score of 4: This corresponds to a probability of approximately 0.0032%. This means that there is a 0.0032% chance that a response will deviate from the baseline by this amount or more due to random variation. Setting the Z Score limit to 4 is suitable for detecting very rare and significant anomalies, further reducing the likelihood of false positives.

By configuring the Z Score limits appropriately, administrators can fine-tune the sensitivity of the response inspection to balance between detecting true anomalies and minimizing false positives.

Response logging

When enabled, server responses will be logged with request violations in the deny log.

Global configuration options

Response inspection and logging must be enabled globally for local settings for individual websites to take effect. If not enabled, the enable options in the website policy configuration will include a reminder - (Not enabled globally).

Global settings are configured in Services > Websites > Global.

Enable global settings override

If enabled, Z score limits and other settings for individual websites can be configured globally and applied to all websites.

Mirror proxy policy from master

This feature allows for configuring the proxy to dynamically mirror the policy of another website proxy.

To mirror a proxy, select it in the drop-down list and enable the Mirror proxy policy from master module.

When mirroring is enabled, it will be indicated in the top of the page with the text (MIRROR OF PROXY xx). Also in the websites overview the information in the Virtual Web server column will contain the text (M:X) where X is the website proxy ID.

Note that the selected mode is not mirrored. This means that if the mirrored proxy (the master) is running in Protect mode and the mirror (the proxy for which mirroring is enabled) is running in Detect mode, it will log/block according to the Detect mode preset while the mirrored proxy will use the Protect mode preset.

Configuration settings that are not mirrored must be configured on the mirror.

Logging, learn, and stats data

Depending on requirements, log, learn, and stats data can either be isolated to the mirror or included with the mirror master.

Log and learn to mirror master

Check box

Include log and learn data with mirror master.

Default: <disabled>
Stats data to mirror master

Check box

Include traffic stats data with mirror master.

Default: <disabled>

Deny and error handling exceptions

Deny response and backend error interception configuration can be exempt from being mirrored if required.

Do not mirror deny action

Check box

Do not mirror Deny action as configured in Websites > WAF > Deny and error handling

Default: <disabled>
Do not mirror error and deny pages

Check box

Do not mirror Deny action pages and error interception configuration as configured in Websites > WAF > Deny and error handling and Websites > WAF > Policy > Output filter > Backend server cloaking > Intercept backend error codes.

Default: <disabled>

SP and Page Integrity exceptions

Configuration, commit messages, and content approval notes configured for Client Protection in Websites > WAF > Policy > Client Protection can be exempt from being mirrored. This may be required if mirrors are based on the same underlying application as the master but are loading different active content.

Page Integrity and Content Security Policy can be excluded individually but since page integrity controls (as required by PCI-DSS 6.4.3) interact with Content Security Policy controls to control execution of inline active content, if Page Integrity must be excluded so should CSP configuration.

Do not mirror CSP configuration

Check box

Do not mirror CSP configuration from master.

Default: <disabled>
Do not mirror Page Integrity configuration

Check box

Do not mirror Page Integrity configuration from master.

Default: <disabled>