WordPress security Archives

The Truth about Managed vs Unmanaged WordPress Hosting

Quick Quiz: What Type of WordPress Hosting do you need – Managed vs unmanaged hosting?

1. Are you more of a (a) Do-it-yourself (DIY) type or b) Plug-and-play kind of person?
2. Do you usually (a) go with the flow or (b) need a backup plan?
3. When traveling, do you prefer (a) shared accommodation or (b) space for yourself?
4. Looking at your lifestyle, do you (a) go for the basic stuff or (b) comfort and security

Unmanaged vs Managed WordPress Hosting Verdict

Well, based on the above criteria, Plesk can tell you which type of WordPress user you are – the managed vs unmanaged hosting type. If you mostly picked (a), then you are an unmanaged hosting type, whereas mostly (b) choices reveal your managed WordPress hosting preference.

Disclaimer: There is no right or wrong answer and you’re fine either way. However, having a full perspective can help you make the best business decisions later on. Keep reading for more info on your business needs, the core differences and benefits of the two different hosting types.

Managed Hosting: The Plug & Play Type

Your profile tells Plesk you are part of a managed hosting category for your WordPress. You trust and rely on someone else for your hosting solution, while you focus on your core business. Going deeper, you can choose from the following managed hosting types: a) Shared; b) Cloud; c) Virtual Private Hosting (VPS); d) Dedicated.

Love Shared Hosting?

This hosting plan is typically the cheapest. Your site shares resources with other accounts on the same server. Shared hosting is a good option as long as website traffic and your end-user base don’t outgrow the server’s resources. The downside is that noisy/resource-hogging neighbors will affect your site as all websites have to share space on the same server.

Scale up to Cloud Hosting

Multiple physical servers work together and the network shares virtual resources. If you choose cloud hosting, it means you want flexibility, resilience, and redundancy. Also, you prefer a pay-as-you-go model. However, for cloud hosting, you need good planning abilities and management skills of this environment.

VPS Hosting Fan?

This means you prefer a virtual instance on a physical server with its copy of an operating system (OS). Plus, your own resources such as CPU, RAM or any other data. You can always add more resources on your plate without the need to migrate your website.

Moreover, you get a similar level of flexibility and benefits as with a dedicated server, but with a shared cost of services. This means almost full freedom. Because you have access to everything and can install any software you want and need. No dependency on traffic or audience.

Your Own Dedicated Hosting

Are you playing in the league of big numbers of visitors? Then dedicated hosting is for you. You probably have an online store with lots of rich media that need to max out on RAM. It’s also the most secure option and provides the highest level of system control.

Therefore, you can keep noisy neighbors out of the picture. However, know that dedicated servers usually come with monthly pricing or some kind of long-term commitment. So you need to think carefully in advance regarding how many resources you’re going to need.

Unmanaged Hosting (DIY) – The Good and The Bad

Based on Plesk analysis, you love being in the ‘techy weeds’. As a DIY type, you prefer to build, configure, maintain and secure your server. While also ensuring that your website is up and performing well. As basic needs’ fulfillment is enough for you, a server with only an Operating System (OS) installed will do. You need to install and configure any additional software such as WordPress, Apache, PHP or MySQL.

Why Unmanaged Hosting Can Be Tricky

If this tips you over between managed vs unmanaged hosting, then you’re dedicated to the tricky craft of managing your website(s) and server. You love it and it costs you almost nothing. However, this may take too much time and keep you away from other more important stuff for your business and growth. Also, you may be saving money now, but in the long run, this may not be as beneficial. Consider this: your site has always been a bit slow to load, but imagine it in two years’ time. When your business and website traffic grow.

Backup plans take too much time and energy for you, but if the worst happens you may pay for it in other ways. For example, after a few days off you find your site compromised and filled with spam links to random websites. Or when something goes wrong with your manual WordPress updated and the website goes down. Constantly having to monitor your site and implement performance and security optimizations may drain you. Thus, possibly crippling your business eventually.

Plesk and WordPress Hosting – Plug, Play and More

You’ll see many options in the WordPress managed hosting candy shop. So it’s hard to choose. But for the ones who prefer a turnkey solution for their websites, Plesk WordPress Edition with WordPress Toolkit is the right combination.

Watch and see how quick you can activate your WordPress hosting solution with Plesk.

Top Plesk WordPress Hosting Benefits

Especially when compared to shared or VPS providers, this WordPress hosting provides better maintenance and data integrity. According to market benchmarks, data hosting providers offering the ability to change the version of PHP used for WordPress score higher.

24/7 customer support

Managed WordPress Hosting is intuitive and requires a few clicks installation. But the house’ specialty, the sweet cherry on top of the Plesk’s WordPress Hosting is our customer support. From onboarding to finish, all clients get 24/7 attention from our side, including website support and tech support for non-developers.

Automated WordPress Security, Backups and Upgrades

Another advantage you’ll welcome with open arms is the free WordPress vulnerability scanner when you create a new site. Plesk’s WordPress Toolkit security scanner goes beyond the basics and implements the latest security recommendations and best practices from WP Codex and WP security experts.

Performance and Speed

Get Plesk with your WordPress Hosting and you’ll have this included in WP-CLI. Thus helping clients import a database, create a new user, update themes and plugins in a flash using the WP-CLI. Speaking of plugins, for an enhanced customers’ WordPress experience, any caching plugin will significantly improve your WordPress performance.

The WordPress Toolkit 4.1 Update

We’re thrilled to announce the public availability of WordPress Toolkit 4.1. Due to the large amount of changes under the hood, we needed more time to ensure everything works. However, good things come to those who wait because here it is now! Featuring the Remote WordPress Management Plugin, Website Quarantine and more great improvements.

Remote Management for WordPress Toolkit Plugin

Let’s start with the biggest change introduced in WordPress Toolkit 4.1: The Remote WordPress Management Plugin. The plugin is a part of the overall Remote Management functionality, which is still available as a Beta feature.

