That's where the fun is...

Yes, that's an occupational habit you catch if you're working in the IT sec world. Where the battlefields of cyperwar are... - That sounds too dramatic, doesn't it?
Well in any case I just like tinkering with "security" stuff. So here it is: my actual project's "security" setup - that will get extended on demand.

Just mess around with it and have fun if you want. - All this stuff is not half as effective as it should be.
I just see a constructive effort in listing the actual measurements to inspire people. Maybe something kewl is missing? Drupal is an open project with ~4000 free different enhancements. The 4001th wouldn't be that bad.

I'll write a similar security review ;).
Have fun!

Security enhancements

PHPIDS

phpids is a "web application intrusion detection" engine, that's validating inputs and reporting incidents based on impact levels. It logs potential XSS, SQL Injection, header injection, directory traversal, RFE/LFI, DoS and LDAP attacks. The filters are quite sophisticated; and even detect some obfuscated more sophisticated attacks.
The Drupal module works with the newest version and filter-sets.
Of course for hard-redirects, a test-periode to calibrate is necessary. At the moment - nothing is being detected. Fair enough! If you encounter false positives I'd love to get a message.

Anti-Spam - yes that's needed

I hate Spam and Captchas. Captchas are annoying and no solution!

So here's the deal: you don't use smear words here and you're allowed to post - even links.
Otherwise you'll get listed on the Troll module :). - Okay, that's just a fun-enhancement. But here's a real effective one: the verification steps are deep: bayesian filtering, URL lists, patterns... and a public API: mollom. That's a distributed way to fight Spam and create statistics. Drupal includes a mollom module, that works out of the box.

Furthermore this is a low traffic blog - so no problems.

Still bad-behaving?

After all, spammers write their bots on the cheap, and have little incentive to code very well. If they could code very well, they probably wouldn’t be spammers.

(source: bad behavior documentation)

If something here behaves like a unsophisticated prat, it'll get banned. By the Drupal application enhanced with the BadBahvior module.
That sounds funny enough, because I don't see a reason to allow bad coded spam-bots to index my contents.

The Drupal module exists, but it could be enhanced to work with the newest rulesets. You have to use version 2.0.13 actually. If you take a second to read the change-logs: it's not that big kind of a deal. There're no schema changes for the detections jet.
And yes: it just blocks lesser sophisticated spam-bots and spiders. If somebody is good enough to spam here, he/she/it just deserves it.

mod_magnet in lighttpd

This is more a concern of host-security, but anyhow: I'd like to mention is because there's a special enhancement for lighttpd's mod_magnet, if the webserver has been compiled with Lua support.
The mod_magnet module allows to set rewrites and redirections based on rules - you can define in Lua. Have a short look at this snippet:

-- little helper function
function file_exists(path)
  local attr = lighty.stat(path)
  if (attr) then
      return true
  else
      return false
  end
end
function removePrefix(str, prefix)
  return str:sub(1,#prefix+1) == prefix.."/" and str:sub(#prefix+2)
end

-- prefix without the trailing slash
local prefix = '/blog'

-- the magic ;)
if (not file_exists(lighty.env["physical.path"])) then
    -- file still missing. pass it to the fastcgi backend
    request_uri = removePrefix(lighty.env["uri.path"], prefix)
    if request_uri then
      lighty.env["uri.path"]          = prefix .. "/index.php"
      local uriquery = lighty.env["uri.query"] or ""
      lighty.env["uri.query"] = uriquery .. (uriquery ~= "" and "&" or "") .. "q=" .. request_uri
      lighty.env["physical.rel-path"] = lighty.env["uri.path"]
      lighty.env["request.orig-uri"]  = lighty.env["request.uri"]
      lighty.env["physical.path"]     = lighty.env["physical.doc-root"] .. lighty.env["physical.rel-path"]
    end
end
-- fallthrough will put it back into the lighty request loop
-- that means we get the 304 handling for free. ;)

I found this script in the official lighty docs, just linked because it's not under GPL.
This also enables "Clean URLs" (no =? necessary), and the option to redirect people to use SSL ("Secure Sites"). Any authentication happens through SSL. Normal readers just don't need it.

modsecurity - as far as I know - just works with the good old Apache and I don't know another free WAF that is compatible.
Everything else, including reverse proxy solutions, don't make sense because I don't have a shop here or anything else that's related with financial interests. But just for fun I might give that a try.

fail2ban for lighttpd

fail2ban works with lighty, too.
Simply putting this into the filter.d directory, and configuring it is enough.

# Fail2Ban configuration file
#
# Author: Arturo 'Buanzo' Busleiman 
#

[Definition]

# Option:  failregex
# Notes.:  regex to match ALERTS as notified by lighttpd's FastCGI Module
# Values:  TEXT
#
failregex = .*ALERT\ -\ .*attacker\ \'\'

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex = 

jails.conf gets the configuration now:

[lighttpd-fastcgi]
enabled = true
port    = http, https
filter  = lighttpd-fastcgi  # how you named the file
logpath = /var/log/lighttpd/error.log # adapt as needed
maxretry = 2 # choose any value that works for you

The only one getting an account here is me, for now. So no problems. This won't work against distributed brute-force attacks. But if works against lesser sophisticated password-cracking.

SSL

I got a very good tip to use StartSSL as a free CA. This means Root-CA, active in IE, FF, Opera, Safari... free. No cert-issues. I'll set this up asap, because actually my SSL is just self-signed.

Anonymized logs

I don't see a reason to save IP logs for more than a couple days. The system can automatically anonymize its logfiles after a definable period.
Attacks and stats get logged separately - with IP information. Normal access won't be logged to keep the overhead low and to minimize the information. It's much easier to filter before the analysis. A mass of logs is senseless.

CSE

There's a concept of Client Side Encryption activated here, which encrypts information within the client's web-browser in the input fields on demand. At least it's using a cryptological algorithm (AES) to separate the sensitive information-flow from too nosy people. This is included just for fun. It's not secure by any means of robustness or integrity.
If you want, give your comment a pass-phrase. Maybe you should reveal it.

Performance

Cached PHP opcode strategies

That's modern nowadays. Performance optimizations for PHP through FastCGI. Nevertheless many documentations for php caching modules claim to be incompatible with lighttpd: they work - just with php5-cgi. Call it a secret.
In any case you need to setup your httpd with FastCGI. Furthermore there's a module optimizing memcache strategies within Drupal. Sweet!

Throttle

If the server load gets extraordinary high, the modular design of Drupal allows to dynamically deactivate and reactivate parts. This prevents DoS situations and keeps the whole system available, because more complex functions won't be initiated as long as there're too many people on the particular site. For example the search function, the tag-cloud, new comments...

Perspective

Passive DB query monitoring

What I truly miss for now is a sophisticated database monitoring. Much performance and security issues lie in Web-App's DB backends. - Normally you'd setup these kinds of systems for customers with a huge amount of entities.
If you simply can't have a short look through the recent queries lots of necessary transparency gets lost - that you could use for optimizations. Especially because SQL injection vulnerabilities spread through almost every Web-App from time to time; or DoS situations are caused by repeated malicious search queries.
The concept of Drupal is to offer Administration through the frontend without direct separation. Of course there're the operating system's DB logs.

So long...

Fast and secure - that's no dichotomy here. People always like their Web-Apps as long as there's no complex problem. In case of Drupal you've got a very friendly and active community support. So I guess the relationship between me, my Weblog and Drupal may last a longer than the previous one with Google's Blogspot. Just guessing for now...

Have fun,
wishi