Skip to content

Secure package for WP CLI, built to provide an easier way of securing your WordPress installation

Notifications You must be signed in to change notification settings

igorhrcek/wp-cli-secure-command

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

wp-cli/secure-command

Official website: Hackthewp.com

Manages common security aspects of WordPress. Supports nginx and Apache.

Basic Usage

This package implements the following commands:

Deploy All Security rules

Deploys all above-mentioned rules at once.

wp secure all

Remove All Security Rules

Removes all security rules.

wp secure flush

Add Security Headers

Adds the HSTS, Referrer-Policy, X-Content-Type-Options and X-Frame-Options

You can choose to add all above or only one or more by using --headers argument.

Example:

wp secure add-security-headers
wp secure add-security-headers --headers=Strict-Transport-Security
wp secure add-security-headers --headers=Strict-Transport-Security,X-Frame-Options

Block the access to sensitive files and directories

wp secure block-access <what-to-block>

By default, this command blocks the direct access to sensitive files and directories: readme.txt, readme.html, xmlrpc.php, wp-config.php, wp-admin/install.php, wp-admin/upgrade.php, .git, svn, cache and vendors

Possible options are:

  • sensitive-files
  • sensitive-directories
  • xmlrpc
  • htaccess
  • custom
  • all (does all the above)

Examples:

wp secure block-access sensitive-files
wp secure block-access sensitive-directories
wp secure block-access xmlrpc
wp secure block-access htaccess
wp secure block-access all

However, you can also block custom files and/or folders of your choice. To do that you should use custom argument and pass one of two additional options --files and/or --directories.

If you want to block custom files, make sure that you pass only file names, not a full file paths.

Examples:

wp secure block-access custom --files=dump.sql,phpinfo.php,adminer.php
wp secure block-access custom --directories=wp-content/mu-plugins

Block Author Scanning

wp secure block-author-scanning

Blocks author scanning. Author scanning is a common technique of brute force attacks on WordPress. It is used to crack passwords for the known usernames and to gather additional information about the WordPress itself.

Examples:

wp secure block-author-scanning

Block Direct Access and Execution in certain directories

wp secure block-php-execution <where>

Blocks direct access and execution of PHP files in wp-content/plugins, wp-content/uploads, wp-content/themes and wp-includes directories.

You need to specify where you want to prevent direct access to PHP files. Possible options are:

  • all
  • plugins
  • uploads
  • themes
  • wp-includes

Examples:

wp secure block-php-execution all
wp secure block-php-execution plugins
wp secure block-php-execution uploads
wp secure block-php-execution themes
wp secure block-php-execution wp-includes

Disable Directory Browsing

wp secure disable-directory-browsing

Disables directory browsing.

By default, when your web server does not find an index file (i.e. a file like index.php or index.html), it automatically displays an index page showing the contents of the directory. This could make your site vulnerable to hack attacks by revealing important information needed to exploit a vulnerability in a WordPress plugin, theme, or your server in general.

Examples:

wp secure disable-directory-browsing

Disable WordPress File Editor

Disables the WordPress file editor. It could be used to edit arbitrary files using the web interface. This makes it easier for attackers to change files on the server using a web browser.

wp secure disable-file-editor

Fix file and directory permissions

wp secure fix-permissions

Use this command to verify that the permissions of all files and directories are set according the WordPress recommendations. This command will set 0644 to all files and 0755 to all folders inside WordPress installation.

IMPORTANT: Don't use this command if you don't know what you are doing here!

Check the integrity of WordPress files

Downloads MD5 checksums for the current version from WordPress.org, and compares those checksums against the currently installed files.

It also returns a list of files that shouldn't be part of default WordPress installation, which can be very useful when you are looking for a possible injected files.

Examples:

wp secure integrity-scan

Global options

Remove single security rule

Using --remove with any rule command, you can remove it from configuration.

wp secure block-access xmlrpc --remove

Get the output instead of writing in configuration files

Using --output option with any rule command, you can see actual rule code which you can inspect or manually copy to any file of your choice.

wp secure block-access htaccess --output
wp secure block-access htaccess --output --server=nginx

Specify server type

By default, all rules are generated for Apache or LiteSpeed web servers that utilize .htaccess file. However, you can use --server to specify nginx if you want.

wp secure block-access htaccess --server=nginx

Specify custom file path

By default, all commands assume that rules should be written in the root of WordPress installation in .htaccess and nginx.conf, depending on which server you choose. However, you can specify a custom file path that is going to be used for storing security rules.

wp secure block-access htaccess --file-path=/home/user/mysite.com/.htaccess

Important Note for nginx users

The nginx rules are stored in the nginx.conf file. However, for rules to actually work, you need to manually include this file in your vhost configuration and then restart nginx server:

systemctl restart nginx

WIth each rule deploy or removal, you also need to restart nginx server.

Installing

To install the latest version of this package over what's included in WP-CLI, run:

wp package install git@github.com:igorhrcek/wp-cli-secure-command.git

Development and testing

You need to set up two working WordPress installations on Apache and nginx. Usage of Docker containers is highly recommended - you can use the official WordPress Docker containers, BitNami or bootstrap your environment using ddev.

For testing you need to create .env file with the following content:

WORDPRESS_NGINX_PATH=wp/nginx
WORDPRESS_NGINX_URL=https://wpnginx.ddev.site
WORDPRESS_APACHE_PATH=wp/apache
WORDPRESS_APACHE_URL=https://wpapache.ddev.site

These paths and URLs are going to be used during tests, so make sure that they are accessible.

Contributing

We appreciate you taking the initiative to contribute to this project.

Contributing isn’t limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation.