If your application is integrated with Akamai Cloudlet platform, you can follow below steps to block bad bots using ShieldSquare API client.   

  1. ShieldSquare Bot IP Feed generates bad bot IPs/CIDRs continuously 

  2. These bad IPs/CIDRs are maintained as a database 

  3. ShieldSquare API Client to be used (as explained below) at regular intervals to blacklist the bad IPs/CIDRs obtained from the latest version of the database


The module requires python 3.4 to be installed. Akamai EdgeGrid library for Python also needs to be installed. Please follow the steps below: 

# Create a virtual environment with Python version 3.4

$> virtualenv -p python3.4 cloudlet

# Activate the virtual environment

$> source cloudlet/bin/activate

# Upgrade pip and setuptools

$> pip install --upgrade pip setuptools

# Install the required Akamai EdgeGrid library for Python

$> pip install requests edgegrid-python

How to implement?

Following are the steps to implement ShieldSquare protection. 

  • At regular intervals (e.g., hourly), the latest version of IPs/CIDRs need to be exported from the database as a csv file. 

  • After the csv file is ready, the program ss_cloudlet_connector.py can be executed within the virtual environment ($> python3.4 ss_cloudlet_connector.py). 

  • The program reads the IPs/CIDRs from the csv file. These IPs/CIDRs are blocked at the CDN level using Akamai cloudlet API. 

  • It is recommended to automate .csv export and the execution of ss_cloudlet_connector.py jobs through a cron job. 

The configuration details of the API client are mentioned in the file config.ini. The path of config.ini can be set in ss_cloudlet_connector.py (default path is the current directory).

Internally, a Request Control cloudlet policy is used for blocking IPs/CIDRs. A new version of the policy is created each time ss_cloudlet_connector.py is executed. The latest set of IPs/CIDRs are added as rules in the new policy version. The new policy version is then activated (this in turn deactivates the previous versions of the policy). 


The configuration details to be added in each section of config.ini are explained below.


The credentials required to access the Akamai API are to be added in this section. These include the API base URL, client token, client secret and access token.


The details of the specific cloudlet to be used are to be added in this section. These include the ids of the group, cloudlet and policy. The value of cloudlet_type should be IG.


The details of the property to be protected are added in this section. These include the property name, network and the action to be taken (e.g., “deny”).


This section contains the limits enforced by the API client. max_ips_per_rule denotes the maximum number of IPs added per rule. max_rules_per_policy denotes the maximum number of rules which can be added per policy. max_ips_per_rule should be 400 and max_rules_per_policy should be 33 in order to conform to Akamai cloudlet’s limitations. If the total number of IPs/CIDRs in the input csv file exceeds 13,200 (i.e., 400*33), the API client will exit with error.

max_policy_versions_retained denotes the maximum number of policy versions maintained in Akamai cloudlet’s history. Older versions of the policy are deleted by the ShieldSquare API client when the limit is reached. 


This section contains the settings for logging. Log rotation feature is available. The parameters include the path to the log file (log_file) and log level. maxBytes denote the file size at which rotation will be invoked and backupCount denotes the number of rotated log files which will be maintained.


This section contains the details of the input file containing the IPs/CIDRs. input_ip_cidr_file denotes the path to the input file and csv_quotechar denotes the quote character used in the input file.

Note : The assumption is that ShieldSquare integration is already available either at your server side or client side. 

Write to support@shieldsquare.com for the required files and any guidance for implementation.