|
| 1 | +--- |
| 2 | +# We use sentence case and present imperative tone |
| 3 | +title: "Attack signatures" |
| 4 | +# Weights are assigned in increments of 100: determines sorting order |
| 5 | +weight: 300 |
| 6 | +# Creates a table of contents and sidebar, useful for large documents |
| 7 | +toc: true |
| 8 | +# Types have a 1:1 relationship with Hugo archetypes, so you shouldn't need to change this |
| 9 | +nd-content-type: reference |
| 10 | +# Intended for internal catalogue and search, case sensitive: |
| 11 | +# Agent, N4Azure, NIC, NIM, NGF, NAP-DOS, NAP-WAF, NGINX One, NGINX+, Solutions, Unit |
| 12 | +nd-product: NAP-WAF |
| 13 | +--- |
| 14 | + |
| 15 | +## Overview |
| 16 | + |
| 17 | +Attack signatures are rules or patterns that identify attack sequences or classes of attacks on a web application and its components. You can apply attack signatures to both requests and responses. F5 WAF for NGINX includes predefined attack signatures to protect your application against all attack types identified by the system. |
| 18 | + |
| 19 | +As new attack signatures are identified, they will become available for download and installation so that your system will always have the most up-to-date protection. You can update the attack signatures without updating F5 WAF for NGINX, and conversely, you can update F5 WAF for NGINX without changing the attack signature package, unless you upgrade to a new NGINX Plus release. |
| 20 | + |
| 21 | +### Signature settings |
| 22 | + |
| 23 | +| Setting | JSON property | F5 WAF for NGINX support | Default value | |
| 24 | +| --------| ------------- | ------------------------ | ------------- | |
| 25 | +| Signature sets | signature-sets | All available sets. | See signature set list below | |
| 26 | +| Signatures | signatures | "Enabled" flag can be modified. | All signatures in the included sets are enabled. | |
| 27 | +| Auto-Added signature accuracy | minimumAccuracyForAutoAddedSignatures | Editable | Medium | |
| 28 | + |
| 29 | +### Signature sets |
| 30 | + |
| 31 | +The default and strict policies include and enable common signature sets, which are categorized groups of [signatures](#attack-signatures-overview) applied to the policy. However, you may wish to modify the list of signature sets and their logging and enforcement settings via the `signature-sets` array property. There are several ways to configure the enforced signature sets. |
| 32 | + |
| 33 | +One way is by use of the `All Signatures` signature set, which is simply a predefined signature set that includes all signatures known to NGINX App Protect WAF. |
| 34 | + |
| 35 | +In this example, the `All Signatures` set (and therefore the signatures included within) are configured to be enforced and logged respectively, by setting their `block` and `alarm` properties: |
| 36 | + |
| 37 | +```json |
| 38 | +{ |
| 39 | + "policy": { |
| 40 | + "name": "attack_sigs", |
| 41 | + "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, |
| 42 | + "applicationLanguage": "utf-8", |
| 43 | + "enforcementMode": "blocking", |
| 44 | + "signature-sets": [ |
| 45 | + { |
| 46 | + "name": "All Signatures", |
| 47 | + "block": true, |
| 48 | + "alarm": true |
| 49 | + } |
| 50 | + ] |
| 51 | + } |
| 52 | +} |
| 53 | +``` |
| 54 | + |
| 55 | +In this example, only high accuracy signatures are configured to be enforced, but SQL Injection signatures are detected and reported: |
| 56 | + |
| 57 | +```json |
| 58 | +{ |
| 59 | + "policy": { |
| 60 | + "name": "attack_sigs", |
| 61 | + "template": { |
| 62 | + "name": "POLICY_TEMPLATE_NGINX_BASE" |
| 63 | + }, |
| 64 | + "applicationLanguage": "utf-8", |
| 65 | + "enforcementMode": "blocking", |
| 66 | + "signature-sets": [ |
| 67 | + { |
| 68 | + "name": "High Accuracy Signatures", |
| 69 | + "block": true, |
| 70 | + "alarm": true |
| 71 | + }, |
| 72 | + { |
| 73 | + "name": "SQL Injection Signatures", |
| 74 | + "block": false, |
| 75 | + "alarm": true |
| 76 | + } |
| 77 | + ] |
| 78 | + } |
| 79 | +} |
| 80 | +``` |
| 81 | + |
| 82 | +Since the "All Signatures" set is not included in the default policy, turning OFF both alarm and block has no effect because all the other sets with alarm turned ON (and high accuracy signatures with block enabled) are still in place and a signature that is a member of multiple sets behaves in accordance with the strict settings of all sets it belongs to. The only way to remove signature sets is to remove or disable sets that are part of the [default policy](#signature-sets-in-default-policy). |
| 83 | + |
| 84 | +For example, in the below default policy, even though All Signature's Alarm/Block settings are set to false, we cannot ignore all attack signatures enforcement as some of the signature sets will be enabled in their strict policy. If the end users want to remove a specific signature set then they must explicitly mention it under the [strict policy](#the-strict-policy). |
| 85 | + |
| 86 | +```json |
| 87 | +{ |
| 88 | + "policy": { |
| 89 | + "name": "signatures_block", |
| 90 | + "template": { |
| 91 | + "name": "POLICY_TEMPLATE_NGINX_BASE" |
| 92 | + }, |
| 93 | + "applicationLanguage": "utf-8", |
| 94 | + "caseInsensitive": false, |
| 95 | + "enforcementMode": "blocking", |
| 96 | + "signature-sets": [ |
| 97 | + { |
| 98 | + "name": "Generic Detection Signatures (High/Medium Accuracy)", |
| 99 | + "block": false, |
| 100 | + "alarm": false |
| 101 | + }, |
| 102 | + { |
| 103 | + "name": "All Signatures", |
| 104 | + "block": false, |
| 105 | + "alarm": false |
| 106 | + } |
| 107 | + ] |
| 108 | + } |
| 109 | +} |
| 110 | +``` |
| 111 | + |
| 112 | +A signature may belong to more than one set in the policy. Its behavior is determined by the most severe action across all the sets that contain it. In the above example, a high accuracy SQL injection signature will both alarm and block, because the `High Accuracy Signatures` set is blocking and both sets trigger alarm. |
| 113 | + |
| 114 | +The default policy already includes many signature sets, most of which are determined by the attack type these signatures protect from, for example `Cross-Site Scripting Signatures` or `SQL Injection Signatures`. See [the full list](#signature-sets-in-default-policy) above. In some cases you may want to exclude individual signatures. |
| 115 | + |
| 116 | +In this example, signature ID 200001834 is excluded from enforcement: |
| 117 | + |
| 118 | +```json |
| 119 | +{ |
| 120 | + "policy": { |
| 121 | + "name": "signature_exclude", |
| 122 | + "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, |
| 123 | + "applicationLanguage": "utf-8", |
| 124 | + "enforcementMode": "blocking", |
| 125 | + "signature-sets": [ |
| 126 | + { |
| 127 | + "name": "All Signatures", |
| 128 | + "block": true, |
| 129 | + "alarm": true |
| 130 | + } |
| 131 | + ], |
| 132 | + "signatures": [ |
| 133 | + { |
| 134 | + "signatureId": 200001834, |
| 135 | + "enabled": false |
| 136 | + } |
| 137 | + ] |
| 138 | + } |
| 139 | +} |
| 140 | +``` |
| 141 | + |
| 142 | +Another way to exclude signature ID 200001834 is by using the `modifications` section instead of the `signatures` section used in the example above: |
| 143 | + |
| 144 | +```json |
| 145 | +{ |
| 146 | + "policy": { |
| 147 | + "name": "signature_modification_entitytype", |
| 148 | + "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, |
| 149 | + "applicationLanguage": "utf-8", |
| 150 | + "enforcementMode": "blocking", |
| 151 | + "signature-sets": [ |
| 152 | + { |
| 153 | + "name": "All Signatures", |
| 154 | + "block": true, |
| 155 | + "alarm": true |
| 156 | + } |
| 157 | + ] |
| 158 | + }, |
| 159 | + "modifications": [ |
| 160 | + { |
| 161 | + "entityChanges": { |
| 162 | + "enabled": false |
| 163 | + }, |
| 164 | + "entity": { |
| 165 | + "signatureId": 200001834 |
| 166 | + }, |
| 167 | + "entityType": "signature", |
| 168 | + "action": "add-or-update" |
| 169 | + } |
| 170 | + ] |
| 171 | +} |
| 172 | +``` |
| 173 | + |
| 174 | +To exclude multiple attack signatures, each signature ID needs to be added as a separate entity under the `modifications` list: |
| 175 | + |
| 176 | +```json |
| 177 | +{ |
| 178 | + "modifications": [ |
| 179 | + { |
| 180 | + "entityChanges": { |
| 181 | + "enabled": false |
| 182 | + }, |
| 183 | + "entity": { |
| 184 | + "signatureId": 200001834 |
| 185 | + }, |
| 186 | + "entityType": "signature", |
| 187 | + "action": "add-or-update" |
| 188 | + }, |
| 189 | + { |
| 190 | + "entityChanges": { |
| 191 | + "enabled": false |
| 192 | + }, |
| 193 | + "entity": { |
| 194 | + "signatureId": 200004461 |
| 195 | + }, |
| 196 | + "entityType": "signature", |
| 197 | + "action": "add-or-update" |
| 198 | + } |
| 199 | + ] |
| 200 | +} |
| 201 | +``` |
| 202 | + |
| 203 | +In the above examples, the signatures were disabled for all the requests that are inspected by the respective policy. You can also exclude signatures for specific URLs or parameters, while still enable them for the other URLs and parameters. See the sections on [User-Defined URLs](#user-defined-urls) and [User-Defined Parameters](#user-defined-parameters) for details. |
| 204 | + |
| 205 | +In some cases, you may want to remove a whole signature set that was included in the default policy. For example, suppose your protected application does not use XML and hence is not exposed to XPath injection. You would like to remove the set `XPath Injection Signatures`. There are two ways to do that. The first is to set the `alarm` and `block` flags to `false` for this signature set overriding the settings in the base template: |
| 206 | + |
| 207 | +```json |
| 208 | +{ |
| 209 | + "policy": { |
| 210 | + "name": "no_xpath_policy", |
| 211 | + "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, |
| 212 | + "signature-sets": [ |
| 213 | + { |
| 214 | + "name": "XPath Injection Signatures", |
| 215 | + "block": false, |
| 216 | + "alarm": false |
| 217 | + } |
| 218 | + ] |
| 219 | + } |
| 220 | +} |
| 221 | +``` |
| 222 | + |
| 223 | +The second way is to remove this set totally from the policy using the `$action` meta-property. |
| 224 | + |
| 225 | +```json |
| 226 | +{ |
| 227 | + "policy": { |
| 228 | + "name": "no_xpath_policy", |
| 229 | + "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, |
| 230 | + "signature-sets": [ |
| 231 | + { |
| 232 | + "name": "XPath Injection Signatures", |
| 233 | + "$action": "delete" |
| 234 | + } |
| 235 | + ] |
| 236 | + } |
| 237 | +} |
| 238 | +``` |
| 239 | + |
| 240 | +Although the two methods are functionally equivalent, the second one is preferable for performance reasons. |
| 241 | + |
| 242 | +The following signature sets are included in the default policy. Most of the sets are defined by the Attack Type they protect from. In all sets the **Alarm** flag is enabled and **Block** disabled except High Accuracy Signatures, which are set to **blocked** (`block` parameter is enabled). |
| 243 | + |
| 244 | +- Command Execution Signatures |
| 245 | +- Cross Site Scripting Signatures |
| 246 | +- Directory Indexing Signatures |
| 247 | +- Information Leakage Signatures |
| 248 | +- OS Command Injection Signatures |
| 249 | +- Path Traversal Signatures |
| 250 | +- Predictable Resource Location Signatures |
| 251 | +- Remote File Include Signatures |
| 252 | +- SQL Injection Signatures |
| 253 | +- Authentication/Authorization Attack Signatures |
| 254 | +- XML External Entities (XXE) Signatures |
| 255 | +- XPath Injection Signatures |
| 256 | +- Buffer Overflow Signatures |
| 257 | +- Denial of Service Signatures |
| 258 | +- Vulnerability Scan Signatures |
| 259 | +- High Accuracy Signatures |
| 260 | +- Server Side Code Injection Signatures |
| 261 | +- CVE Signatures |
| 262 | + |
| 263 | +These signatures sets are included but are not part of the default template. |
| 264 | + |
| 265 | +- All Response Signatures |
| 266 | +- All Signatures |
| 267 | +- Generic Detection Signatures |
| 268 | +- Generic Detection Signatures (High Accuracy) |
| 269 | +- Generic Detection Signatures (High/Medium Accuracy) |
| 270 | +- High Accuracy Signatures |
| 271 | +- Low Accuracy Signatures |
| 272 | +- Medium Accuracy Signatures |
| 273 | +- OWA Signatures |
| 274 | +- WebSphere signatures |
| 275 | +- HTTP Response Splitting Signatures |
| 276 | +- Other Application Attacks Signatures |
| 277 | +- High Accuracy Detection Evasion Signatures |
0 commit comments