Policy

The Policy page is part of the Alert Logic Managed Web Application Firewall (WAF) section in the web based management interface. To learn about all of the features in the WAF section, see WAF.

This page contains information for the following features found under the Policy section on the WAF page :

To go to the documentation for the previous section of Alert Logic Managed Web Application Firewall (WAF), see Policy. To go to the documentation for next subsection in the WAF 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.

Basic operation

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.

Violations

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

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.

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.

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>

Request header re-writing

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

Enable header re-writing

Select or clear the check box Enable request header re-writing to enable this feature.

Rewriting rules

In the input area enter one or more rules for header rewriting.

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

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 blocking

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>

Geolocation IP access control

Geo IP blocking restricts access to your website from certain regions based on the geographic location of the incoming request. The Alert Logic Managed Web Application Firewall (WAF) product checks incoming IP addresses against a blacklist or whitelist account, and determines whether to approve or deny access to the request. You can configure which countries you want WAF to block.

Enable GeoIP access control

Check box
  • Select the country you want to either blacklist or whitelist. You can also select more than one country.

    • Default: <disabled>

    Select

    Whitelist

    or

    Blacklist

    		Whitelist or Blacklist the countries you added.

    Single-clicking will deselect all other countries if you previously had other countries selected. You must select the countries you previously had selected again, and any new ones you want to add. To select more than one country, click and hold the control key on your keyboard as you click to select countries.

    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>

    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 is 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).

    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)

    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.