Forum Discussion
CirrostratusASM_REQUEST_BLOCKING not being triggered in iRule
I believe it found the issue, as this is a response violation (it is not something bad send by the client, but the response the webserver sends is what should be blocked) it should be handled in the ASM_RESPONSE_VIOLATION event.
this iRule both logs the violation and allows me to rewrite the block page.
when ASM_RESPONSE_VIOLATION { log local0. "response violation" 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]" } }} ASM::payload replace 0 [ASM::payload length] "" ASM::payload replace 0 0 "12345607890" HTTP::header replace Content-Length [ASM::payload length] }logs
Oct 26 19:32:00 bigip-01 info tmm[20840]: Rule /Common/irule-asm_blockpage <ASM_RESPONSE_VIOLATION>: response violation Oct 26 19:32:00 bigip-01 info tmm[20840]: Rule /Common/irule-asm_blockpage <ASM_RESPONSE_VIOLATION>: violation=VIOLATION_REDIRECT Oct 26 19:32:00 bigip-01 info tmm[20840]: Rule /Common/irule-asm_blockpage <ASM_RESPONSE_VIOLATION>: support_id=5611810483771277404 Oct 26 19:32:00 bigip-01 info tmm[20840]: Rule /Common/irule-asm_blockpage <ASM_RESPONSE_VIOLATION>: web_application=/Common/asm-1 Oct 26 19:32:00 bigip-01 info tmm[20840]: Rule /Common/irule-asm_blockpage <ASM_RESPONSE_VIOLATION>: severity=Error Oct 26 19:32:00 bigip-01 info tmm[20840]: Rule /Common/irule-asm_blockpage <ASM_RESPONSE_VIOLATION>: attack_type=ATTACK_TYPE_OTHER_APPLICATION_ACTIVITY Oct 26 19:32:00 bigip-01 info tmm[20840]: Rule /Common/irule-asm_blockpage <ASM_RESPONSE_VIOLATION>: request_status=blockedonce you can confirm ill try to get the cloud docs updated. these things can be made a lot easier when a couple of extra lines explaining the different types of events.
CirrostratusIf I do that then my website will not be reached and I'll get this browser error message:
This page isn’t working
my.domain.com didn’t send any data.
ERR_EMPTY_RESPONSEI see the iRule triggered but with errors in /var/log/ltm :
Oct 12 07:30:07 My-F5 info tmm5[14584]: Rule /Common/ASM_custom_block_page_v3 <ASM_REQUEST_DONE>: hello world
Oct 12 07:30:08 My-F5 err tmm5[14584]: 011f0016:3: http_process_state_prepend - Invalid action:0x10a010 Server sends too much data. serverside (172.26.137.34:443 -> 172.26.137.46:6759) clientside (1.2.3.4:62170 -> 172.26.137.41:443) (Server side: vip=/Common/myserver_test profile=http pool=/Common/srv-myserver server_ip=172.26.137.34)
MVPso that was an interesting one, took me a few tries to get something working.
the cloud docs suggest that ASM::payload works in most of the ASM events, but for me it only seems to work in ASM_REQUEST_BLOCKING, well certainly the replace only works there.
there is also a known issue which shouldn't be an issue for 14.1 but is for me: https://support.f5.com/csp/article/K13696
so if you set the irule events mode to normal then you use ASM_REQUEST_DONE (instead of the two other ones) but can only check for what happened.
the replacing still has to happen in ASM_REQUEST_BLOCKING.
can you try something like this and show the ltm log output?
when ASM_REQUEST_DONE {
log local0. "req 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]" }
}}
}
when ASM_REQUEST_BLOCKING {
log local0. "req block"
ASM::payload replace 0 [ASM::payload length] ""
ASM::payload replace 0 0 "abcdefghi"
HTTP::header replace Content-Length [ASM::payload length]
}this is 14.1.2.3 (lab) btw, so things might have changed in 15.1 although i can't find details on that.
