Web Rules Engine

The Web Rules Engine is a User Portal-based service that enables you to self-serve site rules as an alternative to .htaccess rules. The service currently supports management of the following rule types: IP-based Allow/Deny rules and response headers.

Overview

The Web Rules Engine (WREn) enables you to self-manage certain site traffic behaviors from the User Portal, such as:

  • Disallowing IP/Range access to protect against malicious attacks and other negative site behavior
  • Allowing IP/Range access for known good actors
    • IPs that have been blocked at a server level cannot be allowed in this way, it only impacts IPs denied by another web rule.
  • Preventing direct access to private files
  • Restricting traffic from specific countries or regions
  • Modifying cache-control headers and security headers

For those who previously leveraged .htaccess file rules to self-manage and control these behaviors, the Web Rules service can now be used instead via the User Portal. 


Manage Web Rules

To manage access and header rules for any environment:

  1. Log in to the User Portal
  2. Select the environment name
  3. Click Web Rules in the menu

Additionally, you can choose the Access Rules tab or the Header Rules tab to manage a specific type of rule.

Web Rules functionality is enabled by default on all environments.

NOTE

In some cases, there may be a temporary Global Setting available on the page above that reads “Enable .htaccess support”. This option is only available in specific cases, you can learn more about it here.


Access Rules

Access rules can allow you to manage the flow of traffic to a website with certain restrictions. For example, access rules can be used to block an IP range.

Access rules are read in cascading order, can be set for IP or IP ranges, and can have certain conditions applied.

IP and CIDR Standardization

The list of IPs and CIDRs for every access rule are sorted, CIDR blocks are standardized, and duplicates are removed. The standardized list is always equivalent to the original. It will not allow or block anything that wasn’t in the original list.

For example:

177.47.19.194/30,
177.47.19.198/30,
177.47.18.106/29,
200.219.195.250/30


Will be standardized to the equivalent:

177.47.18.104/29,
177.47.19.192/30,
177.47.19.196/30,
200.219.195.248/30

Add Access Rule

To add a new web rule:

  1. Open the Web Rules engine
  2. Select Access Rules
  3. Click Add Rule
  4. Enter the rule
  5. Click Add Rule to validate and save the new rule
  6. Once your web rules have been validated and applied, they will populate in the rule table

Insert Relative Access Rule

Users with existing web rules have additional options for adding new rules in relation to existing rules. This can be useful when creating rules whose order is significant.

  1. Open the Web Rules page
  2. Locate an existing rule
  3. Click the 3 dot menu icon to the right
  4. Select Insert rule above or Insert rule below

Edit Access Rule

To edit an existing access rule, for example manually changing the order or IP:

  1. Open the Web Rules page
  2. Locate the rule you wish to edit
  3. Click the 3 dot menu icon to the right
  4. Select Edit Rule
  5. Make the necessary changes, then click Save and apply to revalidate and apply the update

Delete Access Rule

To delete an existing web rule:

  1. Open the Web Rules page
  2. Locate the rule you wish to edit
  3. Click the 3 dot menu icon to the right
  4. Select Delete Rule

Access Rule Conditions

All conditions for the rule must evaluate to true, otherwise the rule will have no effect.

Conditions can be one of the following types:

  • URI
  • QUERY_ARG
  • REQUEST_METHOD
  • HEADER
  • GEOIP COUNTRY CODE

Conditions can use the following operators:

  • Equal to ( = )
  • Not equal to ( != )
  • Regex match ( ~ )
  • Negative regex match ( !~ )

Access Rule Examples

Below are some examples of common rules you may use. Rules can be modified as necessary, for example switching deny and allow, or using an IP range versus a single IP.

Deny an IP address:

  • Action: Deny
  • IP: [IP address to deny]
  • Conditions: None are needed

Deny a bot by way of its user agent:

  • Action: Deny
  • IP: All
  • Conditions:
    • Type: Header
    • Name: User-Agent
    • Operator: Regex matches (~)
    • Value: [Enter the actual user agent name in this field] EX: badbot

Block xmlrpc.php for all IP addresses:

  • Action: Deny
  • IP: All
  • Conditions:
    • Type: URI
    • Operator: Regex matches (~)
    • Value: xmlrpc.php

Allow a single IP address access to wp-admin and deny all other IPs access:

