La sécurité est un domaine qui débute et se termine au niveau de l'administrateur système. Alors que tous les systèmes multi-utilisateurs UNIX® BSD ont des sécurités inhérentes, la mise en place et la maintenance des mécanismes supplémentaires de sécurité pour conserver des utilisateurs “honnêtes” est probablement une des tâches les plus vastes de l'administrateur système. La sécurité des machines est celle que vous voulez bien mettre en oeuvre, de plus les préoccupations en matière de sécurité sont plus que jamais en concurrence avec les besoins de confort des utilisateurs. Les systèmes UNIX sont, en général, capables d'exécuter un nombre important de processus simultanément et plusieurs de ces processus fonctionnent en tant que serveur — cela signifiant que des entités extérieures peuvent se connecter et échanger avec ces processus. Comme les mini-ordinateurs et les gros ordinateurs d'hier deviennent aujourd'hui nos ordinateurs de bureau, et comme les ordinateurs sont désormais en réseau et reliés à Internet, la sécurité devient d'autant plus un problème majeur.
La sécurité système concerne également la lutte contre les diverses formes d'attaque, y compris les attaques destinées à faire planter, ou à rendre inutilisable le système, mais qui ne cherchent pas à compromettre le compte root. Les problèmes de sécurité peuvent être divisés en plusieurs catégories:
Attaques par déni de service.
Compte utilisateur compromis.
Le compte root compromis par l'intermédiaire de serveurs accessibles.
Le compte root compromis par l'intermédiaire de comptes utilisateur.
Création d'une “Backdoor” (porte dérobée).
Une attaque par déni de service (“DoS”) est une action qui prive la machine de ressources nécessaires à son bon fonctionnement. Généralement, les attaques par déni de service sont des mécanismes de force brute qui tentent de faire planter ou tout au moins de rendre inutilisable la machine en saturant ses serveurs ou sa pile réseau. Certaines attaques par déni de service peuvent se servir de bogues présents dans la pile réseau pour faire planter une machine avec un seul paquet. Ces problèmes ne peuvent être corrigés que par l'application d'un correctif sur le noyau. On peut souvent remédier aux attaques sur les serveurs en fixant correctement des options pour limiter la charge que provoquent ces serveurs sur le système lors de conditions critiques. Les attaques réseau par force brute sont plus difficiles à traiter. Une attaque par paquets usurpés (“spoofed-packet”), par exemple, est quasi-impossible à arrêter, à moins de déconnecter de l'Internet votre système. Elle peut ne pas être en mesure de stopper votre machine, mais elle peut saturer votre connexion Internet.
La compromission d'un compte utilisateur est bien plus fréquente qu'une attaque de type DoS. De nombreux administrateurs utilisent toujours sur leurs machines les versions standards des serveurs telnetd, rlogind, rshd, et ftpd. Par défaut, ces serveurs ne fonctionnent pas avec des connexions chiffrées. Cela aura pour résultat si vous disposez d'un nombre d'utilisateurs conséquent qu'un ou plusieurs de ces utilisateurs ayant l'habitude de se connecter à partir d'une machine distante (ce qui représente la manière la plus courante et la plus pratique pour ouvrir une session sur un système) auront leur mot de passe “sniffé”. L'administrateur système méticuleux analysera ses journaux de connexions effectuées à partir de machines distantes à la recherche d'adresses sources suspectes même pour les ouvertures de sessions ayant réussies.
Il faut toujours supposer qu'une fois l'attaquant a l'accès à un compte utilisateur, il pourra s'attaquer et avoir accès au compte root. Cependant, la réalité est que dans un système bien sécurisé et surveillé, l'accès à un compte utilisateur ne donne pas nécessairement à l'attaquant l'accès au compte root. Cette distinction est importante car sans accès aux droits de root, l'attaquant ne peut généralement pas dissimuler ses traces et peut, dans le meilleur des cas, ne rien faire d'autre que mettre la pagaille dans les fichiers de l'utilisateur ou faire planter la machine. La compromission de comptes utilisateur est très fréquente parce que les utilisateurs n'ont pas l'habitude de prendre les précautions que prennent les administrateurs système.
Les administrateurs doivent garder à l'esprit qu'il existe potentiellement de nombreuses manières d'avoir accès au compte root sur une machine. L'attaquant peut connaître le mot de passe root, l'attaquant peut trouver un bogue dans un serveur tournant avec les droits de root et être en mesure de devenir root par l'intermédiaire d'une connexion réseau à ce serveur, ou l'attaquant peut connaître un bogue dans un programme suid-root qui permet de devenir root une fois qu'il a accédé à un compte utilisateur. Si un attaquant a trouvé un moyen de devenir root sur une machine, il n'aura peut-être pas besoin d'installer une “backdoor” (porte dérobée). De nombreux trous de sécurité root trouvés et fermés à temps demandent un travail considérable à l'attaquant pour effacer ses traces, aussi la plupart des attaquants installe des portes dérobées. Une porte dérobée offre à l'attaquant un moyen aisé d'avoir à nouveau accès aux droits de root sur le système, mais cela donne également à l'administrateur système intelligent un bon moyen de détecter l'intrusion. Rendre impossible à un attaquant l'installation d'une porte dérobée peut en fait être préjudiciable à votre sécurité, parce que cela ne fermera pas le trou qu'a découvert en premier lieu l'attaquant pour pénétrer sur le système.
Les solutions aux problèmes de sécurité devraient toujours être mises en place suivant l'approche multi-couches de “la pelure d'oignon”, elles peuvent être classées comme suit:
Sécuriser les comptes root et d'administration.
Sécuriser les serveurs exécutés avec les droits de root et les binaires suid/sgid.
Sécuriser les comptes utilisateurs.
Sécuriser le fichier des mots de passe.
Sécuriser le noyau, les périphériques et les systèmes de fichiers.
Installer un mécanisme de détection rapide des modifications inappropriées apportées au système.
La paranoïa.
La section suivante de ce chapitre abordera de manière plus approfondie les points énoncés ci-dessus.
Précédent | Sommaire | Suivant |
Sécurité | Niveau supérieur | Securing FreeBSD ** Traduction en Cours ** |
Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.