Je ne suis en aucun cas un expert en s�curit� informatique. Mais j'ai tra�n� dans le secteur et j'ai un petit conseil pour ceux qui se pr�occupent de la s�curit�. Mais attention. Ce n'est pas absolument pas une liste compl�te des probl�mes li�s � NFS et si vous pensez �tre en s�curit� une fois que vous avez lu et mis en pratique tout ceci alors j'ai un pilier de pont (presque neuf) � vous vendre.
Cette section n'a probablement pas d'int�r�t si vous �tes sur un r�seau ferm� o� vous avez confiance en tous les utilisateurs, et que personne en qui vous n'avez pas confiance ne peut obtenir un acc�s sur les machines du r�seau. I.e., il ne devrait y avoir aucun moyen de se connecter � votre r�seau depuis l'ext�rieur et il ne devrait �tre reli� � aucun autre r�seau o� vous n'avez pas confiance en tous les utilisateurs et en sa s�curit�. Vous pensez que je suis parano ? Pas du tout. C'est un conseil de s�curit� de base. Et rappelez-vous que c'est juste le commencement. Un site s�r n�cessite un administrateur consciencieux et bien inform� qui sait o� trouver l'information sur les probl�mes de s�curit� existants ou potentiels.
Un probl�me de base de NFS est que le client, si on ne lui demande pas le contraire, fera confiance au serveur NFS et vice versa. �a peut �tre mauvais. Cela signifie que si le compte root du serveur est cass� (broken into) il peut �tre tr�s facile de casser le compte root du client. Et vice versa. Il y a quelques moyens de g�rer ce probl�me sur lesquels nous reviendrons.
Les documents consultatifs (advisories) du CERT sur NFS sont une bonne source d'information, la plupart des probl�mes (et des solutions) �voqu�es ci-dessous sont trait�s dans ces documents. Voyez ftp.cert.org:/01-README pour une liste � jour. En voici quelques-uns li�s � NFS (il n'y a pas � ma connaissance de version fran�aise) :
CA-91:21.SunOS.NFS.Jumbo.and.fsirand 12/06/91 Vulnerabilities concerning Sun Microsystems, Inc. (Sun) Network File System (NFS) and the fsirand program. These vulnerabilities affect SunOS versions 4.1.1, 4.1, and 4.0.3 on all architectures. Patches are available for SunOS 4.1.1. An initial patch for SunOS 4.1 NFS is also available. Sun will be providing complete patches for SunOS 4.1 and SunOS 4.0.3 at a later date. CA-94:15.NFS.Vulnerabilities 12/19/94 This advisory describes security measures to guard against several vulnerabilities in the Network File System (NFS). The advisory was prompted by an increase in root compromises by intruders using tools to exploit the vulnerabilities. CA-96.08.pcnfsd 04/18/96 This advisory describes a vulnerability in the pcnfsd program (also known as rpc.pcnfsd). A patch is included.
Du c�t� client il y a quelques options de mount qui permettent de ne pas
faire trop confiance au serveur. L'option nosuid interdit le d�marrage
de programmes suid depuis le syst�me de fichiers NFS. C'est une option �
utiliser syst�matiquement, car elle emp�che le root du serveur de cr�er un
fichier suid sur le syst�me de fichiers NFS, puis de se loger dans le client
en utilisateur et de lancer le programme suid pour devenir root sur le
client. Il est aussi possible d'interdire l'ex�cution des fichiers du
syst�me de fichiers NFS avec l'option noexec. Mais ceci est beaucoup
moins utile que nosuid car le syst�me de fichiers contiendra tr�s
probablement au moins quelques scripts ou programmes � ex�cuter. Ces
options se rentrent dans la colonne d'options, avec wsize et
rsize, s�par�es par des virgules.
Du c�t� serveur on peut ne pas faire confiance au root du client, avec
l'option root_squash (rembarrage du root :-) dans le fichier exports :
/mn/eris/local apollon(rw, root_squash)
Dans ce cas, si un utilisateur du client avec l'UID 0 essaye d'acc�der (en
lecture, �criture ou effacement) au syst�me de fichiers, le serveur remplace
l'UID par celui de l'utilisateur `nobody' du serveur. Ceci signifie que
l'utilisateur root du client ne peut acc�der/modifier les fichiers du
serveur que seul le root du serveur peut acc�der/modifier. C'est bien, et
vous aurez probablement � utiliser cette option sur tous les syst�mes de
fichiers que vous exportez. J'en entends un qui me dit : ``Mais
l'utilisateur root du client peut toujours utiliser 'su' pour devenir
n'importe qui et acc�der � ses fichiers !'' Et l� je r�ponds : ``Oui, c'est
comme �a, c'est Unix''. Ceci a une cons�quence importante : tous les
fichiers et binaires importants devraient appartenir � root, et pas
bin ou un compte autre que root, car le seul compte auquel le root du
client ne peut pas acc�der est le compte root du serveur. Plusieurs autres
options permettant de ne pas faire confiance � qui ne vous plait pas sont
�num�r�es dans la page de manuel nfsd. Il y a aussi des options pour
rembarrer (to squash) des intervalles d'UID ou GID.
Il est important aussi de s'assurer que nfsd v�rifie que toutes les requ�tes viennent d'un port privil�gi�. S'il accepte les requ�tes de n'importe quel port du client, un utilisateur quelconque peut ex�cuter un programme qu'il est facile de se procurer sur l'Internet. Il parle le protocole NFS et pourra pr�tendre �tre n'importe qui et �tre cru. �a fait peur hein ? Le nfsd Linux effectue cette v�rification par d�faut, sur d'autres syst�mes d'exploitation il faut la valider. �a devrait �tre d�crit dans les pages du manuel de ce syst�me.
Autre chose. N'exportez jamais un syst�me de fichiers vers `localhost' ou 127.0.0.1. Croyez-moi.
Le portmapper de base, en combinaison avec nfsd pr�sente un probl�me de conception qui rend possible de r�cup�rer les fichiers d'un serveur NFS sans avoir aucun privil�ge. Heureusement le portmapper utilis� par la plupart des distributions Linux est relativement s�r vis � vis de cette attaque, et peut �tre s�curis� en configurant les listes d'acc�s au moyen de deux fichiers.
Toutes les distributions de Linux ne sont pas �gales. Certaines
apparemment � jour n'incluent pas un portmapper sur, m�me aujourd'hui,
alors que le probl�me est connu depuis plusieurs ann�es. Au moins une
distribution contient m�me la page de manuel pour un portmapper s�r alors
que le portmapper effectivement install� n'est pas s�r. Pour d�terminer
simplement si votre portmapper est le bon ou pas, lancez strings(1) et voyez
s'il lit les fichiers appropri�s /etc/hosts.deny et
/etc/hosts.allow. Si votre portmapper est
/usr/sbin/portmap ex�cutez la commande strings
/usr/sbin/portmap | grep hosts. Sur ma machine cela donne :
/etc/hosts.allow /etc/hosts.deny @(#) hosts_ctl.c 1.4 94/12/28 17:42:27 @(#) hosts_access.c 1.20 96/02/11 17:01:27
Tout d'abord, �ditons /etc/hosts.deny. Il devrait contenir la
ligne :
portmap: ALL
qui refusera l'acc�s � quiconque. Maintenant qu'il est ferm�, lancez
rpcinfo -p pour v�rifier qu'il lit et se conforme au contenu du
fichier. rpcinfo ne devrait rien renvoyer, ou peut �tre un message
d'erreur. Il ne devrait pas y avoir besoin de relancer le portmapper.
Fermer le portmapper � tous le monde est peut �tre un peu excessif, nous
r�-ouvrons donc quelque peu l'acc�s en �ditant le fichier
/etc/hosts.allow. Mais il faut d'abord savoir ce qu'on va y
mettre. � la base, il devrait contenir les noms de toutes les machines qui
doivent avoir acc�s � votre portmapper. Sur le syst�me Linux moyen il y a tr�s peu de machines qui ont une bonne raison de demander cet
acc�s. Le portmapper administre nfsd, mountd, ypbind/ypserv, pcnfsd et les
services ``en r'' comme ruptime et rusers. Parmis ceux-ci, seuls nfsd,
mountd, ypbind/ypserv et peut-�tre pcnfsd ont de l'importance. Toutes les
machines qui ont besoin d'acc�der � ces services sur votre machine devraient
y �tre autoris�es. Disons que votre machine est 129.240.223.254 et que tout
ce qui vit sur le sous r�seau 129.240.223.0 doit pouvoir y acc�der (si ceci
n'est pas clair pour vous, voyez le HOWTO r�seau). On �crit :
portmap: 129.240.223.0/255.255.255.0
dans hosts.allow. C'est l'adresse de r�seau que vous donnez aussi � la
commande route et le masque de r�seau que vous donnez �
ifconfig. Pour le p�rif�rique eth0 sur cette machine ifconfig
devrait donner :
... eth0 Link encap:10Mbps Ethernet HWaddr 00:60:8C:96:D5:56 inet addr:129.240.223.254 Bcast:129.240.223.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:360315 errors:0 dropped:0 overruns:0 TX packets:179274 errors:0 dropped:0 overruns:0 Interrupt:10 Base address:0x320 ...
et netstat -rn devrait donner :
Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface ... 129.240.223.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0 ...
(Adresse r�seau dans la premi�re colonne)
Les fichiers hosts.deny et hosts.allow sont d�crits dans les pages
de manuel de m�mes noms.
IMPORTANT : ne rien mettre d'autre que des adresses IP (num�riques) dans les lignes portmap de ces fichiers. Les host name lookup (recherche d'adresse IP (num�rique) � partir de l'adresse alphanum�rique ex. ftp.lip6.fr donne 132.227.77.2) peuvent indirectement d�clencher une activit� portmap qui d�clenchera un host name lookup qui d�clenchera...
Ceci fait, votre serveur devrait �tre un peu plus solide. Le dernier probl�me (mais oui !) est que quelqu'un casse le compte root (ou boute MS-DOS) sur une machine de confiance et utilise ce privil�ge pour envoyer des requ�tes depuis un port s�r en se faisant passer pour n'importe quel utilisateur.
C'est une tr�s bonne id�e de bloquer les ports NFS et portmap dans votre
routeur ou firewall. nfsd utilise le port 2049, que ce soit avec tcp ou
udp. Le portmapper est au port 749 (tcp et udp) et mountd aux port 745 et
747 (tcp et udp). V�rifiez les ports avec la commande rpcinfo -p.
Si au contraire vous voulez que NFS traverse un firewall, il existe des options sur les nfsd et mountd r�cents pour leur sp�cifier le port � utiliser. Vous pouvez donc choisir un port qui ne soit pas bloqu� par le firewall.
Si vous configurez correctement votre installation portmapper/NFS avec
hosts.allow/deny, root_squash, nosuid et les ports privil�gi�s, vous �vitez
beaucoup des bogues connues de NFS et pouvez presque vous sentir en s�curit�
au moins pour �a. Mais de toutes fa�ons : quand un intrus obtient
l'acc�s � votre r�seau, il/elle peut faire appara�tre des commandes bizarres
dans votre .forward ou lire votre mail quand /home ou
/var/spool/mail sont export�s. Pour la m�me raison, vous ne devriez
jamais acc�der � votre cl� priv�e PGP par NFS. Ou au moins vous devez savoir
quel est le risque. Et maintenant vous savez un peu.
NFS et le portmapper constituent un syst�me complexe et il n'est donc pas totalement exclu que de nouvelles bogues soient d�couvertes, soit dans la conception soit dans l'impl�mentation que nous utilisons. Il pourrait m�me y avoir des d�fauts de s�curit� connus, que quelqu'un utilise. Mais c'est la vie. Pour vous tenir au courant, vous devriez au moins lire les forums comp.os.linux.announce et comp.security.announce comme minimum absolu (en fran�ais, consultez fr.comp.os.linux.annonces).
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:37