120+ Security Based Modules? Really?

If user registration is open or you have contact forms then Mollom is a must have to keep away spam bots.

In my opinion, SecurePages and SecurePages Prevent Hijack are two must-haves. In all cases - even on a small site - I think it's important to protect your login credentials during transit.

Also, I did a large spreadsheet comparison of all of the various access control modules, and the one that came out on top for me was content_access. It also happens to have the highest usage compared to the other node access modules.

You are falling into the wormhole of content permissions in Drupal :) I spent quite a bit of time in that hole so I can relate. I'm not using forums but I know there are a few modules that have been specifically designed for that purpose. Forum Access seems to be a pretty popular one, was updated very recently, and also relies on the ACL module like content access does. Perhaps that would be a good option to investigate.

The big item to look at for file permissions, and a big decision with a Drupal site overall, is whether or not you will use a public or private filesystem. There are advantages and disadvantages to both approaches. You might want to poke around the Drupal.org site and read some of the threads. This is a decision you should make early on and then stick with it. Changing things down the road with this one can be difficult. The base decision is whether or not the web server itself or Drupal controls access to files.

My main site requires authentication for the user, but my filesystem is public. This would allow someone to directly get to a file if they knew the URL but I don't care based on the content - it's not sensitive. If I was dealing with documents that really needed to be locked down and not visible to anyone but an authenticated user, I'd opt for a private filesystem. This choice also impacts performance since you can't do things like CSS/Javascript aggregation with a private filesystem. In that case you need to look into a few of the optional modules that can help with a site that needs mixed public/private filesystems.

Note that none of this is 'under the hood' at the OS/filesystem level - it's all about how content is served to users and how Drupal interacts with it. In my experience nobody other than the site admin/root can get under the hood to start mucking with permissions at the OS level so it hasn't been a concern for me.

I agree that Drupal can be overwhelming with modules, so let me give you my top modules that I use with pretty much every site. They are not all security-related and some of them may not seem terribly interesting at first glance but really are important. Transliteration, Token, and Pathauto come to mind.

http://drupal.org/project/admin_menu
http://drupal.org/project/advanced_help
http://drupal.org/project/auto_nodetitle
http://drupal.org/project/cck
http://drupal.org/project/content_access
http://drupal.org/project/ctools
http://drupal.org/project/devel
http://drupal.org/project/drupalforfirebug
http://drupal.org/project/drush
http://drupal.org/project/drush_mm
http://drupal.org/project/filefield
http://drupal.org/project/imageapi
http://drupal.org/project/imagecache
http://drupal.org/project/imagefield
http://drupal.org/project/logintoboggan
http://drupal.org/project/masquerade
http://drupal.org/project/panels
http://drupal.org/project/pathauto
http://drupal.org/project/securepages
http://drupal.org/project/securepages_prevent_hijack
http://drupal.org/project/taxonomy_manager
http://drupal.org/project/token
http://drupal.org/project/transliteration
http://drupal.org/project/views

Well, sadly for my testing server, I do not have SSL . Where/how can I make my own? Yes, I understand that it will be an unofficial certificate but I need something there for me to enable SecurePages

Generally OpenSSL is the best bet for both Windows and Linux. Google around for openssl and self-signed cert and you should find plenty of stuff. Here's a link I found - http://sial.org/howto/openssl/self-signed/

The folks at www.cacert.org will also generate one, although it's basically the same as self-signed. If you want a real SSL cert cheap the lowest prices I have found were with GoDaddy.

...how do I get the non-SSL equipped server to use it? I do not have command line abilities with that server. On my test server, I of course do.

The easy answer is you don't :) Unless the server software itself supports SSL, you are out of luck. If you are using a hosting provider it may be in their docs as to how you would upload the cert assuming they support it. Generally providers will up-charge for SSL support if you are using your own domain/hostname since you can't easily do virtual hosting on an SSL site like you can on a non-SSL site. The IP is more or less dedicated to your site.

You won't solve the SSL problem without SSL. If you don't put it in, there is no encryption of the user's password across the wire and it's open to interception. There are a total of 3 issues in the queue and no code update for more than a year which would also automatically disqualify CSE from my perspective.

