Question

Est-ce que je peux faire pour empêcher quelqu'un de connaître mon site utilise Drupal en regardant le code source de la page d'accueil? Je fais référence aux gens qui les sites d'analyse en utilisant un logiciel qui détecte le logiciel utilisé pour faire fonctionner le site Web pour pouvoir l'attaquer en utilisant tout point faible connu.

S'il est impossible de cacher complètement le fait que le site utilise Drupal, est au moins possible de les confondre (par exemple, par aliasing les pages de noeuds avec des URL comme http://example.com/servlets/<node-id>.jsp)?

Était-ce utile?

La solution

Ceci est un vieux et déjà répondu à la question, mais je l'ai mis récemment un certain effort en écrivant une description de tous les choses que vous avez besoin de changer:

  • Retirez le générateur de méta pour Drupal 7
  • Retirez-conte tell texte comme CHANGELOG.txt
  • Vérifiez l'en-tête Expires
  • répertoires de marche pour HTTP 200/404/403 codes d'état
  • Rechercher les messages texte par défaut - modifier tous les messages faisant face à l'utilisateur
  • Regardez le HTML - HTML par défaut du noyau et des modules est un signe révélateur

En gros: il pourrait être techniquement possible de cacher le fait que votre site fonctionne Drupal, mais vous passer beaucoup de temps à ce que ce n'est pas la peine. Vous devriez plutôt se concentrer sur sa sécurisation et sur les opérations sécurisées (par exemple la possibilité de déployer des mises à jour rapidement, les journaux de surveillance, etc.).

Autres conseils

Vous ne pouvez pas le cacher complètement. La plupart de ce qui est nécessaire pour le faire, aurait besoin de base de piratage. Le plus grand tell, est la variable Drupal JavaScript qui est lisible à partir de la page d'accueil ou une page pour cette question.

Si vous voulez améliorer votre sécurité sites en se cachant que c'est un site Drupal, votre effort est mieux dépensé sur des revues de code qu'il est à essayer de cacher le fait que le site est réalisé avec Drupal.

Il est trop facile à faire, kiam!

  • Utilisez un proxy inverse ou de personnaliser votre http démon pour filtrer l'ennuyeux Drupal http tête
  • Refuser http accès à tous les dossiers par défaut Drupal
  • Utiliser tampon de sortie PHP pour réécrire et obscurcir votre source HTML, supprimer les données inutiles
  • Utiliser un alias d'URL ou custom_url_rewrite_in / sortant pour faire vos URL un gâchis
  • Modifier l'erreur 404 par défaut, supprimer / changement update.php
  • Assurez-vous d'autres modifications si quelqu'un découvre

Et last but not least, assurez-vous que votre site est si simple qui ne nécessite pas JS ou CSS pour des comportements normaux (ne pas utiliser les vues ou ctools ...), ne l'authentification utilisateur prend pas en charge, etc. que des moyens votre site doit être aussi simple que d'un site html statique.

Ok, tout ça pour faire croire que votre site ne fonctionne pas Drupal. Quoi qu'il en soit, la sécurité par l'obscurité est inutile.

Il y a un article et une discussion officielle concernant même .

  

