You are here

Announcing Airlock 5.1

Airlock 5.1 Feature Tour: Major improvements in flexibility and completely revised rulesets.

Airlock 5.1 introduces a new framework for request/response actions. The initial set of actions allows rewriting, insertion, and deletion of headers, as well as redirecting requests based on header values. Some existing features, such as rewriting of the host header, rewriting of the request referer or request/response header whitelists are replaced by this more generic approach.

Furthermore, default deny rules (e.g., against XSS or SQL injection) are revised and extended. The monolithic one-size-fits-all rules are replaced by groups of fine-grained rules with different security levels. At the same time, exceptions to deny rules become much more powerful. For instance, it is now possible to exclude parameters on certain paths or source IP ranges and combine several exceptions.

Framework for Request/Response Actions

Airlock 5.1 introduces a new framework for handling HTTP headers. Request and response headers can easily be modified based on patterns in header names or values. The current list of supported action types is:

  • Rewrite header values
  • Redirect a request based on a header name or value
  • Remove a specific header
  • Add (or replace) a header
  • Add a header if it is missing

Airlock comes with a large set of built-in default actions. Examples include rewriting the host or request referer headers, header whitelisting, and various HTTP Security headers (see below).

Default response actions in Airlock 5.1
Figure 1: Default Response Actions with Airlock 5.1

These built-in actions are enabled or disabled globally. The global activation state for actions is used by default on all mappings, but can be overridden if required. That is, by enabling the X-Frame-Options action globally, a header "X-Frame-Options: SAMEORIGIN" is added to all responses. If this is not desired for some mappings the action can be turned off specifically where needed.

Of course, custom actions can be defined on mappings. This enables the user to freely manipulate HTTP headers without resorting to Apache expert settings.

HTTP Security Headers

Useful default rules configure Airlock in a secure way. Known leaky headers, such as X-Powered-By or X-AspNet-Version, are blacklisted. Too permissive CORS headers are removed as well. Well-known good headers are whitelisted. Important security headers, e.g. X-XSS-Protection or Strict Transport Security (HSTS) are added to request and response if they are missing. Rules for more invasive headers such as Content-Security-Policy (CSP) are ready to use, but not enabled by default. They can be enabled globally with just one click.

Deny Rule Flexibility

Up to Airlock 5.0, default deny rules were static blocks of distilled wisdom. In case of an issue with a default deny rule, the user was given the options to either copy the rule and make manual modifications, add a mapping-wide exception, or completely disable the rule. Of course it is not recommended to disable rules due to the severe impact on overall security this implies.

Airlock 5.1 adds several options for dealing with false-positives:

  1. Specific parts of deny rules can now be deactivated separately
  2. 1-click filter strength adjustment
  3. Exceptions to deny rules are no longer bound to have a mapping-wide scope and are much more flexible

Deny Rule Groups

In Airlock 5.1, default deny rules are split up and organized in deny rule groups. Each rule is now much more fine-grained and deals with a single aspect of a certain attack. This gives the user the additional option to deactive single sub-rules instead of complete groups. Also, exceptions can be added on sub-rules, if desired.

Deny rule groups with security levels in Airlock 5.1Figure 2: 1-click filter strength adjustment with security levels in Airlock 5.1

1-click Filter Strength Adjustment

Filtering is always a tradeoff between a good detection rate and a low false-positive rate. Making rules more strict catches more attempts to trick the system but usually triggers more false-positives as well. Depending on the application, different tradeoffs may be desired. For instance, a forum typically accepts a wider range of input values than a login screen.

To address this issue, Airlock now offers different security levels for deny rule groups instead of delivering a single rule set for each attack type (see Fig. 2). Thus, a login application may be protected by a strict XSS rule set while the forum uses the basic XSS rule set. The rule sets for different security levels are managed and updated by the Airlock security team. If desired, custom rule sets can be defined.


Airlock 5.1 comes with flexible and powerful deny rule exceptions. Whereas today parameter exceptions have a global scope, it is now possible to include conditions for all deny rule attributes in exceptions. That is, exceptions may for instance be configured for a certain path, content type, or IP address. In addition, several exceptions can be combined on a deny rule group or a single rule. This allows crafting deny rule exceptions like the following:

(parameter comment on path /forum/*) OR (source IP range 192.168.*.*) OR (header User-Agent contains iPhone)

Knowledge Base Categories: