Forum Discussion

SteveD1979's avatar
SteveD1979
Icon for Cirrostratus rankCirrostratus
Nov 16, 2023

Can I use an Irule to bypass an access policy if a cookie is present

Hi,

I have an issue where I have a Kerberos based access policy set up to give users access to an application.  The policy works great for users but when we try to use a vulnerability scanner from an outside vendor the cookies don't get sent through and it fails the credential check.  I use the access policy to also capture AD attributes for the user and send them as headers for permissions inside the app.

Is there a way to have an irule tied to the VIP where I could check for a custom header inserted by the scanner and if it and the value are present I can bypass the access policy and just send it through to the application?

  • Thanks for the clear explanation. Yes sure, this should be pretty easy.

    Firstly: APM "hides" some session-setup HTTP events from HTTP_REQUEST for safety, so you have to disable that.

    Second: APM offers an "ACCESS::disable" command that completely turns off APM from the current connection flow.

    So to put these two together, you could do something like:

    when CLIENT_ACCEPTED {
        ACCESS::restrict_irule_events disable
    }
    when HTTP_REQUEST {
    if { [string tolower [HTTP::header {x-turn-off-apm}]] == "yes" } {
    ACCESS::disable } }

     

    Then we can apply this to a vip and test it with curl. See how when we satisfy the header condition in that irule, the access profile is turned off and we get directly to the pool defined, then if we don't satisfy the condition, the APM does the normal set-cookie and /my.policy redirect: 

    L.Thompson@test ~ % curl -I -X GET -k --header 'x-turn-off-apm: no' https://10.154.73.51
    HTTP/1.0 302 Found
    Server: BigIP
    Content-Length: 0
    Location: /my.policy
    Set-Cookie: LastMRH_Session=8d8df9f4;path=/;secure
    Set-Cookie: MRHSession=7a4cd79cb764e8fa74ba2a618d8df9f4;path=/;secure
    Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/;secure
    Connection: close

    L.Thompson@test ~ % curl -I -X GET -k --header 'x-turn-off-apm: yes' https://10.154.73.51
    HTTP/1.1 200 OK
    Content-Type: text/html
    Last-Modified: Wed, 08 Feb 2023 02:30:13 GMT
    Accept-Ranges: bytes
    ETag: "e0e3b745653bd91:0"
    Server: Microsoft-IIS/10.0
    Date: Thu, 16 Nov 2023 20:16:09 GMT
    Content-Length: 703

     

  • you can also set separate VS with non-kerberos auth (such as HTTP 401 Authenticate) then tell the scanner vendor to set this VS address in their hosts file.

  • Thanks for the clear explanation. Yes sure, this should be pretty easy.

    Firstly: APM "hides" some session-setup HTTP events from HTTP_REQUEST for safety, so you have to disable that.

    Second: APM offers an "ACCESS::disable" command that completely turns off APM from the current connection flow.

    So to put these two together, you could do something like:

    when CLIENT_ACCEPTED {
        ACCESS::restrict_irule_events disable
    }
    when HTTP_REQUEST {
    if { [string tolower [HTTP::header {x-turn-off-apm}]] == "yes" } {
    ACCESS::disable } }

     

    Then we can apply this to a vip and test it with curl. See how when we satisfy the header condition in that irule, the access profile is turned off and we get directly to the pool defined, then if we don't satisfy the condition, the APM does the normal set-cookie and /my.policy redirect: 

    L.Thompson@test ~ % curl -I -X GET -k --header 'x-turn-off-apm: no' https://10.154.73.51
    HTTP/1.0 302 Found
    Server: BigIP
    Content-Length: 0
    Location: /my.policy
    Set-Cookie: LastMRH_Session=8d8df9f4;path=/;secure
    Set-Cookie: MRHSession=7a4cd79cb764e8fa74ba2a618d8df9f4;path=/;secure
    Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/;secure
    Connection: close

    L.Thompson@test ~ % curl -I -X GET -k --header 'x-turn-off-apm: yes' https://10.154.73.51
    HTTP/1.1 200 OK
    Content-Type: text/html
    Last-Modified: Wed, 08 Feb 2023 02:30:13 GMT
    Accept-Ranges: bytes
    ETag: "e0e3b745653bd91:0"
    Server: Microsoft-IIS/10.0
    Date: Thu, 16 Nov 2023 20:16:09 GMT
    Content-Length: 703