We've been doing some testing recently with using the APM Proxy for ADFS which is basically a check box in the APM section of a virtual server that allows one to establish a trust with the ADFS backend servers for automagical certificate renewals.
What we are now adding on is an AWAF policy. I understand that APM comes before ASM when it comes to traffic processing order (https://support.f5.com/csp/article/K00363504). What we are experiencing in our testing, is that if we go to https://10.10.10.10/etc/passwd via cURL, an ASM event is not triggered for either "Host Header contains IP Address" or the attack signature "/etc/passwd" but rather a 404 response code.
When we add in https://10.10.10.10/adfs/ls/etc/passwd via cURL, a block event happens and we can view it in the ASM event logs. This to me indicates that the previous "/etc/passwd" doesn't even get processed by ASM and somehow, APM knows the URLs used by ADFS due to using the proxy setting on the virtual server and gives a 404 back, thus never even pushing to ASM.
I'm trying to look for some documentation on this functionality but can't seem to find anything. Does anyone know if there is documentation around the functionality fo the ADFS proxy with F5?
Any help is greatly appreciated!
Solved! Go to Solution.
I've done some work on the ADFS Proxy but not with both that and ASM. What you are saying makes sense though - traffic is destined to APM ( rather than to a backend server, which is what ASM is more normally used for ) and APM translates them to the Microsoft ADFS proxy protocol. Have you looked at https://support.f5.com/csp/article/K13315545
So what'eve we found is that once we add the /adfs to the URL, we get a 404 response code with no event logs for ASM. We believe that using the ADFS Proxy setting on a virtual server, the BIG-IP will allow anything with /adfs in the URL to be processed by ASM but if a request doesn't start with /adfs in the URL, it immediately gives a 404 response code. No iRules were in play to provide that.
While we're happy that APM is providing some sort of security, we get no logs out of this to send to our SIEM. We looked at that article so we're looking into it. We're onto another problem with version 15 not supporting ADFS 5.0.
It could be a url filter or layer 7 access list in the APM session policy or if there is a per-request policy. You can also enable APM HSM logging to try to see the APM logs that block this:
See at the end of this link about HSM with APM:
ASM can use the APM session id for user session matching:
As your APM is before the ASM you can also place the ASM before the APM to protect the login page or webtop if you use those. But in this case maybe the session feature will not work as the APM will be after the ASM but still the ASM may track by username by the login page:
I created a test adfs config and I take my words back as by default the ADFS config shouldn't provide any URL protections but if you modified it and if the ASM/Advanced WAF is the one doing this as it could block without returning custom page if someone has made it so.
ADFS config with APM authentication and F5 SMS OTP:
We're working with support on this issue but there is no APM policy that is in use for ADFS. We are using the ADFS Trust portion that shows on a Virtual Server where you enter in Domain Admin creds to establish the trust and a certificate is autorenewed with the ADFS servers. That's where you see that anything which does not include a "/adfs" is presented with a 404. No ASM policy is in play.
Definitely a nice feature but if you're trying to put an AWAF policy in front, the violations are never triggered. Looking into having a virtual server placed in front of the ADFS virtual server but that is challenging too
We ended up putting a virtual server for the AWAF policy and then sending it back to the ADFS virtual server.
Traffic -> AWAF VIP -> ADFS VIP
It would prefer if we could do everything on one VS but since APM is evaluated before AWAF, no violations will be triggered. One day F5 may re-evalute it but today is not that day...haha.