For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Jim_Stumbo's avatar
Jim_Stumbo
Icon for Altostratus rankAltostratus
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's avatar
    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

Jim_Stumbo's avatar
Jim_Stumbo
Icon for Altostratus rankAltostratus
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?

Jim_Stumbo's avatar
Jim_Stumbo
Icon for Altostratus rankAltostratus
Jul 01, 2021

I think it is a timing thing... I put a message box in at each step, so before the matching, before the auth, and after the auth. It shows the WAF IP as the client IP both before and after the matching, but changes it to my actual one (via the irule), after the auth.