Hiding the fact that your site runs Drupal

Hiding the fact that your site runs Drupal

Difficulty: 
Piece of Cake

Things like Drupagedon exist. This was an SQL Injection issue publicly disclosed at the end of 2014 that affected virtually every Drupal site.  Just as a side note the issue did not affect users running Drupal with SQL Server, the security issue was spotted by one of the SQL Server maintainers 12 months before it as publicly disclosed here and both the SQL Server Driver and the MS SQL PDO driver prevented the SQL Injection from happening.

When such things happen you want to make it difficult for bots to tell if you are a vulnerable target (you also want your site not to have been previously indexed as using Drupal).

In the attached article (by Acquia and worth reading due to the level of detail) they highly discourage hiding that you run Drupal due to the level of effort required to do so. The in-depth obfuscation they propose is quite a nightmare:

  • Remove the meta generator (X-Generator header) by implementing a hook in PHP.
  • Remove Drupal specific text files such as COPYRIGHT.txt, MAINTAINERS.txt, etc..
  • Make your CSS and JS files differ from the original by using the Advanced Aggragation module, or by completely rewriting them by hand.
  • Change the default Drupal expire headder by implementing a hook in PHP.
  • Move regular admin urls (/user/*, /admin/*) to a new location using the Rename Admin Paths module.
  • Change all default text messages using localization or the String Overrides module.
  • Change all Drupal templates so that they differ from their originals as much as possible.

The truth is that no matter the level of effort, hiding the fact that you are running Drupal will technically not make your site more secure. The post Silly Security Scans drops some interesting thoughts, and specially this quote:

[...] if you think that hiding the server version actually *improves* security, then think again. Security through obscurity does not work. When doing security analysis, you always assume that the adversary has infinite time, resources, and resiliency, so even if you hide it, they will find it.

Now, what if you can implement some of the described above without changing your application's source code and by just adding a few lines to your web server's configuration?

Rewriting response headers

Using the IIS URL Rewrite module (that you must install in order to run Drupal on IIS) we are going to turn this:

Expires: Sun, 19 Nov 1978 05:00:00 GMT
Server: Microsoft-IIS/8.5
X-Powered-By: PHP/5.6.6
X-Generator: Drupal 7 (http://drupal.org)

into this:

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Server: Apache
X-Powered-By: PHP/5.3.28
X-Generator: Mono

by simply dropping these lines into your web.config

    <rule name="RESPONSE_X-POWERED-BY">
         <match serverVariable="RESPONSE_X-POWERED-BY" pattern=".*" />
         <action type="Rewrite" value="PHP/5.3.28" />
    </rule>
    <rule name="RESPONSE_SERVER">
        <match serverVariable="RESPONSE_SERVER" pattern=".*" />
        <action type="Rewrite" value="Apache" />
    </rule>
    <rule name="RESPONSE_X-GENERATOR">
        <match serverVariable="RESPONSE_X-GENERATOR" pattern=".*" />
         <action type="Rewrite" value="Mono" />
    </rule>
    <rule name="RESPONSE_EXPIRES">
        <match serverVariable="RESPONSE_EXPIRES" pattern="Sun, 19 Nov 1978 05:00:00 GMT" />
        <action type="Rewrite" value="Thu, 19 Nov 1981 08:52:00 GMT" />
    </rule>

Was that easy? You can also modify these settings at a server level and get them enforced for every single application in it.

Hiding Files

You can use the web.config to deny access to specific paths such as:

<location path="README.txt"><system.web><authorization><deny users="*"/></authorization></system.web></location>
<location path="COPYRIGHT.txt"><system.web><authorization><deny users="*"/></authorization></system.web></location>
<!--And so on...-->

The full featured solution

IIS is extremely pluggable and extendable. Our customers get a custom developed HTTP Module that plugs in at the server level and takes care of:

  • Ensuring your HTTP headers disclose no relevant information.
  • Remove Drupal specific text files such as COPYRIGHT.txt, MAINTAINERS.txt, etc..
  • Obfuscate and rename regular Drupal paths.
  • On the fly CSS and JS minification and obfuscation.

All these changes are done without having to touch your PHP code or deployment settings. Just download the compiled DLL file and add the HTTP module to your web.config.

Comments

With AdvAgg you can change the default directory that the css/js files are saved to by using hook_advagg_get_root_files_dir_alter(array $css_paths, array $js_paths);

I can't understand why should you hide the think you are running yor staff on drupal cms if we have such great examples of sites on drupal as White house, BBC and so on?
Anyway, thank you for the post, w ho knows, it might be helpful one day :)

Thanks.. Important points made here but I have noticed that a popular tool used to find out what framework a site is using looks for the JS object window.Drupal .. If it finds it, then it must be Drupal running on the back-end. Any idea how to rename that window.Drupal object, thank you.

Add new comment

By: david_garcia Sunday, March 15, 2015 - 00:00