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 WAF. 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.

Validation order and scope

The Policy page is defined a list of allowed requests and parameters to a given web system. WAF filters access of the allowed requests and parameters.

The policy is defined by a collection of proxy global policies and application specific policies. This combination provides the ability to specify short yet fine grained access control policies, global and web application.

Global policy

Global policies are general rules which specify criteria that allow requests on a proxy global basis. Rules are specified by extension and by specifying a grammar (using regular expressions) for valid URLs and parameters.

Global patterns include Static content policies, Global URL policies, and Global parameters policies.

Web applications

In access policy terms, a web application is defined as an URL path which takes one or more parameters as input.

The web application policy list consists of one or more URL paths each with a specific policy, a web application policy entry.

The web application policy entry is defined by its URL path. The valid input for one or more of the URLs parameters are defined using either a list of allowed values, grammar (a regular expression) or a class which is a predefined regular expression.

Web application policy entries always take precedence over global rules. It is possible though to use a combination of global and specific rules, even for a single application.

Incoming requests are validated in the following order:

  1. Static content policy: If the extension and path of the requested filename matches the policy defined in static content policy and the request has no parameters, the request is allowed.
  2. Global URL path policy: If the request has no parameters and one of the global URL policy patterns matches, it is allowed. If the URI matches one of the Denied paths policy rules, the request is denied.
  3. Web applications policy: If the request (including possible parameters) matches an entry in the detailed web application policy, it is allowed.
  4. Web applications policy + global parameters policy: If a request matches an entry in the web applications policy but one or more parameters are offending, these parameters are checked against the global parameters policy. If there is a combined match, the request is allowed.
  5. Global URL policy + global parameters policy:If a requested URL with parameters matches a global URL policy pattern and all supplied parameters match global parameter patterns the request is allowed.
  6. No match:: The request is denied.

Regular Expressions guide

WAF has full support for standard PCRE (Perl Compatible Regular Expressions). Click the drop-down to follow a brief regular expression guide. For a more thorough explanation of the subject some links and books are recommended at the end of the section.

What are regular expressions

A regular expression is a formula for matching strings that follow some pattern.

Regular expressions are made up of normal characters and special characters. Normal characters include upper and lower case letters and digits. The characters with special meanings and are described in detail below.

In the simplest case, a regular expression looks like a standard text string. For example, the regular expression "john" contains no special characters. It will match "john" and "john doe" but it will not match "John".

In an input validation context we always want the expression to match the whole string. The expression above would now be expressed as ^john$, where the characters ^ and $ means starting of line and end of line. Now john will only match "john" but not "john doe". To obtain match of "john doe" as well as "john smith" etc. we employ a few more simple special characters. In its simplest form "john lastname" could be expressed as "^john.*$" meaning: A string starting with the characters "john" followed by zero or more (the "*") occurrences of any character (the "."). For those familiar with the simple wild-card character "*" in (a.o.) DOS and Unix, ".*" equals "*" - that is: anything.

Specifying anything is not very useful in an input validation context. With regular expressions much more fine grained input validation masks can be defined with the rich set of meta characters, character classes, repetition quantifiers, etc.

A brief explanation with some examples follows below.

Metacharacters

^ Beginning of string (implied in WAF)
$ End of string (implied in WAF)
. Any character except newline
* Match 0 or more times
+ Match 1 or more times
? Match 0 or 1 times; or: shortest match quantifier (i.e. *?)
| Alternative (like logical OR)
() Grouping
[] Set of characters (a list of characters)
{} Repetition modifier
\ Quote or special

Metacharacters in regular expressions


To present a metacharacter as a data character standing for itself, precede it with \ (e.g. \. matches the full stop character "." only).

In WAF all regular expressions are forced to match the entire string (URL path or parameter value) by automatically prefixing an expression with "^" and suffixing it with "$".

Repetition

a* Zero or more a's
a+ One or more a's
a? Zero or one a's (i.e., optional a)
a{m} Exactly m a's
a{m,} At least m a's
a{m,n} At least m but at most n a's
repetition? Same as repetition but the shortest match is taken

Repetition in regular expressions


Read "a's" as "occurrences of strings, each of which matches the pattern a".

Read repetition as any of the repetition expressions listed above it.

Shortest match means that the shortest string matching the pattern is taken. The default is "greedy matching", which finds the longest match.

Special notations with \

\t tab
\n newline
\r return (CR)
\xhh character with hex. code hh
\b "word" boundary (zero space assertion)
\B not a "word" boundary
\w matches any single international character classified as a "word" character (alphanumeric or _). Examples: A, z, 1, 9, Æ, â
\W matches any non-"word" character
\s matches any whitespace character (space, tab, newline)
\S matches any non-whitespace character
\d matches any digit character, equiv. to [0-9]
\D matches any non-digit character
\pN Matches any UNICODE character classified as numeric

Notations with \ in WAF regular expressions


Character sets [...]

A character set is denoted by [...]. Different meanings apply inside a character set ("character class") so that, instead of the normal rules given here, the following apply:

