WordPress security on VIP

Multiple layers of security are in place to protect WordPress applications:

• The VIP Code Analysis Bot (the Bot) automatically analyzes any code pushed to GitHub pull requests. Feedback from the Bot is posted on reviewed pull requests based on the results of automated scans including Vulnerability and Update Scan, PHPCS analysis, PHP linting, and SVG analysis. 
• Plugins that are located in the /plugins directory of a WordPress environment’s wpcomvip GitHub repository branch are automatically scanned by Codebase Manager. Known security vulnerabilities and available version updates identified by Codebase Manager are reported in the VIP Dashboard’s Plugins panel. Pull requests to upgrade plugins with available updates can be created within the VIP Dashboard’s Plugins panel.
• Media files uploaded to /wp-content/uploads are not located in a web container’s filesystem. They are stored in a separate, read-only, globally distributed object store called the VIP File System. 
• It is possible to programmatically write a file to the /tmp directory of a web container or the /wp-content/uploads directory on the VIP File System. However, files written to either of those directories cannot be run or executed (e.g., PHP).
• Software stack version upgrades for security releases (e.g., WordPress Core and VIP MU plugins) are automatically deployed to all environments on the platform as quickly as possible.

Site access

• The username admin is disallowed for WordPress sites. Attempts to log in with the admin username will be blocked and the notice Logins are restricted for that user. Please try a different user account. will be displayed.
• Two-Factor Authentication (2FA) is enforced for users with an administrator role and for custom roles that have the manage_options capability. As a security recommendation, 2FA should be required for all user roles.
• Single Sign On (SSO) can be enabled on any WordPress site.
• It is possible for security scans to identify a site’s /wp-json/wp/v2/users/ WP REST API endpoint as a username enumeration vulnerability. The WordPress project does not consider usernames or user IDs to be private or secure information. To increase the security of private user account information, all user accounts should have strong passwords and 2FA enabled.
• Customers have the ability to restrict site access for specific URLs, the WordPress admin, or for an entire site or environment.

WP Cron, XML-RPC, and login endpoints

VIP has multiple security protections in place to protect against unauthorized access and abuse of the WP Cron (/wp-cron.php), login (/wp-login.php), and XML-RPC (/xmlrpc.php) endpoints.

• At the network level, dynamic security protocols are in place that can be triggered by unusual behavioral patterns. An automated attack would trigger VIP’s dynamic security measures, and login attempts would be completely blocked.
• The functionality of WordPress Core’s /wp-cron.php is disabled on WordPress VIP. Cron control on WPVIP is initiated and regulated by Automattic’s Cron Control plugin.
• Brute force attempts on /wp-login.php and /xmlrpc.php are detected and mitigated at the edge (i.e., firewall, NGINX). Attempts to obfuscate the URL of the WordPress login page by altering the URL—via a plugin or otherwise—will remove VIP’s brute force login protections from the login URL.

• Access to the /xmlrpc.php endpoint is restricted to authorized requests only.
• The XML-RPC server in WordPress Core code prevents more than one failed authentication attempt per a system.multicall request.

Rate limiting

Rate limiting is a strategy to constrain how often an action can be repeated within a certain timeframe. The implementation of rate limiting can help to prevent some forms of malicious bot activity and to reduce strain on web servers. On the VIP Platform, rate limiting is in place at the application level for all WordPress sites, managed by VIP MU plugins, and at the edge.

XML-RPC rate limiting

The rate limiting threshold for XML-RPC requests at the edge is 10 times per minute, with a one-hour block timeout when this is exceeded. During the block timeout, 403s are returned. This rate is global and not customizable per application.

Login rate limiting

Logic applied to the login rate limiting threshold varies depending on the context. For example, for any given username+IP combination, the limit is 5 failed attempts every 5 minutes. This layer protects against more localized, user-specific attacks.

The login rate limiting thresholds can be adjusted with the wpcom_vip_ip_login_threshold and wpcom_vip_ip_username_login_threshold filters. Custom code using these filters should be added to a file located within /client-mu-plugins.

The number of failed login attempts to allow for an IP address can be adjusted with the wpcom_vip_ip_login_threshold filter. In this code example, the threshold limit is set to 10:

add_filter( 'wpcom_vip_ip_login_threshold', function() {
    return 10;
} );

The number of failed login attempts to allow for an IP address and username combination can be adjusted with the wpcom_vip_ip_username_login_threshold filter. In this code example, the threshold limit is set to 1 for login attempts by the usernames exampleuserone and exampleusertwo:

add_filter( 'wpcom_vip_ip_username_login_threshold', function( $threshold, $ip, $username ) {
    if ( 'exampleuserone' === $username || 'exampleusertwo' === $username ) {
        $threshold = 1;
    }
 
    return $threshold;
}, 10, 3 );