Many customers told us they couldn’t use the Remote Management feature because they don’t have root SSH access to the remote server. The only other (reasonable) way to connect remote WordPress sites on such servers was to use a WordPress plugin.

Once you provide access credentials to the remote WordPress site, WordPress Toolkit connects to it and installs the plugin. The Toolkit can then manage the site to the full extent of capabilities offered by the Remote Management functionality.

In rare cases where WordPress Toolkit for some reason cannot connect to your site and install the plugin, there is a workaround offered directly in the interface:

In short, you need to download the plugin and install it in WordPress manually. Then copy the connection data and paste it in the connection window inside WordPress Toolkit.

To minimize the impact on hosters, the ability to use the plugin is limited to server administrators. The plugin will leave Beta once the whole Remote Management feature leaves Beta. Speaking of which, we’ve made a number of improvements to the Remote Management functionality based on internal testing and user feedback.

WordPress Website Quarantine

We’ve often encountered a situation where scanning the server for WordPress sites made the WordPress Toolkit completely unresponsive. After some digging, we found that, most of the time, it is malware infection on one or more WordPress sites on the server that causes this problem. This caused WordPress Toolkit not to properly access certain important files. So it was doomed to eternally wait for files, while not responding to any commands.

To address this issue, we added a reasonable timeout for certain WordPress Toolkit operations. The suspicious WordPress websites that WordPress Toolkit finds now go into quarantine mode. Then, WordPress Toolkit proceeds to working with the rest of the websites. This fix should also address several reported issues with connecting remote servers that host such websites.

Site Health Check Support for WordPress Toolkit 5.2

WordPress 5.2 has introduced a new feature called Site Health Check. This feature helps website owners get useful information about the health of their website. Unfortunately, we found out WordPress Toolkit was not working well with WordPress updates.

This was not easy to fix, but thankfully, our top-notch engineers found a good solution. The constant in wp-config.php file now contains the actual status of WordPress automatic updates. So the health check isn’t triggered by it – unless you turn off all automatic updates manually. However, WordPress Toolkit will still handle the updates, and you can get notifications and use Smart Updates as before.

WordPress Toolkit improvements, fixes and upcoming releases

WordPress Toolkit now provides more information about broken websites to help users identify the website and troubleshoot the problem. You can now find the exact path where the broken files are located.

Another notable improvement was related to the Clone and Copy Data functionality. These operations can now handle absolute paths in WordPress database.

Our team has also fixed a bunch of customer-reported bugs too, which you can find in the full WordPress Toolkit 4.1 release notes. The next WordPress Toolkit release will focus on changing the way our Smart Updates work. This and several more customer requests that we’ll address. So stay tuned for news about WordPress Toolkit 4.2.

How do you like the new available WordPress Toolkit 4.1 release? Tell us in the comments.

remote management WordPress security WordPress Toolkit WordPress Toolkit 4.1

WordPress File Permissions

Different files and directories in Linux-based file system use permissions to indicate who and what can read, write, modify and access them. WordPress file permissions matter because it might want access to write to files in your wp-content directory.

Permission Modes

7	5	5
user	group	others
r+w+x	r+x	r+x

4+2+1 4+0+1 4+0+1 = 755

WordPress file permissions modes are computed by adding up the following values for the user, the file group, and for everyone else. The diagram illustrates this.

Read 4 – Allowed to read files
Write 2 – Allowed to write/modify files
eXecute 1 – Read/write/delete/modify/directory

7	4	4
user	group	others
r+w+x	r	r

4+2+1 4+0+0 4+0+0 = 744

Example Permission Modes

Mode	Str Perms	Explanation
0477	-r–rwxrwx	owner has read only (4), other and group has rwx (7)
0677	-rw-rwxrwx	owner has rw only(6), other and group has rwx (7)
0444	-r–r–r–	all have read only (4)
0666	-rw-rw-rw-	all have rw only (6)
0400	-r——–	owner has read only(4), group and others have no permission(0)
0600	-rw——-	owner has rw only, group and others have no permission
0470	-r–rwx—	owner has read only, group has rwx, others have no permission
0407	-r—–rwx	owner has read only, other has rwx, group has no permission
0670	-rw-rwx—	owner has rw only, group has rwx, others have no permission
0607	-rw—-rwx	owner has rw only, group has no permission and others have rwx

Permission Scheme for WordPress

WordPress file permissions will vary between hosts, so we can only outline general principles here and can’t cover all scenarios. This guide is relevant to servers that run a standard setup (note, for shared hosting using “suexec” methods, see below).

Usually, all files should be owned by your user (ftp) account on your web server and should be writable by that account. On shared hosts, files shouldn’t ever be owned by the webserver process itself (sometimes this is www, or apache, or nobody user).

A file that needs write access from WordPress should be owned or group-owned by the user account used by WordPress (which may be different from server account). For instance, you might have a user account that lets you send files to your server via FTP, but the server itself may run under a separate user, in a separate usergroup, like dhapache or nobody. If WordPress is running as the FTP account, that account must have write access, meaning it must be the owner of the files, or be in a group that has write access. If that’s the case, it would mean permissions are set more permissively than default (for example, 775 rather than 755 for folders, and 664 instead of 644).

The file and folder permissions for WordPress will probably be the same for most users, depending on how you installed it and the umask settings of your system environment at the time of installation.

You probably won’t need to be changing file permissions if someone with experience installed WordPress for you. It’s best not to alter his unless you’re having problems with permission errors, or you know what you’re doing. If you installed WordPress yourself, you probably WILL need to change WordPress file permissions permissions. Some files and directories should be “hardened” with more strict permissions, in particular, the wp-config.php file. To start with, this file is created with 644 permissions, but it isn’t safe to leave it like that.

In most instances, all essential WordPress files should only be writable by your user account (or the httpd account, if it’s different). ( Sometimes though, numerous ftp accounts may be used to manage an installation, and if all ftp users are known and trusted, meaning not shared hosts, it may be okay to assign group writable. Ask your server admin about this. ) However, if you make use of mod_rewrite Permalinks or other .htaccess features you should ensure that WordPress can also write to your /.htaccess file.

