Actions required when upgrading
Airlock Gateway 7.8 - Actions required when upgrading

This section describes changes in Airlock Gateway 7.8 that may require manual actions. Usually, manual intervention is only necessary in corner cases. Please read this section carefully to see whether your configuration is affected.

Explicit header allow/block lists

The header white- and blacklist actions are turned into explicit header allow and deny lists, clearly separating Airlock-maintained defaults and custom headers. Configurations are migrated to use the new feature during the update.

However, when using the mapping import functionality on Airlock Gateway 8.0 to import mappings from earlier versions, option INHERIT for these actions can't be properly migrated. For imported white- and blacklist actions with INHERIT flag, the following defaults will be set:

  • Default request header allow list: ON
  • Default request header deny list: ON
  • Default response header allow list: OFF
  • Default request header deny list: ON

Airlock Anomaly Shield: Cold DB and trained models will be resetted

Due to substantial extensions of the machine learning models, the cold DB and models trained with earlier versions will be resetted.

REST API changes

See Airlock Gateway REST API Changes for a summary of changes on the REST API.

Kibana Saved Objects

Kibana searches, visualizations, and dashboards will be updated. Modifications to Airlock dashboards will be overwritten and custom objects will be removed. In case you have created custom Kibana objects, make sure to export them prior to the update and import them again after the update (Reporting -> Management -> Saved Objects).

Deny Rule Updates

Default Deny Rules have been improved and extended. Critical applications should be tested in a pre-production environment. In summary, the following changes were made:

  • New Rules
  • Rules SAN_080, SAN_090, SAN_100, SAN_110 and SAN_120 have been added to the default Header Value Sanity Rules group. The rules validate the well defined format of certain standard HTTP request headers. The rules do not preform exact RFC checks because many standard clients violate RFCs.
  • Rule TI_001 has been split in two Rules, TI_001 and TI_002, both in Security Level Standard. Exceptions on TI_001 are not copied to TI_002.
  • Deleted Rules
  • The strict rule HPE_001 has been deleted due to false positives. In its place, a less strict version of the rule, HPE_005, will protect from response header injection attacks. HPE_005 was already present in previous releases and has now been linked to all security levels basic, standard and strict.
  • Security improvements
  • Rule PHP_002 does not recognize the special characters U+00A0 and U+0085 as whitespaces anymore.
  • Multiple security improvements for UNIX and SQL Rules. Thanks to our bug bounty program the rules have been improved to block new possible attacks that have been brought to our attention.
  • XSS rules recognize and correctly match multiple special characters that were not recognized before.
  • Performance improvement and false positives reduction
  • Rule SQL_050 will not check X-Forwarded-Host and X-ClientStatstics header values anymore.
  • Rule SAN_060 will not limit the length of the Accept-Language header value anymore.
  • Content-Type und Sec-WebSocket-Key Headers Value will not be checked anymore by the following Rules: LDAP_001, LDAP_002, HTML_001, HTML_002, UNIX_001, SQL Rules 005, 025, 040, 045, 055, 060, 065 and XSS Rules 030, 035, 040, 050, 055.