CONSEILS DE SECURITE DESTINES AUX MACHINES UNIX SUR UN RESEAU TCP/IP
Version 2.0 (avril 91)
Jean-Luc Archimbaud CNRS/UREC
charge de mission "securite informatique" au CNRS
Voir aussi CV et ses autres très intéressantes documentations
Ce document peut etre diffuse sans restriction, mais dans son integralite.
Il est disponibile par "ftp anonymous" sur la machine ftp.imag.fr dans le
fichier pub/securite/conseils.unix.ps.gz. N'hesitez pas a me faire part de
vos corrections et suggestions a l'adresse electronique : jla@imag.fr.
La securite informatique n'est plus un domaine reserve a la Defense
Nationale. Sans devenir paranoiaques, responsables et utilisateurs des
systemes d'information doivent s'appliquer a limiter les risques
qu'encourent leurs donnees et leurs materiels.
Le Responsable de la securite d'un systeme est l'administrateur de ce
systeme
Ce document est donc destine aux administrateurs de stations de travail
Unix, pour les aider dans cette tache. Il a pour but de fournir les
conseils de base pour rendre une machine Unix, connectee sur un reseau
TCP/IP, moins vulnerable aux pirates. C'est une compilation de differentes
publications, volontairement limitee a n'etre qu'un "livre de recettes" au
detriment de l'analyse des failles et des remedes.
Il est limite a l'aspect logiciel (Unix), et n'aborde pas les conseils
generaux de protection contre le feu, le vol, ... Il ne s'adresse ni aux
gourous Unix, ni aux specialistes de securite informatique.
Unix est un systeme d'exploitation cree par des programmeurs, pour des
programmeurs, dans un laboratoire de recherche. La securite n'a donc pas
ete une preoccupation dominante lors de sa conception. Mais, plus que d'un
atavisme, sa vulnerabilite provient principalement de :
. Sa popularite : c'est le systeme d'exploitation le plus connu. Beaucoup
de pirates ont exploite et exploiteront les bugs d'un systeme dont le
source est facilement disponible.
. L'attitude des vendeurs : ils livrent un systeme totalement ouvert.
1. CONSEILS AUX ADMINISTRATEURS
En tant que Responsable de la securite sur votre machine, vous devez
effectuer les verifications necessaires et mettre en place les outils
fournis par les constructeurs pour la proteger. C'est ce que passent en
revue les points suivants. Mais la technique est loin de proteger
integralement votre systeme. L'attention et la vigilance sont vos 2
principales armes. Les militaires ont coutume de dire que "La securite,
c'est 20% de technique et 80 % de bon sens".
Et, avant toute chose, n'oubliez pas cette conduite a tenir :
En cas de probleme de piratage, avertissez immediatement votre responsable
hierarchique
1.1. VERIFICATIONS lors de la mise en service de la machine
Apres l'installation de votre systeme sur disque (a la livraison ou lors
d'un changement de version), faites une sauvegarde et conservez la. Elle
pourra servir de reference.
1.1.1. /etc/passwd et /etc/group
Sur ces fichiers :
. Verifiez que le proprietaire est root avec les acces 444 ou 644; et que
tous les utilisateurs et tous les groupes sont declares avec un mot de
passe (le second champs de chaque entree ne doit pas etre vide).
. Si vous n'utilisez pas les "Yellow Pages", supprimez la ligne dont le
premier caractere est + (si elle existe).
. Si vous les utilisez, verifiez que les lignes "+ : :0 : :0 : : :" et "+
:" sont absentes dans les fichiers de la station serveur. Elles ne doivent
etre presentes que sur les machines clientes.
Dans /etc/passwd :
. Seul root doit posseder 0 comme "user id" (UID).
. Modifiez les mots de passe que vous avez utilises lors de l'installation
du systeme, ainsi que ceux fournis avec le systeme.
. Otez les utilisateurs de service : guest, visitor, tutor, demo, ...
1.1.2. Fichiers sensibles
. Sous /dev :
Le super utilisateur "root" doit etre le proprietaire de tous les
fichiers, exceptes les fichiers relatifs aux terminaux actuellement login.
Les fichiers kmem, mem et les partitions des disques (avec les noms sd*,
rxy*, ... selon le materiel) doivent avoir l'acces 0 pour "other".
. Si votre systeme offre la possibilite de "secure terminal", mettez la en
pratique : enlevez le mot "secure" dans chaque ligne du fichier /etc/ttytab
(ou /etc/ttys). L'absence de cet attribut proscrira le login direct sous
root. L'acces au super utilisateur se fera uniquement par la commande su.
Specifiez aussi les quelques utilisateurs qui pourront faire su lors de la
declaration du groupe wheel dans /etc/group.
. Supprimez "." (le directory courant) dans les regles de recherche de
l'utilisateur root (la variable path est initialisee dans /.cshrc et PATH
dans /.profile).
. Detruisez le ficher /.rhosts s'il existe.
. Effacer le fichier /etc/hosts.equiv si vous n'en avez pas l'utilite. Dans
le cas contraire, verifiez que ce fichier ne contient pas une seule ligne
d'un seul caractere : +.
. Si vous n'utilisez pas NFS, ou si vous ne desirez pas rendre accessible
(exporter) une partie de votre arborescence, detruisez le fichier
/etc/exports. Dans le cas contraire, verifiez que chaque nom de directory
que vous desirez "exporter" est suivi des noms des stations qui ont le
droit d'y acceder. Autrement, n'importe qu'elle station pourra "monter" ce
directory. La syntaxe depend des versions d'Unix (faites : man exports).
. Enlevez, s'ils sont presents, les alias "decode" et "uudecode" dans le
fichier aliases sous /etc ou /usr/lib.
. Supprimez l'acces w a other sur aliases, aliases.dir et aliases.pag sous
/etc ou /usr/lib.
. Dans le ficher sendmail.cf (sous /etc ou sous /usr/lib), verifiez que la
variable W (wizard password) a pour valeur le caractere etoile.
Concretement, dans ce fichier, la ligne commencant par OW (la lettre O
suivie de la lettre W) doit etre de la forme : OW*
. Supprimez les acces a "other" sur le fichier
/usr/var/spool/cron/crontabs/root. Verifiez que root est le seul
utilisateur a posseder l'acces w sur toutes les procedures lancees par ce
fichier.
1.1.3. inetd.conf
Le daemon inetd, toujours actif, offre des services tels que telnet,
rlogin, ftp, ... . Ces services, qui s'executent sur votre machine, sont
accessibles depuis les machines du reseau. Seuls les services declares dans
le fichier inetd.conf (sous /etc ou /usr/lib) ou /etc/servers repondront
aux machines distantes. N'hesitez pas a faire du menage dans ce fichier, en
ajoutant un # devant les services que vous n'utilisez pas.
Ce peut etre :
. fingerd (ou in.fingerd) : tres utile au demeurant (pour obtenir le numero
de telephone d'un utilisateur, par exemple); il permet aussi a un pirate,
depuis une machine quelconque du reseau, de connaitre les personnes
connectees sur votre station.
. tftpd (ou in.tftpd) : version simplifiee de ftp, il est utilise pour
charger le systeme d'une station sans disque (un terminal X par exemple)
via le reseau. Les versions anterieures a la fin de l'annee 88 ont un bug
tres dangereux. Les versions recentes et securisees se reconnaissent par la
presence de l'argument "-s" dans la ligne qui lance le daemon.
De maniere plus restrictive encore, si votre station n'est jamais accedee
depuis une autre machine (donc dans le sens entrant), vous pouvez supprimer
:
. telnetd (ou in.telnetd) : gere les acces interactifs a votre machine par
telnet
. ftpd (ou in.ftpd) : gere les transferts de fichiers par ftp initialises
depuis une machine distante
. rlogind (ou in.rlogind) : gere les rlogin entrants
. rshd (ou in.rshd) : gere les executions de commandes sur votre machine,
lancees depuis une machine distante
. rexecd (ou in.rexecd) : le pendant de rshd pour les fonctions
. rpc.* : repond aux requetes RPC (Yellow Pages, NFS, ...) venant de
machines distantes
Ces suppressions n'affectent pas le sens sortant. Vous pourrez toujours,
depuis votre station, utiliser telnet, ftp, ...
1.1.4. /etc/rc*
Les scripts /etc/rc* lancent des daemons reseaux, similaires a inetd. Les
scripts livres avec les systemes ont la facheuse tendance d'activer des
daemons inutiles. Il est preferable de ne pas les lancer (en ajoutant un #
devant les lignes add hoc du script) si vous n'en avez nul besoin. Entre
autres :
. rwhod (ou in.rwhod) : diffuse regulierement a toutes les machines du
reseau des informations concernant les utilisateurs login sur votre
station.
. sendmail : pour recevoir du courrier (mail) venant d'autres machines du
reseau (c'est l'option de debug distant de certaines versions de sendmail
qui est dangereuse). Attention, ce daemon est obligatoire pour la
messagerie inter-machines.
. routed (ou in.routed) : met a jour et diffuse des tables de routage IP de
maniere automatique et incontrolable.
. nfsd : pour etre serveur NFS.
. biod : pour etre client NFS.
1.2. ACCES TCP/IP
1.2.1. Rappels sur TCP/IP
Sur un reseau TCP/IP, pour acceder a un service offert par une machine
(interactif, transfert de fichiers, nfs, rwho, lpd ...) il faut que ce
service soit ouvert : le daemon doit etre lance et vous devez posseder les
autorisations necessaires (mot de passe, ...). Mais, avant cette phase, il
faut que les machines puissent dialoguer en TCP/IP. C'est ce que l'on peut
appeler "l'acces TCP/IP". En limitant les possibilites d'acces TCP/IP a
votre machine, vous minimisez d'autant les risques de piratage.
Avec TCP/IP, l'acces est toujours symetrique. Si vous pouvez acceder a une
machine X, un utilisateur sur cette machine X pourra acceder a votre
materiel. Inversement, si vous ne pouvez pas acceder a X, X ne pourra pas
vous atteindre. Donc, si vous ne pouvez pas atteindre un reseau, vous etes
certain que les machines de ce reseau ne pourront pas vous pirater. Par
contre, si vous pouvez acceder aux ordinateurs du monde entier ...
1.2.2. Routage IP
Les routages IP installes sur votre machine (visualises par la commande
netstat -r) determinent les acces TCP/IP de votre machine. Voici quelques
conseils :
. Ne mettez en place que les routages necessaires aux acces dont vous avez
besoin.
. Sauf si vous connaissez RIP, supprimez le daemon routed (ou in.routed)
lance dans un des scripts /etc/rc*. Utilisez de preference le routage
manuel avec des commandes route.
. Mesurez bien la consequence d'une route par defaut (commande route add
default ...) : toutes les machines TCP/IP du Monde peuvent essayer d'entrer
sur votre systeme.
. De maniere plus restrictive encore, privilegiez le routage par machine au
routage par reseau. Ainsi la commande : route add 129.89.32.2 ... vous
permettra de communiquer avec cette machine particuliere, sans ouvrir
l'acces a toutes les machines du reseau 129.89.
1.2.3. Passerelle avec l'exterieur
Si votre laboratoire dispose d'un reseau Ethernet TCP/IP, raccorde sur un
reseau federateur (d'un campus ou d'une region) lui-meme connecte sur un
reseau national, ... il peut etre sage d'installer un equipement avec 2
coupleurs Ethernet entre votre reseau interne et le reseau federateur. Il
sera routeur IP, passerelle entre votre laboratoire et le monde exterieur.
Ce peut etre un materiel dedie ou une banale station de travail.
En limitant le routage IP (en otant, par exemple, le daemon routed sur la
passerelle et en ajoutant aucune commande route add ...), les stations
internes ne seront jamais inquietees. Il vous suffira de surveiller l'acces
a cette passerelle; et de n'y installer aucun daemon ou utilitaire
dangereux, et aucune donnee confidentielle. Mais attention, un utilisateur
qui a pu entrer sur la passerelle pourra acceder aux machines internes.
1.3. OPERATIONS A EFFECTUER REGULIEREMENT
1.3.1. Sauvegardes
De maniere evidente, une bonne politique de sauvegardes periodiques est
imperative pour la securite de votre systeme. Il faut pouvoir revenir a un
etat anterieur propre et sur.
Utilisez dump et non pas tar, ni cpio pour ces operations.
1.3.2. Mot de passe
Dans /etc/passwd :
. Otez les utilisateurs qui ne travaillent plus sur votre machine.
Detruisez aussi tous les fichiers de ces utilisateurs. La commande suivante
liste les fichiers qui appartiennent a personne (en fait les fichiers dont
l'UID du proprietaire n'est plus dans /etc/passwd). Elle peut etre utile :
find / -nouser -o -nogroup -print
. Verifiez que tous possedent un mot de passe et que 2 utilisateurs n'ont
pas le meme UID.
. Verifiez que le caractere "+" n'a pas disparu de la ligne "+ : :0 : :0 :
: :" si elle existe.
Rappelez a vos utilisateurs (par mail ou par motd) de changer leur mot de
passe.
1.3.3. Root
Parcourez l'historique des login (et des su) de root. Vous pouvez consulter
ces traces dans des fichiers tels que messages* ou sulog sous /usr/adm.
1.3.4. Verifications sur certains fichiers
Verifiez que :
. Il n'y a pas de fichier etrange dont le nom commence par un "." sous /tmp
et /usr/tmp.
. Le contenu de /etc/hosts.equiv et de /etc/exports est correct.
. Les executables des programmes su, login et telnet sont ceux d'origine.
. Les fichiers lances par cron pour root ne presentent aucune anomalie
(dans /usr/var/spool/cron/crontabs/root ou ...)
. Il n'y a pas plethore de fichiers avec l'acces w a "other", avec la
commande :
find / -type f -perm -2 -exec ls -al {} \;
1.3.5. Sushi
Un Sushi (Super User SHell Interactive), permet a un utilisateur d'etre
sous le shell avec tous les privileges de root. C'est le programme shell
avec le Set-User-ID bit (SUID) positionne. Pour depister un Sushi, verifiez
regulierement que les fichiers qui appartiennent a root avec le Set-User-Id
bit sont uniquement des utilitaires. Il ne doit pas y avoir ce genre de
fichier sous une arborescence d'utilisateur. La commande :
find / -user root -perm -4000 -exec ls -al {} \;
permet de lister ce type de fichier.
1.4. CONSEILS GENERAUX
N'oubliez pas qu'une station peut-etre relancee en mode stand alone et que
dans cet etat, l'utilisateur a tous les privileges. Il faut donc prendre en
compte cette possibilite, en controlant par exemple l'acces physique aux
machines.
1.4.1. Habitudes de travail
. Le mot de passe de root est la clef qui ouvre toutes les portes :
choisissez le apres reflexion, changez le tres regulierement, ne le
divulguez pas.
. Faites logout chaque fois que vous quittez votre poste de travail.
. Si vous utilisez X-Window, conservez en permanence une fenetre "console"
sur votre terminal (commande : xterm -C)
. Reservez le login sous root a l'administration du systeme. Utilisez un
autre login lorsque vous n'avez pas besoin de privilege.
. Ne laissez jamais une autre personne travailler sous root, meme pour
quelques minutes.
. Faites /bin/su au lieu de su pour acceder a root.
. Dans votre fichier .login ou .profile, rajoutez la commande who. Elle
peut vous permettre de detecter des utilisateurs qui ne devraient pas etre
presents sur votre machine.
. Utilisez un compte special, avec le minimum de privilege, lors des
demonstrations, essais, ... en presence d'autres personnes.
1.4.2. /etc/hosts.equiv
Avec hosts.equiv vous deleguez entierement les controles de securite aux
machines citees dans ce fichier. Vous faites alors totalement confiance a
d'autres administrateurs. Ceci est tres dangereux. Donc, sauf besoin tres
particulier, proscrivez l'utilisation du fichier hosts.equiv (detruisez
le).
1.4.3. .rhosts
Controlez l'utilisation des fichiers .rhosts chez vos utilisateurs. Ils
permettent d'entrer sur votre systeme sans mot de passe local. Pour
afficher le contenu de ces fichiers, vous pouvez utiliser la commande :
find / -name .rhosts -print -exec cat {} \;
1.4.4. Groupes
. Si des utilisateurs desirent partager des fichiers, ne les laissez pas
ceder a la facilite de l'acces rw a "other" sur les fichiers. Les
possibilites des groupes (cf /etc/group, /etc/passwd, umask 007, chown,
chmod, newgrp, ...) resolvent ce probleme d'acces partage.
. Chaque compte declare sur votre machine doit correspondre a une et une
seule personne physique clairement identifiee. Vous devez posseder les
coordonnees de chaque utilisateur, avec son domaine d'activite sur votre
machine.
1.4.5. Divers
. Sensibilisez vos utilisateurs aux problemes de securite. La premiere
action est de diffuser largement le chapitre "Conseils aux utilisateurs".
2. CONSEILS AUX UTILISATEURS
Une regle officielle et primordiale : si vous decouvrez un piratage, un
essai de piratage ou un etat suspect :
avertissez immediatement l'administrateur de la machine et
votre responsable hierarchique
2.1. Mot de passe
. Prenez du temps pour le choisir.
. Changer le regulierement.
. Ne reprenez pas un mot de passe que vous avez deja utilise.
. Modifiez le avant de partir en vacances.
. Ne l'ecrivez pas, ne le confiez a personne.
. Ne choisissez pas :
. Votre nom, prenom ou celui de vos proches.
. Une information personnelle : numero de telephone, ...
. Un nom commun ou un nom propre contenu dans un dictionnaire.
. Une variation sur les 3 groupes precedents (inversion, initiales, ...)
. Un bon mot de passe doit etre compose :
. d'au moins 6 caracteres.
. d'un melange de majuscules, minuscules, chiffres et caracteres de
ponctuation
. Exemple : c'est1KO
Pour decouvrir un mot de passe, le pirate ne teste pas toutes les
combinaisons de caracteres. Il s'appuie sur les habitudes de l'utilisateur
moyen. Il essaie, entre autres, toutes les informations relatives a
l'utilisateur (nom, ... avec les variations) et les mots du dictionnaire.
2.2. umask
La commande umask permet de creer un masque qui force les modes d'acces
attribues aux fichiers crees. Generalement, ce masque est initialise a 002
ou 022 pour tous les utilisateurs du systeme, ce qui correspond a l'acces
775 ou 755. Ainsi, par defaut, tout nouveau fichier est accessible en
lecture a tous.
En ajoutant la commande umask dans votre .login ou .profile, vous pouvez
modifier l'acces par defaut. Ainsi umask 077 vous assurera une protection
maximale sur les fichiers crees.
2.3. Travail en groupe
Si vous devez partager un meme environnement de travail avec plusieurs
collaborateurs, demandez a l'administrateur d'enregistrer tous les membres
de votre equipe sous un meme groupe. Pour stocker les fichiers partageables
sont un repertoire "Commun" :
. Creez un sous-repertoire qui contiendra les objets partageables : mkdir
Commun
. Donnez les acces rws au groupe sur ce repertoire : chmod g+rws Commun
. Pour eviter certains conflits d'acces : chmod +t Commun
. Rajoutez dans votre .login ou .profile : umask 007
2.4. Divers
Dans les regles de recherche (path ou PATH), specifiez le repertoire
courant "." en fin de liste et non au debut.
Lorsque vous accedez a votre machine, lisez attentivement l'heure et la
date de votre derniere connexion, information generalement contenue dans la
banniere d'accueil.
Utilisez a bon escient .rhosts et verifiez regulierement son contenu.
3. DOCUMENTS
Documents ayant inspires ce "livre de recette" :
. Improving the security of your unix system
David A. Curry
. Security features guide
Sun Microsystems OS 4.0.3
. The Internet Worm Program : An Analysis
Eugene H. Spafford
. Unix System Administration (chapitre security)
David Fiedler & Bruce H.Hunter
. Internet Intruder Warning
CERT