How to prevent an admin account from taking over the server?

[Anders]

Let's say some bad guy steals my ProcessWire admin account password (by reading it off the post-it note I so conveniently have on my screen). Obviously, they have full control of my site now and can do whatever they please. That can not be prevented in this scenario. But on many ProcessWire installations, I think the attacker could also gain control of the server, e.g. by installing a PHP shell. That could probably be prevented somehow.

My goal is to lock down things so that an admin user can not insert any PHP to the site. What would I need to do to achive that? I can think of a few things:

• Disable module install/upload/download.
• I guess the hanna code module must be uninstalled?
• Anything more? Any other modules or settings to look out for?

I understand that features like one click module install are very useful, so this is not a critique against ProcessWire - it's the best CMS I have ever used. I am just interested how I can be a bit extra cautious. Also, I understand that it is best to just never lose your admin password, but I think defence in depth is a good thing.

[dragan]

35 minutes ago, Anders said:

by reading it off the post-it note I so conveniently have on my screen

yeah well... no matter what system you use, that's a bad idea.

37 minutes ago, Anders said:

• Anything more? Any other modules or settings to look out for?

Tracy Debugger can wreak havoc if used by non-trusted users (terminal, Adminer, console etc.). But you don't want to remove and install it again each time you log in as legitimate superuser, do you?

[Anders]

For the record, I don't actually have the password on a post-it... ? 

6 minutes ago, dragan said:

Tracy Debugger can wreak havoc if used by non-trusted users (terminal, Adminer, console etc.). But you don't want to remove and install it again each time you log in as legitimate superuser, do you?

Are you talking about this module? I don't have that installed, so it should not be a problem for me personally. But it is good to know anyways.

Thanks!

[Martijn Geerts]

When you know your I.P. maybe you could check against that. One hook you could use is session::allowLogin

[adrian]

If someone has your superuser password, it hardly matters whether they have Tracy installed or not - they can just go install it, because they have superuser permissions ? Sure, you could lock down /site/modules/ permissions so that PW can't install modules (meaning you would need to install them all via FTP / Git / etc rather than via the web interface. But I have to ask - surely if you're worried about someone getting access to your superuser account, aren't you just as worried about them getting your FTP access details? You could lock down FTP via SSH security keys which would take care of that. Regarding locking down superuser access, you could always install PW's 2FA system - that's probably the safest approach to protect things.

 

[Anders]

In production mode, I have no need for functionality that lets admin modify PHP code. From a security perspective it is usually good to disable things you don't need. However, in this case there doesn't seem to be a trivial off button, so perhaps it is not worth the hassle.

[teppo]

While I agree that securing the superuser account with 2FA — and, preferably, not creating multiple of such accounts — is a very good idea, you can still make sure that even if a superuser account is compromised, it won't provide anyone with any more than the necessary capabilities on the host system.

• Don't allow PHP to write into directories where executable code is stored; most importantly index/config/htaccess files, /site/modules/, /site/templates/, and /wire/. This means that a) module installs via ProcessWire GUI are out of the question, and b) at least in production you can't use modules that allow authoring or executing code via a GUI.
  • Technically File Compiler also writes executable code, but it's a bit different (and can usually be disabled as well). I wouldn't worry about it too much.
• While ProcessWire used to allow storing custom code in Page reference field settings, that's no longer the case (hooks are used instead). As such, at the moment I can't think of any core feature that would allow superusers to access the underlying system once aforementioned precautions are taken — so after this it's essentially about only installing modules you know and trust ?
• Finally — and this is not a ProcessWire thing per se — make sure that the system itself is secure, and that whatever user Apache is running as doesn't have access to anything it doesn't need access to. Also: try not to store anything that doesn't need to be public under a publicly (web)accessible directory, whether or not there's .htaccess protection in place.

I won't go into server side security here, but there's a truckload of stuff you can do there both to avoid user accounts being compromised, and to limit the impact of compromised accounts. For an example you can make it so that even if someone does gain shell access through the site, they won't have access to the whole server (this is always the case in shared hosting, at least if the host has any idea whatsoever of what they're doing).

Often it all boils down to how hardcore you want to get with this stuff, really ?

[Anders]

Thanks @teppo! That is some great advice. First bullet point is neat - solve the problem at the filesystem level and you don't have to keep track of what individual models do.

I quess what you would still have to look out for is if there is any PHP stored in the DB and then evaled. Like if the hanna code scripts would be stored in the DB. But I guess grepping for eval would let me find stuff like that, will investigate further.

[bernhard]

It depends on your usecase, but a very simple solution could be to prevent login of superusers for the live system:

// site/ready.php
$wire->addHookAfter('Session::allowLogin', function(HookEvent $event) {
  $liveHost = "my.live.site";
  if($this->config->httpHost != $liveHost) return;
  if($event->arguments(1)->isSuperuser()) $event->return = false;
});