Securing the Stack: Hardening Your Drupal Deployment

Running a blog or CMS-based web site is a big responsibility. For an organization, a single poorly secured web site can be the foothold an attacker needs to breach a network. If you run a small business, you could be putting your clients in danger. The challenges to add security to these deployments can often be confusing when trying to figure out what to secure and how to do it.

This talk will go over a number of security enhancements that most administrators can make in minutes that collectively can add some much needed security hardening to your typical Drupal deployment. Mark will provide insights into why certain steps are needed and the realities of not following the guidance being given from someone who has not only had to secure web sites for years, but also break into them for his job. If you run Drupal and care about keeping your clients or organization secure, you'll want to catch this talk!

Transcript

1. Securing The Stack Hardening Your Drupal Deployment Mark Stanislav <mstanislav@duosecurity.com>
2. Content Management Systems Matter A LOT •About 1 in 3 web sites utilize some sort of CMS backend •For many organizations, a web site is one of the few portions of infrastructure being exposed to the Internet •Between users, plugins, themes, and visitor interaction, CMS sites have many potential areas where security can fail •How can we add layered security within the various levels of a typical Drupal deployment stack to give the site a fighting chance? http://w3techs.com/technologies/history_overview/content_management/all
3. The Typical “It Won’t Happen To Me” Statements 1.“My site is hosted by a third-party/outside my firewall, so I’m safe.” 2.“My site is scanned daily and has been shown to be hacker-proof.” 3.“There’s nothing of importance on that server/web site.” 4.“I patch all of my plugins and updated Drupal daily, so I am safe.” 5.“No one is going to waste time trying to break into my company.”
4. “My Site Is Hosted By A Third-party/Inside Of A DMZ, So I’m Safe.” Having your web server at a third-party hosting facility or in a DMZ is a positive step. Segmentation of resources helps to limit a compromise in many cases... BUT, if an attacker can compromise your company’s server they will be able to steal password hashes, edit config files, capture password changes, send malware to visitors, trojan your downloads, and then attack you.
5. “My Site Is Scanned Daily And Has Been Shown To Be Hacker-proof.”
6. “There’s Nothing Of Importance On That Server/Web Site.” Your view of “importance” and an attacker’s view are often quite di erent. An attacker can use any server for... •Sending spam out •Denial of Service (DoS) attacks •Piracy hosting/downloading •Launching attacks against other servers •Host malware to infect your site’s visitors
7. “I Patch All Of My Plugins And Update Drupal Daily, So I Am Safe.” That is honestly a great start and really critical to have a chance at surviving this cesspool we call the Internet. However, plugin authors don’t always: •Patch vulnerabilities as soon as possible •Maintain their software consistently •Respond to security researchers in a timely manner •Necessarily even care when there is a problem...
8. “No One Is Going To Waste Time Trying To Break Into My Company.” Attackers in most cases have no clue who they are even attacking unless it’s been highly targeted. By using Google, SHODAN, or a network scanner, attackers will look for people who are vulnerable and figure out what they can get out of you later on. The fact you’re vulnerable makes you an important site.
9. Where Can We Add Security? Core OS/Services Web Server Development Platform Web Application •Operating System Patching •Mandatory Access Controls •Network Filtering/Firewall •Strong Authentication •Reduce module attack surface •Prevent excessive information leakage •Proper SSL/TLS configuration deployed •Adequate logging and retainment •Limit module usage and patch regularly •Prevent log disclosure and information leakage •Add privilege separation and reduce attack surface •Mitigate risks for backend attacks, e.g. SQL injection •Keep all modules, themes, and core patched •Enable XSS/CSRF/click-jacking mitigations •Add strong authentication, enforce good passwords •Interrogate tra c to server and CMS configuration
10. Core OS/Services: Overview •Ensure that your hosting company, Managed Services Provider, or internal team are keeping your OS patched in a timely manner •Mandatory Access Controls (App Armor, SELinux) creates policies around services that will limit the ability for attackers to elevate their privilege if your web site does get compromised •Only expose network services that need to be exposed. This goes for internally and externally. Also, separate services across multiple servers if it’s reasonable for your architecture. •Utilize two-factor authentication for SSH/VPN or any other remote access into the server its self. Stolen credentials are a HUGE issue.
11. Patches For One And All Core OS/Kernel: Please do this. Please ACTUALLY do this. :) Languages: Don’t forget about your programming languages! Critical issues that can negatively a ect your entire application’s security are often tied to the underlying interpreter/runtime. Libraries: CPAN? Gems? PEAR? Don’t forget to check for updates to libraries used in your languages that may be system-installed and not shipped with your application. Firmware: It may seem unlikely but issues do pop-up for things like IPMI where backdoors or code issues can exist in outdated versions.
12. Mandatory Access Controls Discretionary Access Controls (DAC) The owner of an object is able to specify who (subjects) are able to access the object. It is up to their discretion. UNIX file permissions (rwx) is a good example of this. Mandatory Access Controls (MAC) The system on which an object exists determines the access subjects have to an object, without regard for who necessarily owns the object. SELinux and App Armor are examples of this. MAC always supersedes DAC if both are utilized on a system.
13. Network Filtering/Firewall Allow/deny tra c based on a country’s IP allocations (GeoIP) http://www.wipmania.com/en/blog/geoip-for-iptables/ Determine network allowances based on a user/group http://linuxpoison.blogspot.com/2010/11/how-to-limit-network-access-by-user.html Cheap-and-easy packet load balancing http://glossopgeek.wordpress.com/2012/10/31/load-balancing-by-iptables/ Throttle brute force attacks against a service (like SSH) http://www.rackaid.com/resources/how-to-block-ssh-brute-force-attacks/ Filtering based on the time and/or calendar constraints http://www.cyberciti.biz/tips/iptables-for-restricting-access-by-time-of-day.html
14. Duo verifies users after their regular login Strong Authentication Duo Push Passcodes SMS Phone call Tokens Using any phone, mobile device, or standard token 1 2 3
15. Web Server: Overview •Reduce the attack surface of your web server by disabling modules providing functionality not needed by your application stack •Prevent information about your deployment from being seen by an attacker during reconnaissance. Security through obscurity is not a bad thing when coupled with actual security! •Transport security means a lot to your end-users, don’t forget to ensure your SSL/TLS configuration is adequately setup. •Log a lot. Keep logs o -site if possible and don’t trust on-box logs!
16. Modules You Don’t Need Are Bad Modules There is not a one-size-fits-all list of modules to disable because each web application may require di erent functionality. Comment out other modules, restart the web server, test your application and enable modules until things work properly! :) These are required for Apache: core, mod_authz_host, mod_auth_basic, mod_authn_file, mod_dir, mod_log_config, mod_mime
17. Reduce Information Disclosure When the latest exploit comes out or a worm is started, many attacks will be based on information that an attacker can glean from the banners of services that you run. Hiding your version may only delay an attacker but sometimes that’s all the head-start you need to protect yourself! •Apache set ServerTokens to Prod •nginx set server_tokens to o •lighttpd set server.tag to lighttpd
18. Transport Security That’s Done Right Utilizing SSL/TLS is more than just creating a self-signed certificate and flipping the switch. If you have many hosts that need a certificate, get the wildcard and save money/time in the long-run. First, read the “SSL/TLS Deployment Best Practices” https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.2.pdf Second, test your site against the “SSL Server Test” https://www.ssllabs.com/ssltest/index.html Third, read what it says you’re doing wrong, fix it, and test again!
19. Logging •The logs that are located on a breached server have low integrity. IP addresses could be changed, logs could be deleted, and important details could be edited. •Don’t just log 200 responses, log errors and debug information, too! Centralize your logs and have a plan to actually review them! •rsyslog supports TLS-enabled, TCP transported logs: http://opensysblog.directorioc.net/2013/02/configuring-rsyslog-to-encrypt-syslog.html •Elasticsearch + Logtash + Kibana let’s you get data visibility! http://kufli.blogspot.com/2013/07/log-analysis-using-logstash.html
20. Development Platform: Overview •Similar to the OS/web server, programming language modules/ libraries that aren’t needed should be removed (or patched ASAP) •Also as before, needless information exposure should be limited as much as possible to prevent attacker/worm reconnaissance •Add privilege separation where applicable such as limited- permission users for backend services like MySQL or similar •Integrate backend security mechanisms such as an SQL proxy to help prevent application security flaws from being weaponized
21. Clean-House On Modules And Libraries •Open-source is awesome but many pieces of contributed code can become unmaintained which means there won’t be a patch if a vulnerability is found. •Don’t forget about an enabled library that you no longer need! •If an extension isn’t needed for PHP, in example, don’t enable it. If you do use a given extension, be sure it’s not unmaintained before enabling it and check-up on it every few months. •Today’s awesome module everyone uses could be completely vulnerable and unmaintained tomorrow. Be vigilant!
22. Restrict PHP Information Disclosure Don’t let attackers see debugging/runtime information •Hide PHP details by setting expose_php to o •Set display_errors and display_startup_errors to o Protect information that could lead to a session compromise •Set session.cookie_httponly to 1 to mitigate cookie stealing via XSS •Set session.cookie_secure to 1 so that cookies only go over SSL
23. Privilege Separation •Giving your application stack too much privilege can lead to a bigger compromise than needed if a vulnerability exists •Don’t utilize the root MySQL user for your web application and create a unique account for each web application •Don’t let your database live on all network interfaces and don’t enable the MySQL root user to have no password or a weak one •Execute commands as an unprivileged user and not root if possible •Leverage PHP in CGI mode if possible to compartmentalize users
24. Backend Security •GreenSQL is a SQL proxy that will sit between your web application and you database server, monitoring requests that may be SQL injection or other attacks. •Check out Mod Security, a free web application firewall http://broadcast.oreilly.com/2010/11/getting-drupal-and-mod-securit.html •Lockdown a user by utilizing DAC/MAC to prevent excessive privilege that could lead to greater exploitation of a system •If you’re using MySQL with multiple servers, utilize SSL (it’s built-in) across your backplane. Don’t trust that nobody will ever get to it...
25. Web Application: Overview •Themes, plugins, and core CMS files need to be updated as soon as possible -- ideally after you QA the updates in development •Utilize any available (and reasonable) features to mitigate attacks such as HSTS, XSS mitigations, CSRF attacks, and click-jacking •Utilize two-factor authentication for all administrative-related accounts in your application and enforce strong passwords across all accounts •Don’t just ignore what tra c your site is responding to be on guard and watch for potential signs of an attacker; pro-activeness counts!
26. Patches For One And All, Web Edition! •You may not be surprised, but themes and plugins are the downfall of most CMS deployments •Be very selective of which contributed themes & plugins you utilize •Have code reviewed (by your team or outside experts) if possible •Don’t just disable a theme/plugin, the code sitting there can actually still be potentially utilized in an attack •Remember, if you’re breached and using free/open-source code, there’s nobody to actually blame but yourself -- it sucks! ;)
27. Proactive Security Enhancements Check out Security Kit for Drupal which provides mitigation from: •Cross-Site Scripting (XSS) •Cross-Site Request Forgery (CSRF) •Clickjacking •MITM attacks (via HTTP Strict Transport Security [HSTS]) Check out https://drupal.org/project/seckit for details!
28. Two-Factor Authentication: Not Just For SSH! Supported for Drupal, WordPress, Expression Engine, and more! https://drupal.org/project/duo
29. Don’t Be The Last To Know About An Issue... •The module Tiny-IDS provides alerts for potential attacks against your Drupal site such as XSS, SQL injection, and code execution. https://drupal.org/project/tinyids •To make sure you’ve setup Drupal securely out of the box, test your site with Security Review to check for configuration issues that could lead to weakened security. https://drupal.org/project/security_review
30. Phew... Security Is Tiring! •There’s a lot here but most importantly, start to think about what you are doing for security and whether or not it’s enough for how important your site/server/network/data is to you •Layering security is hugely important so don’t think your firewall or security module or patching will solve problems by themselves •Don’t underestimate your worth to an attacker and don’t expect them to only attack things you think are sensitive https://drupal.org/security https://drupal.org/security/contrib Don’t forget to follow... https://drupal.org/security/psa
31. THANK YOU! QUESTIONS? •mstanislav@duosecurity.com •@markstanislav •uncompiled.com