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!
Per-Request policy Proxy Select and HTTPS
Hi, I can't see any info about limitation for Proxy Select object in Per-Request Policy (PRP) to only http traffic. It's working without issue for http request and pass them to upstream proxy. For https requests (with SSL Bypass Set before Proxy Select) Connection is never reaching upstream proxy. Instead in PRP log I have entry: Common/explicit_proxy_policy:Common:642030b8: Executed agent (/Common/explicit_complete_bypass_act_proxy_select_ag) failed with reason (UNKNOWN) Any idea why? PiotrForward proxy, proxy chaining and APM issue
Hi, I am really desperate, everything I tried failed and I don't know if it's because of my mistake, setup is not possible or there is some bug. Goal: BIG-IP working as explicit proxy for internal clients Users logged into domain should be transparently authenticated using NTLM (prefered) or Kerberos All request should be passed to upstream proxy Everything is working OK until there is 302 to internal APM resources - like when authentication fails or some other conditions prevents user accessing given URL. Scenario used: Standard VS with reverse http profile APM profile with SWG-Explicit type Result when APM sends 302 with Location pointing to vdesk... URI: Client sends request with proxy kind URI, like GET For NTLM I can see proper NTLM handshake (at least for me looking like proper - similar to when there is initial NTLM handshake to authenticate user) When NTLM handshake is finished instead of OK 200 I am getting again 302 to the same location It repeats indefinitely until exceeding browser redirection limit In case of Kerberos there is no reauthentication for redirection request but still loop is there. Is there any way (via iRule?) to avoid this loop? Any other approach that can be used to achieve my goal? I will really appreciate any help to solve this issue. My Access Profile is working OK to authenticate users both for NTLM and Kerberos - so scenario is working for users allowed to access given URL - authentication is performed, request are passed to upstream proxy, users are getting web sites in the browser... but everything breaks when there is redirection to internal APM pages. Piotr
Forward proxy, proxy chaining and APM issue
Hi, I am really desperate, everything I tried failed and I don't know if it's because of my mistake, setup is not possible or there is some bug. Goal: BIG-IP working as explicit proxy for internal clients Users logged into domain should be transparently authenticated using NTLM (prefered) or Kerberos All request should be passed to upstream proxy Everything is working OK until there is 302 to internal APM resources - like when authentication fails or some other conditions prevents user accessing given URL. Scenario used: Standard VS with reverse http profile APM profile with SWG-Explicit type Result when APM sends 302 with Location pointing to vdesk... URI: Client sends request with proxy kind URI, like GET For NTLM I can see proper NTLM handshake (at least for me looking like proper - similar to when there is initial NTLM handshake to authenticate user) When NTLM handshake is finished instead of OK 200 I am getting again 302 to the same location It repeats indefinitely until exceeding browser redirection limit In case of Kerberos there is no reauthentication for redirection request but still loop is there. Is there any way (via iRule?) to avoid this loop? Any other approach that can be used to achieve my goal? I will really appreciate any help to solve this issue. My Access Profile is working OK to authenticate users both for NTLM and Kerberos - so scenario is working for users allowed to access given URL - authentication is performed, request are passed to upstream proxy, users are getting web sites in the browser... but everything breaks when there is redirection to internal APM pages. Piotr