redirect not working
I have below scenario works without redirect if statement . when i add the if statement for uri redirect getting a reset. when HTTP_REQUEST { if { [HTTP::uri] starts_with "/" } { HTTP::redirect /testpage } #log local0. "Active members is [active_members pool1]" if { [active_members pool1] == 0 }{ if { ( ( [class match [IP::client_addr] eq "whitelist"] ) && ( [active_members pool2 ] > 0 ) ) } { pool pool2 } else { HTTP::respond 503 content [ifile get "applicationdown.html"] } } }iRule resulting in too many redirects
I have two requirements with my virtual server. 1. A redirect to /pc/service/SSOLogin 2. 24 hour persistence based on the JSESSIONID cookie in the request header. The first one was accomplished early on with a policy that redirects to location '/pc/service/SSOLogin' at request time. This has worked without any issues until I tried to implement the JSESSIONID persistence. To accomplish the second, I created an iRule to be used with the Universal persistence profile. When I implemented this persistence profile, the redirect policy no longer worked. My assumption was that the iRule and the policy were conflicting with each other. To resolve this, I created a single iRule to handle both of these requirements. Now, I am getting too many redirects. The iRule is below. when HTTP_RESPONSE { ## PERSISTENCE # If the JSESSIONID exists, we'll pass the cookie along if { [HTTP::cookie exists "JSESSIONID"] } { persist add uie [HTTP::cookie "JSESSIONID"] 86400 } } when HTTP_REQUEST { ## PERSISTENCE # If the JSESSIONID exists, we'll maintain that persistence if { [HTTP::cookie exists "JSESSIONID"] } { persist uie [HTTP::cookie "JSESSIONID"] } ## REDIRECT # This grabs the base url from the incoming request # For Example, https://my.site.com/some/path the base_url is set to https://my.site.com set base_url "https://[HTTP::host]" # Defining the new path set new_path "/pc/service/SSOLogin" # Construct the new URL # For example, https://my.site.com/pc/service/SSOLogin set new_url "$base_url$new_path" # Redirect to the new URL HTTP::redirect $new_url }F5 BIG-IP iRule based TCL DNS server
Short Description This code is for the purpose if there is a need to return a custom DNS reply not from the main DNS server but from the F5 Virtual Server. Problem solved by this Code Snippet The code is meant for small lab or dev environments as F5 has F5 DNS/GTM for replying to DNS requests with Intelligent Load Balancing, DNS Express Memory cache etc. How to use this Code Snippet Modify the irule code to configure the custom domain you want replies from the irule code and not the real DNS server. Add the irule to a DNS UDP LB Code Snippet Meta Information Version: 17.1 Coding Language: TCL Code You can find the code and further documentation in my GitHub repository: irule_dns/irule1 at main · Nikoolayy1/irule_dns (github.com)Protecting APIs with Access Policy Manager and custom iRules
The problem: Unprotected API - Vulnerable to Overload Without Rate-Limiting Enforcement Our customer in the B2B sector is encountering a challenge with their public API. Despite having implemented a custom method for generating long-lived API keys, they find themselves unable to enforce rate-limiting effectively. This absence of rate-limiting mechanisms poses significant challenges, potentially resulting in the overloading of their system due to excessive requests or the exploitation of their API by unauthorized users. Without proper rate-limiting controls in place, the customer faces risks to both the performance and security of their API infrastructure, necessitating a solution to mitigate these concerns and ensure the smooth operation of their services for their clients. Our customers wants to offer two tiers of service level agreements (SLAs) - gold and standard. Complicating matters further, the API key, integral to authentication, is transmitted via a custom HTTP header. The solution: BIG-IP APM and Custom iRules for Effective Rate-Limiting My solution involves leveraging the API Protection feature of BIG-IP APM in conjunction with a custom iRule. By utilizing this combination, our customer can effectively extract the API Keys from HTTP requests and enforce rate limiting on specific API endpoints. As for now they only want to enforce rate limiting on the POST endpoints. This approach empowers the customer to secure their API while efficiently managing and controlling access to critical endpoints, ensuring optimal performance and safeguarding against abuse or overload. With this iRule we can to extract the API key from the HTTP Requests and store it in a variable, that can later be used by the API Protection feature of the APM. API Keys and the associated SLA level are stored in a Data Groupof the typestring. # Enable (1) or disable (0) logging globally when RULE_INIT { set static::debug 1 } # Access and analyze the HTTP header data for SLA value when HTTP_REQUEST { set sla [class lookup [HTTP::header value apikey] dg_apikeys] if { $static::debug } {log local0. "Made it to HTTP_REQUEST event with SLA value $sla."} } # Evaluate SLA value during per-request access policy execution when ACCESS_PER_REQUEST_AGENT_EVENT { set id [ACCESS::perflow get perflow.irule_agent_id] if { $id eq "read-sla" } { if { $static::debug } {log local0. "Made it to iRule agent in perrequest policy with SLA value $sla."} ACCESS::perflow set perflow.custom "$sla" } } And this is how the Per Request Policy in the API Protection profile looks. It uses the value of the API Key (extracted with the help of the the iRule) and the Source IP of the client to enforce Rate Limiting on the POST endpoints, using two different SLAs. In the APM log you should see the following message, once the client exceeds his quota defined in the SLA. Apr 28 20:12:42 ltm-apm-16.mylab.local notice tmm[11094]: 01870075:5: (null):/Common: API request with weight (1) violated the quota in rate limiting config(/Common/demo_api_ratelimiting_auto_rate_limiting_standard). Apr 28 20:12:42 ltm-apm-16.mylab.local notice tmm[11094]: 0187008d:5: /Common/demo_api_ratelimiting_ap:Common:6600283561834577940: Execution of per request access policy (/Common/demo_api_ratelimiting_prp) done with ending type (Reject) Further reading: You can find a more detailed write-up on my GitHub page: https://github.com/webserverdude/f5_APM_API_Protection There you can find the Per Request Policy explained in all details. The Data Group with for the iRule. A demo API for testing my solution. A Postman Collection for working with my demo API.
Json parsing with iRules
JSON is now the format of choice for most APIs. It's time we were able to parse JSON with F5 iRules too, as simple string matching is not always good enough. That's why I wrote a simple JSON parser for iRules. It is a validating single pass parser that processes the JSON string char by char until the JsonPath expression matches, no recursion or any other fancy stuff. As I do not wanted to reinvent the wheel, it is basically a rewrite of the JSON parser found in themongoose webserver project in plain TCL. The usage is very simple: set token [call json::json_get_tok { $json $path }] $json is the json string to parse $path is a JsonPath expression, following operators are implemented: Operator Description $ The root element to query. This starts all path expressions. .<name> Dot-notated child. [<number>] Array index. Example Simple JSON: { "aud": "audience \"test\"", "iss": "https://issuer.de/issuer/", "iat": 1701422123, "roles": [ "role1", "role2" ], "obj": { "sub": "adcad2b8", }, "ver": "2.0" } JsonPath expression to parse this simple JSON: JsonPath Return value $.aud "audience \"test\"" $.iat 1701422123 $.obj.sub "adcad2b8" $.roles[0] "role1" To decode the extracted JSON string: set decoded [call json::json_decode_str { $token }] This removes the enclosing quotes from a string and decodes JSON escapes. Code You can find the code and further documentation in my GitHub repository: https://github.com/JuergenMang/f5-irules-json
Clone F5 traffic and forwarded into different Pool
Dear All, I have scenario, to forwarded Splunk F5 VIP traffic to more then one backend pools. upon checking we find Clone Pool (Client) or Clone Pool (Server ) Option but its limited with TCP/HTTP VIP not with stateless VIP. https://my.f5.com/manage/s/article/K8573 Can you please advise way to achieve this scenario through Irule or LTM policy Thanks
Irule Check payload contains
Hi Everyone, i have a request payload like this: POST /webconsole/api/security/auth/login HTTP/1.1 Host: Connection: keep-alive Content-Length: 58 sec-ch-ua: "Chromium";v="122", "Not(A:Brand";v="24", "Google Chrome";v="122" Accept: application/json, text/plain, */* Content-Type: application/json sec-ch-ua-mobile: ?0 User-Agent: Mozilla/5.0 ( OrganizationID: sec-ch-ua-platform: "Windows" Origin: Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: Accept-Encoding: gzip, deflate, br, zstd Accept-Language: en-GB,en-US;q=0.9,en;q=0.8 Cookie: {"UserName":"test.org\\secadm01","Password":***************} I want to create an irule to check with this URI: /webconsole/api/security/auth/login and client IP address is not X.X.X.X and the user login with user secadm will be blocked. other users with usernames not contain "secadm" would be ok. But this does not work. Please help advise I write an irule as below: when HTTP_REQUEST { if { [HTTP::path] equals "/webconsole/api/security/auth/login"} { if { [IP::addr [IP::client_addr] != 10.168.17.127] } { if { [HTTP::payload] contains "secadm" } { drop } } } }iRule - Using GeoIP to block/allow externally, and allow internal 10.0.0.0/8 subnets.
when CLIENT_ACCEPTED { if { [class match [IP::client_addr] equals allowed_internal_subnets] } { log local0. "Internal Clients allowed: \ [IP::client_addr]" pool MY_POOL } } when FLOW_INIT { set ipaddr [IP::client_addr] set fromCountry [whereis $ipaddr country] if {! [class match $fromCountry equals allowed_geoip_datagroup]}{ drop } } ltm data-group internal allowed_internal_subnets]{ records { 10.0.0.0/8 { } } type ip } ltm data-group internal allowed_geoip_datagroup { records { EU { } US { } } type string } Hi everyone! Need some help here from all the smart people on this forum. We are trying to create an Irule to block all countries not in the data group using the BigIP GeoIP database and lookup...however, we still have users within the 10.0.0.0/8 internal subnets needing to connect. When they connect to the VIP, their source address is in the 10.0.0.0/8 range, however, they get dropped by the FLOW_INT match for some reason....what am I doing wrong and how do I fix this? Here is what it should happen.... All external internet users coming from US/EU (using the bigip geoip lookup database) should be allowed, otherwise all countries not matching this should be dropped...this seems to be working.. All internal users coming from the 10.0.0.0/8 or RFC 1918 should be allowed and not dropped. How do I add both logic together in one flow? This irule is dropping the internal users for some reason...how do we allow all internal users in also, while dropping external users not matching the GeoIP logic? Thanks again...
