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?

Why tell folks to use cron when Drupal has a built-in cron system since 7?

I didn't see mention of using a WAF?

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.

Have you run this by the Drupal security team? They'll probably give the best feedback.

On Nov 17, 2013, at 9:10 PM, Mike Gifford mike@openconcept.ca wrote:

On Nov 19, 2013, at 3:04 PM, John Kinsella jlk@thrashyour.com wrote:

We do.

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..

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

We don't mention a general Web Application Firewall, but from here:
https://www.owasp.org/index.php/Web_Application_Firewall

We do certainly mention ModSecurity.  I'll add that link in though so that it is clear and that people can consider other options.

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.

I've definitely reached out to them and am seeking further input.  Absolutely they have solid experience.

Mike

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

Mike - didn't intend to come off harsh/blunt in my last note but I did, my apologies.

I also didn't intend to not read the paper, but it seems like i did that as most of what I pointed out was incorrect. Not sure what crawled up inside me this morning!

Overall (now that I'm awake), good doc. I think partially what got me is the mix of links and indented example text - I think just flipping through it, I was looking just at the indented text and missed a bunch of the suggestions/recommendations. The reason I was flipping through was because the doc is 30 pages long, which is why I suggested just linking to hardening guides for the sections up-front. You've included tons of links to options/suggestions - great for the academic discussion, but I'd guess the target reader would prefer something more prescriptive?

I suspect you posted this morning for security feedback not "it's too long," so I'll bring it back to that - as it felt too long to me, I bypassed a significant portion of the information. If I was trying to harden a system based on the doc, I would have missed a bunch of stuff.

Maybe have a TL;DR version, as well as the more conservational one? Just a thought, hopefully this feedback's a little more useful. :)

John

On Nov 19, 2013, at 12:49 PM, Mike Gifford mike@openconcept.ca wrote:

On Nov 19, 2013, at 6:21 PM, John Kinsella jlk@thrashyour.com wrote:

No worries. It's a reasonably long document and I was asking for a free review from a list which contains folks with a lot more security expertise than I have.

Happens to all of us some of the time I figure.

The intended audience of the document isn't straight forward.  The first part of the document is really meant to be an overview that could be shared with management.  Ultimately, if they don't understand why security is important or why it needs proper resourcing then they aren't going to fund it correctly.

This document could very easily become a book, however, I don't have time for that and really am not enough of a writer or security geek to pull it off.  I was trying to achieve a balance between simple command line tools that an administrator could install and the vast documentation that could accompany each one.  Thus all the links to other documents throughout.

I'm still not sure what the target reader would prefer.  I haven't gotten enough feedback.

This is very useful feedback.  Possibly it should be a number of distinct documents.  We're also looking at putting something up on Github that's more targeted.  Possibly with Puppet scripts or checklists that can be downloaded.

This was useful but the last one also reminded me to reach out to the security team on Drupal.org.  So I reached out to almost everyone here:
https://drupal.org/security/

Lee Rowlands told me about:
http://rkhunter.sourceforge.net/
sudo apt-get install rkhunter

And reminded me about Puppet/Chef which would allow you to:
a) restore your server and come back online quickly
b) ensure you don't miss critical setup steps

That makes it longer still, but if it's broken down into small pieces it should help deal with the TL:DR issue.

Mike

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