Tips for Site Builders on configuring and setting up their Drupal 7 sites to be safer and less-hackable.

1. Securing Drupal 7:
Don’t get Hacked or
Spammed to death!
Adelle Frank
Friday, February 15, 2013
GT Drupal Users Group

2. Who is the presentation for?
• Site builders
• NOT Server admins
• NOT module/theme coders.
– For secure coding tips, see:
http://drupal.org/writing-secure-code
2

3. Places that need securing in Drupal
1. YOUR Code
2. Drupal Core
3. Drupal Contrib(uted) Themes/Modules
4. External Libraries & Code
5. Editor Support
6. Server & Monitoring
3

4. 1. YOUR Code Choices
• http://drupal.org/writing-secure-code
• Be careful if you write a module or make code
changes to a Theme!!
– Separate/Comment any changes to Code.
– Don't hack CORE!
• Don't install non-recommended modules or libraries
OR THEMES
4

5. 2. Drupal Core: Updating
• Update manager (module ON & configured for
security emails admin/reports/updates/settings)
• Apply every security patch after backing up
EVERYTHING
– module updates are EASY in Drupal 7
– Installatron makes CORE updates easier (but MUST
backup .htaccess and robots.txt).
http://drupal.gatech.edu/wiki/importing-existing-site-insta
• http://drupal.org/project/security_review (module)
5

6. 2. Drupal Core: Some module settings
• PHP filter (module OFF)
• Tracker (module OFF, unless have LOTS of users
or sensitive data)
• Comments (module OFF, unless have use case,
and will require protective measures)
• Error message display (NONE/OFF)
admin/config/development/logging, but keep ALL.
• File system (admin/config/media/file-system):
private?
• Database logging (module ON, instead of Syslog)
6

7. 2. Drupal Core: User accounts
• admin/config/people/accounts & admin/people
• Disable User #1 (& masquerade) in Drupal 7 b/c not
needed, give self "administer software updates”
• Choose: "Disable the account and keep its content.”
b/c deleting users who have created content can
lead to access bypass
• Only Admins can register accounts.
• OFF: Enable personal contact form by default
• OFF: Enable signatures (b/c applies to ALL)
• OFF: Enable user pictures (b/c applies to ALL)
7

8. 2. Drupal Core: Permissions
• admin/people/permissions
• Only give ANONYMOUS & AUTHENTICATED
“View published content”, add more if NEEDED.
• Only Developer/SuperAdmin gets "Administer...”
• (Possible) Exception. Might give EDITORS
"Administer” for: Blocks, Comments, Menus.
• Contrib Modules for fine grained permissions:
– override node options,
– role delegation or role assign
– field permissions, etc.
8

9. 2. Drupal Core: Filters
• http://drupal.org/node/224921
• Filter (module ON) = Text input formats
• Do NOT allow these tags: SCRIPT, IMG, IFRAME,
EMBED, OBJECT, INPUT, LINK, STYLE, META,
FRAMESET, DIV, SPAN, BASE, TABLE, TR, TD
• ORDER of Filters (plain text for ALL at TOP)
• Filter Permissions (limit ANONYMOUS &
AUTHENTICATED to plain, give EDITOR basic)
– More filters details in Contrib. modules
9

10. 3. Contrib Modules & Themes
• Disable or un-install modules you are not using (UI
& Devel modules, like Masquerade). Regularly audit
sites for unused modules.
• Criteria for evaluating contrib (Erik Webb):
– supported version(s)
– maintainer reputation
– total usage
– number of open issues
– usage change over time
• Criteria 2: allows PHP execution? Some modules
that do are: Devel; CCK fields; Views; Webform
10

11. 3. Contrib: CAS and Captcha/Spamicide
• For GTaccount holders, CAS module (requiring GT
Logins for certain pages/forms) will usually be
sufficient to protect individual content types/forms
– admin/config/people/cas
– Redirection > Specific pages
• If ANONYMOUS users can Add content or can
Login, MUST HAVE Captcha + Spamicide
• Helpful Tool: StopSpamForum.com (esp if you
Block IPs in your Drupal site).
11

