Important
EOL notice! Drupal 8 reached end-of-life on November 2, 2021. Therefore, Acquia will not be performing any testing related to Drupal 8 to ensure compatibility. Acquia recommends upgrading to Drupal 9 or later. For more information, see Frequently Asked Questions.
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 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.
To include this functionality:
In a command prompt window, edit your website’s settings.php
file (located by default in docroot/sites/default/
).
Add the following code to the end of the file:
if(!defined('DRUPAL_ROOT')) {
define('DRUPAL_ROOT', getcwd());
}
if (file_exists(DRUPAL_ROOT . '/sites/acquia.inc')) {
require DRUPAL_ROOT . '/sites/acquia.inc';
}
Save your changes to the settings.php
file.
In the docroot/sites/
directory create a file called
acquia.inc
. You can download a sample
acquia.inc
file for your use with your website. A Markdown
file with examples and explanations
of the code contained in this file is also available.
Contact Acquia Support to obtain a list
of Acquia IP addresses for allowlisting in your acquia.inc
file.
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.
Important
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.
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:
RewriteCond %{ENV:AH_Client_IP} !^123\.456\..*
RewriteRule ^http://www.google.com [R=307,L]
For more information about blocking with .htaccess
and rewrites, see
Blocking access using rewrites.
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
.
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
.
Note that 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
Order allow,deny
Allow From All
Deny from env=DENY
</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. Note that 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_Host
# Match a specific IP address
SetEnvIf AH_CLIENT_IP ^192\.168\.10\.10$ Deny_Host
Order allow,deny
Allow from all
Deny from env=Deny_Host
</ifmodule>
All IPs in the 104.128
subnet and the IP address 192.168.10.10
get a
DENY
header. The rewrite rules check for allowed, and then deny everyone
with a DENY header.
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:
<ifmodule mod_setenvif.c>
# Match all IP addresses beginning with 104.128
SetEnvIf AH_CLIENT_IP ^104\.128\.
Allow_Host
# Match a specific IP address
SetEnvIf AH_CLIENT_IP ^192\.168\.10\.10$ Allow_Host
Order deny,allow
Deny from all
Allow from env=Allow_Host
</ifmodule>
The most recent preceding code is the opposite of the first example, by using
the ALLOW
header to give only certain groups access to the website,
instead of denying those groups.
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
:
<ifmodule mod_setenvif.c>
SetEnvIf AH_CLIENT_IP ^123\.234\.123\.234$ DENY=1
SetEnvIf X-Forwarded-For 123\.234\.123\.234 DENY=1
Order allow,deny
Allow From All
Deny from env=DENY
</ifmodule>
XFF headers use a pattern match without the ^
and $
anchors—if the IP
address appears anywhere in the value of XFF header, the request will be
blocked. This method may generate false positives when using patterns to block
entire subnets, such as 123.234
.
If everything works as it should (assuming an attacker isn’t spoofing IP addresses), the actual source IP should typically display in the XFF header.
Note
You can’t be sure of the IP address’ position, as its position can vary based on the proxy’s or balancers’ configuration.