If you’re going to use the built-in theme editor, all files need to be group writable. It’s best to use it before you go changing file permissions. (This may hold true if different users uploaded the WordPress package and the Plugin or Theme. This wouldn’t be a problem for Plugin and Themes installed using the admin panel. When you upload files with different ftp users, group writable will be needed. On shared hosting, ensure the group is exclusive to users who you trust… an apache user shouldn’t be in the group and shouldn’t own files.)

Some plugins need the /wp-content/ folder to be made writeable, but in cases like this, you will be informed about it during installation. In some instances, you may need to assign 755 permissions. This is also true for /wp-content/cache/ and possibly /wp-content/uploads/ (if you’re using MultiSite setup you may also have to do this for /wp-content/blogs.dir/)

Additional directories under /wp-content/need to be documented by whichever plugin / theme requires them. Permissions will vary.

Shared Hosting with suexec

This may not apply to shared hosting systems that use the “suexec” approach for running PHP binaries. This is a popular approach which many web hosts use. With these systems, the php process runs as the owner of the php files themselves, which simplifies configuration and provides a more secure environment for shared hosting.

Do not use suexec methods on a single-site server configuration. They are only the most effective option for shared hosting.

With suexec configuration, the correct WordPress file permissions scheme is easy to understand.

All files should be owned by the actual user’s account, not the user account used for the httpd process.
Group ownership is not relevant unless there are particular group requirements for the web-server process permissions checking. This doesn’t usually happen.
All directories should be 755 or 750.
All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to stop other users on the server from reading it.
Directories should never be given 777, not even upload directories. As the php process is running as the files’ owner, it gets the owners permissions and can even write to a 755 directory.

With this particular type of setup, WordPress detects that it can directly create files with the proper ownership, and so it will not need to request FTP credentials when it has to install or upgrade plugins.

sysadmins use these popular methods are set up:

suPHP: runs through php-cgi, currently unmaintained since 2013.
mod_ruid2: apache module, currently unmaintained since 2013.
mpm_itk: apache module.
mod_fcgid: an Apache module and FastCGI server with more extensive configuration.

PHP-FPM, an alternative FastCGI server with shared OPCode, for use with Apache and Nginx.

How to Use the Command Line

If you have shell/SSH access to your hosting account, you can use chmod for changing file permissions, which is the preferred method for experienced users. Before you start using chmod it’s recommended that you go through some tutorials to ensure you understand how it works. If you set the wrong WordPress file permissions you could end up taking your site off-line, so it’s best to be safe rather than sorry.

You can make all the files in your wp-content directory writable in two steps, but before you do, consider safer options like modifying just the directory first. Give each of these commands try first, and if they don’t work then go recursive. This will even make the image files of your themes writable. Replace DIR with the folder you want to write to

chmod -v 746 DIR

chmod -v 747 DIR

chmod -v 756 DIR

chmod -v 757 DIR

chmod -v 764 DIR

chmod -v 765 DIR

chmod -v 766 DIR

chmod -v 767 DIR

If those don’t let you write, try each of them again in order, only this time put-R instead of-v, which will recursively modify each file that’s in the folder. If that still doesn’t work then try 777.

About Chmod

chmod is a Unix command which means “change mode” on a file. The -R flag tells it to apply the change to every file and directory inside wp-content. 766 is the mode we are changing the directory to, and it makes the directory readable and writable by WordPress and any and all other users on your system. At last, we have the name of the directory we are going to modify, wp-content. If 766 doesn’t work, then try 777, which makes every file and folder readable, writable, and executable by all users, groups, and processes.

If you use Permalinks then remember to change WordPress file permissions of .htaccess to ensure that WordPress can update it when you change settings, like when you a new page, redirect, category, etc. which requires updating the .htaccess file when mod_rewrite Permalinks are being used.

Go to the main directory of WordPress
Enter chmod -v 666 .htaccess

From a WordPress security point of view, even a little protection is better than a directory that’s wide open to anybody to rewrite. Start with low permissive settings like 744 and work your way up until your successful. Only use 777 if you have to, and hopefully then only for a short while.

The dangers of 777

The root cause of this permission situation is the manner of your server configuration. The username you use to FTP or SSH into your server is probably not the username that the server application itself uses to serve pages.

7	7	7
user	group	others

4+2+1 4+2+1 4+2+1 = 777

The Apache server is frequently ‘owned’ by the www-data, dhapache or nobody user accounts. These accounts have limited access to files on the server, and with good reason. If you set your personal files and folders owned by your user account to be World-Writable, that’s exactly what you are doing. It means that the www-data, dhapache and nobody users that run your server, serve pages, execute php interpreters, and so on, can get at all of your user account files, and they can do this using any process on the server.

That’s why it’s best to only change WordPress file permissions when you are forced to, and even then with great care. We’ve never come across a situation what warranted more than 767, so it’s hard to imagine why 777 would be required.

If you do use 777 permissions, what’s the worst that could happen? Well, a nefarious individual could upload a harmful file, or inject malicious code to gain total control of your blog, its database and password info.

You can easily get the enhanced features that WordPress plugins can provide without exposing yourself to risk. The Plugin author or your server support should be able to give you a workaround.

Finding Secure File Permissions

The .htaccess file is one that’s accessed by the owner of the process that runs the server. So, if your WordPress file permissions are set too low, your server will be denied access to the file and return an error. It shows you the way to find your best settings. Start with greater restriction and then relax it until it works.

The example below has a custom compiled php-cgi binary and a custom php.ini file located in the cgi-bin directory for executing php scripts. To stop a web browser directly accessing the interpreter and php.ini file they are protected by a .htaccess file.

Default Permissions (umask 022)

644 -rw-r–r– /home/user/wp-config.php
644 -rw-r–r– /home/user/cgi-bin/.htaccess
644 -rw-r–r– /home/user/cgi-bin/php.ini
755 -rwxr-xr-x /home/user/cgi-bin/php.cgi
755 -rwxr-xr-x /home/user/cgi-bin/php5.cgi