[characters] matches any of the characters in the list (c,h,a,r,a,c,t,e,r,s)
[x-y] matches any of the characters from x to y (inclusively) in the ASCII code
[\-] matches the hyphen character -
[\n] matches the newline; other single character denotations with \ apply normally, too
[^something] Negation. Matches any character except those that [something] denotes; that is, immediately after the leading [ the circumflex ^ means "not" applied to all of the rest

Character sets in regular expressions




Advanced Signature Model

The WAF Advanced Signature model is based on a combination of signature confidence and connection trust. Trusted connections are validated using signatures with a very low false positive risk, but if a connection proves to not be trustworthy because of attack activity, signatures with a higher potential rate of false positives are included in the validation of HTTP requests from that specific connection.

In addition to mapping Signature Confidence level to Connection Trust, you can also set the WAF Operating Mode to automatically change from Detect to Protect-based on Connection Trust. This new feature is called Adaptive Protect Mode.

The new signature model also includes improved HTTP header inspection and new file contents inspection capability.

Attack Signatures usage

Two signature engines are available in Fortra WAF:

  • Legacy Signature Engine: The original WAF signature engine. While detection capability is excellent, the Legacy engine allows for less granular discrimination – both in terms request element validation and source differentiation.

  • Advanced Signature Engine: Utilizes a combination of signature confidence and connection trust to validate connections, adapts WAF Operating Mode from Detect to Protect based on Connection Trust, and includes HTTP header and file contents inspection.

For more information, see Attack Signature usage.

Legacy Signature Engine

The Legacy Signature Engine uses the original Fortra WAF signatures and signature format. While it boasts excellent detection capabilities, it has certain limitations compared to the Advanced Signature Engine:

  • Granularity: The Legacy engine offers less granular discrimination in both request element validation and source differentiation.

  • Signature Confidence: Unlike the Advanced engine, signatures in the Legacy engine are not rated by confidence levels.

  • Request Element Grouping: Signatures are not grouped based on the request elements they apply to, which can affect the precision of threat detection.

Overall, the Legacy Signature Engine provides robust detection but lacks the refined control and adaptability of the Advanced Signature Engine.

Advanced Signature Engine

The Advanced Signature Engine employs a signature and validation model that is based on a combination of signature confidence and connection trust. Trusted connections are validated using signatures with a very low false positive risk, but if a connection proves to not be trustworthy because of attack activity, more sensitive signatures with a higher potential rate of false positives are included in the validation of HTTP requests from that specific connection.

In addition to mapping Signature Confidence level to Connection Trust, the WAF Operating Mode can automatically change from Detect to Protect based on Connection Trust. This feature is called Adaptive Protect Mode.

The Advanced Signature Model includes specific HTTP header inspection and file contents inspection capability.

Signature Confidence

Signatures are grouped in three confidence levels (High, Medium, and Low) based on how likely they are to trigger false positives. The higher the signature confidence the more known exploit content is required to be present in the HTTP request for the signature to match. The higher signature confidence would include special characters that often are required to inject the exploit code – like an apostrophe in SQLi exploits. For lower confidence signatures, presence of keywords may be enough to trigger the signature, and tend to trigger more false positives. Thus, lower confidence signatures also have a lower false negative rate and are more likely to detect attacks that are difficult to discern from normal activity.

Based on testing the signature model on real traffic data, more than 80% of detection across the three confidence levels is within the 90-confidence level. Each of the 80 and 70 confidence levels add around 10 percent-point marginal detection in return of a much steeper increase in false positives.

Initial signature confidence is configured by Sensitivity setting. The options are Standard sensitivity (use High confidence only), High sensitivity (use High and Medium confidence), and Very High sensitivity (use High, Medium, and Low). The default is Standard for trusted connections. However, for WAF user that prefer to trade a high increase in false positives for all connections for a small decrease in false negatives, the initial Sensitivity can be set higher. In most cases, a better option would be to change how fast specific connections are downgraded and validated using lower confidence signatures – without negatively affecting non-hostile connections.

Connection Trust

“Connections” (source IPs) are grouped in three trust levels (High, Medium, and Low) based on accumulated signature detection. Connections start at the highest possible trust level but as they trigger signature violations, they are downgraded to lower trust levels. The contribution of each violation to trust downgrade depends on the confidence of the signature. The higher the signature confidence the more trust is downgraded.

Attack activity is tracked across all website security profiles configured for the Advanced Signature Model on a WAF instance, but Connection Trust may be calculated differently for individual website security profiles depending on Trust Downgrade configuration. If Trust Downgrade is set to Fast, it takes less signature violations for a connection to be downgraded than if set to Medium. For website security profiles where Trust Downgrade is set to Off, Connection Trust is not downgraded regardless of connection attack activity.

Connection activity is tracked in run time memory and is currently not reset until a core restart – such as when applying changes to policy or proxy configuration.

Resetting Connection Trust

You can reset Connection Trust for an individual source IP or all source IPs in Services > Network > Connection Trust.

Advanced Signature Engine Features

The Advanced Signature Engine in Fortra WAF introduces several enhanced capabilities to improve security and adaptability. Below are the key features:

Adaptive Protect Mode

The concept of using high confidence signatures for trusted connections to limit risk that authorized traffic is blocked because of a false positive, can also be applied to the operating mode of the WAF. Adaptive Protect Mode upgrades the Operating Mode from Detect to Protect for specific connections based on Connection Trust. Connections with downgraded trust are blocked when triggering violations while normal, non-downgraded, connections are only logged if they happen to trigger a violation without intending to attack the web application.

Adaptive Protect Mode is configured in “WAF operating mode definitions” and the options are Low, Medium, and Off which correspond to the three Connection Trust levels. For example, when set to Low, only connections that have been downgraded to lowest level are blocked when triggering violations.

Website security profiles should not be put in Protect mode until they are flagged as Tuned (based on not observing unwanted violation detection); Adaptive Protect Mode is not effective until the Tuned flag is set.

Improved HTTP header inspection

In addition to existing specific HTTP header inspection capability, the Advanced Signature Model includes header specific signatures that allows for more thorough signature-based inspection of HTTP headers.

Signature-based inspection of headers is already available as a Virtual Patch capability, and the new Advanced Signature Model extends this vulnerability/exploit specific capability to apply generally to signature based validation.

File Contents Inspection

The Advanced Signature model extends current file upload inspection capabilities to also include contents of file uploads in signature inspection using specific file validation signatures.

File contents inspection is only effective if enabled in the File Uploads section of the Policy.

Signature-based inspection of file contents is already available as a Virtual Patch capability, and the new Advanced Signature Model extends this vulnerability/exploit specific capability to apply generally to signature based validation.

Streaming Inspection of Unlimited Request Body Size

The Advanced Signature Engine enables streaming inspection of unlimited request body sizes. When requests are too large to buffer before inspection, they can be streamed and inspected in real-time using signatures designated for streaming inspection. This capability allows the WAF to inspect large request bodies without size limitations, ensuring comprehensive security coverage for all incoming data, regardless of its size.

Upgrading already tuned website profiles from Legacy to Advanced

When upgrading from Legacy (original, old) to Advanced signature model existing tuning configuration still applies and is equally effective. In fact, it is possible to switch back and forth between Legacy and Advanced to only evaluate the new signature model while the website security profile is being monitored.

As the New Advanced Signature model includes extended validation of HTTP headers and file upload contents and the signatures are a bit different from the Legacy model (although with a much lower rate of false positives at confidence level 90), some caution is warranted – in particular for the improved inspection of headers and file uploads.

Depending on risk profile, the website security profile can either be put back in Detect mode while monitoring the effect of moving to the new signature model. As an alternative for website security profiles already running in Protect mode, you can configure the individual violations “File contents illegal” and “Header illegal” to Detect in the “WAF operating mode definitions” section of the Policy while the effect of making the change is monitored and then be put back in Protect when it is verified that everything is working as expected.

WAF User Interface Configuration Options

Advanced Signature Model

WAF UI path: WAF > Policy > Website Global Policy > Attack Signatures usage

UI option: Signature Engine

Toggle between Legacy and Advanced signature model

UI option: Sensitivity
  • What signature confidence level to initially use for non-downgraded connections
  • Default: Standard
  • Options
    • Standard = 90 (highest confidence)
    • High = 80
    • Very High = 70
UI option: Trust Downgrade
  • Amount of accumulated signature violations required for an IP to be downgraded
  • Downgrade is progressive and is based on number of detected violations with higher confidence signatures contributing more heavily than lower confidence sigs
    • Confidence 90 contributes 1.00 “downgrade ticks”
    • Confidence 80 contributes 0.50 “downgrade ticks”
    • Confidence 70 contributes 0.25 “downgrade ticks”
  • Options (examples based on confidence level 90 sigs)
    • Off = no downgrade, no cross-site contribution
    • Standard = downgrade at 12 (step 1) and 17 (step 2) violations (with current logic)
    • Fast = downgrade at 8 and 12 violations for step 1 and 2 respectively

To avoid inaccurately configured trusted proxy and X-Forwarded-For extraction to cause an internal load balancer to represent all external connections private IPs are currently exempt from downgrade.

Adaptive Protect mode

UI Path: WAF > Policy > Basic operation > WAF operating mode definitions

UI option: Adaptive protect mode
  • Move to protect mode for connections that are trust downgraded
  • Only effective when website is flagged as tuned
  • Options
    • Low (default): use Protect mode for connections that have been downgraded to low trust
    • Medium: use Protect mode for connections that have been downgraded to medium trust
    • Off: Adaptive protect mode off

Streaming Inspection of Unlimited Request Body Size

UI Path: WAF > Policy > Web Applications > [web application]

UI option: Streaming HTTP body inspection

  • Enable streaming of unlimited size request body

  • Configure deny/allow, parsing and validation signatures per content type

    • Allow: Yes/No

    • Parse (extract name/value pairs from payload): Yes/No

    • Validation:

      • Raw – use signatures intended for unparsed payloads

      • Upload – use signatures intended for upload payloads

      • Bypass – bypass request body without validation

  • Tune by excluding signatures

    • Add named signatures to exclude them from the validation signatures