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

  • 8,889 views
Uploaded 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.

More in: Self Improvement
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • 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
    Your message goes here
  • Free Download : http://gg.gg/114bb
    Are you sure you want to
    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) :            www.goo.gl/yT1SNP
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
8,889
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
27
Comments
3
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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: http://drupal.org/writing-secure-code2
  • 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 • 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. – 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). 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. 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: 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, dont 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-opted19
  • 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-sites22