Yep. I used to clean up servers at a hosting company that would get hit with malware and if we had done it like this person did, they would get re-pwnt in a few minutes / hours. Much of the pwnage wasn't even personal, but automated exploitation en masse of outdated PHP scripts like Wordpress, Joomla, PHPNuke, SMF, PHPbb, vBulletin, one of the 10 popular photo gallery scripts, etc etc.

The best bet is to back up the DB and reinstall the PHP scripts clean on a new server. Upgrade them to the latest version in the process. Try not to re-use any files from the old server, and inspect the heck out of any you do.

Suphp + suhosin + open_basedir + SELinux + chroot, jails, or lxc, proper permissions + proper Umask and Apache config + LMD + tripwire + mod_security + owasp rules + clamav + competent sysadmin team + monitoring + alerting will get you most of the way to a safe PHP hosting environment. Not impossible but not something I'd recommend considering how cheap decent hosting is these days.

I think your last paragraph is overstating things a little. If you're providing hosting for other 'random' clients who upload their own plugins, sure, you need to be wildly over-zealous.

I, and probably many others, provide hosting for a few wordpress sites that we admin, and a client has only editor access to.

The way I've got it set up is:

- nginx running as nginx:nginx, handling static files, and passing on to PHP-fpm only for non-upload directories. - each site directory is owned by $clientname:$clientgroup. - php-fpm runs in each dir as $clientname-php:$clientgroup.

So wp-config.php, etc. configuration stuff is readable only by the group, and only writable by the owner user.

The PHP running user can upload media, post new content, but cannot upload plugins, edit any other PHP files, change any site-level configuration, etc.

To upload plugins, or do updates, inside wordpress it asks the user each time for a FTP username/password, which it uses to create a local ftp connection in to the server, as $clientname, which can then write to the plugins directory. FTP is only accessable from localhost, so there's nothing in plaintext on the wire.

Wordpress and plugin updates are done by WP-CLI hourly as a cronjob by the $clientname user.

Each site has its own database, user, and all that too.

All of this is set up by ansible, so it takes me about 3 commands to create a new site from scratch, or 5 to provision it onto a new server.

I've got reasonably defaults set up in php-fpm, so basedir, maxupload, restrictions, and all that. And as much as possible restrictions in place by nginx as well.

I'm working on automatic SSL certs from letsencrypt, which is working on some sites now, which beats the self-signed ones I had before (log-in only to wp-admin by SSL).

It seems relatively good for me. The sites are fast, cheap, and for my clients (small businesses, friends, family, church(s), etc), perfectly adequate.

I understand the full stack, and can keep the very cheap VPS running in less than an hour or so a month.

In the future, I hope that there is something more self-contained and easy to deploy, perhaps like caddy[1].

I'm not a huge fan of wordpress... but it's everywhere, and enough people have heard of it / can do stuff with it. The bus factor is a lot lower than many alternatives.

[1] https://caddyserver.com/

Are your ansible scripts available, as this sounds an awesome setup?

Thanks.

I'll try to at some point - but a lot of it was hacked together pretty quickly to various deadlines, so I'd like to refactor some bits and audit it to make sure I didn't do anything stupid like put mysql root passwords in a config template somewhere... I'll try and post to HN when I do.

Caddy is brilliant. Give it another year and I think it will have a significant share of the webserver market. I replaced about 200 lines of nginx configuration with about 15 lines of Caddyfile. This is mostly due to sane defaults and inbuilt support for Let's Encrypt.

I've never worked with PHP before, so basedir meant nothing to me. A minute with Google turned this up:

http://php.net/manual/en/ini.core.php#ini.open-basedir

I have to say, for all the general brain-deadness we hear about from the PHP community, the core developers have made a lot of progress on cleaning up their mess. I don't know of anything equivalent to this functionality from Python or Ruby.

This is not new. PHP3 already had it, but not many people actually care enough to use it.

Other languages have LSMs and seccomp (linux), pledge (bsds), chroot (all *nix). It doesn't need to be built into the language itself.

I think basedir like functionality is a good idea, but this is not the languages responsibility, this is an operational concern.

There's too many ways around it if you're trying to do this in a language ... for example, limiting checks on the open() call would be relatively straight forward, but what about people who use syscalls directly from the language? Or what about shelling out to another process?

Chroot jails get kind of close of this in a very broad/blunt way, but back to my original point: This is not the languages responsibility

PHP doesn't have direct access to syscalls. (not without extensions anyway) exec / system / other shelling out functions should be disabled unless you actually know you need them.

Unfortunately on point #1, the majority of Wordpress deployments are sitting on cPanel servers running suExec. More often than not, the application runs as the only account a customer has access to.

If you have stylistic comments/advices about the "reading pain" you get, they are welcome!

It was a pain because of conclusions / actions rather than the writing style.

Ok ;) sorry for that