ASM_REQUEST_DONE¶
Description¶
This event is triggered after ASM finished processing the request and
found all violations of the ASM policy, if there were any, and before
enforcing the action on the request, either forwarding to the server
or responding with a blocking page. In case the of 100-Continue
response, the event will be triggered after the body of the request
was received by the ASM. This event replaces the ASM_REQUEST_VIOLATION
event which is kept for backward compatibility. The iRules developer
can check whether there have been violations using the
ASM::status command.
Examples¶
when ASM_REQUEST_DONE
{
set x [ASM::violation_data]
for {set i 0} { $i < 7 } {incr i} {
switch $i {
0 { log local0. "violation=[lindex $x $i]" }
1 { log local0. "support_id=[lindex $x $i]" }
2 { log local0. "web_application=[lindex $x $i]" }
3 { log local0. "severity=[lindex $x $i]" }
4 { log local0. "source_ip=[lindex $x $i]" }
5 { log local0. "attack_type=[lindex $x $i]" }
6 { log local0. "request_status=[lindex $x $i]" }
}}
if {([lindex $x 0] contains "VIOLATION_EVASION_DETECTED")}
{
log local0. "VIOLATION_EVASION_DETECTED detected, uri=[HTTP::uri]"
HTTP::header insert header_1 value_1
ASM::payload replace 0 0 "1234567890"
} else {
log local0. "violation=[lindex $x 0]"
log local0. "Decided to route is to different pool"
HTTP::uri /index.php
pool phpauction
}
}