Forum Discussion

Altostratus

Jul 01, 2021

Solved

Use x-forwarded-for to bypass authentication?

I am pretty new to all the irule stuff and the more advanced access policy stuff, so please be gentle on me. What we are trying to do is when a connection is made to our F5, check the x-forw...

application delivery

BIG-IP Access Policy Manager (APM)

iRules

security

Daniel_Wolf
Jul 01, 2021
Hi Jim,
you could add this iRule
when HTTP_REQUEST { if {[HTTP::header exists X-Forwarded-For]}{ ACCESS::session data set session.user.clientip [HTTP::header X-Forwarded-For] } }
It will replace the Session Variable session.user.clientip with the value of the X-Forwarded-For header.
And then you could use the APM action Endpoint Security (Server-Side) >> IP Subnet Match in the APM Access Policy to check whether the IP is matching the allowed Subnets.
I didn't test the iRule, let me know whether it works or not.
KR
Daniel
EDIT: Typo in iRule

Daniel_Wolf

MVP

Jul 01, 2021

Hi Jim,

you could add this iRule

when HTTP_REQUEST {
    if {[HTTP::header exists X-Forwarded-For]}{
        ACCESS::session data set session.user.clientip [HTTP::header X-Forwarded-For]
    }
}

It will replace the Session Variable session.user.clientip with the value of the X-Forwarded-For header.

And then you could use the APM action Endpoint Security (Server-Side) >> IP Subnet Match in the APM Access Policy to check whether the IP is matching the allowed Subnets.

I didn't test the iRule, let me know whether it works or not.

Daniel

EDIT: Typo in iRule

Jim_Stumbo
Altostratus
Jul 01, 2021
thank you very much. I will give this a shot.
Jim_Stumbo
Altostratus
Jul 01, 2021
It does not look like the iRule works. When I apply it, the website does not come up at all. I have not done the access policy part yet, but just doing the iRule makes it not respond. I am guessing that maybe by changing the clientIP, it is trying to respond to the client directly, instead of going back through the WAF?
- Daniel_Wolf
  MVP
  Jul 01, 2021
  Check again, I had a typo in the iRule
  OLD:
  ACCESS::session data ~~set~~ set session.user.clientip
  NEW
  ACCESS::session data set session.user.clientip
- Jim_Stumbo
  Altostratus
  Jul 01, 2021
  Yeah, I caught that after I started looking at it. Getting rid of that allows the website to load. Looked at the logs and it appears to be making the clientip equal to the x-forwared-for value, so that is good. Still having a problem with it recognizing the IP/Subnet on the access policy. I have tried using the IP Subnet Match and using both the actual IP address of my test system, which matches what it is displaying when I look at the session variables, as well as the following: (numbers are made up for reference) "10.8.8.2", 10.8.8.2/32", and "10.8.8.0/24". Since my IP would be 10.8.8.2, and after I hit the WAF, it would be the x-forewarded-for value, and the IP would then be the WAF. It is changing the clientIP from that of the WAF, to my x-forwarded-for value, but when I try to key off that, it never gets a match, so I always get asked to authenticate.. thanks for the help.
- Daniel_Wolf
  MVP
  Jul 01, 2021
  I think 10.20.30.40/32 should be the right format for a single IP, otherwise 192.168.1.0/24 or 10.0.0.0/8 will work too. You could add a message box or a log event on both paths (fallback and IP Subnet Match) that shows the session.user.clientip variable value.
  
  Do you see anything in the Per-Session Policy logs that would explain why you hit the fallback path? See K24826763 and K45423041 for configuring debug logging.