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, Vered
iRule - Fallback Persistence
Hi - I'm trying to create an iRule for the Persistence Profile of one of my applications. The preferred method is to use cookie - the application actually injects a cookie in the HTTP RESPONSE and the F5 looks for this cookie in both the HTTP RESPONSE and HTTP REQUEST to do persistence, identical to how JSESSIONID works. However in the event that the client has configured their browser to reject / disable cookies, the expectation is that we persist based on their source IP, however as they come in to our data centre via Akamai, we actually need to extract their IP from the X-Forwarded-For header. What I came up for this was: when HTTP_REQUEST { if { [HTTP::cookie exists "App_SessionId"] } { persist uie [HTTP::cookie "App_SessionId"] 1800 } else if {[HTTP::header X-Forwarded-For] != ""} { persist uie [lindex [ split [lindex [HTTP::header values X-Forwarded-For] 0] "," ] 0] 1800 } else { persist uie [IP::client_addr] 1800 } } when HTTP_RESPONSE { if { [HTTP::cookie exists "App_SessionId"] } { persist add uie [HTTP::cookie "App_SessionId"] 1800 } } I haven't had the chance to test this but reviewing the logic I see that we may have a problem with the first request cominf from the user's browser. When a user first lands on the website, the HTTP_REQUEST from their browser will not have the App_SessionId cookie and this causes the LTM to add a persistence record based on the X-Forwarded-For header, or add a persistence record based on the user's source IP address. When the request makes it to the server and the server responds ( HTTP_RESPONSE ), that response will have a App_SessionId cookie, and the LTM adds another persistence record based on this cookie. Then the subsequent HTTP_REQUEST from the users browser will have the App_SessionId cookie, and this will now match the if { [HTTP::cookie exists "App_SessionId"] } section of the iRule and they will be persisted to the same server that inserted the cookie. This is good but there's the loose end which is the initial persistence record based on the X-Forwarded-For header that's lingering. Would this lingering persistence record based on the X-Forwarded-For header cause a conflict with the persistence record based on the App_SessionId cookie? How do I clean up this loose end? On the flip side, if the user had configured their browser to reject cookies, the persistence record based on the X-Forwarded-For header is vital to maintain session consistency. But now we have the loose end of the persist add uie [HTTP::cookie "App_SessionId"] 3600 in the HTTP_RESPONSE .BIG-IP : http profile : insert x-forwarded-for : enabled
F5 BIG-IP Virtual Edition v11.4.1 (Build 635.0) LTM on ESXi HTTP Profile Insert X-Forwarded-For : Enabled Suppose the client has already added the "X-Forwarded-For" header value to the request. How will BIG-IP behave ? Will it leave the existing header value intact ? Or will it overwrite the value with what it believes to be the request client ip ? Further, at what point in request-processing does the insert/replace header operation occur ? Does it occur before iRule processing so that the header value is available within the iRule event processing when HTTP_REQUEST {} ?BIG-IP : HTTP Profile Insert X-Forwarded-For Enabled but not found in request headers collection
F5 BIG-IP Virtual Edition v11.4.1 (Build 635.0) LTM on ESXi For a Virtual-Server assigned an HTTP Profile configured with : Insert X-Forwarded-For Enabled under what circumstances would the header not be inserted ? My iRule logs : when HTTP_REQUEST { log local0. "X-Forwarded-For header = [HTTP::header X-Forwarded-For]" ` indicate header is not present -- here is log output : `X-Forwarded-For header = Could disabling HTTP_REQUEST event at end of iRule affect HTTP Profile ability to add the header ?
X-Forwarded-For header
Hi All, My application team requirement is to able to see the actual client ip address whoever accessing the application instead of BIG IP address as SNAT (Auto map) is enabled. I have read some SOL on it and understand that we can achieve this by iRule & HTTP profile. However, my requirement is to have an iRule as we can take decision whether to add X-Forwarded-For header to client requests. Can anyone please share the iRule script pertaining to this requirement. Thanks in advance, MSK
iRule - http redirect and x-forward
Hi folks, I need help to check if my iRule on LTM A (external) is redirecting the traffic to LTM B VIP correctly and iRule on LTM B will help keep the users host and uri and display the page on the servers. LTM A (External): ------------------------------- VS: vs_abc_com_test Destination IP: Public IP:80 Pool: pool_efg Member: 10.10.30.30 iRule on VS: "abc.com" { if { [HTTP::uri] starts_with "/test"} { pool pool_abc_test snat automap } else { HTTP::redirect "https://abc.com[HTTP::uri]" } } Pool in iRule: pool_abc_test Member: 10.10.10.1 ----------------- which is the VIP on LTM B LTM B (Internal): ----------------------------- VS: vs_pool_abc2_test2 Dest IP: 10.10.10.1 Pool: pool_abc2_test2 Members: 20.20.20.1:80 20.20.20.2:80 iRule on VS: when HTTP_REQUEST { if { ([HTTP::uri] contains "/xyz/login.aspx") || ([HTTP::uri] contains "/uvw/login.aspx")}{ if {not [HTTP::header exists "X-Forwarded-For"]} { HTTP::header insert X-Forwarded-For [IP::client_addr] } } }
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 } } } }
Can I have two UIE persistence record for the same connection
I have a web service that uses the ASP.NET_SessionID cookie for persistence. However, I'm running into scenarios where the ASP.NET_SessionID is not sent in the request, or the value of that cookie is blank. This of course is breaking persistence. I'm trying to get the developers to fix that issue, but they're not having a lot of luck. Normally it would make sense to set Source_Addr as the fallback persistence method, but in this case the traffic is going through a third party, which changes the client IP address. The original client IP address is included in a X-Forwarded-For header. My question is this: In my iRule, can I create a UIE persistence record for the ASP.NET_SessionID cookie and also a UIE record for the X-Forwarded-For value, or will they overwrite one another? If I can't do that, can I create a source_addr persistence record using the value in the X-Forwarded-For header? Thanks for any help on this. Robert
Multiple X-Forwarded-For ip address
We have enabled X-Forwarded-For on F5 and in apache we have added following code LogFormat blah...\"user-agent\": \"%{User-agent}i\", \"client\": \"%{X-Forwarded-For}i\",...blah Now i am doing experiment and sending forge X-Forwarded-For using Modify Header plugin on Chrome browser. In apache logs i am seeing two IP addresses. like following 123.123.123.123 is fake IP. "client": "123.123.123.123, 210.76.39.145" Question: is there a way in apache/F5 LogFormat to extract only last IP address which is valid one?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!