The document summarizes discussions from a Drupal camp meeting. It introduces the panelists and their experiences. It then summarizes questions and responses about eliminating bot registrations, detecting and preventing form spam, determining if a site has been compromised, and securing Drupal sites. The panelists provided suggestions on modules, configuration, and best practices to address these issues.

1. Notes from Western Mass Drupal Camp
January 19, 2013

2.  Seth Viebrock has worked on Justin Bieber's web site, led a team as CTO
at a start-up company, traveled to Tokyo for data center security
assessments, worked on world-class e-commerce software, provides
Drupal expertise for Estee Lauder and their many international brands,
been building web sites for clients since 1996, and started a few
businesses, including Origin Eight.
 Gary Parker is a Systems Administrator for the Office of Information
Technology and is the primary administrator for Drupal sites hosted by
OIT at the University of Massachusetts Amherst.
 Rob Higgins is a Drupal Developer currently working with Origin Eight and
MIT. He has been developing Drupal applications for 5 years and draws
his experience from building a custom newspaper publication
management system on top of Drupal as well as many smaller scale
projects.
 Cheryl Handsaker is a Technical Project Manager and Drupal Developer
supporting the work of ALM Enterprises, Origin Eight and Charlemont Web
Works. She has cajoled these smart people to serve as panelists.

3. I work on a site for a small non-profit that runs a yearly conference.
Admission to the conference is free but an accurate head-count on
registrations is helpful for planning. It is a goal of the organization that
the barriers to registration are low.
User registration requires a username and email address be provided.
Mollom is enabled and completing a CAPTCHA is required for
submission, a controversial decision given ease of use concerns. In
addition the email address provided must be verified before the user can
complete the remaining profile fields and be officially registered.
Despite these precautions, we receive 5-6 bot registrations/ day. These
have reasonable looking user names but are tied to unrelated nonsense
emails, typically from the hotmail domain but we have also seen gmail
and yahoo domains as well.
How can I eliminate bot registrations without continuing to raise the barrier
for registration from real humans?

4.  Disqus -- http://drupal.org/project/disqus -- If all you need is commenting, use
Disqus and disallow user registration altogether. Or, if you need user registration,
but the major problem is comment spam, use Disqus.
 Captcha Riddler -- http://drupal.org/project/riddler -- Create your own Captcha
riddles. In the case of a Drupal conference event, the question could be "What
does that little blue drop stand for at the top of the page? Hint: It starts with a 'd'."
 Help text: "If you reeeeally need help figuring out what the blue drop stands for,
email help@conferencename.net"
 Spambot -- http://drupal.org/project/spambot -- Spambot protects the user
registration form from spammers and spambots by verifying registration attempts
against the Stop Forum Spam (www.stopforumspam.com) online database.
 Botcha -- http://drupal.org/project/botcha -- The approach of BOTCHA is to add
various elements to forms that need protection from bots. These elements do not
present new fields to users, so BOTCHA is completely transparent to humans. Both
humans and bots submit those forms and BOTCHA performs heuristic analysis on
each submitted form. Bots are usually programs/scripts that are relatively dumb,
and most of the time they fail BOTCHA tests and human users don't. The more
there are opportunities for the bot to slip and prove it is a bot, the better defense
from spam we have. So we can combine multiple BOTCHA recipes as opposed to
only one CAPTCHA per form. This gives huge advantage to BOTCHA. To prevent
spam most effectively, you must combine and fine-tune several of the available
"recipes.”

5.  Countryban and ip2country -- If your target audience is only one or a few countries,
try http://drupal.org/project/ip2country for D6 (could be upgraded to D7), or write
something around http://drupal.org/project/ip2country to either block or give a
special registration form to users from a set of countries.
 Mollom - http://drupal.org/project/mollom -- Provides a decent captcha, and helps
analyze statistical data about the poster and the poster's content. I'd use reCaptcha
(see below) for the captcha on user registration, and have Mollom deal with content
analysis by already-registered users.
 reCaptcha - Owned by Google. Very common captcha for user registration.
http://drupal.org/project/recaptcha
 Social network auth - i.e. http://drupal.org/project/fboauth,
http://drupal.org/project/gigya -- use social login to help prevent spam.
 Drupal core - Require users to validate their email address. In worst-cases, require
admin approval of account.
 Community moderation of users - Use something like
http://drupal.org/project/rules_link or http://drupal.org/project/flag to block users
after their content has been marked as "spam" by a certain threshold of community
users. Put a flag right on the content and let your community participate in the work.

