Malformed request protection, URL blocking, BMR patterns and no-replacement-for-displacementThis type of protection is enabled by aiCache model and doesn't require any additional configuration. Only valid requests are forwarded to origin servers by aiCache. If you detect a flooding IP address or an IP address range you can block those IP addresses with aiCache IP Blocking feature. You can add offending IP addresses to aiCache by providing one or more block_ip global directives, you can provide single IP addresses or whole network ranges, like in the following example: block_ip 1.2.3.4 block_ip 45.222.13.0/24 block_ip 10.0.0.0/8 aiCache will silently drop the connection or redirect the blocked IP to the URL set with the following block_ip_sorry_url global directive: block_ip_sorry_url http://test.com/ipblockedsorrypage.html You might want to white list some IP addresses, this is possible with the following directives: allow_ip 1.2.3.4 allow_ip 45.222.13.0/24 allow_ip 10.0.0.0/8 To add IP addresses or IP ranges from Command Line Interface you can use the blip command: blip 2.2.2.2/16 on To remove the IP range from Command Line Interface, use the following command: blip 2.2.2.2/16 off You can also provide a list of IP addresses and/or IP ranges from a file, by using the following command: fblip block.txt on To remove a list of IP addresses and/or IP ranges from a file, use the following command: fblip block.txt off Note: Commands fblip, blip are peer-aware, thus if you run the command on a single node it will automagically propagated to the rest of aiCache instances in the cluster. You can also choose to be alerted in case the number of blocks per second reached a limit with the following global directive alert_blocked_ip_sec 20 Intelligent Request ThrottlingWhen enabled, this protection mode allows any given source IP to make only a certain amount of requests per certain amount of time - both, of course, configurable. To configure this mode you need to specify optional block_ip_interval and block_ip_max_req: block_ip_interval 20 ; (default value is 10) block_ip_max_req 10 ; (default value is 20) The above settings will allow up to 10 requests from every single source IP address every 20 seconds. As in IP blocking you can set block_ip_sorry_url. In addition if aiCache has to block the offending IP address multiple times it will ban that IP address for a bigger period of time. For this you can set the optional block_ip_punish_factor and block_ip_punish_time. For example, the following set up: block_ip_punish_factor 5 ; (default value is 5) block_ip_punish_time 1200 ; (default value is 600 seconds) specifies that if offending IP address was blocked more than 5 times it will be hard-blocked for 20 minutes (1200 seconds). You can enable/disable this feature in CLI: > clipt on > clipt off Note: clipt command is also peer-aware. To set up alerts in case of reaching the limit of blocks per second by setting the alert_ip_throttled_sec directive. Reverse Turing Access Token Control (RTATC)This feature is like a very flexible and configurable CAPTCHA. To set this up you need to specify the configurable prefix atc_challenge_prefix_file apf.txt # note that aicache needs to be in the same directory as the executable, otherwise specify whole path which should contain some information for the user that he landed to a challenge (captcha) page. Next you need to provide the challenge information to aiCache with the following directive: atc_challenge_dir /usr/local/aicache/atc_challenges this is the name of a directory that contains a set of challenge files. Each file is named after the proper response to the challenge. With RTATC mode on, every user will be subject to challenge. On a successful challenge pass an Access Token is issued, as a cookie. You can configure the cookie's name via optional atc_cookie_name global setting: atc_cookie_name xaiatccookie ; (default value is xaiatccookie) The cookie is issued to the requesting browser with expiration set to session. Internally, aiCache marks the issued cookie for expiration within a configurable amount of time, set via optional atc_ttl setting. The cookie is a one way cryptographic function of Client IP, Token expiration time and a special secret. You configure the secret via optional atc_salt setting. While it does have certain default value, we recommend you change to your own alphanumeric string of 6-10 characters: atc_ttl 1800 ; (default value is 1800 seconds) atc_salt yourPass Upon successful completion of the challenge, the requestor is redirected to a URL that you configure via required atc_welcome_url setting: atc_welcome_url http://test.com/DOSChallengeOK.html If there are 5 failed challenge tries then the user will be blocked for the interval set via the atc_fail_punish_time directive: atc_fail_punish_time 1800 ; (default value is 1800 seconds) There is also an optional setting for the challenge verification URL, which has a certain default value: atc_submit_url. It is up to you if you want to change it. You can enable/disable RTATC mode from CLI with the following commands (please make sure the above directives are set before starting RTATC mode): > atct on ; turns RTATC mode on > atct off ; turns RTATC mode off > atct ; shows the status of the mode Note: atct command is also peer-aware Note: When you activate RTATC mode, the intelligent throttling is activated automatically, as best DOS protection is attained when both protection modes are on. When turning RTATC mode off, please turn off intelligent throttling separately, via clipt off CLI command. Following is an example of an ATC page once it's activated: Sample configuration fileSo now that you know how to configure DoS on your aiCache instance, here's a sample config file, where you just need to specify your hostname. The DoS part is under the DoS settings section. |