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.
Ce document, ainsi que d'autres peut être téléchargé sur ftp://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>.