Forum Discussion
Use x-forwarded-for to bypass authentication?
- 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
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_StumboJul 01, 2021Altostratus
thank you very much. I will give this a shot.
- Jim_StumboJul 01, 2021Altostratus
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_WolfJul 01, 2021MVP
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.
- Daniel_WolfJul 01, 2021MVP
Check again, I had a typo in the iRule
OLD:
ACCESS::session data
setset session.user.clientipNEW
ACCESS::session data set session.user.clientip
- Jim_StumboJul 01, 2021Altostratus
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.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com