12. 3. Contrib: Editor & More Filters
• Because user content is dangerous, pay attention
to settings for editing and file uploading modules.
• Who can use IMCE to add files/images & which file
extensions are allowed? (profile)
• Who can use LinkIt to make a Link? (profile)
• Use WYSIWYG Filter to strip out unwanted code
• Limit buttons on CKEditor Toolbar
• Use Plain Text for ANONYMOUS users and on
most TextArea Fields.
12

13. 3. Contrib: Field permissions & privacy
• Create unique names for every field that holds
remotely-sensitive info. Why? Because permissions
are by FIELD NAME regardless of content type
– Example: field_user_address, if used on 2 different
forms, has the SAME permissions on both forms.
• Tip: Use bundle_copy module to make a generic
Content Type with pre-set fields & display settings
that are easy to alter & copy.
13

14. 3. Contrib: Fields, cont.
• Types of data NOT to store and NOT to share:
– FERPA student data not in directory (directory =
name, email, field/dept)
– HIPAA health-related
– Identity theft-prone (SSN, Birthdate, etc.)
• Types of permissions for fields and content types:
– create
– edit OWN; view OWN (might be safe)
– edit ANY; view ANY (editors or admins only)
– delete OWN; delete ANY (be careful, admins only)
14

15. 3. Contrib: Webform
• http://drupal.org/project/webform
• NOT good at fine-grained permissions
• Can have PHP execution vulnerabilities
• You have MUCH better better access control &
reporting options (Views), if you use Content Types,
instead.
• Content types are Safer, but harder to delegate to
editors for set up.
15

16. 3. Contrib: Views
• http://drupal.org/project/views
• Very popular, will be Core in Drupal 8.
• Allows you to report out on data in LOTs of ways
• Must take care with PERMISSIONS, esp by Role,
for each View, esp if any data is private or sensitive.
• Be careful not to allow PHP in arguments, unless
necessary.
16

17. 3. Contrib: Pathauto & Auto Label
• http://drupal.org/project/auto_entitylabel
– If hide Title field and auto create the Title, don't give
away private info in that Title.
• http://drupal.org/project/pathauto
– [user:name] not good default path for user URLs (will
show gtaccount)
– Do your content type auto aliases reveal too much
about content?
17

18. 4. External Libraries & Code
• HOW Can we: ?
– Regularly check libraries for security notices
(CKeditor, phpCAS, jquery.cycle, etc.).
– Audit 3rd party code for security holes (such as
superglobals like $_GET)
– Audit libraries’ example code or other 4th party
included packages.
– Discover unneeded code to remove from libraries
(and, of course, notate in README.txt file)
18

19. 5. Editor Support
• Training, especially security implications of:
– forms
– comments
– file types
– tag choices in HTML
• Regular audits of content + users
– every semester
– less files/revisions/people to look over if hacked
– less chance of un-used file/account being co-opted
19

20. 6. Server & Monitoring
• Not a good use of time = hide clues that a site runs
on Drupal (http://drupal.org/node/766404)
• Robots.txt (only works on good search engines)
• .htaccess (can limit to on-campus or VPN access,
Drupal already hides directories)
– RewriteCond %{REMOTE_ADDR} !^130.207.
– RewriteCond %{REMOTE_ADDR} !^128.61.
– RewriteCond %{REMOTE_ADDR} !^143.215.
– RewriteCond %{REMOTE_ADDR} !^192.93.8.
– RewriteRule ^.* http://site.gatech.edu/message.html
[R=301,L]
20

21. 6. Server & Monitoring, cont.
• HTTPS, instead of HTTP
• Securing file permissions and ownership
(settings.php, etc., http://drupal.org/node/244924)
• Regular BACKUPS (and diffs for comparison)
• Avoid installing multiple softwares on same server
(i.e. Wordpress AND Drupal)
• Avoid storing ANYTHING other than the Drupal
install in the web ROOT (httpdocs).
21

22. References
• http://drupal.org/security/secure-configuration
• List of security-related contrib modules:
http://drupal.org/node/382752
• http://www.slideshare.net/meghsweet/badcamp-
2012-drupal-support
• http://www.slideshare.net/erikwebb/performance-
for-site-builders
• http://drupalscout.com/knowledge-base/dangers-
3rd-party-libraries-drupal-sites
22