Security scanner is fine in the case you are writing your own modules and need to write Simpletest/QA scripts to evaluate the security of the module.

I think you may be overthinking the security side a bit. There are a few important things to consider, and a lot of them don't have to do with Drupal or modules.

1) Operating System. Make sure the underlying operating system is fully patched and was built from known-good media. If you are on a hosting provider, you may just have to ask them what version they use, what their patching process is, the underlying OS, and status. Make sure they are keeping it up-to-date.

2) Database. Same goes for #1 - make sure it is current.

3) Network Access Control. Make sure you know what network ports are open to your host. This includes things like SSH access or other daemons that may be running that you don't want on there. Again shared hosting may make this a moot point. One thing you do want to make sure of is that your database and SSH ports are not directly exposed to the Internet with no filtering. MySQL is port 3306 and SSH is port 22.

4) Web server configuration. The conf file should be reviewed carefully if you have access to it. Assuming you are talking Apache, there are lots of public guides on how to harden it. Removing unused modules is a good starting point, and you may also want to wrap the cron.php and update.php inside of access control directives that restrict access by IP or by basic authentication.

5) PHP configuration. I am a fan of the Suhosin extensions and they have worked well with my Drupal sites so you might explore it.

6) The mod_security web application firewall extension for Apache. This works well if you know how to tune the rules and to disable it for specific Drupal paths. I have a good customized mod_security conf file for Drupal that I can make available if needed.

7) Drupal itself, make sure you are using strong passwords, and enable SSL/SecurePages/SecurePages Prevent Hijack to protect user login credentials over the network. Also make sure you have good node and content access controls inside of Drupal to protect your content from unauthenticated and authenticated users.

Most of the above you aren't going to be able to do if you are on shared hosting. You basically inherit whatever the shared host provides you, but if you know enough to ask how they manage their environment you may be able to find a good/secure provider. Vendor selection is the most important part of this process - not your own technical configuration and modules.

The major web attacks today deal with SQL injection and cross-site scripting, and Drupal core is pretty resilient against those type of attacks. The modules are a different story as they don't all go through the same Q/A process. That's where things like Suhosin and mod_security come in, but they take a fair bit of time and know how to get them going.

My opinion is that you should probably move ahead with your project, but sign up for the Drupal e-mailed security notices. Whenever a notice comes out about core or a module you are using, just make very sure you react right away and upgrade. That should keep you fairly safe. If you are dealing with very sensitive data my recommendation would be to get off of shared hosting and go with a properly configured/secured cloud server that you manage yourself. I'm on Amazon EC2 and it works well for this purpose.

Thanks so much. Security is just what came up as my primary focus first and foremost, simply because Im on a job I wont have full control over this server. Got totally spoiled on having the one here at the house. :) Besides, other CMS require more plugins/extensions that deal with Security. Guess I got used to that part being the inconvenience.

IMO, core Drupal is pretty good from a security standpoint. I have run IBM's commercial AppScan application code review tool against it and it came back clean. Where you get into trouble are with contributed modules, and then moreso with the modules that may not have a wide audience of users or senior developers. It's easy to roll a module, but not everyone keeps things like check_plain() in mind and that can open you up to issues. The other area is misconfiguration of Drupal on the part of the admin which can be solved by learning more about the security model.

There are a few web videos on Drupal security from some of the presentations - mostly dealing with writing secure code - but they are worth watching if you have the time. Here's a book if you have the inclination to buy something - very good resource on Drupal security.
http://drupal.org/node/597378

OK, so someone asked about mod_security so here goes. My rules are enclosed below. Mostly it was a matter of disabling specific signatures for different parts of the site. The idea was to remove the signatures in the most narrow method possible to 'fix' the usability of the site while maximizing security.

Your mileage may vary if you are using modules that I am not using. In that case, just watch your web server error logs closely. When you see something legitimate breaking (the log will give you the path and ID), add another LocationMatch and SecRuleRemoveById for it. Note that a path like /admin covers everything under that directory - /admin/foo /admin/bar etc. The more specific you are with rule creation (/admin/bar being more specific) the less coverage you disable and the more security you get.

In my case, this is my modsecurity_localrules.conf file. I tried to annotate it as to what module the disables were for.