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.

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

No notes for slide

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

  1. 1. Securing Drupal 7:Don’t get Hacked orSpammed to death! Adelle Frank Friday, February 15, 2013 GT Drupal Users Group
  2. 2. Who is the presentation for? • Site builders • NOT Server admins • NOT module/theme coders. – For secure coding tips, see:
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. References • • List of security-related contrib modules: • 2012-drupal-support • for-site-builders • 3rd-party-libraries-drupal-sites22