Use x-forwarded-for to bypass authentication?

[Jim_Stumbo]

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-forwarded-for field and if it is a certain IP address range, then bypass the authentication in the access policy. We have users and systems that are making this connection and we want to users to have to do the two factor authentication we have in place, but the systems that make this connection cannot do the two factor authentication. So we want them to be able to skip over that. We are taking precautions on our WAF to prevent the spoofing of the x-forwarded-for header, so we should be OK there.

Any suggestions on how to do this? I am assuming, from what I have read... that I can create an irule that checks the x-forwarded-for and sets a variable depending on if it is in the range that we know is from the systems directly, and then somehow in the access policy, check for that variable, and if it is a certain value, go to success directly bypassing the SAML auth, but if it is not that value, then they go to the authentication to do their two factor auth.

Thanks for any help.

Jim

[Daniel_Wolf · Accepted solution]

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]

thank you very much. I will give this a shot.

[Jim_Stumbo]

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]

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]

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]

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.

[Jim_Stumbo]

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.

[Daniel_Wolf]

See this diagram: https://devcentral.f5.com/s/articles/iRule-Event-Order-Flowchart

You could try and replace the HTTP_REQUEST with ACCESS_SESSION_STARTED.

Sorry.... I really should have tested the iRule.

[Jim_Stumbo]

Thanks. I was looking at the same thing and was about to reply that if I changed it to the below it worked. I think I am good now. Thank you very much for all your help. Slowly I am learning all the more complex sides of this thing.

when ACCESS_SESSION_STARTED {

  if {[HTTP::header exists X-Forwarded-For]}{

    ACCESS::session data set session.user.clientip [HTTP::header X-Forwarded-For]

  }

}