Follow

Q&A: What Information does Silverline need to configure Brute Force / Velocity Rate Limit Protection

Question

  • The intent of this article is to provide a guide to collecting the necessary information to setup/configure an iRule to mitigate Brute Force / Velocity Rate attacks

 Environment

  • Silverline WAF
  • Proxy/Proxies
  • iRule
  • Brute Force Attack

Answer

  1. Here are the details that we'll need to collect in order to configure the iRule for Brute Force / Velocity Rate Limit Protection 
    • Requirement(s):
      • Settings Purpose Example Valid/Acceptable Value(s)
        detect_window The number of seconds over which we're looking for <detect_rate> failed logins to occur 60 seconds 1-86400 seconds
        detect_rate The number of failed logins that happen within a <detect_window> to determine a bruteforce is under way 20 1-1000 requests
        blk_lifetime The maximum number of seconds a client IP will remain in the shun table 86400 10-86400 seconds
        whitelist_ips A list of IP addresses that will never be considered as a source of bruteforce ["1.2.3.4","fe80::1234"] a list of valid IPs or subnets
        action The TCP layer shun response after a bruteforce has been detected for new connections drop log/drop/reject
        response_code The HTTP response code to return to the request that triggered the bruteforce 429 a valid HTTP response status code
        response_content The HTTP response content to return to the request that triggered the bruteforce "Too many requests" a valid HTML response
      • What are the conditions for the detect criteria? (Example, POST request to /login URL)
        • Settings Purpose Example Valid/Acceptable Value(s)
          method The request method that is used when a user submits a login POST a valid HTTP method
          url The URL to monitor for logins "/login" a valid URL
          url_compare The Tcl operator to use for checking the URL "eq" "eq" / "ne" / "contains" / "starts_with" / "ends_with"
      • What are the conditions for the login to fail or succeed?
        • Setting Purpose Example Valid/Acceptable Value(s)
          status The HTTP response code that determines a login <detect> 302 a valid HTTP response code, usually '302' for redirect, '200' or '403' for content. type 'content' and '302' don't make sense together, neither does type 'redirect_*' anything other than a 30? code
          type The response type we're inspecting to determine login <detect> redirect_path redirect_path/redirect_full/content
          detect Wether the response we're detecting is a successful or failed login "success" success/failure
          casesensitive Wether the response check of content or Location header is case-sensitive false true/false
          max_content_len The maximum number of bytes to collect when checking a response 1024 1-8192
          content The content to look for in the HTTP response payload if using a <type> of "content" "Login failed" if using type "content", the content to find in the response before max_content_len bytes
          redirect_location The location to look for in the HTTP response Location header, either just the path or the full header / if using type "redirect_path", the path portion of the redirect given in the Location header, if using type "redirect_full", the full redirect given in the Location header
          redirect_compare The Tcl operator to use for checking the Location header "eq" "eq" / "ne" / "contains" / "starts_with" / "ends_with"

Related Content 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request