How can I obscure what I am using to run my site?

Question

Is there anything I can do to prevent somebody from knowing my site is using Drupal by looking at the source code of the front page? I am referring to people who scan sites using software that detects the software used to run the website to be able to attack it using any known weak point.

If it is not possible to completely hide the fact that the site is using Drupal, is it at least possible to confuse them (e.g., by aliasing the node pages with URLs like http://example.com/servlets/<node-id>.jsp)?

Answer 1

This is an old and already answered question, but I recently put some effort into writing up a description of all the things you would need to change:

• Remove the meta generator for Drupal 7
• Remove tell-tale-text like CHANGELOG.txt
• Check the Expires header
• Walking directories for HTTP 200/404/403 status codes
• Look for default text messages - tweak all user-facing messages
• Look at the HTML - default html from core and modules is a telltale sign

Basically: it might technically be possible to hide the fact that your site runs Drupal, but you would spend so much time on it that it's not worth it. You should instead focus on making it secure and on secure operations (e.g. the ability to deploy updates quickly, monitoring logs, etc.).

Answer 2

You can't hide it completely. Most of what's needed to do it, would require hacking core. The biggest tell, is the Drupal JavaScript variable which is readable from the front page, or any page for that matter.

If you want to improve your sites security by hiding that it's a Drupal site, your effort is better spent on code reviews than it is on trying to hide the fact that the site is made with Drupal.

Answer 3

It's too easy to do, kiam!

• Use a reverse proxy or customize your http daemon to filter the annoying Drupal http header
• Deny http access to any Drupal default folders
• Use PHP output buffering to rewrite and obscure your HTML source, remove unnecessary data
• Use url alias or custom_url_rewrite_in/outbound to make your URLs a mess
• Change the default 404 error, remove/change update.php
• Make any other changes if someone finds out

And last but not least, make sure that your site is so simple that does not require JS or CSS for normal behaviors (don't use Views or Ctools...), does not support user authentication, etc. that means your site should be as simple as a static html site.

Ok, all that to make people believe that your site does not run Drupal. Anyway, security by obscurity is useless.

Answer 4

There is an official article and discussion regarding the same.

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 Is that site 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 forgo 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.

You may be interested in reading Securing your site too.

Remember Never hack core

Answer 5

There is no point in hiding that your site runs Drupal. It is the wrong way to look at developing websites. What you should be focusing on is security. Make sure you implement all securities measures and everything will be fine. There is not one reason in the world to hide that you are using a certain cms or other piece of software. With FF addons like Wappalyzer, you can tell in an instant if a site uses Drupal, so the question is pretty moot.

Answer 6

An extra thing you may do is using also the File Aliases module to change the default file structure.

The File Aliases module allows you to use token customisable aliases for your uploaded files, giving you the ability to keep your file system organised as per usual while providing clean looking paths (i.e., no more /sites/default/files/).

Answer 7

I agree with other people that you can't hide it entirely. If you look at the HTML source, you will notice that many times CSS and JavaScript files haven't been aggregated. CSS and JavaScript aggregation should be enabled.

Answer 8

In that past I've swapped my fonts for the typical Ruby project fonts like Lucida Sans, also increasing input sizes like all the hip kids do.

Another give away is the "throbber" graphic for autocomplete fields. It also doesn't work when you increase the input size. Here's one you can steal: http://beta.seattlebedandbreakfast.com/misc/throbber.gif