Goal
To block a certain set of abusive IP addresses before they hit the application layer. This can be IPs identified to cause high load or otherwise harm the system, e.g. crawlers / bots, malicious scripts, hacking attempts, or IPs that should be blocked for any other operational reason.
Assumptions
- Access to a project hosted on Platform.sh
- Administrator rights on the project
- Knowledge on using the Platform.sh CLI and the web UI
Problems
Sometimes a website can be stressed by traffic originating from IP addresses that are causing high load or any other negative impact on the application environment. In some cases it makes sense for those IP addresses to be added to a deny liset in order to stabilize system resource usage. In other cases certain IP ranges might need to be blocked for a different operational reason.
Platform.sh allows for such a deny list to be configured either through the CLI, or through the project’s web UI.
Depending on personal taste or technical familiarity level, there are 2 ways to go about configuring IP deny list on the project.
Steps (Via the CLI)
If the Platform CLI is preferred, these are the steps to take in order to block IP addresses.
1. Log in to Platform CLI
$ platform login
2. Find the project ID
Note the project ID of the project to enable the deny list for:
$ platform project:list
3. Find the environment ID
Note the environment ID for the environment on the project that needs securing:
$ platform environment:list -p <project-ID>
4. Create the deny list
Run the following command to create the deny list and include the IP that needs to be blocked:
platform httpaccess --access deny:<the-IP-to-be-blocked> -p <project-ID> -e <environment-ID> (optional: --no-wait)
Note:
If multiple IPs are meant to be denied, this entire block has to be repeated:
--access deny:<the-IP-to-be-blocked>Example:
platform httpaccess --access deny:<the-IP-to-be-blocked> --access deny:<another-IP-here> -p <project-ID> -e <environment-ID> (optional: --no-wait)If multiple IPs of the same subnet need to be denied, it’s also possible to add the whole subnet to the list in CIDR notation. For example:
--access deny:69.63.176.0/20To clear the whole list and allow all traffic from any IP:
platform httpaccess - - access allow:any -p <project-ID> -e <environment-ID> (optional: --no-wait)If there are already IPs on the deny list, another
platform httpaccess --access deny:<new-IP-to-be-blocked> -p <project-ID> -e <environment-ID> (optional: --no-wait)will not add the new IP to the list. Instead, it will redefine the entire list and therefore delete all previously listed IPs unless they’re included again in the statement.
Steps (Via the web UI)
Since the CLI and the web UI are both connecting to the same API in the background, they both provide the same set of commands around its functionality. If the UI is preferred over the CLI, the same settings can be activated through the browser.
1. Browse to the general settings tab on the project’s environment:
2. Add IP address or subnets
Expand the HTTP access control tab via Edit and add IP addresses or subnets as shown, then save:
For the duration of the propagation, environments will be in status Dirty but resolve quickly back to Active.
Caveats:
IP restriction is per environment / branch.
Deny lists are not inherited on already existing environments.
However, it is inherited on newly created environments. These new environments inherit from their respective parent environment.
The UI is probably the safer choice to manage blacklists due to its ability to easier add any IP to an already existing list.
Be careful with adding IPs to the list via CLI as the command overwrites the existing list. Any IPs not included in the command will be deleted from the list.
Conclusion
Platform.sh makes it easy to manage IP deny lists on a per-environment basis. A choice can be made between using the CLI for list management, or clicking through the UI in the browser.
Once IPs are added to the list and the change is deployed to the environment, any traffic coming from those IPs will be filtered out on Platform’s infrastructure before the request can hit the application layer and cause any harm.