Preventing bot access to users account

This section describes how to configure HTPP throttling in order to prevent bots to force users passwords.

This task shows you how to:

Configure the HTTP Throttling Filter

HTTP throttling allows Administrators to configure patterns that will detect attempts of bots to force users passwords, block these attempts and notify administrator users of such attempts.

  1. Click Security, then the HTTP Throttling tab.
  2. Configure the HTTP throttling filter.

    The options are:

    Based on IP
    The HTTP throttling filter will track the attempts based on the source IP of the login requests (activated by default).
    Based on user
    The HTTP throttling filter will track the attempts based on the user whose account is under attack (activated by default).
    Based on session
    The HTTP throttling filter will track the attempts based on the session from which the suspicious requests originate.
    Maximum authorized failures
    The number of login failures after which we consider that password brute forcing is occurring (the default is 10).
    Delay (in milliseconds)
    The period during which the maximum number of failures should occur to consider the requester as suspicious (the default is 10000).
    Initial blocking period (in milliseconds)
    The number of milliseconds during which the 3DPassport should block suspicious requests (the default is 60000).
    Multiplier
    A multiplication factor by which we multiply the blocking period every time a suspicious request which had already been blocked, is authenticating incorrectly (the default is 2).

    Every time the HTTP throttling filter creates a new set of blocking parameters, it will write in the logs the following message:

    Level: ERROR – Type: FRAUD A throttling attempt has been detected coming from : (IP = IP, user = email / 3DEXPERIENCE ID)
    Level: WARN – Type: FRAUD Throttling detected from BlockingParamDO [id=0, sessionid=null, remoteip=IP, useridentifier=email 
    / 3DEXPERIENCE ID, creationdate=1524485515205, enddate=1524485535205]. It will be blocked delay ms

    where IP is the IP address, email is the user's e-mail address, 3DEXPERIENCE ID is the user ID, and delay is the number of milliseconds.

    When a blocking period is extended, the following message is logged:

    Level: WARN – Type: FRAUD	
    An already blocked user is still trying to login 
    (BlockingParamDO [id=0, sessionid=null, remoteip=IP, useridentifier=email / 3DEXPERIENCE ID, creationdate=1524486071151, enddate=1524486271622]). 
    This time, the user will be blocked for multiplier*delay ms
    

    where IP is the IP address, email is the user's e-mail address, 3DEXPERIENCE ID is the user ID, multiplier is the multiplier factor and delay is the number of milliseconds.

    In this second case, we display the username or the email (actually the raw content of the field username of the login form) of the user to avoid having to access the database once more to retrieve the user's information.

    Configuration example

    Let's assume the administrator configured the filter as follows:

    • Based on IP: active
    • Based on user: active
    • Based on session: inactive
    • Maximum authorized failures: 10
    • Delay: 10000
    • Initial blocking period: 10000
    • Multiplier: 2

    As soon as there are ten authentication errors from the same IP address and for one particular user, and in less than ten seconds, authentication attempts (posts on /login) from the IP and for the user will be refused with a HTTP Status 403 error for ten seconds starting from the last failure.

    After this initial blocking period of ten seconds, for the next authentication attempt from this IP for the user, the blocking period will be 2*10 ten seconds = 20 seconds.

    After the following twenty seconds, if authentication fails again, the blocking period will be 2 * 20 seconds = 40 seconds, and so forth. This will stop as soon as the authentication succeeds.

    When a user tries to log in multiple times in a way that triggers the HTTP throttling filter, any further attempts to log in will be blocked for the period of time defined by the administrator using the Delay value. Administrators will receive an e-mail informing them that the HTTP throttling filter has been triggered. If a user is involved, the user will be warned by an e-mail. During this blocking period, if the user continues to attempt to log in in a way that triggers the HTTP throttling filter, access will be refused and the following message will be displayed in the browser:

    HTTP Status 403 -
    type
    message
    description  Access to the specified resource has been forbidden

    The e-mail received by the administrator when blocking has been activated contains the following details:

    Dear FirstName LastName
    The HTTP throttling filter created a new block with the following
    details:
    IP: IP
    User: User
    Session: Session

Handle Blocked Requests

Administrators can see all the requests that are being blocked by the HTTP throttling filter.

  1. Click Security > HTTP Throttling.
  2. View the information.

    The following example lists blocked connection attempts when HTTP throttling Based on IP and Based on user are activated.

    The left-hand columns in the table are the criteria selected while configuring the HTTP throttling filter (IP, user, session).

    Creation Time
    Date of the first creation of the blocked connection attempt. If a user triggered the creation of the block on date X, then, just after the blocking period triggered the HTTP throttling event on date Y, creation time will be date X and not date Y.
    End Time
    Date at which the blocking period is supposed to end.

  3. Click Delete to delete the blocked connection attempt.
    Deleting the line unblocks the user.