13-Oct-2022 08:39 - edited 13-Oct-2022 08:41
When I attach DOS and BOT profiles with local traffic policy or iRule I always need a default BOT and DOS profile even when I have a default rule that catches all the traffic. That is one thing but the strangest thing is when I decide to attach a Bot profile with iRule it does not work but the Local traffic policies allow this.
I will need to test this but is really strange. This is the first time something is only possible with Local Traffic Policies but I will have to test if it works 🙂
Solved! Go to Solution.
13-Oct-2022 10:06
Two things:
13-Oct-2022 10:06
Two things:
14-Oct-2022 08:18 - edited 14-Oct-2022 09:19
Kevin to the rescue. Thanks and I tested it and it works fine. The bot defence has better whitelist based on url and/or Ip address not just ip address as the DOS profile but to stop a specific protection for API traffic based on HTTP header like Browser valudation and Device ID was not possible and started doing the irule below but the one that unblocks the client side challenge and it is suggested at https://clouddocs.f5.com/api/irules/BOTDEFENSE__cs_possible.html is wrong for me (the one irulefor deviceid is ok) as if the API traffic can't reply to javascript and this irule will not block it but this will also unblock it for every bot violation that will trigger TCP RST if I am not wrong or maybe as the other Bot violations returns support id web page maybe they will not match the tcp_rst.
Still thanks again!
https://clouddocs.f5.com/api/irules/BOTDEFENSE__cs_possible.html
https://clouddocs.f5.com/api/irules/BOTDEFENSE__cs_attribute.html
# EXAMPLE: Prevent blocking of requests that cannot be responded with a
# client-side challenge.
when BOTDEFENSE_ACTION {
if { ([BOTDEFENSE::action] eq "tcp_rst") &&
(not [BOTDEFENSE::cs_possible])} {
BOTDEFENSE::action allow
}
}
when BOTDEFENSE_REQUEST {
BOTDEFENSE::cs_attribute device_id enable
}