Last updated 17 February 2014. Created on 9 April 2010.
Edited by cloudrider9@gmail.com, Nikdhil Mdohfan, Garrett Albright, shamio. Log in to edit this page.

Many times, new users with an incomplete idea of "security" ask:

  1. How can I hide from the visitor that the site is using Drupal?
  2. How can I hide from the visitor what kind of modules/themes are used for this web site?

The short answer is :

You can't. Do not try.

  • Automated attacks (by far the most common attacks) do not even inspect the server before trying their exploits.
    Inspecting the logs of any high-profile site will show thousands of fruitless requests for /AspBB/db/betaboard.mdb, _private/cmd.asp, /scripts/../../winnt/system32/cmd.exe, /wp-login/, /administrator/components/com_wmtgallery/admin.wmtgal, /cgi-bin/ip.cgi… and any number of attempts at historical exploits on any unrelated system.
    Attacks on exploits happen even if the exploits do not exist on your OS or CMS. Whatever you do to mis-identify your site will be ignored anyway by amateur hackers.
  • Whatever you think you can hide, there are other clues for any system.
    Simply removing the some of all strings that contain "Drupal" does not disguise your site to any reasonable snooper. There are dozens of ways that can be used to guess what is serving your pages, even dedicated services to tell if a site is running Drupal. Just the keywords that you recognize and think are a threat are a minor subset of the real indicators.
    Ask for index.php/?q=user. Then try to disable that response without crippling your site.
  • Security by obscurity is no security. It gives a false impression of being "safe" when you are only hiding vulnerabilities behind a smokescreen that any attacker that posed any real threat would be able to see through.
  • Although it's not entirely impossible to hack the code to the point where most traces of Drupal are hidden from the HTML source (it's open source after all), the steps required to do so would necessarily break core so badly that your hacked branch of the code would be incompatible with the real security updates that you could not patch and would genuinely be open to any real future threats identified by the security team. This is a true route to system vulnerability.
  • Most significant or useful modules have their own code "signature" that is hard to hide without significant rewrites. If you are using Views, CCK, Ad, Imagecache, jQuery, CSS aggregation, contributed themes or anything useful on your site - someone can tell. Hiding that entirely would usually require a total conversion of the theme functions - at least. Even then, obsfucation probably won't work.
  • To remove identification of many of the advanced features, like even the easy install of Google Analytics that may use Drupal Libraries to work, you must necessarily either forego those features altogether, or rewrite them in a way that does not take advantage of the Drupal infrastructure. Sometimes this is possible, but in all cases it is counter-productive.

Statements on this page may come up against certain deeply-held convictions. Handbook pages are not for discussion threads, so please take debate to the forums with the Security Team and existing Sysadmins, after reviewing a few previous statements on the negligible value of obsfucation by luminaries like greggles, dopry, Morbus Iff, webchick, dww, Gábor Hojtsy , catch, sepeck, VM, etc

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

Diegen’s picture

What I would like to know is even though it should not be done.. how does on hide most of the module files as they have done ? To me this is not so much actually hiding anything but rather having cleaner code.

http://www.look.co.uk/

http://london.gov.uk/

and even smaller sites like >

http://kofiannanfoundation.org/

http://transasialawyers.com/

dman’s picture

Sounds like you are asking about css aggregation which is used to serve just one css file instead of two dozen small ones from individual module directories.
Enabling css compression on a live site is good, and highly recommended, and does produce a terser HTML header.

Diegen’s picture

Hi Dan,

are you referring to Css compression under the performance tab ? I have tried this and it works great, similarly I have tried the Style stripper module which appears to do the same. Which would be the better option? Using boost or the standard drupal performance would allow me to not use another module which is probably better ?

freescholar’s picture

This module really helps on the top layer:
https://drupal.org/project/rename_admin_paths

Give a Drupal

nithinkolekar’s picture

Short ans: simply not possible.

Whether you rename the admin path, created symlink or any other method, one can easily identify by viewing html source and look for keywords like page-node , not-front , page, views , views-field,,views-row-first, views-field-title etc.