Secured Permissions

600 -rw——- /home/user/wp-config.php
604 -rw—-r– /home/user/cgi-bin/.htaccess
600 -rw——- /home/user/cgi-bin/php.ini
711 -rwx–x–x /home/user/cgi-bin/php.cgi
100 —x—— /home/user/cgi-bin/php5.cgi

.htaccess permissions

644 > 604 – The bit giving the group owner of the .htaccess file read permission was got rid of. 644 is normally recommended and needed for .htaccess files.

php.ini permissions

644 > 600 – Before, all groups and all users with access to the server could access the php.ini, even just by requesting it from the site. The difficulty is that because the php.ini file is only used by the php.cgi, we only needed to ensure the php.cgi process had access. The php.cgi runs as the same user which owns both files, so that single user is now the only user which can access this file.

php.cgi permissions

755 > 711 This file is a compiled php-cgi binary used in place of mod_php or the default vanilla php which the hosting company provides. The default permissions for this file are 755.

File permissions WordPress WordPress File Permissions WordPress security

The End of Cross-Site Scripting: WordPress 5.1.1 Released

Cross-Site Scripting and WordPress v5.1.1

Older versions of WordPress make all posts vulnerable to cross-site scripting. But the cross-site scripting vulnerability in WordPress is a thing of the past now since the release of v5.1.1. The WordPress team have introduced several fixes in this new version. But first – What does a cross-site scripting vulnerability actually mean?

Dangers of cross-site scripting

Every website which has comments enabled is in danger of cross-site scripting because of the way comments are stored in the database. An attacker only needs a maliciously-crafted comment, their own website and a tricked WordPress admin. If that particular admin visits the malicious website, a cross-site request forgery (CSRF) exploit will run against the WordPress blog. That CSRF could lead to Remote Code Execution and a full take-over of the WordPress site. And you, the admin, won’t notice anything – until it’s too late.

How WordPress solved cross-site scripting vulnerabilities

WordPress 5.1.1 introduced many fixes and enhancements, but most importantly XSS-related ones. These work with the way comments are filtered. The fastest solution is to disable comments entirely – but who wants to create a non-inclusive space? The other option is to keep your WordPress sites regularly maintained. So we suggest you download the latest WordPress 5.1.1 version to safeguard your business.

Since WordPress is responsible for 30% of all websites, millions of sites are in danger. So if you’re a WordPress administrator, don’t fall victim to cross-site scripting. Also, be careful not to make these common website mistakes .

Perform a security check with WordPress Toolkit

Did you know that Plesk lets you experience one of the best WordPress Security Solutions? You can secure all your instances, plugins, and themes all from one dashboard. But you can also use WordPress Toolkit for its many other capabilities that simplify your WordPress admin workload tenfold. All you need is to install the Plesk all-in-one control panel first.

Find out more about the latest Remote WordPress Management release on Plesk WordPress Toolkit 4.0

Experienced cross-site scripting ? Tell us what you think of the new WordPress solution in the comments below

cross-site scripting WordPress security wordpress toolkit 4.0

All You Need to Know about the New WordPress Toolkit 3.5 [ VIDEO ]

Your needs come first so rest assured that we’re constantly evolving Plesk to bring you more value. Hence, the release of WordPress Toolkit 3.5, introducing an assortment of new security measures, a reimagined installation experience and more. Read on for a detailed overview of the updates you wanted, a WordPress Toolkit tour, plus WordPress Toolkit 3.6 spoilers.

Quick Tour of the updated WordPress Toolkit

Our pal Joe Casabona was one of the first to take the new WordPress Toolkit 3.5 for a spin. Here’s him demonstrating how easy it is to install and secure your WordPress, update multiple sites, clone and create a staging environment. All in just over 7 minutes!

New WordPress Toolkit Security Measures

First, you’ll likely see this notification pop up or find your previously secure instances suddenly marked as insecure. But don’t be alarmed – this just means you need to review and update the security status of your WordPress instances. Why? Because WordPress Toolkit 3.5 introduces 8 new security measures.

1. New Hotlink Protection

Preventing other websites from displaying, linking or embedding your images (hotlinking), as this quickly drains your bandwidth and can make your site unavailable.

2. Disable unused scripting languages

This security measure removes support for the scripting languages WordPress doesn’t use, like Python and Perl. Thus, blocking their related vulnerabilities. Available if you have the corresponding Hosting Settings management permission.

3. New Bot Protection

Blocks bots that overload your site with unwanted requests, causing resource overuse. Note that you may want to temporarily disable this if you also use a service that scans your site for vulnerabilities, since it may also use bots.

4. Disabled file editing in WP Dashboard

This measure prevents you from editing plugin and theme file sources directly in the WordPress interface. This is an extra protection layer for the WordPress instance in case an admin account is compromised so no malicious executable code gets into plugins or themes.

5. Block access to sensitive files

Now you can choose to block files like wp-config.bak and wp-config.php.swp, from public access as they contain sensitive information, like connection credentials. Thus, also preventing exposure of files with info used to determine your WordPress instance. Also included are files like logs, shell scripts and other executables that may exist on your WordPress instance and whose security can be compromised.

6. Block author scans / user ID phishing

These scans find registered usernames, especially WordPress admin, and brute-force attack your site’s login page. The above block prevents this, but note that depending on your site’s permalink configuration, you may also be preventing visitors from accessing pages that list all articles by a certain author.

7. Block access to .htaccess and .htpasswd

Attackers who gain access to .htaccess and .htpasswd files can exploit your site to a variety of breaches. These files aren’t usually accessible by default, but sometimes they might be. This is where this security measure steps in.

8. Disable PHP execution in cache directories

