Comment puis-je masquer ce que j'utilise pour exécuter mon site?

72

Est-ce que je peux faire quelque chose pour empêcher quelqu'un de savoir que mon site utilise Drupal en consultant le code source de la page d'accueil? Je parle des personnes qui analysent des sites à l'aide d'un logiciel qui détecte le logiciel utilisé pour exécuter le site Web afin de pouvoir l'attaquer en utilisant n'importe quel point faible connu.

S'il n'est pas possible de cacher complètement le fait que le site utilise Drupal, est-il au moins possible de les confondre (par exemple, en aliasant les pages de nœuds avec des URL similaires http://example.com/servlets/<node-id>.jsp)?

kiamlaluno
la source
76
Tu ne veux pas cacher Drupal. Drupal est génial.
Damien Tournoud
4
Pourquoi ne pas commencer par supprimer le fichier CHANGELOG.txt du répertoire racine! Non, mais sérieusement - cela ressemble à une perte de temps totale pour moi. Tenez-vous au courant des mises à jour de sécurité et il n’est pas nécessaire de cacher le fait que c’est Drupal. The Whitehouse cache-t-il le fait qu’ils utilisent Drupal? Non, ils le crient des toits :)
Tom Kirkpatrick
10
Dans ce cas, la sécurité par l'obscurité n'offre pas plus de sécurité.
Bryan Casler
3
Vous voudrez peut-être lire Cacking Drupal: une goutte d'eau dans le seau , un excellent traité sur la sécurisation de votre site Drupal.
Mawg
2
Si vous pensez que le cas d'utilisation de la sécurité ne fait pas l'unanimité, voici une alternative: la confidentialité commerciale. Une entreprise peut ne pas vouloir que ses concurrents soient en mesure de déterminer facilement à partir de quoi son site est construit. Ou encore, une agence ou un cabinet de conseil voudra peut-être garder ses concurrents au courant de la gamme actuelle d'outils utilisés.
user56reinstatemonica8

Réponses:

53

C’est une question ancienne à laquelle on a déjà répondu, mais j’ai récemment fait quelques efforts pour rédiger une description de tout ce que vous auriez besoin de changer:

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

Fondamentalement: techniquement, il serait peut-être possible de cacher le fait que votre site utilise Drupal, mais vous y consacriez tellement de temps que cela n'en vaut pas la peine. Vous devriez plutôt vous concentrer sur la sécurisation et la sécurisation des opérations (par exemple, la possibilité de déployer rapidement les mises à jour, les journaux de surveillance, etc.).

greggles
la source
Vous avez oublié Drupalun objet JavaScript qui doit être renommé.
Mołot
@ Molot bon point. Est-ce possible? Un pointeur sur la façon de le faire? Mon argument est que le faire ne vaut pas la peine d'être pris, ajouter des conseils supplémentaires sur la façon de le faire n'est donc utile que si cela va dans le même sens. J'espère que c'est vraiment difficile de faire ce que vous mentionnez :)
greggles
Eh bien, je l’ai testé avec le remplacement mass regex sur un répertoire Drupal et cela a fonctionné ... mais je ne crois pas que ce soit vraiment bon. Et bien sûr, c’est le cas avec chaque mise à jour de module.
Mołot
Correct. Ça ne vaut pas votre temps. Concentrez-vous sur des choses plus importantes :)
fige
101

Vous ne pouvez pas le cacher complètement. La plupart de ce qui est nécessaire pour le faire nécessiterait un noyau de piratage. Le plus grand tell, est la Drupalvariable JavaScript qui est lisible à partir de la page d'accueil, ou n'importe quelle page d'ailleurs.

Si vous souhaitez améliorer la sécurité de vos sites en masquant le fait qu'il s'agit d'un site Drupal, mieux vaut consacrer vos efforts à la révision des codes qu'à la dissimulation du fait que le site est créé avec Drupal.

googletorp
la source
7
D'accord. La structure des chemins CSS / JS / image est un autre élément mortel.
Fuzzy76
2
Vous pouvez également visiter /node/1et voir ce qui se présente ou vérifier les en-têtes HTTP .
Paul Jones
39
Si vous essayez de cacher votre site avec la sécurité par le biais de l'obscurité, vous allez simplement perdre votre temps.
Dave Reid
6
D'accord avec tout ce qui précède. De plus, il serait alors plus difficile pour les personnes qui effectuent des comparaisons avec CMS de voir combien de sites géniaux
utilisent
La discussion que nous avons eue ici est pertinente pour geerlingguy: groups.drupal.org/node/113024#comments
coderintherye
42

C'est trop facile à faire, kiam!

  • Utilisez un proxy inverse ou personnalisez votre démon http pour filtrer l'en-tête http Drupal
  • Refuser l'accès http à tous les dossiers Drupal par défaut
  • Utilisez la mise en mémoire tampon de sortie PHP pour réécrire et masquer votre source HTML, supprimez les données inutiles
  • Utilisez url alias ou custom_url_rewrite_in / outbound pour gâcher vos URL
  • Modifier l'erreur 404 par défaut, supprimer / modifier update.php
  • Apportez d'autres modifications si quelqu'un le découvre

Enfin, assurez-vous que votre site est si simple qu’il ne nécessite ni JS ni CSS pour les comportements normaux (n’utilisez pas Views ou Ctools ...), ne prend pas en charge l’authentification des utilisateurs, etc. ce qui signifie que votre site doit être aussi simple qu'un site HTML statique.

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

jcisio
la source
@ jcisio "Quoi qu'il en soit, la sécurité par l'obscurité est inutile.", vous auriez dû ajouter cela au-dessus de votre commentaire: P.
arpitr
@arpitr Tout le monde le fait, alors je pense que je n'en ai pas besoin;)
jcisio le
34

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