First rule:

  • Order: 1
  • Action: Allow
  • IP: [IP address to allow]
  • Conditions:
    • Type: URI
    • Operator: Regex matches (~)
    • Value: wp-login

Second Rule:

  • Order: 2
  • Action: Deny
  • IP: All
  • Conditions:
    • Type: URI
    • Operator: Regex matches (~)
    • Value: wp-login

Deny traffic from non-US GeoIPs:

  • Action: Deny
  • IP: All
  • Conditions:
    • Type: GeoIP Country Code
    • Operator: Not equal to (!=)
    • Country Codes: [‘US – United States’]

Block multiple countries from accessing a website:

In this example, block China, India, and South Africa.

  • Action: Deny
  • Comment: Block China, India, and South Africa
  • Conditions:
    • Type: GeoIP Country Code
    • Operator: Equals (=)
    • Value: CN, IN, ZA

Only allow traffic from specific countries, block all other countries:

In this example, allow traffic from the United States (US), and Canada (CA) and block everyone else.

  • Action: Deny
  • Comment: Only allow US and Canada
  • Conditions:
    • Type: GeoIP Country Code
    • Operator: Does Not Equal (!=)
    • Value: US, CA

If you want to block an entire country/region but allow a specific IP in one of those countries to access the site, you would just create an Allow rule for the specific IP and place it before the country block. Be sure to name the rule with an identifiable phrase, as the order here is important.


Header Rules

Using the Web Rules Engine, response headers can be set. This section can be used to add security headers or to modify cache behavior via cache control headers.

Header rules function the same as access rules; they are read in cascading order and can be set/unset by header name.

Add Header Rule

To add a header rule to Nginx:

  1. Log in to the User Portal
  2. Select the environment name
  3. Click Web Rules
  4. Select Header Rules
  5. Click Add header rule
  6. Enter the rule, then click Save

For header rule conditions, see Access Rule Conditions above.

Header Rule Examples

Set a Header to Allow All Access Control for 2xx status responses:

  • Action: Set
  • Name: Access-Control-Allow-Origin
  • Value: *
  • When: Only on successes
  • Conditions: None are needed

Unset Set-Cookie header for all responses:

  • Action: Unset
  • Name: Set-Cookie
  • When: All responses
  • Conditions: None are needed

Set Cache Control for URIs in /resources:

  • Action: Set
  • Name: Cache-Control
  • Value: max-age=604800, public
  • When: Only on successes
  • Conditions:
    • Type: URI
    • Operator: Regex matches (~)
    • Value: /resources/

Set HSTS header for 2 years, include subdomains, and preload:

  • Action: Set
  • Name: Strict-Transport-Security
  • Value: max-age=63072000; includeSubDomains; preload
  • When: Only on successes
  • Conditions: None are needed

Restricted Headers

  • x-powered-by
  • server
  • date
  • x-orig-cache-control
  • nr-enabled
  • x-cache
  • x-cache-group
  • x-cacheable
  • X-pass-why
  • Any header that includes WPE

Web Rule Order

Web rules are read from top to bottom and the web Rule order allows you to manually organize the rules. The lowest order number is at the top of the list (read first) and the highest order number is at the bottom of the list (read last). Rules must have an order value that is greater than zero and should be within a reasonable range. For example, if you have two rules they should have the order 1 and 2, not 1 and 100.

The order of web rules can be critical to how they function because rules can impact each other depending on the order they are read. Rules that are read first take priority. For example, an IP range can be blocked but a specific IP address within that range can be allowed. To do this the rule allowing the specific IP address must be read before (listed above) the rule blocking the IP range.

For example, to block all IPs from accessing the wp-admin but allow a single IP access, the rules should look like the following:

When adding a rule relative to another rule the order values will be updated automatically. It’s recommended to use the relative adding method when possible, rather than manually setting each value, to ensure the order is applied as intended.

Rules can have comments added to help prevent breaking the rule order down the road. For example, the rule to allow a Chinese IP must be above the rule blocking China. Adding notes can help keep this order clear as the rules list changes or grows:


NEXT STEP: Learn how to enable WebP for image optimization

Still need help? Contact support!

We offer support 24 hours a day, 7 days a week, 365 days a year. Log in to your account to get expert one-on-one help.

The best in WordPress hosting.

See why more customers prefer WP Engine over the competition.