Vous ne pouvez pas. Ne pas essayer

  • attaques automatiques (de loin   les attaques les plus courantes) n'inspectent même pas le serveur avant   essayer leurs exploits .
    les journaux de Contrôle tout   site de haut profil affichera des milliers de demandes infructueuses pour   /AspBB/db/betaboard.mdb _private/cmd.asp   /scripts/../../winnt/system32/cmd.exe   /wp-login/   /administrator/components/com_wmtgallery/admin.wmtgal,   /cgi-bin/ip.cgi ... et un certain nombre de tentatives de   exploits historiques sur tout système sans rapport.
    Attaques sur   les exploits se passent, même si les exploits n'existent pas sur votre système d'exploitation ou   CMS. Quoi que vous fassiez mal à identifier votre site sera   ignoré de toute façon par les pirates amateurs.
  • Tout ce que vous   pensez que vous pouvez cacher, il y a d'autres indices pour tout système.
      Il suffit de retirer la partie de toutes les chaînes contenant « drupal » ne fonctionne pas   déguiser votre site à un fouineur raisonnable. Il existe des dizaines de façons   qui peut être utilisé pour deviner ce qui est au service de vos pages, même dédié   services Est-ce dire fonctionnement du site Drupal. Juste les mots-clés    reconnaître et penser sont une menace sont un sous-ensemble mineur de   les indicateurs réels.
    Demandez index.php /? q = utilisateur. Ensuite, essayez de   désactiver cette réponse sans paralysant votre site.
  • sécurité par l'obscurité est pas de sécurité. Il donne un   fausse impression d'être « sûr » quand vous êtes ne cache   vulnérabilités derrière un écran de fumée que tout attaquant qui a posé une   menace réelle serait en mesure de voir à travers.
  • Bien que ce n'est pas   tout à fait impossible de pirater le code au point où plus   traces de Drupal sont cachées à la source HTML, (Il est open source   après tout) les mesures nécessaires pour le faire romprait nécessairement noyau donc   mal que votre branche piraté du code serait incompatible   avec A Mises à jour de sécurité que vous ne pouviez pas correctif   et serait vraiment ouvert à toutes les menaces réelles futures identifiées par   l'équipe de sécurité. Ceci est une vraie route vers la vulnérabilité du système.
  •   
  • La plupart des modules importants ou utiles ont leur propre code « signature »   qui est difficile à cacher sans réécritures importantes. Si vous utilisez   'Vues', 'CCK', 'ad', 'imagecache', 'jquery', css-agrégation,   thèmes contribué ou quelque chose d'utile sur votre site - quelqu'un peut   dire . Hiding que tout serait généralement besoin d'un total   conversion des fonctions thématiques - au moins. Même alors, obsfucation    ne fonctionnera probablement pas .
  • Pour supprimer l'identification des   un grand nombre des fonctionnalités avancées, comme même l'installation facile de Google Analytics qui peuvent utiliser   Les bibliothèques Drupal au travail, vous devez nécessairement soit renoncer à ceux   caractéristiques tout à fait, ou les réécrire d'une manière qui ne prend pas   avantage de l'infrastructure Drupal. Parfois, cela est possible,   mais dans tous les cas, il est contre-productif.

Vous pouvez être intéressé par pour sécuriser votre site aussi.

Rappelez-vous jamais noyau bidouille

Il n'y a pas de se cacher que votre site fonctionne Drupal. Il est la mauvaise façon de regarder développement de sites Web. Ce que vous devriez concentrer sur la sécurité. Assurez-vous de mettre en œuvre toutes les mesures de valeurs mobilières et tout ira bien. Il n'y a pas une raison dans le monde à cacher que vous utilisez un certain cm ou tout autre logiciel. Avec FF comme addons Wappalyzer, vous pouvez dire en un instant si un site utilise Drupal, la question est donc assez discutable.

Une chose supplémentaire que vous pouvez faire est d'utiliser également le module Alias ??fichier pour modifier la structure de fichier par défaut.

  

Le module de fichier Alias ??vous permet d'utiliser des alias personnalisables jeton pour vos fichiers téléchargés, vous donnant la possibilité pour garder votre système de fichiers organisé comme d'habitude tout en offrant des chemins propres à la recherche (c.-à-pas plus / sites / default / fichiers /).

Je suis d'accord avec d'autres personnes que vous ne pouvez pas le cacher entièrement. Si vous regardez la source HTML, vous remarquerez que CSS plusieurs fois et les fichiers JavaScript ne sont pas agrégées. CSS et l'agrégation JavaScript doivent être activés.

Dans ce passé, j'ai troqué mes polices pour les polices de projet typiques Ruby comme Lucida Sans, les tailles d'entrée en augmentant comme le font tous les enfants de la hanche.

Une autre give se trouve le « throbber » graphique pour les champs de saisie semi-automatique. Il ne fonctionne pas lorsque vous augmentez la taille d'entrée. Voilà celui que vous pouvez voler: http://beta.seattlebedandbreakfast.com/misc/throbber.gif

Licencié sous: CC-BY-SA avec attribution
Non affilié à drupal.stackexchange
scroll top