Restricting access via an IP Allow List

Using the IP Allow List, you can limit access for each application environment to a specified list of IP addresses or ranges of IP addresses (aka subnets). Once you have applied the IP Allow List to an environment, any and all requests from an IP address list outside of the allowed list or range will be denied.

The IP Allow List applies to all requests:

• Requests from logged in and anonymous users
• Requests for files
• Requests for a WordPress or Node application
• Cached and uncached requests

The only exception is services within Automattic’s networks, as these will need access to support the operation of your application.

You control the IP Allow List separately for each environment of your application, e.g. the production environment has a separately controlled IP Allow List to the develop environment.

Viewing and controlling your IP Allow List

The IP Allow List for an environment is controlled from your VIP Dashboard. Anyone with access to the VIP Dashboard for your application can view the IP Allow List. Only users with admin roles on the GitHub repository for your application are authorized to add and remove IP addresses and ranges for your application environments. The UI for the IP Allow List is shown below:

To view the IP Allow List

1. Visit the VIP Dashboard.
2. Select the application from the list of applications that you have access to.
3. From the left hand menu for that application, choose “Settings”.
4. At the top of the “Settings” screen choose the environment you want to configure, e.g. “Production”, “Develop”, etc.
5. Click on the “IP Allow List” section.

If your IP Allow List is configured, you will be able to see the details here.

If your IP Allow List isn’t configured, you will see a notice saying “No IP addresses have been added. Your site is accessible to everyone.”

To add an IP or subnet (aka CIDR range, aka IP range)

Select the “Update” button top right and follow the directions. Adding the first IP address will immediately deny access from all other IP addresses.

To remove an IP or subnet

Click the “Remove” (button) to the right of the IP or subnet. Removing the last IP or subnet will make the environment accessible from anywhere on the internet.

If you want to remove mutliple IPs or subnets in one go, use the “Update” button in the top right.

Techniques for restricting access

Restricting by IP (Full Site)

When and how to use

If you want to completely restrict access to the entire site to a defined list or range of IP addresses (i.e. subnets) for your team, use the IP Allow List feature. Common implementations are for sites with highly sensitive content, intranets, and non-production environments.

What is restricted

Once enabled, any requests from IP addresses outside of the allowed range will be rejected with a 403 response from our CDN.

The restriction applies to all requests to the environment: cached and uncached requests, static files, media files, and dynamically generated content.

Content is also blocked from Jetpack’s content distribution tools. To change this behavior, please see Controlling Content Distribution via Jetpack.

Considerations

For added protection, you can also require all users to log in before accessing the site. See the Full Site section of Restricting via Authentication for more information.

Restricting by IP (Partial Site)

When and how to use

If you want to restrict access to certain parts of the site (e.g. WordPress Admin) to a defined list or range of IP addresses, you can do so at the application level.

For this to work, users must be logged in to access the restricted portions of the site. This is to avoid the caching and leaking of restricted content.

To enforce this, hook into the WordPress login flow and all subsequent logged in requests, and reject access if the user is not visiting from an authorized IP address.

What is restricted

Since the restrictions are implemented at the application level (i.e. your code), you have full control over which WordPress content and pages should be restricted.

Please note that the restrictions will only apply to content generated by WordPress; media and static assets will continue to be publicly accessible.

Content will also continue to be syndicated via Jetpack’s content distribution tools. To change this behavior, please see Controlling Content Distribution via Jetpack.