If a compromised PHP file ends up in one of the cache directories of your site, executing it can lead to compromising the whole site. So this measure disables execution of PHP files in cache directories to prevent such exploits. However, certain plugins and themes may ignore WordPress Security recommendations and store valid PHP executables in their cache anyway. So you can disable this security feature for them to work, or find a more secure alternative, as recommended.

You’re in Control of Security Updates

You should be able to supervise any website-affecting changes so WordPress Toolkit won’t automatically apply these new security measures on existing installations. So upon opening your list of WordPress instances after the WordPress Toolkit 3.5 update, you’ll see a one-time notification about this.

On that note, you’ll now see that two existing security measures are now less restrictive. First, the “Security of the wp-includes directory” checker now excludes the wp-tinymce.php file to avoid potential issues with Gutenberg and other editing plugins. Second, the “Security of the wp-content directory” measure now prevents the execution of PHP files only in the wp-content/uploads directory.

These checkers will be reapplied automatically for convenience and do not reduce WordPress security in any noticeable way.

New WordPress Toolkit 3.5 Installation Experience

WordPress Toolkit previously offered two installation options: Quick and Custom. Both had unfortunate shortcomings. ‘Quick’ didn’t ask you questions, but also didn’t give info on the parameters to use when installing WordPress. ‘Custom’ gave you control and displayed everything, but you had to fill out the form.

Now users can make an informed choice whether to confirm defaults and install WordPress quick, or take time to change the options they want. With the new, unified WordPress installation, you can still install WordPress in one click, but you’ll always know how it’s happening. Meanwhile, you can change all relevant installation parameters when necessary.

Bonus: You now have to enable automatic updates of plugins and themes within a more streamlined form, without Search Engine Visibility and Debug Mode.

The final change to the WordPress installation process is the ability to install on any domain from any accessible subscription. This is available anytime you click WordPress in the left navigation panel, even if you’re a reseller or server admin. One small step for WordPress Toolkit, one giant leap for adminkind.

WordPress Classic Plugin anyone?

If you’re not yet ready to use Gutenberg, you have a new ‘WordPress Classic’ plugin set. It also has a sibling ‘WordPress Classic with Jetpack’. However, note that we don’t plan to add immediate support for ClassicPress.

Updates to CLI

We updated the CLI command for the new WordPress installation. Specifically adding -auto-updates, -plugins-auto-updates, and -themes-auto-updates to the plesk ext wp-toolkit install command. And plesk ext wp-toolkit –clear-wpt-cache to clean WordPress Toolkit cache and handle issues with invalid cache data like corrupted WordPress distributive lists, or broken lists of languages and versions.

WordPress Toolkit 3.6 Spoilers

The Plesk team fixed a record 43 issues reported by customers and over 140 bugs reported overall. Moving forward, WordPress Toolkit 3.6 will lay foundations for the upcoming release of Remote Management for WordPress Toolkit. Plus, we’re continuing the switch to the new UI, this time redesigning the Clone and Sync procedures along with more relevant user-requested improvements. We’re also busy improving our internal process so we can deliver more high-quality stuff in less time, so stay tuned!

bot protection CLI hotlink protection security update WordPress plugins WordPress security WordPress Toolkit WordPress Toolkit Video Tutorial

WordPress Security Guide 2019

With so many websites relying on WordPress it’s no surprise that millions of website owners are out looking for the best ways to secure their WordPress sites. The widespread prevalence of WordPress also makes it a target for hackers, with tens of thousands of websites getting infected with malware, becoming the sources of phishing schemes and getting blacklisted by search engines. In this guide we cover everything you need to know about WordPress security, including a comprehensive list of do-it-yourself WordPress security tips for hands-on website owners. Read on to see how you can protect your website against even the most determined attacker.

Why WordPress security is so important

At its core WordPress is very secure, the CMS is audited by hundreds of expert coders who write security into WordPress. Nonetheless WordPress can still be hacked and often it is due to a lack of basic security practices.

WordPress sites that are hacked can be very damaging for the owner as it inevitably leads to a loss of reputation while also leading to financial loss. A hacker can rob a business of its confidential user data, can install software that leads to further damage down the road or even install malicious programs on your user’s PCs.

Google plays a strong role in policing websites. First, it can exclude potentially hacked websites from search results – and indeed it blacklists tens of thousands of sites every week. Google also warns users away from infected sites by displaying a warning in Chrome. The resulting warnings can lead to a huge drop in traffic for website owners.

The responsibility for securing a website lies, of course, with the website owner. It’s no different from business security at a physical place of business. Essentially, your website is your premises and you need to ensure that it is secured.

General WordPress security tips

At Plesk we appreciate that risk elimination is very difficult to achieve, if large and well-protected government and military websites can be hacked it is clearly difficult for even the most capable security regimes to eliminate risk. That’s why we believe in risk reduction instead. These are the first, most actionable steps we suggest that you take.

Pick a host you can trust

Though much of your WordPress security regime is simply up to you, there is one element that you probably do not control: security on the server hosting side. In fact, it can be argued that picking a secure shared hosting provider is your very first step in getting WordPress security up to scratch.

With shared hosting you share the physical and software hosting environment with many other users. So, when one user’s website gets hacked it can spread across to yours. This is called cross-contamination and can mean that your site gets infected through no fault of your own.

Therefore, you need to select a host that you can really trust. One option is to use a managed WordPress hosting company which can offer a range of services that help you secure your WordPress site, including advanced security configurations and automatic backups and updates.

User permissions and passwords

A stolen password is like handing the keys to a hacker, which is why stolen passwords are so commonly involved in compromised WordPress websites. One way to “steal” a password is to guess it, if you use a weak password a hacker can easily guess it and get access to your WordPress instance.

Instead, choose strong passwords for both your WP logins as well as every other area of your hosting solution including FTP and MySQL. This goes for your email addresses too as a hacked email account can be used to reset passwords.

Also watch out for user permissions, don’t hand out your admin credentials to just anyone. Where your website works using a larger team including contributors you need to ensure you control access by limiting user privileges to the absolute minimum. Don’t give users full administrator access unless they really need it.

Always update WordPress

If your host doesn’t provide automatic WordPress updates you should make sure you execute these updates yourself, regularly. As open-source software the WP codebase is regularly updated, with minor changes to the code automatically installed. However major new releases of WordPress require user intervention for the update to install.

Updates also stretch across to the stacks of plugins and custom themes that so many websites make use of. Here, too, you must ensure that 3^rd-party updates are tested and installed in a timely manner. Both WordPress core updates and 3^rd-party updates are key to ensuring your WordPress website is impervious to hackers.

Getting a third party involved to boost WordPress security

We’ve outlined some of the basic elements of good WordPress security. Later in this WordPress security guide we will cover DIY steps, but one way to ensure your WordPress site is really secure is to make use of a third party security service.

In this section we will cover the WordPress security tips you can follow that doesn’t require an understanding of how WordPress works, and which you can implement just by pointing and clicking. For beginner users these steps are ideal as they are easy to implement yet effective. Let’s take a look.

Activate an automatic backup solution

Earlier in this article we highlighted how it is almost impossible to make a website 100% secure against hacker attacks. You can reduce the probability of a successful attack but not eliminate it. So, website owners must assume there is a chance of a successful attack. Effective backups are the most important defence against a successful attack as it allows you to restore your website should the worst happen.

Thankfully it’s not hard to get WordPress backups into place, and you have a choice of paid-for and free solutions. However, you must save your backups in a remote location – not in your main hosting account. Otherwise, if your hosting account is compromised, your backup is simultaneously compromised. Instead store your backups in cloud storage such as OneDrive, Dropbox or AWS.

Backup frequency is important, depending on how often your site is updated it should be at least once a day but for many scenarios ongoing backups that mirror all site changes are the better option, especially where user registrations are involved. Some of your best no-coding backup solutions include VaultPress as well as Backup Buddy.

Install a third-party WordPress security plugin

Backups are your first step, but you should go further when setting out your WordPress security measures. Understanding what happens on your site is important, so you need a monitoring tool that can audit everything from failed access attempts, scanning efforts performed by malware and the integrity of WordPress core files.

One excellent tool is from a company called Sucuri. The Sucuri plugin installed directly into your WP instance and is free to install and use. You start by generating a free (API) key which will activate logging as well as automatic integrity checks and various other core Sucuri features. We also recommend that you fully activate the WP “hardening” features offered by Sucuri – simply click “Harden” next to every option on the relevant Sucuri tab.

Sucuri’s hardening features essentially automatically lock down a number of areas the are often targeted by WP hackers. There is one hardening option that Sucuri uses that is not included in the free plug-in, it is effectively a firewall for websites, we cover it in the next section.

In fact, we will also cover some of Sucuri’s hardening features in a later section where we show you how to manually harden your WordPress site, thought note that these options are typically for the more technically savvy.

Overall Sucuri is really easy to set up because, once you’ve ticked all the “Harden” boxes, it’s job done, you don’t need to change much else. However we do suggest that you customise the email notifications that Sucuri sends as these can be bothersome.

To stop your inbox cluttering up too much with notifications you should edit the settings in Sucuri so you only get a message when there is a major change, for example when a new plugin is installed or when a new user registers.

Overall the Sucuri plugin is a top choice for automatic WordPress protection and we encourage you to browse through the different sections of the plugin including its malware monitoring, logs and the list of failed logins. However, you can take Sucuri to the next level if you are willing to pay for a subscription.

Get a firewall for your website

Also called a Website Application Firewall or WAF, a firewall for your website is one of the best ways to keep your website safe and secure. Why? Because a firewall protects your website from malicious traffic before this traffic even reaches your website.

Clearly, stopping intruders from reaching your site in the first instance is top WordPress security priority but Sucuri offers more. In the unlikely chance that intrusion succeeds Sucuri can also do a cleanup and can help you remove your sites from black lists, in fact the company guarantees that it can do so. Sucuri will do the fix themselves.

It’s not cheap to get a hacked website fixed and it can take a long time, which makes hacks costly. Sucuri’s technicians charge over $200 per hour, but you get access to the full Sucuri service for just $199 in subscription fees. Note that you have other choices for website application firewalls, one example would be Cloudflare.

The DIY WordPress security guide

We’ve given a number of important pointers that should get your WordPress site to a point where it is reasonably safe from attack, but if you are more technically minded you can go further and do a few more things to help you get your WordPress site as safe as can be. Some of the following instructions require a bit of knowledge of coding, but other steps are simple to complete. Let’s take a look.

Stop PHP file execution where it’s not needed

Some WordPress directories are not intended to run code, instead these just store files. For example, /wp-content/uploads/. Hackers can, for example, upload PHP code to these directories and then execute the malicious code. Stop hackers from doing so by blocking PHP code execution where WordPress doesn’t need it.

It’s simple to do so, open a pure text editor such as Windows’ Notepad and paste this text:

<Files *.php> deny from all </Files>

You then need to save the code to a file called .htaccess and upload it to the directory you want to block PHP code execution in, such as /wp-content/uploads/. However don’t add this code to just any WordPress directory as it can stop your site from working.

Alternatively, simply use the Sucuri plugin to help you, blocking PHP file execution in unnecessary directories is one of the hardening options included in the plug-in.

Change file editing permissions

WP comes with a code editor built-in which allows you to edit the files used by plugins and themes, but we recommend that this is turned off. This direct access can cause problems when used by a rogue actor. It’s easy to switch off the ability to edit plugin and theme files. Just add this code to your wp-config.php file:

// Disallow file edit

define( 'DISALLOW_FILE_EDIT', true );

Of course, as we explained, Sucuri allows you to change this setting right in the Sucuri plugin’s control panel, ideal if you’re not keen on editing configuration files.

Don’t use “admin” for the administrator account

Older WordPress installations started out with “admin” as the username for the main administrator account so many WordPress website owners still access their sites via the “admin” account. This matters because of a lot of automated WordPress attacks rely on hitting “admin” with a guessed password to get into the WordPress instance.

