The first point release of the Guardr distribution for Drupal was released last week. Though the Guardr node wasn't created until May 2012, the project actually started about 5 years ago. The product follows much of the history of Drupal - as a collaboration between many developers across multiple different shops. The reality is that the Guardr make file is just a way to organize a crap-load of work that was done in module contrib land.

I was faced with hardening Drupal beyond the built-in controls as part of a project for a Fortune 100 company. At the time, my thoughts were to turn Drupal from a social publishing platform into a business application. One of my project requirements was to conform to business practices that would limit users' sessions - to make sure when someone shared a login at work that it could only be used by one person at a time. Shared logins break a security principle of accountability. As long as users are sharing the same account, nobody can tell for sure who updated node content or changed site configuration. That's when I started committing patches to the Session Limit project.

The Drupal Security Report, updated recently in December 2013, enumerates how Drupal is secure by default and how each of the security points match to the OWASP Top 10 vulnerabilities for web applications. The mitigations for OWASP Top 10 items haven't changed substantially over the past 5 years in Drupal core.

Though Drupal's default configuration sends seemingly harmless information, Guardr goes an extra step - it checks for security updates by default. It seems odd that I should even have to tout that as a feature. Drupal tries to be helpful by displaying errors to the screen after the installation is complete.

Guardr's install profile disables displaying error reporting by default, silently logging them instead. You should be reviewing your logs regularly anyway. Every time Drupal has to log a PHP warning, a deprecated function, or Drupal nuance, it drags down your database and extends your page load times. Even if you mess up in a big way, Guardr hides fatal PHP errors, too.

Part of Drupal's history is as a social platform. Even though the forum module has always been a joke to usefulness, the default new user rules permit new user registration without administrator approval - again, something that Guardr locks down.

While LoginTobogan was a great introduction for usability improvement, allowing users to login using their email address is a security weakness. I recently just added my real email address to the footer of my blog. If I then also allowed anyone on the Internet to login using my email address, the evil they would also have half of the credentials needed to break into my account. Guardr removes usernames from the default outgoing email texts, then combines the Realname module to help keep login usernames private. If the attacker doesn't know the username or their password, they've really got a lot of username/password combination permutations to try. Think of it like a poor man's two-factor authentication.

The Internet has several lists of modules that make Drupal sites more secure, but it's things like the pairing of modules like Realname with the removal of usernames in outgoing core emails that's what makes Guardr stand out. It's the build script. Another example - the Remove Generator module removes the META tag that displays "Drupal 7" in the HTML source of every page, but Guardr's build also removes the CHANGELOG.txt file from the root directory, another easy vector for determining both the software and the version of CMS. Why give the vulnerability scanners and penetration testers the easy way out? Let them try some Wordpress vulnerabilities first so your web application firewall and intrusion detection system can flag them well before they get to specific Drupal version exploits.

Starting with Guardr takes away a bunch of the headaches for securing your site from the start. Imagine having a password policy in place that even forces UID 1 to have a reasonably secure password or which even denies UID 1 the ability to activate the PHP input filter. Run your code through version control, test it, review it, wrap it in accountability, tag it, and don't skip the proper workflow.

Guardr's configuration keeps enough logs that you can actually go back a few weeks to review what your users have been doing, who's accountable, and pin-point events at specific times. Role watchdog module helps you track down scenarios where a user gave themselves extra access through a role change, then removed the role later - it's logged.

All this configuration and the modules to go with it are maintained by people who have studied advanced security issues, who work for companies who pursue security-conscious customers, and have proven over several years to contribute back to the Drupal security co-op.

It's my opinion that starting with Guardr and using the modules therein, sway the balance of Drupal towards being more secure without burdening administrators and users with excess annoyances and overhead. It gives you tools for maintaining uptime, auditing for accountability, injecting countermeasures for attacks, and enforcing policies to make active countermeasures less necessary.

Post categories

Drupal