X-Forwarded-For through proxy and F5
My organization recently got the ASM module when they purchased a pair of 5250Vs. I've never used ASM before and we don't have anyone in our organization that has either, so I'm learning on the fly. I have a small SharePoint farm behind the F5. Two web front ends in a pool that uses SNAT. This farm is accessible from within our organization only, not available from the open internet. We have geographically dispersed users and offices, all over the United States. Some offices have a web proxy that all client web traffic goes through as it leaves their local enclave and some sites do not have a proxy like this. For traffic that comes from a site that goes through a proxy, the X-Forwarded-For header shows in ASM as the proxy IP, not the actual client IP. For sites that do not go through a proxy, I see the actual client IP in this header. I contacted the group that manages the proxy at my location and confirmed that the proxy at my site also has X-Forwarded-For enabled, they even sent me a screen shot that showed it was enabled. I'd like to see the IP of the original client through the proxy. From what I read, I thought maybe I'd see multiple IPs in some circumstances, but I admit I've never worked with X-Forwarded-For header before now. Thanks in advance.
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!
Preserve original source IP with SNAT for SMTP
Hi guys, Reading through various posts here on devcentral I have a feeling I will not be able to achieve what I want but I rather ask again. Our topology looks like: source -> firewall -> F5 LTM -> firewall -> router -> backend servers I am trying to load balance SMTP but the server guys need to see the original source IP in order to allow or deny sending emails. The problem is that I need to work with SNAT because the backend servers are far from the LB, behind another firewall and router. Their default gateway must be the one of the router. If I keep the original source IPs, I would face asymmetric routing and the some firewall on the way back would kill the session. We checked the backend SMTP server configuration and there is no other way to allow/deny sources there except of the IP addresses. So can I load balance SMTP traffic with SNAT while somehow be able (on the backend server) to tell what was the original source IP? Thanks.
Issue with value of X-Forwrded-For header + Incapsula
One of our application has X-FORWARDED-FOR enabled and spoofing protection is enabled as well. The application use Incapsula Web Application Firewall for internet traffic, it accepts traffic from client and forwards to F5. The app team can only see Incapsula IP address instead of client IP addresses. Is there a way where F5 can retain client IP addresses provided by Incapsula so that they can see client IP's instead on Incapsula IP. Our X-FORWARDED-FOR profile is configured this way Request Header Erase : X-FORWARDED-FOR Request Header Insert : X-FORWARDED-FOR:[IP::client_addr]
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 {} ?
