The internet is crawling with malware bots checking websites for known outdated software/vulnerabilities.
Therefore if one or more of the website code like plugin or main wordpress core is outdated it is just a matter of time when these automated bots succeed in getting through the website.
WordPress software is not out of the box hardened. It is highly advised to put in place more pro-active measures including a firewall plugin with assistance of your developer to block such attempted precautions in future.
Disable File Editing Disable File Editing
The WordPress Dashboard by default allows administrators to edit PHP files, such as plugin and theme files. This is often the first tool an attacker will use if able to login, since it allows code execution. WordPress has a constant to disable editing from Dashboard. Placing this line in wp-config.php is equivalent to removing the ‘edit_themes’, ‘edit_plugins’ and ‘edit_files’ capabilities of all users:
This will not prevent an attacker from uploading malicious files to your site, but might stop some attacks.
Plugins # Plugins
First of all, make sure your plugins are always updated. Also, if you are not using a specific plugin, delete it from the system.
Firewall # Firewall
There are many plugins and services that can act as a firewall for your website. Some of them work by modifying your .htaccess
file and restricting some access at the Apache level, before it is processed by WordPress. A good example is iThemes Security or All in One WP Security. Some firewall plugins act at the WordPress level, like WordFence and Shield, and try to filter attacks as WordPress is loading, but before it is fully processed.
Besides plugins, you can also install a WAF (web firewall) at your web server to filter content before it is processed by WordPress. The most popular open source WAF is ModSecurity.
A website firewall can also be added as intermediary between the traffic from the internet and your hosting server. These services all function as reverse proxies, in which they accept the initial requests and reroute them to your server, stripping it of all malicious requests. They accomplish this by modifying your DNS records, via an A record or full DNS swap, allowing all traffic to pass through the new network first. This causes all traffic to be filtered by the firewall before reaching your site. A few companies offer such service, like CloudFlare, Sucuri and Incapsula.
Additionally, these third parties service providers function as Content Distribution Network (CDNs) by default, introducing performance optimization and global reach.
Plugins that need write access # Plugins that need write access
If a plugin wants write access to your WordPress files and directories, please read the code to make sure it is legit or check with someone you trust. Possible places to check are the Support Forums and IRC Channel.
Code execution plugins # Code execution plugins
As we said, part of the goal of hardening WordPress is containing the damage done if there is a successful attack. Plugins which allow arbitrary PHP or other code to execute from entries in a database effectively magnify the possibility of damage in the event of a successful attack.
A way to avoid using such a plugin is to use custom page templates that call the function. Part of the security this affords is active only when you disallow file editing within WordPress.
Security through obscurity # Security through obscurity
Security through obscurity is generally an unsound primary strategy. However, there are areas in WordPress where obscuring information might help with security:
Rename the administrative account: When creating an administrative account, avoid easily guessed terms such as admin or webmaster as usernames because they are typically subject to attacks first. On an existing WordPress install you may rename the existing account in the MySQL command-line client with a command like UPDATE wp_users SET user_login = ‘newuser’ WHERE user_login = ‘admin’;, or by using a MySQL frontend like phpMyAdmin.
Change the table_prefix: Many published WordPress-specific SQL-injection attacks make the assumption that the table_prefix is wp_, the default. Changing this can block at least some SQL injection attacks.