Convention de dénomination des noms d'ordinateur pour la sécurité
J'ai fait un audit de sécurité et j'ai découvert que vous pouvez facilement identifier les rôles d'hôte et exécuter les services simplement par leur nom d'ordinateur (en utilisant nslookup).
Je voudrais signaler cela afin qu'ils utilisent des noms d'ordinateur moins évidents et qu'il devienne plus difficile pour un attaquant d'identifier les rôles des machines sur le réseau. Je voudrais donner un certain poids à cette proposition en créant un lien vers une convention de dénomination de sécurité d'une organisation de confiance. Après quelques recherches, je n'ai pas pu en trouver. Y en a-t-il déjà?
Vous n'avez identifié qu'un seul risque, celui d'un attaquant identifiant les rôles de machine sur le réseau à l'aide de noms d'hôtes prévisibles.
Je pense que vous avez manqué le risque concurrent, celui d'une erreur accrue de l'opérateur en n'utilisant pas de noms d'hôtes prévisibles et descriptifs.
Voici comment j'évaluerais ces mesures contradictoires:
Utiliser des noms d'hôtes imprévisibles
Avantage (s)
Un attaquant devra consacrer (considérablement) plus d'efforts à déterminer la configuration de votre réseau et à identifier les cibles les plus rentables pour une tentative de pénétration.
Risques
Erreur d'opérateur. Les utilisateurs et les administrateurs peuvent avoir des difficultés à identifier les systèmes et leurs rôles appropriés, par exemple confondre les systèmes de test et de production.
- Probabilité: élevée
- Impact: élevé
Justification: La plupart des humains ont de terribles souvenirs en ce qui concerne les données "aléatoires" -> forte probabilité.
De plus, il existe généralement très peu d'obstacles qui empêchent les utilisateurs et les administrateurs de confiance de commettre des erreurs à fort impact -> à fort impact.
Utilisez des noms d'hôtes prévisibles
Avantage (s)
Taux d'erreur de l'opérateur réduits, facilité de gestion et d'automatisation.
Risques
Les attaquants auront également plus de facilité à déterminer la configuration de votre réseau et à identifier les cibles les plus rentables pour une tentative de pénétration.
- Probabilité: moyenne
- Impact: faible
Justification: Toutes les conventions de dénomination ne sont pas immédiatement intuitives pour un attaquant chapeau noir -> probabilité moyenne.
L'utilisation de noms d'hôtes pour prédire une configuration réseau n'est également qu'un raccourci, mais ne fournit pas d'informations qu'un attaquant ne pourrait pas apprendre par d'autres moyens. Et la connaissance du rôle d'un serveur tel que divulgué par un nom d'hôte ne le rend pas automatiquement plus vulnérable (seulement plus ou moins précieux). -> faible impact.
Le fait qu'il n'y ait pas d'informations facilement disponibles pour étayer votre conclusion devrait vous donner une idée de sa validité.
Le fait est que si votre attaquant est déjà dedans, il devra quand même faire une empreinte supplémentaire. Votre nom d'hôte peut être database.xyz.intranet, mais si le nmap vous donne 1521 (Oracle), 1433 (serveur sql) ou 5432 (Postgress), cela donne quelques informations sur les vulnérabilités possibles .. Bien sûr, cela vous fera gagner du temps en sachant que www.companyname.com n'est probablement pas le serveur de base de données principal, mais c'est minime.
D'un autre côté: vos développeurs sont-ils vraiment heureux de faire des requêtes SQL sur linux20195681.intranet? Qu'est-ce qu'ils lancent une deuxième base de données dans votre cloud local? Donner des noms significatifs simplifie également leur vie. Et bien sûr, c'est plus facile pour le stand-by qui est appelé à 2 heures du matin.
De plus, vos vrais serveurs peuvent être cachés derrière un équilibreur de charge. Le VIP obtiendrait alors généralement le nom fonctionnel et les hôtes derrière lui un certain numéro de séquence.
Si vous êtes dans une petite organisation, vous pouvez envisager de donner à vos hôtes des noms à thème (par exemple, mes Pi à la maison s'appellent pi, rho, sigma, phi, etc.), mais même dans ce cas, j'ai du mal à me rappeler que sigma est ma maison automatisation, psi mon serveur DNS, etc. Et oui, vous pourriez avoir pour thème Zeus comme base de données de production, Jupiter comme test et Odin comme développer, mais à un moment donné, toute forme de polythéisme imposera une limite au nombre de serveurs.
Il est donc préférable de leur donner des noms fonctionnels.
D'un autre côté: ne soyez pas trop précis ou séduisant. Appel d'un hôte privatekeybackup.intranet attirera sûrement un peu plus l'attention.
Il y a eu quelques idées de randomisation des noms d'hôte (rfc8117) mais cela semble plus un problème pour les clients.
Ce que vous préconisez s'appelle "la sécurité par l'obscurité". Alors qu'en théorie, l'obscurité offre une protection supplémentaire sans aggraver les choses, elle aggrave généralement les choses dans la pratique. Cela (1) ajoute de la complexité au système, ce qui conduit à des erreurs, (2) dilue la compréhension des informations secrètes et de celles qui ne le sont pas, et (3) peut avoir un coût de maintenance non négligeable.
Un exemple de (1) serait un administrateur appliquant des paramètres de sécurité faibles à un serveur très sensible car le fait qu'il était sensible n'était pas évident d'après le nom.
Un exemple de (2) serait un utilisateur à qui le service informatique demande de divulguer le nom du serveur qu'il pense être secret. Plus tard, lorsqu'un agresseur se faisant passer pour un informaticien lui demandera de divulguer son mot de passe, il sera moins surpris et moins méfiant.
Un exemple de (3) serait le fait que pour maintenir des noms de serveur obscurs, le service informatique devra les changer chaque fois qu'ils soupçonnent que leur réseau est compromis.