Modx Security

Is there a definitive resource for Securing a MODx Site? I’m having a cascading issue the reports of malware from my users, and would like to make sure the site is locked down.

+1

I’m aware of this wiki article: http://wiki.modxcms.com/index.php/MODx_Security but I can imagine there would be a lot of people who would be very interested in how those heavily involved with MODx manage their site from a security point of view. I won’t mention names, but I can think of at least half a dozen people who’d I’d love to grill about their own approach/setup.

I’m currently digging through Jeff Starr’s site (http://perishablepress.com/). Some of it is Wordpress specific, but there seems to be a lot of good stuff on general security and keeping out bad bots.

I have a few things I prefer, and a few things I always do.

1. Get hosting that provides suexec. The user gets switched from the Apache user to the owner of the file being run, so there’s no need for world-writable directories and files.

2. Decent passwords.

3. The two index.php files and the config.inc.php file get set to read-only.

4. The first app I install is the BkupMODx module, and I immediately make a backup to keep as a last-ditch fall back in case the site gets hacked. Then I backup frequently; daily if busy, once a week or once a month as management activity warrants.

5. When installing third-party apps (snippets, modules, plugins), make sure the file provided for copy/pasting into the Manager when creating the element is not a .php file. Rename it or remove it.

6. Spend time studying up on how to make my own code as bullet-proof as possible.

Thanks Susan (you were on that list!).

Although not all necessarily to do with MODx directly, does anybody have thoughts on:

- Suppressing PHP errors
- Monitoring raw access logs; what do you do when you notice weird requests/404s for suspicious resources?
- Moving core outside of public_html or similar (I think I’ve read that this is possible in Revo)
- Moving DB access details outside of public_html, and using ’require_once’ in config.inc.php

Has anyone had experience of either their computers or clients’ computers being compromised by keg loggers etc? I guess all you can do there is have the necessary paperwork in place that ensures they understand the risk, especially if they don’t run appropriate anti-virus etc.

I’m not praising Joomla (never used it), and I’ve currently only scanned this, but these security docs look quite thorough:

http://docs.joomla.org/Category:Security_Checklist

Some of the more general information might well be relevant to MODx as well. A dedicated resource like this on the MODx wiki would be good though - if I ever find the time I might have a crack at it myself!

No matter how hard you try, if you’re on any kind of shared hosting your weakest security link will always be the host itself. Look at the latest rash of compromised sites on GoDaddy and a few other of the bigger hosts. If somebody gets root access to an entire server, they’ve got full super-admin access to anywhere up to 400 or more sites to play with. So your best final defense line is a solid backup policy.

I’d second Susan’s recommendation: have a solid backup policy in place. There are lots of ways your site can break -- Your server, PHP, MySQL, and MODx can all be exploited, so having a backup is kinda like having an extra life in a video game.

Here’s a short article I wrote: http://tipsfor.us/2010/05/10/basic-web-security/

I included a couple backup scripts on that post for anyone who needs them. It’s not the end-all-be-all security article by any stretch, but it does boil down the high-risk points from a couple security audits I’ve been through.

Thanks for sharing that Everett, I think that’s more comprehensive than anything on the MODx wiki at the moment. This was also quite an interesting read - http://25yearsofprogramming.com/blog/20070705.htm

I try and keep an eye on my access logs when possible; this forum post (http://modxcms.com/forums/index.php/topic,33783.0.html) looks like it could be very useful in relation to suspicious 403/404s. If people haven’t seen these resources hopefully they may be of use.