| Mandrake Linux 8.2: Manuel de référence serveur | ||
|---|---|---|
| Page précédente | Chapitre 10. De la sécurité sous GNU/Linux | Page suivante |
L'aspect suivant à regarder est la sécurité de votre système vis-à-vis des utilisateurs locaux. Avons nous dit utilisateurs locaux? Oui!
Obtenir l'accès au compte d'un utilisateur local est la première chose que fait un intrus, sur le chemin de l'exploitation du compte root. Avec une sécurité locale laxiste, il peut alors « améliorer » ses privilèges du compte normal vers des privilèges de root en utilisant un certain nombre de bogues et de services locaux mal configurés. Si vous vous assurez que votre sécurité locales est serrée, alors l'intrus suera un peu plus pour passer la barre.
Les utilisateurs locaux peuvent aussi causer beaucoup de dégâts sur votre système, même (et surtout) s'ils sont vraiment qui ils prétendent être. Donner des comptes à des gens que vous ne connaissez pas ou pour lesquels vous n'avez pas de renseignements est une très mauvaise idée.
Vous devriez vous assurer de fournir aux comptes utilisateurs le strict minimum requis pour leur tâche. Si vous donnez un compte à votre fils (10 ans), vous voudrez qu'il puisse accéder à un traitement de textes et un programme de dessin, mais qu'il ne puisse pas effacer des données qui ne sont pas les siennes.
Plusieurs bonnes règles à suivre lorsque vous autorisez des gens à accéder à votre machine GNU/Linux :
Leur donner la plus petite quantité de privilèges dont ils ont besoin.
S'assurer de quand/où ils se connectent, ou devraient se connecter.
S'assurer de supprimer les comptes inutilisés, que vous trouverez aisément en utilisant la commande last ou en vérifiant les fichiers journaux pour déterminer si ses utilisateurs sont encore actifs.
Pour faciliter la maintenance des comptes et l'analyse des données de log, il est conseillé d'utiliser du même numéro d'usager (userid) sur tous les ordinateurs et réseaux.
La création de groupes de userids devrait être strictement interdite. Les comptes d'utilisateurs permettent aussi la responsabilisation, ce qui est rendu impossible par les comptes groupés.
Beaucoup de comptes d'utilisateurs locaux qui sont utilisés dans des infractions de sécurité n'ont pas été utilisés pendant des mois ou des années. Comme personne ne les utilise, ils sont des vecteurs d'attaque idéaux.
Le compte le plus sollicité sur votre machine est le compte root (super-utilisateur). Ce compte a l'autorité sur toute la machine, ce qui peut aussi inclure l'autorité sur d'autres machines du réseau. Rappelez vous que vous ne devriez utiliser le compte root que pour de très courtes tâches particulières, et être le plus souvent sous votre compte normal. Même de petites erreurs commises lorsque vous êtes connecté en tant que root peuvent causer des problèmes. Au moins vous êtes connecté avec les privilèges de root, au plus sûr ce sera.
Plusieurs astuces pour éviter de bousiller votre propre machine en tant que root :
Lorsque vous effectuez des commandes complexes, essayer de les faire tourner d'abord de manière non destructive... tout particulièrement les commandes qui utilisent l'englobement. i.e., si vous voulez faire rm -f foo*.bak, lancez d'abord ls foo*.bak et assurez vous que vous allez effectivement effacer les fichiers que vous pensiez. Utiliser echo à la place d'une commande destructive marche aussi parfois.
Ne devenez root que pour lancer des tâches spécifiques. Si vous vous retrouvez en train de vous demandez comment faire pour résoudre un problème, revenez sous votre compte normal, jusqu'à ce que vous soyez sûr de ce que vous avez besoin de faire en tant que root.
Le chemin de commandes pour l'utilisateur root est très important. Ce chemin de commandes (c'est a dire, la variable d' environnement PATH) désigne les répertoires dans lesquelles le shell cherche les programmes. Essayez de limiter le chemin de commandes pour l'utilisateur root le plus possible, et n'y incluez jamais . (qui signifie « le répertoire courant ») dans votre PATH. De plus, n'ayez jamais de répertoires en écriture dans votre chemin de recherche, car cela pourrait permettre aux attaquants de modifier ou placer de nouveaux binaires dans votre chemin de recherche, leur permettant de se lancer comme root la prochaine fois que vous utilisez la commande.
N'utilisez jamais le suite d'outils rlogin/rsh/rexec (appelés les « r-utilitaire ») en tant que root. Ils sont sujet de plusieurs attaques, et sont cruellement dangereux utilisés comme root. Ne créez jamais un fichier .rhosts pour root.
le fichier /etc/securetty contient la liste de terminaux depuis lesquels root peut se connecter. Par défaut, cela est arrêté aux consoles virtuelles locales (ttys). Soyez très prudent lors de l'ajout de nouvelles choses à ce fichier. Vous devriez être capable de vous connecter à distance avec votre compte normal, puis utiliser su si nécessaire (de préférence sous couvert de ssh ou un autre tube crypté), il n'y a donc pas de besoin de se connecter directement sous root.
Soyez toujours lent et réfléchi sous root. Vos actions peuvent modifier beaucoup de choses, faites sept fois le tour du clavier avant de taper!
Si vous avez assurément absolument besoin d'autoriser quelqu'un (de préférence de toute confiance) à avoir un accès root sur votre machine, il y a un certain nombre d'outils qui peuvent vous y aider. sudo autorise les utilisateurs à accéder à un certain nombre de commandes comme root avec leur propre mot de passe. Cela devrait vous permettre ainsi de laisser un utilisateur éjecter et monter un support amovible, sans aucun autre privilège root. sudo garde aussi une trace de toutes les tentatives fructueuses ou non d'utilisation, vous permettant de savoir qui a utilisé quelle commande pour faire quoi. Pour cette raison sudo marche bien même à des endroits où certaines personnes ont des accès root, car il vous aide à suivre les changements apportés.
Bien que sudo puisse être utilisé pour donner à certains utilisateurs des privilèges pour effectuer certaines tâches, il présente quelques inconvénients. Il devrait être utilisé uniquement pour un ensemble de tâches limitées, comme redémarrer un serveur ou ajouter de nouveaux utilisateurs. Tout programme offrant une fuite vers un shell donnera l'accès root à un utilisateur l'invoquant depuis sudo. Cela inclus la plupart des éditeurs, par exemple. De même, un programme aussi inoffensif que /bin/cat peut être utilisé pour écraser des fichiers, ce qui pourrait être utilisé pour exploiter root. Envisagez sudo comme un moyen de responsabilisation, mais n'espérez pas qu'il remplace l'utilisateur root tout en étant sûr.
| Page précédente | Début | Page suivante |
| Sécurité physique | Remonter | Sécurité des fichiers et des systèmes de fichiers |