Actions required when upgrading

This section describes changes in Airlock Gateway 8.1 that may require manual actions. Read this section carefully to see whether your configuration is affected.

Downgrades from minor versions are no longer possible. This means after installing Airlock Gateway 8.1, you cannot uninstall it to revert back to Airlock Gateway 8.0. This is due to limitations of the underlying operating system. Uninstalling of Bugfix versions (e.g., 8.0.1 or 8.1.1) is still possible.

• Suggestions:
• Create Snapshots, if Airlock Gateway is operated as a virtual machine.
• Use system backup and restore.
• Export the current configuration.
• Ensure the installation media of the old release is available.

In Airlock Gateway 8.1, the new query parameter model (QPM) has been added. This anomaly detection model can detect parameter probing, tampering and polluting by monitoring request query parameters and values.

• Automatic upgrade actions:
• Updating from Airlock Gateway 8.0 to 8.1 will incorporate the QPM-related columns in your ColdDB.
• Existing Anomaly Shield models will be removed because the new version of Anomaly Shield does not accept old models (without QPM).

0. After the upgrade, the following approach for migration from 8.0 to 8.1 is suggested:
1. Re-train the models as described in the article Training and model enforcement.
2. After training, the prepared model will have an incomplete status, which is expected since ColdDB lacks training data for the new QPM model. Nevertheless, you can use all other models for anomaly detection while collecting new training data that include QPM values.
3. Enforce the incomplete model to secure your Anomaly Shield application as before the upgrade.
4. Enable training data collection for your Anomaly Shield application to collect traffic, including QPM values.
5. Wait until you have collected sufficient realistic production data in the ColdDB (see suggestions in article Enable training data collection).
6. Re-train your models and proceed with the follow-up configuration tasks.

• Suggested follow-up configuration tasks:
• Rules offer new IP Aggregation action features that should be enabled in order to identify and block suspicious IP addresses.
• Existing trigger patterns should be reconfigured using the new Query Parameters feature.

A best practice configuration for both topics can be found here.

By using Expert-Settings it is possible to track the client's session by a request header. Improvements required to change the settings to enable this feature. The feature itself is still available but other settings must be configured.

Discontinued, not available anymore in Gateway 8.1:

Session.Tracking.ExternalToken.Enable             "FALSE" 
Session.Tracking.ExternalToken.AllowTokenUpdate   "TRUE" 
Session.Tracking.ExternalToken.MaxLength          "256" 
  
Session.Tracking.ExternalToken.Request.Header.Pattern    "^Access-Token: ([[:graph:]]+)$" 
Session.Tracking.ExternalToken.Request.Header.IgnoreCase "TRUE" 
Session.Tracking.ExternalToken.Request.Header.Template   "$1" 
Session.Tracking.ExternalToken.Response.Header.Pattern    "^Authorization: Bearer ([[:graph:]]+)$" 
Session.Tracking.ExternalToken.Response.Header.IgnoreCase "TRUE" 
Session.Tracking.ExternalToken.Response.Header.Template   "$1" 

Replacement in Gateway 8.1 and newer:

Session.Tracking.HeaderToken.Enable                               "True" 
Session.Tracking.HeaderToken.Response.Header.Name                 "Access-Token" 
Session.Tracking.HeaderToken.Request.Header.Name                  "Authorization" 
Session.Tracking.HeaderToken.Request.Header.Value.Pattern         "^Bearer ([[:graph:]]+)$" 
Session.Tracking.HeaderToken.Request.Header.Value.IgnoreCase      "TRUE" 
Session.Tracking.HeaderToken.Request.Header.Value.Template        "$1"