With industry security standards and audit requirements, you may need high-level security tuning for a public Drupal website. There are several methods you can use to do tuning, including adding a module to your website or configuring IP restriction in Drupal itself. You may also want to block particular IP addresses due to attacks or other problems.
IP restriction in Drupal (Recommended)
IP restriction in Drupal is an important addition to protect websites from unwanted visitors. Whether these websites are development testbeds that should be kept from the general web, or private intranets of companies hosted in the cloud, it’s important to know your website is safe from prying eyes.
Acquia hosting subscribers don’t have access to Apache’s VirtualHosts, and can’t add standard Apache protections. There is no all-encompassing module or other easy method to both protect administrative file paths and restrict access to only allowlisted IP addresses on Cloud Platform.
It’s possible to restrict content service to users accessing the website from an allowed IP, users with the correct HTTP authentication, or both. Use the method based on your website’s installed version of Drupal:
Important
Even with these protections in place, Varnish® can cache a restricted webpage if the webpage isn’t specifically marked uncacheable, is accessed by a allowlisted user, and isn’t protected by HTTP authentication. Admin webpages should never be cached. If you are restricting an entire website, using Drupal’s access controls and requiring an authenticated user are better methods of accomplishing this goal.
Acquia recommends that you try the Drupal-based IP restriction method. In addition, you can restrict IP addresses. To obtain a list of Acquia IP addresses, create a Support ticket.
Alternate use cases
If you do not need the flexibility the Drupal IP restriction offers, there are some tasks you can use requiring less code, and if you have a small restriction, may be easier to upkeep.
Modifying the .htaccess file requires a code deployment and can potentially break your website by pushing erroneous code. Therefore, Acquia recommends that you test changes in a non-production environment or with a .htaccess checker.
Redirecting users outside an IP address range with .htaccess
In a non-Acquia hosting environment, you can use the %{REMOTE_ADDR} variable in the .htaccess file to redirect users to Google if they’re not in the 123.456.* IP address range. This does not work on Cloud Platform because of its load balancing structure.
To carry out the redirect on Cloud Platform, use the %{ENV:AH_Client_IP} variable:
Cloud Platform uses Varnish® and load balancers, causing typical access controls to not work as expected. This method is like the one detailed in Best practices on setting up an edit domain. You can use a combination of an environment variable that is present on your Cloud Platform infrastructure, AH_Client_IP, and Apache’s mod_setenvif and mod_authz_core.
You must ensure that these rules are in the section determining that the Apache mod_rewrite module is enabled. If these rules are not present, the redirects fail.
To block a single IP, the following example sets an environment variable on the specific IP address 192.168.15.20, using mod_setenvif. You must add the following code to the top of the .htaccess file:
<IfModule mod_setenvif.c>
SetEnvIf AH_CLIENT_IP ^192\.168\.15\.20$ DENY=1
</IfModule>
<IfModule mod_authz_core.c>
<RequireAll>
Require all granted
Require not env DENY
</RequireAll>
</IfModule>
To block several IPs, the following example blocks addresses from the group 104.128.*.* and the IP address 192.168.10.10. You can specifically deny access to these two subnets and allow access to all other IPs. You must add the following code to the top of the .htaccess file:
<IfModule mod_setenvif.c>
# Match all IP addresses beginning with 104.128
SetEnvIf AH_CLIENT_IP ^104\.128\. DENY
# Match a specific IP address
SetEnvIf AH_CLIENT_IP ^192\.168\.10\.10$ DENY
</IfModule>
<IfModule mod_authz_core.c>
<RequireAll>
Require all granted
Require not env DENY
</RequireAll>
</IfModule>
All IPs in the 104.128 subnet and the IP address 192.168.10.10 get a DENY environment variable. The rewrite rules check for allowed, and then deny everyone with a DENY variable.
To restrict access and allow only certain IP addresses to reach a website, you can add the following code to the top of the .htaccess file:
# Restrict everything, only allow access to the following:
<IfModule mod_setenvif.c>
# Match all IP addresses beginning with 111.222
SetEnvIf AH_Client_Ip ^111\.222\. Allow_Host
# Match a specific IP address
SetEnvIf AH_Client_Ip ^123\.123\.11\.22$ Allow_Host
</IfModule>
<IfModule mod_authz_core.c>
<RequireAll>
Require env Allow_Host
</RequireAll>
</IfModule>
The most recent preceding code is the opposite of the first example, by using the ALLOW environment variable to give only certain groups access to the website, instead of denying those groups.
Using XFF headers to block by IP address
If blocking by IP in .htaccess using AH_Client_IP doesn’t work, you can use the X-Forwarded-For header. The following example includes this header in the blocking rules in .htaccess:
The rule based on the X-Forwarded-For (XFF) does not anchor the pattern at the beginning (^) or end ($). If the target string appears anywhere in the value of the XFF header, the request is blocked. However, you must exercise caution when using this approach not to match a pattern more broadly than intended. For example, a pattern like 12.23 matches the IP: 22.112.234.55. For optimum results, Acquia recommends that your patterns are as specific as possible.
Note
You can’t be sure of the IP address’ position, as its position can vary based on the proxy’s or balancers’ configuration.
Restricting website access
With industry security standards and audit requirements, you may need high-level security tuning for a public Drupal website. There are several methods you can use to do tuning, including adding a module to your website or configuring IP restriction in Drupal itself. You may also want to block particular IP addresses due to attacks or other problems.
IP restriction in Drupal (Recommended)
IP restriction in Drupal is an important addition to protect websites from unwanted visitors. Whether these websites are development testbeds that should be kept from the general web, or private intranets of companies hosted in the cloud, it’s important to know your website is safe from prying eyes.
Acquia hosting subscribers don’t have access to Apache’s VirtualHosts, and can’t add standard Apache protections. There is no all-encompassing module or other easy method to both protect administrative file paths and restrict access to only allowlisted IP addresses on Cloud Platform.
It’s possible to restrict content service to users accessing the website from an allowed IP, users with the correct HTTP authentication, or both. Use the method based on your website’s installed version of Drupal:
Important
Even with these protections in place, Varnish® can cache a restricted webpage if the webpage isn’t specifically marked uncacheable, is accessed by a allowlisted user, and isn’t protected by HTTP authentication. Admin webpages should never be cached. If you are restricting an entire website, using Drupal’s access controls and requiring an authenticated user are better methods of accomplishing this goal.
Acquia recommends that you try the Drupal-based IP restriction method. In addition, you can restrict IP addresses. To obtain a list of Acquia IP addresses, create a Support ticket.
Alternate use cases
If you do not need the flexibility the Drupal IP restriction offers, there are some tasks you can use requiring less code, and if you have a small restriction, may be easier to upkeep.
Modifying the .htaccess file requires a code deployment and can potentially break your website by pushing erroneous code. Therefore, Acquia recommends that you test changes in a non-production environment or with a .htaccess checker.
Redirecting users outside an IP address range with .htaccess
In a non-Acquia hosting environment, you can use the %{REMOTE_ADDR} variable in the .htaccess file to redirect users to Google if they’re not in the 123.456.* IP address range. This does not work on Cloud Platform because of its load balancing structure.
To carry out the redirect on Cloud Platform, use the %{ENV:AH_Client_IP} variable:
Cloud Platform uses Varnish® and load balancers, causing typical access controls to not work as expected. This method is like the one detailed in Best practices on setting up an edit domain. You can use a combination of an environment variable that is present on your Cloud Platform infrastructure, AH_Client_IP, and Apache’s mod_setenvif and mod_authz_core.
You must ensure that these rules are in the section determining that the Apache mod_rewrite module is enabled. If these rules are not present, the redirects fail.
To block a single IP, the following example sets an environment variable on the specific IP address 192.168.15.20, using mod_setenvif. You must add the following code to the top of the .htaccess file:
<IfModule mod_setenvif.c>
SetEnvIf AH_CLIENT_IP ^192\.168\.15\.20$ DENY=1
</IfModule>
<IfModule mod_authz_core.c>
<RequireAll>
Require all granted
Require not env DENY
</RequireAll>
</IfModule>
To block several IPs, the following example blocks addresses from the group 104.128.*.* and the IP address 192.168.10.10. You can specifically deny access to these two subnets and allow access to all other IPs. You must add the following code to the top of the .htaccess file:
<IfModule mod_setenvif.c>
# Match all IP addresses beginning with 104.128
SetEnvIf AH_CLIENT_IP ^104\.128\. DENY
# Match a specific IP address
SetEnvIf AH_CLIENT_IP ^192\.168\.10\.10$ DENY
</IfModule>
<IfModule mod_authz_core.c>
<RequireAll>
Require all granted
Require not env DENY
</RequireAll>
</IfModule>
All IPs in the 104.128 subnet and the IP address 192.168.10.10 get a DENY environment variable. The rewrite rules check for allowed, and then deny everyone with a DENY variable.
To restrict access and allow only certain IP addresses to reach a website, you can add the following code to the top of the .htaccess file:
# Restrict everything, only allow access to the following:
<IfModule mod_setenvif.c>
# Match all IP addresses beginning with 111.222
SetEnvIf AH_Client_Ip ^111\.222\. Allow_Host
# Match a specific IP address
SetEnvIf AH_Client_Ip ^123\.123\.11\.22$ Allow_Host
</IfModule>
<IfModule mod_authz_core.c>
<RequireAll>
Require env Allow_Host
</RequireAll>
</IfModule>
The most recent preceding code is the opposite of the first example, by using the ALLOW environment variable to give only certain groups access to the website, instead of denying those groups.
Using XFF headers to block by IP address
If blocking by IP in .htaccess using AH_Client_IP doesn’t work, you can use the X-Forwarded-For header. The following example includes this header in the blocking rules in .htaccess:
The rule based on the X-Forwarded-For (XFF) does not anchor the pattern at the beginning (^) or end ($). If the target string appears anywhere in the value of the XFF header, the request is blocked. However, you must exercise caution when using this approach not to match a pattern more broadly than intended. For example, a pattern like 12.23 matches the IP: 22.112.234.55. For optimum results, Acquia recommends that your patterns are as specific as possible.
Note
You can’t be sure of the IP address’ position, as its position can vary based on the proxy’s or balancers’ configuration.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform