Internal Changes to Managed WordPress Hosting

The saying often goes, “you can have security or convenience” meaning that secure things are not going to be easy to use and having things easy sacrifices security. That is very true when it comes to hosting.

Technology is ever-changing and along the way some growing pains occur. This is the case with the current relationship between PHP 7 and SSH2. PHP 7.1 is the latest version of the scripting language. SSH2 is what allows secure communications between other computers and your web site. Unfortunately the two have not gotten along very well in quite some time.

We use SSH2 to access all of our servers because it allows us to log in without using passwords. We use what are called “shared keys” – 2048-bit encrypted key pairs – one of which are stored on the server. This is superior to passwords because they cannot be guessed. The public key is stored on the server and the private key on our local machine. SSH2 looks at the two and determines if the user connecting is allowed. Plus all traffic is encrypted which makes it’s security superior to standard, unencrypted FTP.

Here’s the problem…

Since there are problems with PHP7 and SSH2 there are problems with our hosted CMS packages. Yes, WordPress. We have spent the last several months digging through the core of WordPress to see if we can find a workaround or narrow down the problem. We have not found an acceptable solution but are continuing our quest. As evidenced by this WordPress Trac ticket, this is not a new issue.

So why not just use FTP?

As mentioned above, it is inherently unsecured. Your username and password can be intercepted when communicating between machines.

Why not just use PHP 5.x?

Support for PHP 5 will end in January 2019. However, these problems also exist on occasion in PHP 5 installations.

Why worry about upgrades to WordPress?

Get out.

So what is the solution?

One option is to enable direct file management through WordPress. While this is convenient, it allows anything to be written to your WordPress directory which moves the needle away from “secure”.

The solution is more complex than we wanted but more secure than other solutions or waiting for the problem to solve itself. We needed the solution to be secure and yet convenient for our users. We are introducing another layer of communications: a local FTP server.

Most of our WordPress clients maintain their sites through the WordPress interface while a few like to upload documents to their site. This solution will work with all scenarios keeping external communications on SFTP while updates are performed locally only.

Also, we love using the WordPress CLI – command-line interface. It makes management quick and easy and reduces the amount of downtime involved with theme and plugin updates. However, the WordPress CLI uses the current user and does not recognize the user/password in the FTP settings. While this is a bump in the road for us it is not an impediment. SononaCare is taking over much of those roles.

To address these issues we are installing PureFTPD on all of our sites. This will allow WordPress to update itself, manage theme and plugin updates and media uploads. For our clients who wish to manage files directly through an FTP client, we will provide a folder specifically for uploads; WordPress management will be handled through VSFTP.

Why VSFTP? It all comes down to permissions. And if you have worked with us any length of time you have heard about Linux permissions.

Typically a secure WordPress installation’s permissions allow reading and writing by the directory’s owner and gives reading and execute permissions to everybody else (this is called “755” or rwxrwxr-x as in “owner: read-write-execute, group: read-execute, others: read-execute”). In the current state of the SFTP/SSH environment under PHP7 and SSH2 we have to give the user ownership over the files and the group PHP runs as read-write-execute permissions (775). This is not secure.

With PureFTPD the FTP daemon owns the files so we can adhere to the 755 scheme for directories (files should be 644, or, r-xr–r– as in owner: read-execute, group and others: read-only because I’m sure that question is burning in your head right now, if you’re not yet asleep).

We decided to move toPureFTPD for a few other reasons:

  1. It jails users into a single directory. This way if your site is compromised we can limit the damage to a single directory.
  2. It allows us to set up separate users for separate sites, to isolate sites from each other and prevent unauthorized users from “branching out”.
  3. Password files are kept separate from Unix password files (vsftpd stores FTP user accounts in the Unix password file)
  4. FTP users do not have shell access.
  5. The FTP service is not advertised to the world (ports 21 and 990 are hidden)
  6. FTP users can only log in from the same server.
  7. There have been fewer vulnerabilities listed in the CVE (Common Vulnerabilities and Exposures) database than vsftpd and ProFTPD.
  8. We have already been using it for quite some time!

One last thing aboutPureFTPD: nobody can access it outside of the server. What is this craziness, you say? Why have an FTP program then? The answer: security and necessity.

See, only the local WordPress site needs to use the FTP server to read and write files. So the FTP software does not need to be accessible from the outside world! Authentication information is sent only within the server and cannot be intercepted by anyone outside of the server!

We realize this may raise more questions than answers so please e-mail us or contact us if you have any questions.

Leave a Comment





Privacy Preference Center