Hiding Drupal Traits

Some users believe that hiding Drupal traits and characteristics may help prevent automated attacks on Drupal sites. This practice is controversial and has been disputed at Hide, obscure, or remove clues that a site runs on Drupal.

That being said, the following is a list of actions that you may take to attempt to conceal the fact that your site is running on Drupal:

  • Remove the CHANGELOG.txt file.
  • Remove the GENERATOR meta tag (e.g. using the Remove Generator META Tag module).
  • Hide PHP fatal errors (e.g. using the Hide PHP Fatal Error module).
  • Rename admin paths (e.g. using the Rename Admin Paths module).
  • Modify the template of your robots.txt file.
  • Disallow viewing of txt files in the core folder.
  • Modify the Drupal default Expires header.
  • Rename default Drupal strings (e.g. using the String Overrides module).
  • Rename default classes in the Drupal theme.
  • Change the default upload paths.
  • Create custom 403/404 pages.
  • Remove, rename, and/or update the update.php file.
  • Remove, rename, and/or update the cron.php file.
  • Update default images, e.g. throbber.

Handling PSA-2014-003 (Drupalgeddon)

  • Immediately upgrade to Drupal 7.32. If upgrade is not possible at this time, patch the vulnerable function in the /includes/database/database.inc file.
  • Check the integrity of files using Git status or Hacked.
  • If possible, redeploy the latest version of the code base.
  • Scan public/private files locations for *.php, *.sh, and any other suspicious file types. There are some strategies to facilitate this process. For example, if only image uploads are allowed, then you may scan for any files other than images.
  • If the web server setup is permissive in terms of permissions and users (e.g. Apache users can write anywhere), it will be necessary to perform an audit of the entire server.
  • Install the Security Review, Drupalgeddon, and Site Audit contributed modules. Execute these modules' checks.
  • If the pages are built using the Features module, revert all features to their original state. Note that this may not always be possible.
  • Rebuild the menu executing core ‘menu_rebuild()’ function.
  • Review the variable table to find any suspicious values. It may be possible to truncate the table entirely if the Features module is used and if default values of variables are acceptable.
  • Check the database for new MySQL users, update MySQL passwords, and regenerate passwords/tokens for any systems that are integrated.
  • Check users’ roles to find out if there are any unexpected users designated as admins.
  • Check menu_router and users' tables for suspicious entries, e.g. with ‘file_put_contents’ callbacks.
  • Dump the entire website HTML—e.g. using a crawler—and grep (search) for additional parameters in links.
  • If possible, analyze the sessions table, looking for logins of admin/advanced users from external IP addresses. Note their last login dates.
  • Analyze Apache Logs for POST keys with strings 'UPDATE', 'INSERT', 'DELETE', and ‘?q=node&destination=node’.
  • Check locations in Panels, Blocks, and Views where custom PHP snippets might be used, e.g. in custom access rules.
  • Set another Drupal hash salt in settings.file for passwords generation. Reset passwords of all users.
  • Check the database for new MySQL users, update MySQL passwords, and regenerate passwords/tokens for any systems that are integrated.