waf
2 TopicsTrigger js challenge/Captcha for ip reputation/ip intelligence categories
Problem solved by this Code Snippet Because some ISP or cloud providers do not monitor their users a lot of times client ip addresses are marked as "spam sources" or "windows exploits" and as the ip addresses are dynamic and after time a legitimate user can use this ip addresses the categories are often stopped in the IP intelligence profile or under the ASM/AWAF policy. To still make use of this categories the users coming from those ip addresses can be forced to solve captcha checks or at least to be checked for javascript support! How to use this Code Snippet Have AWAF/ASM and ip intelligence licensed Add AWAF/ASM policy with irule support option (by default not enabled under the policy) or/and Bot profile under the Virtual server Optionally add IP intelligence profile or enable the Ip intelligence under the WAF policy without the categories that cause a lot of false positives, Add the irule and if needed modify the categories for which it triggers Code Snippet Meta Information Version: 17.1.3 Coding Language: TCL Code You can find the code and further documentation in my GitHub repository: reputation-javascript-captcha-challlenge/ at main · Nikoolayy1/reputation-javascript-captcha-challlenge when HTTP_REQUEST { # Take the ip address for ip reputation/intelligence check from the XFF header if it comes from the whitelisted source ip addresses in data group "client_ip_class" if { [HTTP::header exists "X-Forwarded-For"] && [class match [IP::client_addr] equals "/Common/client_ip_class"] } { set trueIP [HTTP::header "X-Forwarded-For"] } else { set trueIP [IP::client_addr] } # Check if IP reputation is triggered and it is containing "Spam Sources" if { ([llength [IP::reputation $trueIP]] != 0) && ([IP::reputation $trueIP] contains "Spam Sources") }{ log local0. "The category is [IP::reputation $trueIP] from [IP::client_addr]" # Set the variable 1 or bulean true as to trigger ASM captcha or bot defense javascript set js_ch 1 } else { set js_ch 0 } # Custom response page just for testing if there is no real backend origin server for testing if {!$js_ch} { HTTP::respond 200 content { <html> <head> <title>Apology Page</title> </head> <body> We are sorry, but the site you are looking for is temporarily out of service<br> If you feel you have reached this page in error, please try again. </body> </html> } } } # when BOTDEFENSE_ACTION { # Trigger bot defense action javascript check for Spam Sources # if {$js_ch}{ # BOTDEFENSE::action browser_challenge # } # } when ASM_REQUEST_DONE { # Trigger ASM captcha check only for users comming from Spam sources that have not already passed the captcha check (don't have the captcha cookie) if {$js_ch && [ASM::captcha_status] ne "correct"} { set res [ASM::captcha] if {$res ne "ok"} { log local0. "Cannot send captcha_challenge: \"$res\"" } } }20Views0likes0CommentsAWS Advanced HA iApp
Problem this snippet solves: SUMMARY For customers who want to deploy Public Internet-facing services on a traditional High Availability pair but also leverage the benefits of AWS’s Availability Zones, we introduce the AWS Advanced HA iApp. The AWS Advanced HA iApp helps facilitate the HA Across AZs deployment, an additional deployment option to those discussed in: F5 in AWS Part 1 - AWS Networking Basics F5 in AWS Part 2 - Running BIG-IP in an EC2 Virtual Private Cloud F5 in AWS Part 3 - Advanced Topologies and More on Highly Available Services As well as enable traditional HA pairs to perform basic route management of AWS route tables (whether in “Single AZ” or the “Across AZ” deployments introduced above). By having the Active BIG-IP take ownership of your client’s or application’s “default” or specific routes, this enables: Virtual Servers to avoid using SNAT* Manage Access Traffic (ex. point clients/servers to BIG-IP APM VPN for specific on-prem networks)* Facilitate various outbound proxy use cases (NAT, URI filtering, etc) For more information, see the Deployment Guide Minimum required BIG-IP version: 12.1.0 HF2. Supported BIG-IP versions: 12.1.0 HF2. Various Cloud Formation Templates that automate the installation of this solution are available on github. They are listed under the naming format "full-stack-across-az-cluster-*" We recommend you first start with "full-stack-" examples to get a fully functioning reference deployment and the "existing-*" ones once you're comfortable with the general requirements (security groups, route tables, etc). RELEASES v1.0.0 iApp template to configure HA Across Availability Zones in AWS by managing EIP mappings. v1.0.1 iApp template to configure HA Across Availability Zones in AWS by managing EIP and route mappings. v1.0.1rc1 This version 1.0.1rc1 of the iApp template is available at downloads.f5.com. This official release candidate version contains the same functionality as the previous version (v1.0.1 on DevCentral), but the presentation has been updated. There is also a new F5 deployment guide to accompany the iApp template. Go to https://downloads.f5.com/esd/index.jsp.2. Click Find a Download. Click iApp Templates. Accept the EULA, and then download the iapps zip file to a location accessible from your BIG-IP system. Extract (unzip) the f5.aws_advanced_ha.v1.0.1rc1.tmpl file, found in the **_RELEASE CANDIDATE_** directory of the zip file. v1.1.0rc1 This version 1.1.0rc1 template is available for download on this page. F5 has released version 1.1.0rc1 of the iApp. This official release candidate version contains the same functionality as the previous version (v1.0.1rc1 on DevCentral), with further checks and support added for AWS EIP ownership. In previous versions, EIP ownership was indicated by which device owns the default floating traffic-group-1. As there was only one floating traffic group, this affected the global Active/Standby status of the devices. This iApp has been updated to validate EIP ownership after an active-active state scenario and ensures the current EIP owner is Active for traffic-group-1 (the traffic-group tied to the EIP mappings). CAVEATS Both BIG-IP devices will now report active for their global status, as each device will now own a device specific traffic group. The active status of the default floating traffic-group-1 will indicate which BIG-IP device is actively serving EIP production traffic. The BIG-IP hostname should not be changed during an active deployment of this iApp. This solution only supports the 3 traffic groups as described above. INSTALLATION If you are using a previous version of this iApp and need to update the application service with this updated iApp, there are two prerequisites before you run this iApp: Remove from the file /config/failover/active this line "python /config/failover/aws_advanced_failover.py” Delete the file /config/failover/aws_advanced_failover.py entirely Reparent the application service to use the new version of iApp template This new version will modify the following files in /config/failover on first configuration run tgactive (modify) tgstandby (modify) and install the following aws_af_tgactive aws_af_tgstandby aws_advanced_failover.py aws_advanced_failover.dat On subsequent reconfiguration, it updates the above 4 files listed. v1.2.0rc1 This version 1.2.0rc1 template is available for download on this page. F5 has released version 1.2.0rc1 of the iApp. This official release candidate version contains the same functionality as the previous version (v1.0.1rc1 on DevCentral, or v1.1.0rc1), with further checks and support added for AWS EIP ownership. In previous versions, EIP ownership was indicated by which device owns the default floating traffic-group-1. As there was only one floating traffic group, this affected the global Active/Standby status of the devices. This iApp has been updated to validate EIP ownership after an active-active state scenario and ensures the current EIP owner is Active. CAVEATS Noted caveats from v1.1.0rc1 removed. INSTALLATION If you are using a previous version of this iApp and need to update the application service with this updated iApp, there are a few prerequisites before you run this iApp: Remove from the file /config/failover/active this line "python /config/failover/aws_advanced_failover.py” Delete the file /config/failover/aws_advanced_failover.py entirely Delete the file /config/failover/aws_af_tgactive (if previous version is v1.1.0rc1) Delete the file /config/failover/aws_af_tgstandby (if previous version is v1.1.0rc1) Reparent the application service to use the new version of iApp template This new version will modify the following files in /config/failover on first configuration run tgactive (modify) tgstandby (modify) tgrefresh (modify) and install the following aws_advanced_failover.py aws_advanced_failover.dat On subsequent reconfiguration, it updates the above 2 files listed. Code : 708281.2KViews0likes3Comments