Loading ...

Would you like to discuss your environment with a knowledgable engineer?

Preferred communication *

Thank you. We will be in touch with you shortly

aiProtect configuration

AWS users are recommended to follow this guide to set up security groups

  1. 1. SYN flood, malformed request protection, URL blocking and BMR patterns (against SQL injections)
  2. 2. IP Blocking
  3. 3. Intelligent Request Throttling (most used and recommended)
  4. 4. Reverse Turing Access Token Control (RTATC)
  5. 5. Sample configuration file
  6. 6. Email alerts: during an attack

SYN flood protection, malformed request protection, URL blocking and BMR patterns .

For optimal configuration of these settings it is best to read our admin guide starting at page 190. The section below does give a good overview. Many settings have a default value an may not need any configuration to work. Others might already be included in the DDoS template, which you can find in the deployment tool.

SYN flood protection

All of our aiProtect instances are properly configured with IPtables rules that will detect, block and log any SYN Flood attacks. Once a SYN Flood is detected an email will be sent to the configured email address in the aiProtect configuration file. This email contains details about attacker’s IP address(es) and provides a URL, through which you can download the logs and take action.

Malformed request protection

As you might know, sometimes hackers try to attack web sites by feeding them URLs configured in certain way, most often to cause buffer overflows with resulting execution of carefully constructed code.  When such malformed requests or URLs are discovered, websites are often left at the mercy of their Web software providers to issue quick patch to address the problem.  Often there’s no way to prevent these dangerous URLs from hitting the web servers, as there is nothing in front of the victimized web servers to filter out these dangerous URLs.

To protect against such malicious/malformed requests, you can specify maximum HTTP header size and body size, via max_header_size (defaults to 8KB) and  max_body_size (defaults to 1MB), both must exceed server MTU to be enforceable. You can also enforce URL length limit at website or pattern level by using max_url_length parameter in the respective section. Pattern setting overrides website-level setting, if any .

URL Blocking

You can also explicitly specify list of patterns that are blocked outright by the aiScaler. To block a pattern, simply define it in the configuration file and add “block” directive below the pattern definition. For example:

pattern exploited.html simple 0

BMR (body-match-reject): Search and filter requests based on their body

You can also define a list of regular expression patterns to apply to request bodies (when such request bodies are available). Should content of request body match one of such body-match-reject (BMR) patterns, aiScaler will drop the matching request.

You can use this functionality to filter out common threats such as SQL injection or any other body patterns that you might find troublesome.
The BMR patterns are defined via bmr_pattern directive . Arbitrary number of these could be placed in global, website or pattern section of the aiCache configuration file. For example:

bmr_pattern update\s+
bmr_pattern delete\s+
bmr_pattern insert\s

IP Blocking

If you detect a flooding IP address or an IP address range you can block those IP addresses with aiScaler IP Blocking feature. You can add offending IP addresses to aiScaler by providing one or more block_ip global directives, you can provide single IP addresses or whole network ranges, like in the following example:

aiScaler 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:

To add IP addresses or IP ranges from Command Line Interface you can use the blip command:

blip on
To remove the IP range from Command Line Interface, use the following command:

blip 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 aiScaler 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 Throttling

When 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 aiScaler 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.
atc_challenge_prefix_file apf.txt
Next you need to provide the challenge information to aiScaler 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, aiScaler 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 file

So now that you know how to configure DoS on your aiScaler instance, here’s a sample config file, where you just need to specify your hostname. The DoS part is under the DoS settings section.

During an attack

Once aiProtect instance gets under a DDoS attack, you will get notified by email specified in /etc/aicache/aicache.cfg file (setting is alert_email). You can then view the files with offending ip-addresses in real time through your browser, either on http://ip.address.of.aiscaler/synflood_offenders.txt (for SYN flood attacks) or http://ip.address.of.aiscaler/clip_offenders.txt (for all other DoS attacks).

If you don’t react by removing the offender files from the server manually, you’ll get notified again in 24 hours.

Removing offender files manually

Log into the aiProtect instance via SSH and become the root. Then execute the following command:

root@aiProtect~# ddos_cleanup.sh

Full configuration example with DoS protection, SSL and caching


US 1 (408) 744-6078   EU +44 20 7993 4587