Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP ASM
Known Affected Versions:
11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2
Fixed In:
12.0.0, 11.6.0 HF6, 11.5.3 HF2
Opened: Jul 07, 2015 Severity: 3-Major
When importing a policy that utilizes a custom signature set, ASM checks whether that signature set is already exists on the system. If it does not exist, then it creates a new set. When a set is created via REST it does not correctly set an internal field that does get set via creation by the GUI or XML import. This causes unexpected behavior and extra signatures being created when a REST client, such as BIG-IQ, attempts to co-ordinate changes across devices utilizing import via XML and REST calls.
Extraneous signature sets are created, and false differences appear with regards to which signature sets are attached to which policies across multiple devices.
A Custom filter-based signature set is created by the GUI and then attached to a security policy. The security is exported in XML format. On a different device an identical signature set is created via REST. The security policy is then imported on that device.
As a workaround, custom filter-based signature sets should be created only via REST or only via GUI across multiple devices.
Custom filter-based signature sets created using REST or the Configuration utility now have the same internal settings and match for XML security policy export/import.