[WEB SECURITY] LAMP Security Guide - Focused on Drupal
mike at openconcept.ca
Tue Nov 19 15:49:50 EST 2013
On Nov 19, 2013, at 3:04 PM, John Kinsella <jlk at thrashyour.com> wrote:
> Telling folks to use ssh keys and disable password authentication would be a big win.
> In general, there's plenty of guides on hardening a lamp stack - why not point users to one of those instead of re-inventing wheels?
We point to lots of them. Tell us which are missing.
We decided to write this as we needed something to pass out which was more understandable and geared to Drupal LAMP folks. So far we've had good feedback and haven't seem a comparable document before. Lots bigger and smaller, more technical and less technical, but I do think this is pretty unique from what I've seen..
> Why tell folks to use cron when Drupal has a built-in cron system since 7?
Well, Drupal 6 is still supported and there may be situations where you still may want to run cron manually. Say, if you wanted to execute cron jobs in low traffic periods rather than in the middle of the day.
I've extended this though to make it clearer and provided links to https://drupal.org/cron
> I didn't see mention of using a WAF?
We don't mention a general Web Application Firewall, but from here:
We do certainly mention ModSecurity. I'll add that link in though so that it is clear and that people can consider other options.
> Most folks using Drupal do so within an environment that has a control panel like CPanel or Virtualmin - and those panels will make several of your steps (such as keeping systems up-to-date) easier, so I'm thinking it'd be better to embrace the CP and show users how to run securely with one.
You can do this, but you're severely crippling your ability to add other modules. We don't recommend it even if it is very common. In our efforts to work with cPanel this summer it was very annoying what common libraries we couldn't add because it hadn't been included in the cPanel fork of CentOS we were given.
People don't have to follow all of the suggestions we've provided, but we've tried to include our reasoning behind them so that there is an understanding of the consequences.
> Have you run this by the Drupal security team? They'll probably give the best feedback.
I've definitely reached out to them and am seeking further input. Absolutely they have solid experience.
Mike Gifford, President, OpenConcept Consulting Inc.
Drupal 8 Core Accessibility Maintainer -> http://drupal.org/user/27930
http://twitter.com/mgifford | http://linkedin.com/in/mgifford
Open source web development for social change – http://openconcept.ca
More information about the websecurity