IBM Security Verify

 View Only
  • 1.  ISVA 10.0.3.1 - Rate Limiting Configuration Questions/Functionality

    Posted Wed June 15, 2022 01:31 PM
    Hello all,

    I have been working in my Development env. just to see if I could get rate limiting to actually block a user. The flow is an API flow using Oauth tokens, and simply the request is to rate limit on the AZN_CRED_PRINCIPAL_NAME on a junction with the name /servicestatus-dev.

    I have set the capacity = 2, with an interval of 30 seconds, and never see the HTTP 429 (reaction set = TEMPLATE) which should return the rate limit template page. 

    I am curious if the format of the YAML file might be the issue and will provide that below. From the ratelimit debug log, it looks like a bucket is started per request and ends per request, yet the same user/token is being provided and all through the same session. 

    I'm just at a loss, because all I'd like to see is this actually function per what documentation I have seen. Can anyone provide any insight? it would be greatly appreciated.

    Sample of current YAML file for Rate Limiting:

    ---
    #=========================
    # Rate limiting AZN_CRED_PRINCIPAL_NAME
    #=========================
    # This policy limits the number of times a given credential can be used to
    # send requests the reverse proxy in <interval> seconds from the first request.

    # Once the rate limiting policy has been finalized it can be attached to a
    # Web Reverse proxy instance via the reverse proxy configuration file.
    # To enable this policy add the following entry to the [rate-limiting] stanza:
    # policy = Limit_AZN_CRED_PRINCIPLE_NAME_Policy.yaml
    #
    #
    #
    #=========================
    # Matching criteria
    #=========================
    # Identifies that this configuration should be applied to the
    # request by method and URL. Wild cards accepted. Method, can be a comma
    # separated list too. This can just as easily be applied to a form provided
    # by an EAI, just update the URL to match the form action.
    #
    # Any request matches this criteria - request URL - HTTP method
    # Examples GET, POST

    resources:
      - url: "/servicestatus-dev*"
        method:
        - "*"

    # Limiting is based on the credential being used
    credential:
       AZN_CRED_PRINCIPAL_NAME: "*"

    # Credential can be used <interval> times during the <capacity> window in seconds
    capacity: 2
    interval: 30

    #=========================
    ## Tokenizing Criteria
    ##=========================
    ## Requests are built into tokens to identify them, these
    ## tokens consist of any permutation of IP, headers, cookies, query string
    ## parameters.
    ## Include the IP of the client
    # ip: true

    #=========================
    ## Reaction
    ##=========================
    ## How the client is notified they have been rate limited. This can
    ## be one of:
    ## 'TEMPLATE' - return a 429 and the rate limit template page
    ## 'CLOSE' - drop the connection.
    ##
    ## A URL to re-write the request to, for example '/dummylogin' which does not
    ## log the user in ever, so they're not actually aware they've been rate
    ## limited.
    ##
    ## In this instance we return the template, if no reaction is included this is
    ## the default
    ## Return the template if a client is rate-limited

    reaction: TEMPLATE

    ...

    ------------------------------
    Bayless Rutherford
    ------------------------------


  • 2.  RE: ISVA 10.0.3.1 - Rate Limiting Configuration Questions/Functionality

    Posted Wed June 15, 2022 05:20 PM

    Bayless,

     

    I just tested your rate limiting file in my environment and it worked fine.  Did you remember to 'activate' the rate limiting policy in your WebSEAL instance by setting the 'policy' configuration entry in the '[rate-limiting]' stanza?

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     






  • 3.  RE: ISVA 10.0.3.1 - Rate Limiting Configuration Questions/Functionality

    Posted Thu June 16, 2022 05:02 PM
    Scott,

    Thank you for your help! Yes when I go the RP instance in the LMI for basic config, on the "Rate Limiting" tab there is the one policy listed pertaining to my policy file above, and in the Webseal conf file I have the following entry in the [rate-limiting] stanza. This is the onlly uncommented parameter in the stanza.

    policy = low.dev.test.yaml

    I notice from the Rate Limiting policy page on the LMI all policies are listed as <policy name>.yaml, as I have above in the Webseal config file. Although if I select the RP/Webseal from the Reverse proxy menu and click on "Edit", if I go to the "Rate Limiting" tab (where it lists Polices that are attached and Redis configuration options) the attached policy just says "low.dev.test" with no ".yaml" on the end. Could the .yaml on the end of the stanza entry above be an issue?

    When the user sends requests, usually about 10 in a brief period, I do see in the rate limit debug that it appears to start a bucket, which appears to end immediately on that sole request. Same session, same client ID, so the user should get the HTTP 429 on the 3rd request, I would think. Here's a snippet of that tracing for two threads. As you can see the rate limiting begin and end on a request just appear to happen immediately.

    2022-06-14-14:18:12.287-04:00I----- thread(184) trace.pdweb.http.ratelimit:3 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:660: ---RateLimiting begin---

    2022-06-14-14:18:12.287-04:00I----- thread(184) trace.pdweb.http.ratelimit:5 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:422: Matching /servicestatus-dev to GET /servicestatus-dev/test/servicestatus/v1/status

    2022-06-14-14:18:12.287-04:00I----- thread(184) trace.pdweb.http.ratelimit:3 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:757: ---RateLimiting end---

    2022-06-14-14:18:12.287-04:00I----- thread(184) trace.pdweb.http.ratelimit:3 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:660: ---RateLimiting begin---

    2022-06-14-14:18:12.287-04:00I----- thread(184) trace.pdweb.http.ratelimit:5 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:422: Matching /servicestatus-dev to GET /servicestatus-dev/test/servicestatus/v1/status

    2022-06-14-14:18:12.287-04:00I----- thread(184) trace.pdweb.http.ratelimit:3 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:757: ---RateLimiting end---

    2022-06-14-14:18:13.202-04:00I----- thread(185) trace.pdweb.http.ratelimit:3 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:660: ---RateLimiting begin---

    2022-06-14-14:18:13.202-04:00I----- thread(185) trace.pdweb.http.ratelimit:5 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:422: Matching /servicestatus-dev to GET /servicestatus-dev/test/servicestatus/v1/status

    2022-06-14-14:18:13.202-04:00I----- thread(185) trace.pdweb.http.ratelimit:3 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:757: ---RateLimiting end---

    2022-06-14-14:18:13.202-04:00I----- thread(185) trace.pdweb.http.ratelimit:3 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:660: ---RateLimiting begin---

    2022-06-14-14:18:13.202-04:00I----- thread(185) trace.pdweb.http.ratelimit:5 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:422: Matching /servicestatus-dev to GET /servicestatus-dev/test/servicestatus/v1/status

    2022-06-14-14:18:13.202-04:00I----- thread(185) trace.pdweb.http.ratelimit:3 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:757: ---RateLimiting end---

    ------------------------------
    Bayless Rutherford
    ------------------------------



  • 4.  RE: ISVA 10.0.3.1 - Rate Limiting Configuration Questions/Functionality

    Posted Thu June 16, 2022 07:12 PM

    Bayless,

     

    The file name extension shouldn't matter too much – WebSEAL will fail to start if you provide a file name which doesn't actually exist.

     

    I just activated trace in my environment, and there are two significant lines in my trace output which show that the rate limiting policy is taking affect:

     

    2022-06-17-09:04:54.257+10:00I----- thread(4) trace.pdweb.http.ratelimit:5 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:423: Matching /index.html* to GET /index.html

     

    2022-06-17-09:04:54.257+10:00I----- thread(4) trace.pdweb.http.ratelimit:5 /build/isam/src/i4w/pdweb/webseald/http/ratelimit/RateLimit.cpp:430: Methods successfully matched

     

    The first line shows the policy URL (in my case I set it to '/index.html*') and the second line shows that the method itself matched (in my case I set the method to '*').

     

    When I compare this to your trace output there are two concerns, the URL you are matching against is '/servicestatus-dev', when it should really be something like: '/servicestatus-dev*'.  The second concern is that regardless of the URL match, the method is not matching. 

     

    Are you able to double-check your policy file, and ensure that the method and URL has a '*'.

     

    Here is an extract from my policy file:

     

    resources:

      - url: "/index.html*"

        method:

        - "*"

     

    # Limiting is based on the credential being used

    credential:

       AZN_CRED_PRINCIPAL_NAME: "*"

     

    # Credential can be used <interval> times during the <capacity> window in seconds

    capacity: 2

    interval: 30

     

    I hope that this helps.

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     






  • 5.  RE: ISVA 10.0.3.1 - Rate Limiting Configuration Questions/Functionality

    Posted Fri June 17, 2022 03:41 PM
    Scott, thank you again for your advice. So I should see the wildcard on the URL in the trace log, which I'm not seeing, so it's like what's running is not representative of what is in the policy file. 

    Your example shows the wildcard, which is a big help, so I should see that in the trace log if the rate limiting was being imposed accurately.

    ------------------------------
    Bayless Rutherford
    ------------------------------