Enhancing the F5 DoD Banner with EU CAPTCHA (Myra) & Sideband Validation
Features & Security Hardening (v1.3) Besides the frontend EU CAPTCHA integration, this iRule introduces several security hardening measures (P3–P9): Strict POST Enforcement: Banner acceptance is strictly limited to POST requests. Content-Security-Policy (CSP): Implements restrictive HTTP headers tailored to safely allow the CAPTCHA's verify.js script to execute. Overview and Benefits of Myra EU CAPTCHA Myra EU CAPTCHA is a bot protection solution developed in Germany. It is positioned as a sovereign, European, and 100% GDPR-compliant alternative to traditional American providers (such as Google reCAPTCHA or Cloudflare Turnstile, which are subject to the CLOUD Act). Key Features: Seamless User Experience (Zero-Click): Verification is performed automatically in the background using cryptographic calculations. The user does not need to take any action (no visual puzzles to solve, no traffic lights to identify). The system is therefore completely accessible and barrier-free. Privacy by Design: The solution operates entirely without cookies and does not use any persistent storage in the browser (meaning you do not need to add a cookie consent banner). Furthermore, no personal data is stored, and any potentially identifying metadata is anonymized using a hashing system. Security and Sovereignty: Built on Myra Security technology, the solution relies on the analysis of over 100 billion daily CDN signals. Customers benefit from a certified sovereign technology (ISO 27001, BSI C5, PCI DSS) and can mandate that data processing takes place exclusively in data centers located in Germany or within the European Union. https://www.eu-captcha.eu/ https://docs.eu-captcha.eu/integration/frontend/html-integration/ Implementation Steps 1. Configure the Internal Sideband Virtual Server The iRule requires an internal Virtual Server to route API traffic to Myra. Create a file named eucaptcha-sideband-vs.conf in /var/tmp/ on your BIG-IP with the following content: ltm node /Common/node-api.eu-captcha.eu { fqdn { autopopulate enabled interval ttl name api.eu-captcha.eu } } ltm monitor https /Common/hm_myra_eucaptcha_https { adaptive disabled defaults-from /Common/https destination *:* interval 20 ip-dscp 0 recv HTTP/1 recv-disable none send "GET / HTTP/1.1\r\nHost: api.eu-captcha.eu\r\nConnection: close\r\n\r\n" time-until-up 0 timeout 21 } ltm pool /Common/pool_eucaptcha_api { members { /Common/node-api.eu-captcha.eu:https { } } monitor /Common/hm_myra_eucaptcha_https } ltm profile server-ssl /Common/server-api.eu-captcha.eu { app-service none defaults-from /Common/serverssl server-name api.eu-captcha.eu sni-default true } ltm virtual /Common/vs_dod_eucaptcha_sb { destination 10.10.10.8:webcache ip-protocol tcp mask 255.255.255.255 pool /Common/pool_eucaptcha_api profiles { /Common/http { } /Common/server-api.eu-captcha.eu { context serverside } /Common/tcp { } } serverssl-use-sni enabled source 0.0.0.0/0 source-address-translation { type automap } translate-address enabled translate-port enabled } Note: This configuration creates the necessary node, pool, Server SSL profile (with SNI enabled), and the internal Virtual Server vs_dod_eucaptcha_sb Merge this configuration into your BIG-IP via tmsh: tmsh load sys config merge file /var/tmp/eucaptcha-sideband-vs.conf 2. Generate Your Local HMAC Key To ensure the integrity of the banner acceptance cookie, generate a robust random string on your BIG-IP bash shell: openssl rand -hex 32 3. Deploy the iRule Create a new iRule on your BIG-IP and paste the source code. You must update the RULE_INIT block with your specific values: when RULE_INIT { set static::dod_banner_ttl 600 set static::dod_banner_hmac_key "PASTE_YOUR_OPENSSL_HEX_KEY_HERE" set static::eucaptcha_sitekey "YOUR_EUCAPTCHA_SITEKEY" set static::eucaptcha_secret "YOUR_EUCAPTCHA_SECRET" set static::eucaptcha_sideband_vs "vs_dod_eucaptcha_sb" # Trusted proxy CIDRs (empty = IP::client_addr only). Ex. : list "10.0.0.0/8" set static::dod_banner_trusted_proxy_cidrs [list] # Max acceptations / IP / window (seconds) set static::dod_banner_accept_rate_limit 10 set static::dod_banner_accept_rate_window 60 } Note: The HTML payload is embedded in the iRule and handles the frontend display and token submission. 4. Attach to your Virtual Server Attach the iRule to the public-facing Virtual Server protecting your application. Validation & Testing Open an Incognito/Private browsing window and navigate to your application. You should be intercepted by the DoD warning banner containing the EU CAPTCHA widget. Solve the challenge. The "I Accept" (J'ai pris connaissance et j'accepte) button will enable. Submit the form. The BIG-IP will validate the token via sideband, generate an HMAC-signed _si_gate cookie, and redirect you to the application. Refresh the page; the banner should be bypassed as long as the cookie remains valid (default 600 seconds). Credits Special thanks to Eric Haupt for the original repository that made this possible: https://github.com/hauptem/F5-LTM-iRule-based-DoD-Banners
No CAPTCHA - URL is not yet qualified for challenge injection
Hi, I am setting up Brute Force protection in ASM and have noted that I can get this drop traffic and alert, but when attempting to show the CAPTCHA, I only get the blocking page we have configured. The help notes that this occurs when the URL is not yet qualified for challenge injection, but the help also provides no details how to correct this. Can anyone assist? Assuming ASM policy: PolicyX and url: /LoginHere.aspx Thank you
Syslog irule corrupts the web page with Captcha configuration
Hi, We have an irule to send vs traffic through the syslog. But when we enable the page does not work. The webpage is configured with captcha. Have you any suggestions for this issue? Thanks. when HTTP_REQUEST { set http_method HTTP/[HTTP::method] set http_uri HTTP/[HTTP::uri] set http_version HTTP/[HTTP::version] set http_request_time [clock clicks -milliseconds] set http_user_agent "\"[HTTP::header User-Agent]]\"" set http_host [HTTP::host] set http_username [HTTP::username] set client_ip [IP::remote_addr] set client_port [TCP::remote_port] set http_request_uri [HTTP::uri] set request_content_length 0 if { [HTTP::header exists "Content-Length"] } { set request_content_length [HTTP::header "Content-Length"] } set request_content_type [HTTP::header "Content-type"] set referer [HTTP::header value referer] set now [clock format [clock seconds] -format "%Y-%m-%d %H:%M:%S"] } when HTTP_RESPONSE { set response_time [expr [clock clicks -milliseconds] - $http_request_time] set virtual [virtual] set content_length 0 if { [HTTP::header exists "Content-Length"] } { set content_length [HTTP::header "Content-Length"] } set lb_server "[LB::server addr]:[LB::server port]" if { [string compare "$lb_server" ""] == 0 } { set lb_server "" } set status_code [HTTP::status] set content_type [HTTP::header "Content-type"] set log_msg "" append log_msg "virtual=$virtual|" append log_msg "client_ip=$client_ip|" append log_msg "client_port=$client_port|" append log_msg "lb_server=$lb_server|" append log_msg "request_content_type=$request_content_type|" append log_msg "$request_content_length|" append log_msg "$http_request_time|" append log_msg "host=$http_host|" append log_msg "username=$http_username|" append log_msg "$http_method|" append log_msg "$http_uri|" append log_msg "http_version=$http_version|" append log_msg "server_status=$status_code|" append log_msg "response_content_type=$content_type|" append log_msg "$content_length|" append log_msg "$response_time|" append log_msg "user_agent=$http_user_agent|" HSL::send [HSL::open -proto UDP -pool POOLNAME] $log_msg log -noname IP:PORT local0. $log_msg log local0. $log_msgGLOBAL Live Webinar: Smart Bots and Al Assisted Attacks: Are you ready?
This event is open to all F5 users regardless of geographic location. Date: Tuesday, May 23, 2023 Time: 10:00am PT | 1:00pm ET What you can do when bots look and act like humans As cybersecurity defenders, we increasingly look to automation and machine learning to detect attacks and tune our defenses. But we’re not alone. Organized crime also uses automation to develop new capabilities and find new ways to attack applications — all while flying under the radar. Join our webinar to get a closer look at the modern automated methods attackers use to bypass CAPTCHAs, multi-factor authentication (MFA), client fingerprinting, and bot detection systems. We will also explore how the recent explosion in generative AI tools could be a catalyst for automating attacks and circumventing existing application defenses. In this webinar, you’ll learn: The tools and techniques attackers use to bypass bot detection How AI/ML based tools may soon be used to even better imitate human users Recommended methods for detecting and dealing with heavily automated attacks Speaker: David Warburton, Sr. Threat Research Evangelist, F5 Labs Click here to register
APM Capcha based on source IP
hey, i have a requirement to show captcha on APM login based on the source IP of the clint. i am using the built in captcha on the APM. is there a simple way to do it? i thought about moving the login page to a macro block and have 2 login pages one with captcha and the other without captcha, however the logon page is customized is there a way to clone and move the logon page to the macro block saving all the page design and customizations ? thanks dor
ASM 13.1.0.x Brute Force - how to configure?
Hi, I am not sure when this protection changed but for sure it is quite different in version 13.1.0.8. There is plenty of new settings there - problem is I can't figure out how to set it up for best protection. When only Username is set then only protection is CAPTCHA - you can attempt to guess password as many times as you wish (if you resolve CAPTCHA) - explanation is to protect user from being locked out when his account is under attack - so far so good. There is one issue here - Your support ID. It's shown each time CAPTCHA is displayed but there is no matching entry in Even Log (All request and responses logged). Even when requests are reported as Illegal (but of course not blocked) Support ID in such request do not match one displayed to user - so what is purpose for displaying Support ID below CAPTCHA? If no other setting will be configured (Device ID, IP) then attacker can repeat attack forever - or until security will notice it and block given user name. Only way to actually block login attempt is to configure either Device ID or IP Address failed logins setting. But if any of above will be configured to Alarm and Blocking page (or Drop) then real user that made mistake will be blocked as well - so not being able to block on username is a bit artificial here. Now there is a question how to unlock such blocked IP? I can't see any way. Another issue I noticed is that for some reason (even if Device ID Tracking is enabled in Session Tracking) no Device ID is reported - is there some minimal number of request necessary to identify given device? I wonder what is good mix of settings there to: Actually do not block real user that forgot password from being locked out Do not allow malicious user to continue guessing forever (if he can afford CAPTCHA solving solution) Only way to block login after given number of resolved CAPTCHA and failed attempts is to set CAPTCHA Bypass Mitigation - but it only works for IP Address and Device ID not Username. Assuming that real user will rather try to login from the same IP Address and/or Device ID then in the end real user will be locked out. Then again there should be some way to unlock - and I can't see it. If attack is distributed (different IPs and Device ID) then not being able to block based on Username looks to me as week spot. Attacker can limit number of attempts per IP to a small number and bypass protection. Based on default settings it is possible to perform up to 9 (4th attempt trigger CAPTCHA, then 5 attempts after solving CAPTCHA) attempts per IP without being locked out. New settings are for sure more powerful but it is not so easy to figure out relations between them and create optimal combination. Piotr
ASM 13.1.0.x Brute Force - how to configure?
Hi, I am not sure when this protection changed but for sure it is quite different in version 13.1.0.8. There is plenty of new settings there - problem is I can't figure out how to set it up for best protection. When only Username is set then only protection is CAPTCHA - you can attempt to guess password as many times as you wish (if you resolve CAPTCHA) - explanation is to protect user from being locked out when his account is under attack - so far so good. There is one issue here - Your support ID. It's shown each time CAPTCHA is displayed but there is no matching entry in Even Log (All request and responses logged). Even when requests are reported as Illegal (but of course not blocked) Support ID in such request do not match one displayed to user - so what is purpose for displaying Support ID below CAPTCHA? If no other setting will be configured (Device ID, IP) then attacker can repeat attack forever - or until security will notice it and block given user name. Only way to actually block login attempt is to configure either Device ID or IP Address failed logins setting. But if any of above will be configured to Alarm and Blocking page (or Drop) then real user that made mistake will be blocked as well - so not being able to block on username is a bit artificial here. Now there is a question how to unlock such blocked IP? I can't see any way. Another issue I noticed is that for some reason (even if Device ID Tracking is enabled in Session Tracking) no Device ID is reported - is there some minimal number of request necessary to identify given device? I wonder what is good mix of settings there to: Actually do not block real user that forgot password from being locked out Do not allow malicious user to continue guessing forever (if he can afford CAPTCHA solving solution) Only way to block login after given number of resolved CAPTCHA and failed attempts is to set CAPTCHA Bypass Mitigation - but it only works for IP Address and Device ID not Username. Assuming that real user will rather try to login from the same IP Address and/or Device ID then in the end real user will be locked out. Then again there should be some way to unlock - and I can't see it. If attack is distributed (different IPs and Device ID) then not being able to block based on Username looks to me as week spot. Attacker can limit number of attempts per IP to a small number and bypass protection. Based on default settings it is possible to perform up to 9 (4th attempt trigger CAPTCHA, then 5 attempts after solving CAPTCHA) attempts per IP without being locked out. New settings are for sure more powerful but it is not so easy to figure out relations between them and create optimal combination. Piotr