Now, WordPress forces users to choose a different administrator username so that “admin” is no longer the default for a new installation. That said some auto-installers that do a one-click install can still make use of “admin”. If you see that your administrator username is “admin” you should really change it.

Unfortunately you can’t simply rename an existing user, so if your administrator username is “admin” you’d need to change it some other way. You do have three options. First, you can create a new administrator account with a different name and delete the old one. The “Username Changer” plugin can also do it for you. Finally, you could simply hack into the WordPress database via phpMyAdmin and make the change yourself.

Change the WordPress database name

A bit like the issue around standard administrator usernames, WordPress assigns a “wp” prefix to the WordPress database, and all its tables. This hasn’t changed and hackers can try and search for WordPress tables using this prefix. Changing it can trip up hackers, but you must be extremely careful when you make this change as it can break your WordPress site so we recommend that you read our detailed instructions before you try to do it.

Set a password for the WordPress login and admin pages

Make life harder for hackers by setting up further password protection server-side that asks for login details before your server presents the WordPress wp-admin directory and the login page inside of it.

Each hosting solution will have a different way of making this change, but it can prevent hackers from running a DDoS attack or some other tricks that try to access the WordPress admin directory.

Stop directory browsing and indexing

Hackers can try to find out whether your site has a vulnerability by browsing the content of your site’s directories. Many hosting solutions leave directory browsing enabled by default providing an opportunity for hackers.

It’s not just hackers you need to be worried about. Directory browsing lets anyone who is curious hunt through the files on your website to find images and other documents or to copy down your directory structure. We strongly suggest that you disable the ability to browse directories as there is rarely any purpose for doing so.

To stop directory indexing you need to edit the .htaccess file for the root directory on your website. You can do so using the file manager on your website’s control panel. You need to add this line to the .htaccess file:

Options -Indexes

Do that and you will stop unwanted users from exploring the file content of your website’s directories.

Disable XML remote procedure calls

XML remote procedure calls, or XML-RPC, can magnify the impact that a brute-force hacker attack has on your WordPress instance. It is a powerful protocol and though it is useful on the one hand (you can connect other websites and apps using XML-RPC) it does carry risks.

XML-RPC has been enabled by default since WordPress 3.5 but it can open the door to hackers. Instead of using 500 individual password attempts on your site, a hacker can simply use system.multicall, a function in XML-RPC, to try these login attempts. In fact this function can try thousands of password with just twenty to fifty XML-RPC requests.

If you are not using XML-RPC the general recommendation is to disable it so that it does not open the door to hackers. You have three options: the most direct and least resource-heavy is doing so by using .htaccess. Alternatively, you can use the Sucuri WAF to do it for you.

Put a cap on the number of chances to login

Hackers often use a technique called “brute force” to try and get into a website if they don’t know the password. They simply keep trying the username against a list of potential passwords. WordPress usually allows users to try to log in as many times as they like, but you can change this. First, a website application firewall can do this for you as it will automatically block brute force attempts.

Alternatively, download a plugin called Login LockDown and install it. We have more detailed instructions on how to install a WordPress plugin elsewhere, consult these if you need more help. You have to set up the plugin once you’ve installed it, visit the Settings > Login LockDown page to do so.

Put a time limit on idle users

Hackers don’t always work from faraway corners in the world. When your administrator walks away from their PC while logged into WordPress they can open your site to security risks. Just as a lot of important sites like financial services force a log out after a period of inactivity you should also consider forcing a log out when a user is idle.

One way to do so is using the “Idle User logout” plugin. Once you’ve installed it go to the Settings > Idle User Logout page and set up the plugin. Here you can set the time duration that you prefer. Make sure to uncheck the “Disable in wp admin” option for maximum security.

Mix up the WP login screen with a security question

Again, in an effort to trip up automated hacking attempts you can make it more difficult to get past your WordPress login screen by setting up a separate security question which hackers won’t expect.

Thwart unauthorised access by installing a plugin. We recommend “WP Security Questions”, again easy to install as a plug-in if you follow our simple instructions. To activate this plugin go to Settings and then to the Security Questions page where you can customise the security question.

Set Alternative WordPress Login URL

Everyone who have an idea about WordPress CMS is aware that it is possible to access WordPress site via wp-login.php. No doubt it is awesome when we talk about the simplicity of WP usage, however not really acceptable when WordPress security is the subject to be concerned of.

There are numerous ways on how to change the default WordPress login URL, however we suggest to use WPS Hide Login or Better WP Security plugins for this purpose.

What to do when every WordPress security effort fails

The are so many facets to protecting your website against WordPress hacking threats. It is not uncommon for even the most switched-on website owners to trip up when they set up protection for their sites and that is why it is so important to have a dependable backup solution and reliable website security partners.

Should the worst happen you should consider letting a security expert do the clean-up as it can be difficult to get rid of everything a hacker installs. It is easy for intruders to leave what is called a “backdoor” which can enable future intrusion attempts. A company such as Sucuri can help fix your site for you. These security companies know what to do to ensure that a website is 100% safe after clean-up. That said, a backup of your site is important too because it makes the repair and clean-up process far easier.

Alternative approach is to use Plesk as a hosting platform for your VPS or dedicated server and enjoy the power of WordPress Toolkit – an ultimate WordPress management solution which will help not only to harden WordPress security, but also to run updates, manage themes/plugins/databases, edit global settings and lots more.

Wordpress performance WordPress security WordPress Toolkit

Guard your WordPress security: Understand SQL injections

Guarding WordPress security - SQL Injections - Plesk

We all know that WordPress has historically been very vulnerable to hacks of all sorts. So most good web hosts will practice good WordPress security measures to avoid falling victim to hacking. However, it can be hard to keep track of all the risks and develop a security solution that really protects your website.

Here, we’ll discuss how one of the most dangerous intrusions may occur. Code injections via SQL. Read on to discover what a SQL injection is, how it happens and what actions you can take to ensure your WordPress site isn’t a victim of an injection attack.

