Your SlideShare is downloading. ×
Securing Drupal 7: Do not get Hacked or Spammed to death!
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Securing Drupal 7: Do not get Hacked or Spammed to death!


Published on

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

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

Published in: Self Improvement
1 Like
  • I love this post and I guess that your fans are having fun to read this post along with knowledge. Keep regular sharing of your articles. Cheers!! You deserve a lot more.
    Dr Oz Forskolin
    Are you sure you want to  Yes  No
    Your message goes here
  • Free Download :
    Are you sure you want to  Yes  No
    Your message goes here
  • The            setup            in            the            video            no            longer            works.           
    And            all            other            links            in            comment            are            fake            too.           
    But            luckily,            we            found            a            working            one            here (copy paste link in browser) :  
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Securing Drupal 7:Don’t get Hacked orSpammed 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:
  • 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 & Monitoring3
  • 4. 1. YOUR Code Choices • • Be careful if you write a module or make code changes to a Theme!! – Separate/Comment any changes to Code. – Dont hack CORE! • Dont install non-recommended modules or libraries OR THEMES4
  • 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). • (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 • • 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. modules9
  • 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; Webform10
  • 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: (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 • • 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 • • 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 • – If hide Title field and auto create the Title, dont give away private info in that Title. • – [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-opted19
  • 20. 6. Server & Monitoring • Not a good use of time = hide clues that a site runs on Drupal ( • 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 ^.* [R=301,L]20
  • 21. 6. Server & Monitoring, cont. • HTTPS, instead of HTTP • Securing file permissions and ownership (settings.php, etc., • 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 • • List of security-related contrib modules: • 2012-drupal-support • for-site-builders • 3rd-party-libraries-drupal-sites22