ASM::violation

Description

Returns the list of violations found in the present request or response together with details on each one.

Syntax

ASM::violation count
ASM::violation names
ASM::violation attack_types
ASM::violation details

ASM::violation count

  • Returns the number of violations found in the request.

ASM::violation names

  • Returns a list with the names of the violations found in the transaction, both built-in and custom (user-defined). The expected names of the available violations can be obtained by looking up the list of violations on the BIG-IP device. If a violation happens more than once, it will appear as many times as the number of occurrences in the request or response. The order of the violations in the list is consistent throughout the other subcommands below that return lists. Thus, violation appearing index i of the list returned by ASM::violation names will have its corresponding attack type also in index i of the list returned by ASM::violation attack_types and its other details are index i in the list returned by ASM::violation details.

ASM::violation attack_types

  • Returns a list with the attack types corresponding to the violations returned in ASM::violation names.

ASM::violation details

  • Returns a list of multimaps, each multimap containing key-value pairs of details on the violations returned by ASM::violation names.

  • The schema of the details in each multimap, that is, the expected keys in the depends on the type of violation and is derived from the logger violation detail XML schema within the occurrences of the “violation_type” element. Each key is the XML element name, with flattened nested structure, such that elments within elements are spearated by dots, as in C structs. For example:

    • Attack signature violations have the following keys:
      • sig_data.sig_id
      • sig_data.blocking_mask
      • sig_data.kw_data_buffer
      • sig_data.kw_data_offset
      • sig_data.kw_data_length
    • Length violations on parameters have the following keys:
      • expected_value_length
      • actual_value_length
      • parameter_data.name
      • parameter_data.value

  • Note that in case of custom violation, the violation details multimap is formatted differently than the multimap used in the ASM::raise command! Rather than having each attribute be represented by its name and value like

    {{n1 v1} {n2 v2}}

    there will be recurring fixed variables named “customParameter.name” and “customParameter.value”, following the respective XML elements pointing to the name and value of the respective original custom parameters (see the “Raising custom violation” section). A particular name belongs to the value that follows just after it. So the previous example the result of “ASM::violation details” will be:

    {{customParameter.name n1} {customParameter.value v1} {customParameter.name n2} {customParameter.value v2}}
    .

Examples

when ASM_REQUEST_DONE {
  set i 0
  foreach {viol} [ASM::violation names]{
    if {$viol eq "VIOLATION_PARAM"} {
      set details [lindex [ASM::violation details] $i]
      set param_name [b64_decode [llookup $details "param_data.param_name"]]
      #remove the bad parameter from the QS - does not work right in all cases, just for illustration!
      regsub -all "\?.*($param_name=[^\&]*)" [HTTP::uri] "?" $new_uri
      HTTP::uri $new_uri
      ASM::unblock
    }
    set i [expr {$i+1}]
  }
}