6. I work on a website for a start-up company that uses forms to
capture sales lead information. We allow anonymous users to
submit inquiries on the site through these forms. The forms
typically have 10-15 required fields, a mixture of free form text
and select boxes. We use the free version of Mollom on the
registration form and 12 general information forms on the site,
which is working very well most of the time. However, on a good
day we run into trouble.
Free Mollom has a per day limit on the number of successful
CAPTCHA completions per day. Occasionally, this limit is exceeded
and we have chosen to accept further form submissions rather
than rejecting because of the nature of the information collected
resulting in spam being delivered to our sales force.
Are there alternatives to the paid version of Mollom for detecting
and preventing form spam that do not make it more difficult for
our target customer to complete them?

7.  Many of the suggestions that Seth outlined for bot
registrations are also effective at reducing form
spam.
 Use only plain text inputs for forms. Do not allow
even filtered html. Insure that php form input is
completely disabled.
 Consider the business goal. Weigh the cost of lost
sales due to increased barriers against the cost of
reviewing and removing spam emails. Many
companies underestimate the cost of handling spam.
 If Mollom is working effectively for you, purchasing
the paid service may be the most cost effective
solution.

8. The patterns of usage on my educational website
shift rather suddenly. In particular, comments are
appearing on nodes that I didn't think had
comments enabled and there is a lot of traffic to
a file download that came over from an early site
migration. I have taken a cursory look at the
Drupal log but there are so many entries there
that only the last few hours of activity are visible.
What steps I can take to determine if my site has
been compromised?

9.  Google your own site as an anonymous user.
Often this is enough to replicate the behavior.
 Check the site with Google Safe Browsing, i.e.
http://www.google.com/safebrowsing/diagnosti
c?site=drupal.org
 Check authentication, especially for powerful
users. Look for evidence of privilege escalation.
 If you have access, review the system logs. All
activity should be logged there.
 Network utilization, unexpected spikes in
memory or cpu usage.

10.  Check the file structure for new or modified
files.
 Use version control to compare to those
deployed.
 Review source code of any changed files
looking for modifications, especially the
introduction of iframes and metadata.

11.  Secure pages module
http://drupal.org/project/securepages and secure
pages hijack prevention (D6)
http://drupal.org/project/securepages_prevent_hijac
k modules. By default, Drupal doesn't force user
authentication over SSL so user names and passwords
could be sent in plain text.
 LDAP integration
 http://newrelic.com/
 Use code repository for all site deployment
 Nagios for Drupal http://drupal.org/project/nagios
 Set password policies:
http://drupal.org/project/password_policy

12.  Cloudflare: http://drupal.org/project/cloudflare reverse
proxy, firewall and CDN
 Securing your site: http://drupal.org/security/secure-
configuration
 Production Checklist:
http://drupal.org/project/prod_check
 Be sure to remove modules used in development on
production (i.e. devel, backup & migrate, views UI).
 Hacked module: http://drupal.org/project/hacked
 Having site code owned by root is OK. If root is
compromised your problems go beyond your website.
 Code review modules
◦ Coder http://drupal.org/project/coder
◦ Secure code review: http://drupal.org/project/secure_code_review

13.  Vulnerability Scanning services (free & paid)
◦ Acquia Insight
◦ Droptor.com
◦ Hackertarget.com/drupal-security-scan/
◦ http://drupalscout.com/
◦ Your staff – ask them to try to hack into your site for a bonus and
much internal glory.
 Ben Jeavons from Acquia at NYC Camp 2012 :
http://archive.org/details/HackIntoDrupalSitesorHowToSe
cureYourDrupalSite
 http://drupal.org/security-team
 Captcha ideas
◦ MINTeye: Identified as not very strong captcha
◦ Use of Esperanto characters and works for catpcha
 Books & Presentations
◦ http://crackingdrupal.com/

14.  Choosing secure Drupal modules
◦ Look at the issue queue – not too many open issues
and no issues with any kind of unaddressed
security vulnerability
◦ Lots of downloads – others are using it widely
◦ Scan the module code for undiscovered
vulnerabilities
◦ Actively maintained
◦ Get involved – report issues you do uncover and
work with developers to resolve these issues.

15.  Seth, Gary and Rob!!
 Eric Peterson who volunteered to be
empanelled at the last minute and supported
the conversation with knowledge and good
humor!
 To the participants. Good suggestions, good
questions, great conversation.
 To the Drupal community for your work and
wisdom and most especially for sharing both.