Restricting access to the Acquia default domain using .htaccess

Overview

Every Cloud Platform environment is provisioned with a default subdomain that ends in .acquia-sites.com, for example, mysite.prod.acquia-sites.com. You cannot remove or replace this default domain. It persists even after you configure a custom domain and point DNS to your environment.

When you protect your site with a CDN or Web Application Firewall (WAF), such as Acquia Edge powered by Cloudflare, Fastly, or Akamai, on your custom domain, the Acquia default domain can still be publicly accessible. Therefore, an attacker who discovers your default domain can send requests directly to your origin server and bypass your CDN or WAF security rules entirely. These rules include rate limits, bot protection, IP blocklists, and DDoS mitigation. 

Use the .htaccess rules in this article to restrict access to the Acquia default domain so that only trusted parties, such as the customer and Acquia Support, can access it.

When to use these rules

Use these rules when all of the following are true:

• Your site uses a custom domain, for example, www.example.com, for production traffic.
• A CDN or WAF that provides security filters fronts your custom domain.
• You want to ensure attackers cannot use the Acquia default domain, mysite.prod.acquia-sites.com, to bypass your CDN or WAF.

If your site does not use a CDN or WAF, adopt Acquia Edge instead. Acquia Edge provides edge-level protection before traffic reaches your origin server.

Prerequisites

Before you implement these rules, ensure the following:

• A custom domain is configured for your environment in Cloud Platform interface. Refer to Managing domains.
• A CDN or WAF is active on your custom domain.
• You have Git or SSH access to your application codebase to modify .htaccess.
• For Option B only, you contacted Acquia Support to obtain the IP addresses used by Acquia Support engineers. Refer to Contacting Support for details.

Understanding AH_Client_IP

On Cloud Platform, all incoming traffic passes through Elastic Load Balancers (ELBs) and Varnish reverse proxy caches before it reaches the Apache web server. Therefore, the standard Apache variable REMOTE_ADDR always returns the internal IP address of the load balancer instead of the actual client IP address. 

To match the real client IP in .htaccess rules, you must use the AH_Client_IP variable. Acquia infrastructure sets this variable, and it always reflects the original client IP. Use the correct syntax for the type of rule that you create:

• In RewriteCond rules: %{ENV:AH_Client_IP}
• In SetEnvIf directives: AH_CLIENT_IP

Option A: Redirect to custom domain

This option redirects all requests that arrive on the Acquia default domain to your custom domain with a 301 permanent redirect. The redirect sends visitors and bots that discover your default domain to your production site.

Add the following rules to your .htaccess file, replacing mysite.prod.acquia-sites.com with your actual Acquia default domain and www.example.com with your custom domain:

# Redirect Acquia default domain to custom domain
RewriteCond %{HTTP_HOST} ^mysite\.prod\.acquia-sites\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Line-by-line explanation:

Option B: 403 Forbidden with IP allowlist

This option returns a 403 Forbidden response to any request on the Acquia default domain that does not come from an allowlisted IP address. Only the IP addresses you specify, such as your office IP and the Acquia Support IP, can access the default domain.

Add the following rules to your .htaccess file, replacing the example IP addresses with your actual trusted IPs:

# Return 403 on Acquia default domain, except for allowlisted IPs
<IfModule mod_setenvif.c>
  # Match requests on the Acquia default domain
  SetEnvIf Host mysite\.prod\.acquia-sites\.com AcquiaDomain=1
  # Allowlist your customer IP address
  SetEnvIf AH_CLIENT_IP ^203\.0\.113\.10$ AllowedIP=1
  # Allowlist Acquia Support IP range (obtain from Acquia Support)
  SetEnvIf AH_CLIENT_IP ^198\.51\.100\. AllowedIP=1
</IfModule>
<IfModule mod_authz_core.c>
  <If "-n %{ENV:AcquiaDomain} && -z %{ENV:AllowedIP}">
    Require all denied
  </If>
</IfModule>

Line-by-line explanation:

Placement guidance

Insert these rules in your .htaccess file after the RewriteEngine On directive and before any other redirect or rewrite rules. Placing them early ensures the rules are evaluated first.

RewriteEngine On

# --- Acquia default domain restriction (add here) ---
RewriteCond %{HTTP_HOST} ^mysite\.prod\.acquia-sites\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
# ---------------------------------------------------

# Your other redirect rules follow here
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Testing your rules

After deploying your .htaccess changes, use curl to verify that the rules are working correctly.

Test Option A (301 redirect):

curl -I http://mysite.prod.acquia-sites.com/

Expected response: HTTP/1.1 301 Moved Permanently with a Location header pointing to your custom domain.

Test Option B (403 Forbidden from a non-allowlisted IP):

curl -I http://mysite.prod.acquia-sites.com/

Expected response: HTTP/1.1 403 Forbidden

To verify that an allowlisted IP receives a normal response, use a machine or VPN connection with the allowlisted IP and repeat the curl command. You must receive a 200 OK response.

Contacting Support

If you want to implement Option B, an IP allowlist, to restrict your Acquia default domain, you must contact Acquia Support to obtain the IP address or IP range that Acquia Support engineers use.  This requirement ensures that Acquia Support can continue to access your environment through the default domain to test, troubleshoot, and maintain the platform.

To request the Acquia Support IP:

1. Open a support ticket at Acquia Support.
2. State that you are implementing .htaccess IP allowlisting on your Acquia default domain.
3. Request the current Acquia Support IP addresses to add to your allowlist.

Related information

• Blocking unwanted traffic on your website
• Restricting website access
• Redirecting visitor requests using the .htaccess file
• Managing domains
• Blocking access using rewrites
• Restricting access