iRule - XFF different case based on direction
I have an issue with Bitbucket versions where XFF is sent differently depending on the direction of traffic between versions. I am sure other apps have this issue as well. Bitbucket versions ( v7.2.5 --> v8.19.3 ) Can the XFF type case-sensitivity be controlled based on direction. (Right side is a mixed up standard and all upper-case versus the left side is all lower-case.
xff and geolocation
If I want to create a dos l7 profile that needs to check the xff header as the source address (I will add an http+xff profile), and I want to exclude a country from the dosL7 policy using an LTM policy - can this be done with XFF? can the ltm policy recognise xff addresses' geolocations? If not with ltm policy, can this be done with an irule? thanks, VeredXFF Universal Persistence iRule
Problem this snippet solves: Simple iRule to read the XFF header on an incoming HTTP Request and use a Universal Persistence ID. Orginal iRule found to have an issue with multiple IP addresses in the XFF header for changed to only pass the first XFF IP. I have updated the iRule line to account for systems where multiple 'X-Forwarded-For' headers have been added. persist uie [lindex [ split [HTTP::header X-Forwarded-For] "," ] 0] to persist uie [lindex [ split [lindex [HTTP::header values X-Forwarded-For] 0] "," ] 0] thanks to the advice from Yann Desmarest. This could also be done with the 'getfield' command see Yann's comments below. How to use this snippet: Create iRule using following code (mine is named 'persist_xff_uie') Create Universal Persistence Profile with iRule set to 'persist_xff_uie' (or what ever name you assign to the iRule) Assign Universal Persistence Profile to Virtual Server (ensure virtual server has HTTP profile assigned) Code : # Name: persist_xff_uie # # To be used with UIE Persistence Profile # # Checks HTTP Request for 'X-Forwarded-For' header and if exists takes the first 'X-Forwarded-For' IP address as sets as # Persist identifier. # If the 'X-Forwarded-For' header does not exist then the client IP address is set as Persist identifier. when HTTP_REQUEST { if {[HTTP::header X-Forwarded-For] != ""} then { persist uie [lindex [ split [lindex [HTTP::header values X-Forwarded-For] 0] "," ] 0] } else { persist uie [IP::client_addr] } } Tested this on version: 11.5
iRule that triggers a capture of the HTTP request before rejecting
I'm using the following iRule to block an attack coming from an IP that is behind a proxy; however we can still see the original in the XFF header. So far this iRule is working but would like to trigger a capture to better build a policy in ASM to block. Is there a way to trigger a method to capture and log the full request when we get a match and send the 410? Note:Credit to hoolio https://devcentral.f5.com/questions/using-x-forwarded-for-to-block-clients when HTTP_REQUEST { if {[HTTP::header "X-Forwarded-For"] ne ""}{ log local0. "XFF: [HTTP::header "X-Forwarded-For"]" foreach xff [split [string map [list " " ""] [HTTP::header "X-Forwarded-For"]] ","] { log local0. "Current XFF element: $xff" if {[IP::addr $xff equals 1.2.3.4]}{ log local0. "Sending 410 for $xff" HTTP::respond 410 break } } } }
X-Forwarded-For: Multiple IP's Chained | Need Original IP | iRules and HTTP Profile?
Hello, I am at a loss. I am a security engineer and one of my jobs is managing the SIEM, which I am building out currently. One of the log sources is, of course, the F5 ASM logs. The problem, however, is that the logs come in with the wrong IP in the source IP field. They come in with IP addresses from our own architecture components such as the ALB or cloudfront instead of correctly parsing the XFF (via the iRule below or otherwise). It definitely has to do with the XFF header situation of our architecture. I have read a boat load of stuff to no avail. Just cannot seem to get the right IP (the ACTUAL origin IP) in the source IP spot. Any help would be greatly appreciated! Architecture: internet/users —> Cloudfront —> ALB —> F5 —> Amazon ECS backend incl. Logrhythm SIEM Also, the profile being used in the LTM is http. We have "insert x-forwarded-for" set to DISABLED, and "Accept XFF" ENABLED, as well as the Alternate XFF box filled in with "X-Forwarded-For" (just to be safe). Desired Solution: We are hoping for the F5 to send its syslog ASM logs to our SIEM (Logrhythm) with the true original IP address listed correctly as the source/client IP address. In other words, We need the SIEM to see the origin IP as the true original IP. Problem: The issues with the xff headers and various IP addresses has created a situation where either Cloudfront, the ALB, the F5, or one of the backend service’s IP address is incorrectly in the original source/client IP spot. The implications of this are far reaching and totally screws things up for our SIEM and security orchestration and all sorts of stuff. iRule Currently Used: We are currently using this iRule which is at the top of the list of execution order. when HTTP_REQUEST { HTTP::header insert X-Forwarded-For [IP::remote_addr] HTTP::header replace X-Forwarded-For [getfield [HTTP::header X-Forwarded-For] "," 1] HTTP::header replace X-Forwarded-For-Raw [getfield [HTTP::header X-Forwarded-For] "," 1] HTTP::header replace CF-Connecting-IP [getfield [HTTP::header X-Forwarded-For] "," 1] } Example Request seen in the F5 ASM Event Logs (to be fwded to SIEM): GET / HTTP/1.1 X-Forwarded-For: AAA.AAA.AAA.AAA, BBB.BBB.BBB.BBB X-Forwarded-Proto: https X-Forwarded-Port: 443 Host: sub.exampledomain.com X-Amzn-Trace-Id: Root=1-5b67cf53-df48e8adfafafdsaff4a726f X-Amz-Cf-Id: PYTrCasdfafgh_5xIO_P4IpHafdsafsdafETZLgQr4CJEfOpQ== User-Agent: Mozilla/5.0 (compatible; Uptime/1.0; http://uptime.com) Via: 1.1 aa9157a1414f639asdfasdfasb7df10.cloudfront.net (CloudFront) CloudFront-Is-Mobile-Viewer: false CloudFront-Is-Tablet-Viewer: false CloudFront-Is-SmartTV-Viewer: false CloudFront-Is-Desktop-Viewer: true CloudFront-Viewer-Country: SG Accept: */* CloudFront-Forwarded-Proto: https x-salt-cloudfront-secret: 6CsSe4cBZwuTBOasdfadUhu3sPKJ5K8SCA X-Forwarded-For: CC.CC.CC.CC X-Forwarded-For-Raw: CC.CC.CC.CC CF-Connecting-IP: CC.CC.CC.CC In this case, the F5 would have CC.CC.CC.CC listed in the source IP Address Thank you very much to anyone who can help!iRule error - bad IP address format (line x)
I just deployed this irule: when HTTP_REQUEST { if { [HTTP::header exists "X-Forwarded-For"] } { set client_ip [HTTP::header value "X-Forwarded-For"] set fromCountry [whereis $client_ip country] if { ( [class match $fromCountry equals Blocked_Countries]) }{ drop } } } And I'm getting this error in /var/log/ltm: TCL error: /parition1/BlockedCoun_XFF <HTTP_REQUEST> - bad IP address format (line 2) invoked from within "whereis $client_ip country" TCL error: /parition1/BlockedCoun_XFF <HTTP_REQUEST> - bad IP address format (line 3) invoked from within "whereis $client_ip country" I saw this article but not sure enough how to implement it in my irule https://support.f5.com/csp/article/K15450552 Could you please advise on this? Thanks
XFF
We have enabled the option to include XFF ip in the header for a VS. We generate alerts from a pool member of one of the VS' that aid debugging etc. When the XFF address comes through, its in this format: HTTP_X______________ = xxxxxxxxxxx, xxxxxxxxxxx Anyone have any suggestions this has worked fine in the past!
