ltm rule command ASM violation

iRule(1)		      BIG-IP TMSH Manual		      iRule(1)



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

SYNOPSIS
       ASM::violation (count | names | attack_types | details)

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

       Syntax

       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 in 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 in 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:
		      o sig_data.sig_id
		      o sig_data.blocking_mask
		      o sig_data.kw_data_buffer
		      o sig_data.kw_data_offset
		      o sig_data.kw_data_length
		 + Length violations on parameters have the following keys:
		      o expected_value_length
		      o actual_value_length
		      o parameter_data.name
		      o 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}}

RETURN VALUE
VALID DURING
       ASM_REQUEST_DONE, ASM_REQUEST_VIOLATION, ASM_RESPONSE_VIOLATION

EXAMPLES
	when ASM_REQUEST_DONE {
	  set i 0
	  foreach {viol} [ASM::violation names]{
	    if {$viol eq "VIOLATION_ILLEGAL_PARAMETER"} {
	      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}]
	  }
	}

HINTS
SEE ALSO
CHANGE LOG
       @BIGIP-11.5.0 --First introduced the command.



BIG-IP				  2017-01-31			      iRule(1)