Renommez / etc / passwd et / etc / shadow pour des raisons de sécurité
J'ai un serveur Mon serveur est sécurisé, mais imaginons un bon pirate informatique qui entre. Il peut maintenant regarder dans /etc/passwd et /etc/shadow. Je voudrais renommer ce fichier /etc/passwd à quelque chose comme /etc/xxanoda.
Je pensais pouvoir faire un lien, mais pour un pirate informatique, il sera facile de faire ls -l.
Il est possible de renommer ces fichiers tout en ayant un système d'exploitation en cours d'exécution, sans problème de compatibilité, ou est-il complètement inutile? Juste pour la recherche de connaissances.
Le norme de hiérarchie du système de fichiers pour les systèmes de type unix inclut /etc/passwd à un emplacement fixe, et les outils sont donc généralement codés en dur pour le rechercher. Tandis qu'en théorie, vous pourriez recompiler tous les utilitaires pertinents pour chercher dans un nouvel emplacement, tout attaquant pourrait toujours rechercher des chaînes dans ces fichiers binaires pour localiser le nouveau fichier, ou utiliser des expressions régulières pour rechercher des fichiers avec passwd- comme le contenu.
Le fichier shadow doit être lisible uniquement par root (et éventuellement par un groupe appelé shadow). Si un attaquant a réussi à obtenir un accès root sur votre système, il a le contrôle complet et sa capacité à lire vos fichiers passwd/shadow est assez peu pertinent à ce stade.
Il peut arriver que vous ayez des fichiers dans des emplacements inattendus, par exemple si vous avez un serveur Web mal configuré qui permet à quelqu'un de demander http://myserver/../../etc/passwd, mais en général, ce type d'indirection nécessitera beaucoup de travail. un avantage de sécurité minimal.
La meilleure chose à faire serait "complètement inutile" comme vous dites. (Cela ne constitue pas un obstacle supplémentaire pour un intrus)
/etc/passwd contient les noms de compte, mais toute personne disposant d'un accès Shell au système pourra les trouver.
/etc/shadow contient des informations sensibles (les hachages du mot de passe), mais elles ne sont lisibles que par l'utilisateur root. Si un intrus parvient à obtenir les privilèges root - comment épeler catastrophe?
Dans les Unices modernes (et similaires à Unix, y compris Ubuntu), /etc/passwd ne contient aucun secret. Renommer cela poserait plus de problèmes qu'il n'en valait la peine, compte tenu du nombre d'utilitaires qu'il faudrait reconstruire pour le rechercher à son nouvel emplacement.
/etc/shadow est un autre problème, car il y a des secrets dans ce fichier, mais le renommer ne vous aidera pas. Il est uniquement lisible par root. Ainsi, même si un pirate informatique pénètre dans le système comme un autre utilisateur, cela ne suffit pas pour accéder au fichier. C’est la raison pour laquelle les mots de passe ont été retirés de /etc/passwd en premier lieu: tout le monde doit pouvoir lire /etc/passwd, mais seule la racine doit pouvoir obtenir les mots de passe réels, les mots de passe ont donc été déplacés. dans un fichier que seule la racine peut lire.
Si le pirate obtient devient root, un changement de nom ne vous sauvera pas. Un simple grep récursif pourrait donner au pirate une liste de fichiers dans un format semblable à celui de /etc/shadow - et le pirate n'aura alors qu'à le parcourir pour trouver les données qu'il souhaite. Vous l'avez retardé de quelques heures au plus, et probablement moins: encore une fois, cela ne vaut pas le temps qu'il faudrait pour modifier et recompiler tous les utilitaires qui dépendent de l'emplacement de /etc/shadow.
Bien qu'il soit probablement inutile de renommer les fichiers /etc/passwd et /etc/shadow, si vous souhaitez renforcer la sécurité, vous pouvez consulter les modules PAM (modules d'authentification enfichables) et NSS (commutateur de service de noms). comme ici.
PAM peut être utilisé pour ajouter des modules d'authentification qui, au lieu de lire leur authentification ifnormation à partir des fichiers standard, le lisent depuis une autre source, telle que ldap ou une base de données. Son utilisation signifierait que le /etc/shadow peut être presque complètement éliminé.
NSS complète PAM en rendant certaines des résolutions de noms (comme les groupes auxquels appartient cet utilisateur) indépendantes des fichiers standard (/etc/passwd, /etc/groups). Son utilisation signifierait que votre fichier passwd ne contiendrait potentiellement qu'une option de secours pour root, et rien de plus. L'utilisation de clés SSH pour valider la connexion root élimine également la nécessité de disposer d'un mot de passe root dans le fichier reflet (bien que cela puisse être souhaité en cas de rupture de la connexion SSH).
Si vous ne souhaitez pas authentifier vos utilisateurs via une base de données distincte ou un hôte ldap, vous pouvez également créer vos propres modules PAM et NSS, qui lisent leurs données à partir d'un fichier non standard, bien que je ne recommande pas cette option.
Lorsque vous voulez essayer de les utiliser, n'oubliez jamais de conserver une sorte de solution de secours sur une couche d'authentification connue et opérationnelle, sinon vous pouvez vous verrouiller en dehors du système, même avec root.
Notez que toutes les applications ne supportent pas PAM (beaucoup le font cependant). Cependant, NSS peut être utilisé pour implémenter l'authentification pour des applications qui ne prennent pas en charge PAM, et certains sites que j'ai lus à propos de NSS suggèrent en fait cette approche. Cela signifie toutefois que le module NSS fournira le mot de passe (potentiellement) haché à toute personne pouvant accéder à la couche d'authentification NSS, ce qui est presque toujours quelque chose que vous souhaitez éviter (c'est fondamentalement la même chose que donner un accès en lecture non root au fichier shadow. )! Par conséquent, si vous optez pour cette approche, assurez-vous toujours que NSS est uniquement utilisé pour fournir à l'utilisateur les données de base (telles que le contenu de /etc/passwd), et que PAM est utilisé en tant que couche d'authentification.
Vous ne pouvez pas simplement renommer ces fichiers. Beaucoup de processus et de programmes vont les rechercher, car il s’agit d’un standard dans les systèmes Linux. Ce que vous pouvez faire est de sécuriser votre serveur de manière appropriée.