Tu ne peux pas. N'essaye pas

  • Les attaques automatisées (de loin les attaques les plus courantes) n’inspectent même pas le serveur avant de tenter leurs exploits .
    Les journaux de inspectant un site 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 d'exploits historiques sur tout système indépendant.
    Les attaques sur les exploits se produisent même si les exploits n'existent pas sur votre système d'exploitation ou votre CMS. Quoi que vous fassiez pour mal identifier votre site, il sera de toute façon ignoré par les pirates amateurs.
  • Quoi que vous pensiez pouvoir cacher, il existe d'autres indices pour tout système.
    Le simple fait de supprimer certaines des chaînes contenant «drupal» ne dissimule pas votre site en snooper raisonnable. Il existe des dizaines de façons de deviner ce qui sert vos pages, même des services dédiés pour indiquer à ce site qui exécute Drupal. Seuls les mots-clés que vous reconnaissez et pensez être une menace constituent un sous-ensemble mineur des indicateurs réels.
    Demandez index.php /? Q = utilisateur. Essayez ensuite de désactiver cette réponse sans endommager votre site.
  • La sécurité par l'obscurité n'est pas une sécurité. Cela donne une fausse impression de sécurité lorsque vous ne cachez que des vulnérabilités derrière un écran de fumée qu'un attaquant présentant une menace réelle serait capable de voir à travers.
  • Bien qu'il ne soit pas tout à fait impossible de pirater le code au point que la plupart des traces de Drupal soient masquées dans la source HTML, les étapes requises pour le faire (c’est Open source) briseraient nécessairement le cœur du code si profondément que votre branche piratée du code serait incompatible avec les véritables mises à jour de sécurité que vous ne pourriez pas corriger et serait véritablement ouvert à toutes les menaces futures identifiées par l'équipe de sécurité. C'est un véritable chemin vers la vulnérabilité du système.
  • Les modules les plus significatifs ou utiles ont leur propre "signature" de code difficile à masquer sans réécriture significative. Si vous utilisez 'vues', 'cck', 'ad', 'imagecache', 'jquery', agrégation de css, thèmes contribués ou quelque chose d'utile sur votre site - quelqu'un peut dire . Cacher cela entièrement nécessiterait généralement une conversion totale des fonctions de thème - au moins. Même dans ce cas, l'obsolescence ne fonctionnera probablement pas .
  • Pour supprimer l'identification de nombreuses fonctionnalités avancées, comme même l'installation facile de Google Analytics pouvant utiliser les bibliothèques Drupal, vous devez nécessairement renoncer à ces fonctionnalités ou les réécrire de manière à ne pas tirer parti de l'infrastructure Drupal. . Parfois, cela est possible, mais dans tous les cas, c'est contre-productif.

Vous voudrez peut-être aussi lire Sécuriser votre site .

Rappelez-vous Ne jamais pirater le noyau

niksmac
la source
Bien que je sois d’accord avec cela, je pense que même en tant que première ligne de défense, supprimer les en-têtes faisant référence à PHP et Drupal est une bonne chose à faire, tout en n’autorisant pas l’accès à des scripts php non indexés. Non, bien sûr, les gens trouveront toujours un moyen de savoir que vous utilisez Drupal et de penser que vous pouvez le cacher, c'est idiot. Mais il n’ya pas de mal à rendre la vie un peu plus difficile au pirate le moins averti.
Matt Fletcher
1

Il est inutile de cacher que votre site utilise Drupal. C'est la mauvaise façon de regarder les sites Web en développement. Ce sur quoi vous devriez vous concentrer est la sécurité. Assurez-vous de mettre en œuvre toutes les mesures de sécurité et tout ira bien. Il n'y a pas une seule raison au monde à cacher que vous utilisez un certain cms ou un autre logiciel. Avec les addons FF tels que Wappalyzer, vous pouvez savoir instantanément si un site utilise Drupal, la question est donc sans objet.

picxelplay
la source
1

Vous pouvez également utiliser le module Alias ​​de fichiers pour modifier la structure de fichier par défaut.

Le module Alias ​​de fichiers vous permet d’utiliser des alias personnalisables par jeton pour vos fichiers téléchargés, ce qui vous permet de garder votre système de fichiers organisé comme d’habitude tout en fournissant des chemins d’apparence clairs (c’est-à-dire, plus de / sites / default / files /).

John
la source
1
Et? Cela corrige une infime partie du processus et peut-être même pas la partie la plus importante.
greggles
1
Je ne voulais pas répéter encore une fois les bonnes réponses des personnes ci-dessus. J'ajoute juste un autre conseil.Et oui, ce conseil est très important, car c'était le plus difficile à faire jusqu'à présent, et la seule façon de comprendre un site est drupal, car habituellement, les webmasters suivent les étapes habituelles, à l'exception de cela. Et oui, il est très facile de comprendre qu’il s’agit d’un site drupal uniquement à cause de cette organisation de structure de fichiers / dossier.
john
1

Je suis d'accord avec d'autres personnes que vous ne pouvez pas le cacher entièrement. Si vous examinez la source HTML, vous remarquerez que bien souvent, les fichiers CSS et JavaScript ne sont pas agrégés. L'agrégation CSS et JavaScript doit être activée.

utilisateur140
la source
0

Dans le passé, j'ai remplacé mes polices par des polices typiques du projet Ruby telles que Lucida Sans, augmentant également la taille des entrées comme le font tous les enfants branchés.

Un autre cadeau est le graphique "throbber" pour les champs à complétion automatique. Cela ne fonctionne pas non plus lorsque vous augmentez la taille d'entrée. En voici un que vous pouvez voler: http://beta.seattlebedandbreakfast.com/misc/throbber.gif

double josh
la source