Hide, obscure, or remove clues that a site runs on Drupal

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}