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.
- Access to a project hosted on Platform.sh
- Administrator rights on the project
- Knowledge on using the Platform.sh CLI and the web UI
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.
If the Platform CLI is preferred, these are the steps to take in order to block IP addresses.
$ platform login
Note the project ID of the project to enable the deny list for:
$ platform project:list
Note the environment ID for the environment on the project that needs securing:
$ platform environment:list -p <project-ID>
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)
If multiple IPs are meant to be denied, this entire block has to be repeated:
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:
To 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.
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.
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
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.
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.