Understanding database injections

Hackers injecting code into a database isn’t uncommon. In fact, pushing rogue code into a WordPress SQL database is a frequently-used method for gaining unauthorised access to a site. It all comes down to WordPress’ reliance on SQL databases. And this has a big effect on WordPress security.

How WordPress stores content

Every WordPress site has a dedicated MySQL database – the standard DBMS used by WordPress websites. Whenever a page is requested, WordPress generates a SQL query. It consults the database for the content. Then plugs the database content into a page theme to render a user-friendly version of the content.

With the help of PHP SQL, queries are served to the system in order to make changes to the WordPress database. Including adding, deleting or changing the database itself. However, hackers do not necessarily connect with a database via WordPress or a control panel. In fact, code can be inserted into a WordPress database in a lot of different ways.

What hackers do to inject code into a WordPress SQL database

Forms. Yes, hackers use your website forms to inject code into your WordPress SQL database. Whatever receives user input can be the gateway to a security issue in its worst form: an SQL injection. Anything like a contact form, login box, sign-up box or even the search bar

The problem with forms is that, in many instances, the submission is captured in the database. Add rogue code in the submission and the code is stored in the SQL database. So, all a hacker needs to do is to enter this rogue SQL code into a form instead of bona fide form responses.

One example is a form field that should only accept valid telephone details. Yes, you should restrict form responses to be in the format of XXX-XXX-XXXX. However, if you leave the field as free-form, a hacker could easily inject SQL code using that field.

So, what happens after an SQL hack?

There are two ways in which a hacker can insert code into your SQL database. The Classic method of doing so involves returning data to the web browser used by the hacker. It’s just the same way you use a form on a website, really.

A query like this can result in your database returning information inside the database. And the purpose of this WordPress security hack is to steal information that is sensitive, including SQL structure which can lead to further hacking attempts.

Another way of inserting code is using a blind SQL injection. Here the injection does not involve the return of data. But instead, the hacker will use the inserted code to run code on your database. This code could do all sorts of damage, including deleting all your database data.

Can’t WordPress security prevent SQL injections?

Yes, WordPress has gone to lengths to try and prevent these common SQL injection attacks. WP security involves validating and cleaning data which is submitted via forms.

For example, validation makes sure that data that is received on a form fit the criteria that are specified. Like matching the data entered into a phone number field against the nature of a real phone number. Another example is the way in which WordPress removes excess and restricted characters from input.

Nonetheless, there are some issues that current WordPress security tactics do not account for. Which means WordPress is not fully-secured against database injections that manipulate SQL code.

For example, in 2017, WordPress published a security update which fixed a known SQL exploit detected by the WordPress team. This protected the core of WordPress. The update, however, did not protect vulnerable themes and plugins. Overall, themes and plugins are vulnerable to exploitation whenever they use a form.

The developers behind these WordPress add-ins need to be very much on top of WordPress security practices. So that database injections don’t cause problems for web hosts. In essence, it’s best to take additional mitigating measures. Because fully managing what WordPress or add-in developers do is simply not possible.

Let’s take a look at what you can do to manage your WordPress security to avoid hacks due to SQL exploits.

Preventing SQL exploits

WordPress itself has a few tricks up its sleeve. But in the end, good sysadmins will add additional measures to make sure their WordPress sites do not suffer from an SQL attack. Here is a short list of practices you need to implement:

1. Trust is the key

There’s a whole lot of reasons why you should be really careful using plugins and themes. But SQL injection risk is one of the biggest. Only use of plugins and themes that come from reliable, qualified and trusted developers.

2. Update regularly

Remember that 2017 WordPress fix we mentioned earlier? It didn’t work for a lot of people. For the simple reason that these users had disabled automatic WordPress updates. So the update never rolled out to their WordPress instance.

When it comes to updates, you need to be really alert. Because it’s not just the WordPress core that needs frequent and regular updating. You also need to make sure your MySQL database software is updated.

Also, always keep your PHP on the latest version. Often, your website management console can make it easy to keep all these aspects of your site up to date.

It can be difficult to manage updates across multiple sites. But you can try something like WordPress Toolkit which can manage updates across a lot of sites via a dashboard interface. So it automates the update process. The golden ticket? You don’t need to log into hundreds of websites to manage updates for sites, plugins, and themes.

3. Control field entries and data submissions

We’ve explained how a SQL injection works. Want a simple WordPress security trick to thwart them? Control the types of data that can be submitted via a form field.

A name field should only allow alpha entries because there’s no reason for numeric characters to be there. Likewise, telephone or payment card data should not contain alphabet letters or special characters. Also, consider deploying sanitize_text_field() so that entries that are not correct or simply dangerous can be blocked.

4. Don’t use the default WordPress database name

This is a really simple WordPress security trick: change the standard WordPress database name. By default your WordPress database will have the prefix of “wp-“. Thus, making it easier for a hacker to use your databases’ credentials, especially with bots and automated scripts. Change this default name and you make it more difficult for them.

5. Keep track of who uses the database

Never give access to your MySQL credentials. And in the case where you just can’t avoid it, log the use of credentials and the overall SQL activity. If unsolicited changes are made, you can detect the problem quicker. WordPress security tools including WordPress Toolkit can help you do this.

6. Use a website application firewall

Yes, you can get a firewall for your website. A website application firewall or WAF can detect SQL injection attempts by analyzing form inputs on your behalf. WAFs will also block known-bad IPs from your site so they can never even make an attempt. There are plenty of WAFs on the market, check them out.

Finally stopping SQL injections in their tracks

Database injections are an incredibly common way to hack into a website, but luckily they’re preventable. Good WordPress security practices can make it difficult for even the most determined hacker to inject code into your database.

You have several tools that can help you, one of these is Plesk WordPress Edition which can assist you in your WordPress security efforts. It also provides a range of other WP tools which makes it much easier to manage and maintain WordPress applications.

SQL injection WordPress security WordPress Toolkit