Is XFF a must for ASM WAF DoS
In this article it is mentioned that you must configure "Accept XFF" in HTTP profile in order to use DOS or Bot protection. https://my.f5.com/manage/s/article/K000133493 "HTTP profile is required also and have XFF enabled is the minimum setting needed" On the other hand in this article it says https://my.f5.com/manage/s/article/K36452759 "If the setting "Accept XFF" is not enabled in the HTTP profile associated with the virtual server using bot or DoS, then the source IP of the traffic as it arrives to the BIG-IP will be used instead." "Note: Ensure this header name is inserted by a trusted source. If you do not trust the header showing the original client IP it may be maliciously altered." "XFF, or equivalent client IP headers, must be configured to be trusted in the HTTP profile for use with Bot Defense and Application DoS profiles" This creates some confusion It is unclear whether XFF is a mandatory. Is it? If there is no trusted proxy in front of F5 and the the actual source IP (as it arrives at F5) is the public source IP, which is the relevant IP to us, does "Accept XFF" still need to be configured? Thank you
Dos Attacks not showing on dashboard
Issue: DoS attacks are not showing on the DoS dashboard. Information: Strange part is this was working but then I made a few changes to split this particular virtual server into internal and external VIPs only apply DoS profile to external VIP. I have a DoS logging profile enabled on this VS I know attacks are happening as I can see them under Security > Event logs > DoS > Application Events However, any of the new attack ids don’t show under the DoS Dashboard located Security > Reporting > DoS > Dashboards Any thoughts on how to fix would be much appreciated? Thanks!Why does the Local Traffic policy allow Bot profile to be selected but the iRule can't ?
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 🙂
traffic flow between IPI, application security policy, bot detection, DoS protection, irule, and geolocation
I want to know how the traffic flow between IPI, application security policy, bot detection, DoS protection, irule, and Geolocation (using irule for Geolocation). I am using Global IPI (mean IPI does not attached to any VS) and have an irule for Geolocation and only have module ASM and LTM (No APM and AFM). I understand that irule can be arranged by the order. The application security policy, bot detection, DoS protection, irule are attached to VS. Here is what I understand the traffic flow. The traffic hits Global IPI -> reached VS for irules in order (including Geolocation, I always put Geolocation at first place) -> Application security policy -> DoS -> Bot detection. Is this correct? Or will application security policy , Dos, Bot detection happen at the same time? What is the best practice for Geolocation? Using an irule for Geolocation or using Geolocation in application security policy?
IP-Intelligence Manual Additions and Bad Actor Additions Not Working
Greetings dev central community, I have come to impasses in two goals on a 15.1.0.5 VE running in esxi related to IP-Intelligence configuration and I would very much appreciate direction for resolution. Impasse 1: Having my manually added IP address be respected by the IP-Intelligence policy. Though pre-existing blacklisted sources are dropped with my configuration, my manually added IP addresses added via are not respected. I'm adding the IP addresses to my categories configured for drop in my IP-Intelligence policy via Security ›› Network Firewall : IP Intelligence : Blacklist Categories >> Add to Category. I've tried with public and private IP's. I've tried with pre-existing and custom blacklist categories. My license is valid. iprep_lookup from the CLI shows no verdict/category for the manually added IP's. Where as the GUI "Check Entry" button shows the IP address as present in the blacklisted category. Impasse 2: DoS blacklisting via Bad Actor Detection is not updating the blacklist category with the offending IP address. My tests have been done via Device DoS Protection via ICMPv4 flooding. I can see the attack vector being rate limited in DoS logs. My settings to add to the bad actor to the blacklist category are set low (Sustained Attack Detection Time of 10 seconds). Even if my test source attacks for a prolonged period of time and is mitigated for this prologed period of time, the address never shows up in the blacklist category specified. I have tried custom categories as well as the pre-made denial-of-service category. I have selected to advertise externally and I have BGP setup to redistribute kernel. Regardless, the IP address that should be shunned does not show up in the routing table as a local blackholed kernel route nor does it show up in the upstream BGP peer as a blackholed route. Manually configured blackholed routes are propogated properly via redistribute kernel. GUI "Check Entry" button does not show the IP address as present in the specified bad actor specified category. I have tried triggering the attack vector/bad actor protection private IP's as well as spoofed public IP's. list security dos device-config dos-device-vector icmpv4-flood allow-advertisement enabled allow-upstream-scrubbing disabled attacked-dst disabled auto-blacklisting enabled auto-scrubbing disabled auto-threshold disabled bad-actor enabled blacklist-category denial_of_service blacklist-detection-seconds 10 blacklist-duration 14400 ceiling 200000 default-internal-rate-limit 100000 detection-threshold-percent 500 detection-threshold-pps 10000 enforce enabled floor 100 multiplier-mitigation-percentage 300 packet-types none per-dst-ip-detection-pps infinite per-dst-ip-limit-pps infinite per-source-ip-detection-pps 1000 per-source-ip-limit-pps 10000 scrubbing-category attacked_ips scrubbing-detection-seconds 10 scrubbing-duration 900 simulate-auto-threshold disabled state mitigate suspicious false threshold-mode manual-multiplier-mitigation valid-domains none
