Dans ce document un certain nombre de references sont faites a des

sites outre atlantique sous forme d'URL, pour des documents ou des
produits.

SVP, verifier s'ils ne sont pas deja soit ici, soit sur ftp.urec.fr.

Pour cela allez voir soit

Ici (pour outils Unix)

soit Ici (pour outils reseaux)
Ici (pour outils de trace reseaux

Jean-Paul Le Guigner (leguigne@univ-rennes1.fr)

==========================================================================

Traduit du document info.cert.org/pub/tech_tips/security_info par

(aussi Ici

Paul Rezvoy (paul@sunlyon3.univ-lyon3.fr)

--------------------------------------------------------------------

En complement de l'information contenue dans ce document, il serait interessant

pour vous de prendre connaissance de la liste des avis CERTs, et d'un
petit descriptif pour chacun.

Ce document a jour peut etre obtenu sur le serveur cert.org :

Via FTP

Une version assez recente se trouve :

Ici (Rennes)
A. Comment d�terminer si votre syst�me � �t� "compromis" (attaqu� avec succ�s
! ).

1. Examinez les fichiers log tels que 'last'-log, comptabilit� des activit�s,
syslog et security log, afin de d�tecter des acc�s de provenance
inhabituelle,
ou des activit�s non usuelles.
Notez que ceci n'est pas fiable � 100 pour 100, beaucoup d'intrus �ditent
les
fichiers d'"accounting" afin de cacher leur activit�.

2. Cherchez partout dans votre syst�me des fichiers inhabituels ou cach�s

(fichiers dont le nom commence par un point et ne sont normalement pas
affiches par
la commande ls) car ils peuvent servir � cacher des informations telles
que des
programmes de "craquage" des mots de passe ou des fichiers password en
provenance
d'ailleurs.
Un truc favori sur les syst�mes UNIX est de placer un r�pertoire cach�
dans un
compte utilisateur ( son r�pertoire ), avec un nom tel que "..." ou "..
",
ou "..^G", (3points, 2points 2espaces, 2points controle-G).
Des fichiers '.xx' et '.mail' ont �t� �galement utilis�s.

3. Rechercher partout dans votre syst�me des fichiers ayant un setuid ( suid
root surtout ).
Les pirates laissent souvent des copies de /bin/sh avec setuid afin
d'avoir un acc�s
root ult�rieurement.
La commande UNIX find peut �tre utilis�e pour "chasser" ces fichiers

find / -user root -perm -4000 -print

Cette commande recherche sur tout le syst�me de fichier, sur toute

l'arborescence,
y compris les syst�mes de fichiers NFS/AFS mont�s.
Certaines commandes find supportent l'option -xdev pour �viter de
rechercher sur ces
r�pertoires.

Une autre fa�on de chercher les fichiers setuid est d'utiliser la commande
ncheck sur
chaque partition.
Par exemple, utilisez la commande suivante pour rechercher les fichiers
setuid et
sp�ciaux sur la partition /dev/rsd0g :

ncheck -s /dev/rsd0g

4. Testez les binaires de votre syst�me afin �tre s�r qu'il n'ont pas �t�
modifi�s.
 Des fichiers tels que login, su, telnet, netstat, ifconfig, ls, find, du,
df, libc,
sync, et autres binaires vis�s par inetd.conf ou tout autre programme
'critique'
r�seau et syst�me ont �t� par le pass� modifi�s par les pirates.
Sur les syst�mes VMS, voir les programmes loginout.exe et show.exe.
Comparez les versions sur votre syst�me avec de 'bonnes copies' telles que
celles
fournies sur les bandes d'initialisation (CD-ROM).
Soyez circonspects vis � vis de vos 'backups' (sauvegardes), ils peuvent
eux aussi
contenir des chevaux de Troie.

Les programmes des chevaux de Troie peuvent produire les m�mes 'checksumm'
standard
et date que la version l�gitime; c'est pourquoi la commande UNIX sum et
les dates
associ�es aux programmes ne sont pas suffisants pour d�terminer si les
programmes
ont �t� remplac�s.

L'utilisation des outils de 'checksum' cryptographique tels que cmp, MD5,

ou autre
est adapt�e pour d�tecter ces programmes de cheval de Troie, la 'checksum'

fournie par ces outils n'�tant pas modifiable par les intrus.

5. Examinez tous les fichiers lanc�s par cron et at : les pirates peuvent
laisser des
entr�es de service dans les fichiers lanc�s par cron ou soumis � at.
Ces techniques peuvent permettre le retour des intrus m�me apr�s que vous
les ayez
'chass�s' de votre syst�me.
V�rifiez bien aussi que tous les fichiers r�f�renc�s, directement ou
indirectement,
par les 'jobs' cron et at ainsi que les fichiers 'jobs' (scripts) eux-
m�mes ne sont
pas accessibles en �criture par tout le monde.

6. Examinez les additions ou modifications �ventuellement non autoris�es dans

le fichier
/etc/inetd.conf., en particulier les entr�es qui ex�cutent un programme
'shell'
(par exemple /bin/sh, /bin/csh), et testez tous les programmes qui sont
sp�cifi�s dans
/etc/inetd.conf pour v�rifier qu'ils sont corrects et n'ont pas �t�
remplac�s par des
chevaux de Troie.

7. V�rifiez vos fichiers de configuration syst�me et r�seau, pour ce qui

concerne les
entr�es non autoris�es; en particulier le signe '+', ou des noms de
machines
ext�rieures dans /etc/hosts.equiv, /etc/hosts.lpd et dans tous les
fichiers .rhosts
(sp�cialement root, uucp, ftp et autre compte syst�me).
Ces fichiers doivent �tre prot�g�s en �criture.
De plus, assurez vous que ces fichiers existaient avant toute intrusion et
n'ont pas
�t� cr��s par un intrus.

8. Examinez toutes les machines sur le r�seau local lorsque vous recherchez
des signes
d'une intrusion. La plupart du temps, si une machine � �t� pirat�e, les
autres sur le
r�seau l'ont �t� aussi. C'est surtout vrai sur les r�seau o� tourne NIS et
o� les
serveurs s'autorisent les un les autres � travers l'usage des fichiers
.rhosts ou
/etc/hosts.equiv. V�rifiez donc tous les serveurs avec lesquels vos
"users" partagent
des acc�s.

9. Examinez le fichier /etc/passwd et v�rifiez tout compte suppl�mentaire ou

modifi�.
En particulier, recherchez les cr�ations de nouveaux comptes non
autoris�es, les
comptes sans mot de passe, ou les changements d'UID (sp�cialement l'UID 0)
sur les
comptes existants.

B. Les probl�mes de configuration des syst�mes UNIX qui ont �t� exploit�s.

1. Les mots de passe d�fectueux.

Les intrus utilisent souvent finger ou ruser pour d�couvrir les noms des
comptes et
essayent des mots de passe simples. Persuadez vos utilisateurs de choisir
des mots
de passe difficiles � deviner (par exemple, mots qui ne sont dans aucun
dictionnaire
quelle que soit la langue; pas de nom propre, y compris les noms de
personnages
c�l�bres r�els ou imaginaires, pas d'acronymes qui sont communs aux
professionnels
de l'informatique, pas de variations simples du nom ou du pr�nom).
De plus recommandez � vos utilisateurs de ne laisser des informations
en clair sur les nom d'utilisateur/mot de passe sur quelque machine que ce
soit.

Un bon choix de mot de passe est de choisir une phrase facilement

m�moris�e,
par exemple "By The Dawn's Early Light" et de prendre les lettres
initiales
des mots pour former le mot de passe.
Ajoutez quelques signes de ponctuation, m�langez majuscules et minuscules
...
Pour la phrase pr�c�dente, un exemple de mot de passe peut �tre bt{DeL}.
( N'UTILISEZ PAS cet exemple pour votre propre mot de passe).

Si des intrus peuvent obtenir un fichier passwd, ils le copient sur une
autre
machine, et font tourner un programme de recherche des mots de passe qui
incluent des recherches dans de gros dictionnaires et travaillent
rapidement
m�me sur des machines lentes. La plupart des syst�mes o� on n'a mis aucun
contr�le sur les mots de passe en ont au moins un qui peut �tre facilement
trouv�.

Si vous pensez que le fichier passwd peut avoir �t� copi�, changez tous
les mots de passe. � tout le moins, les mots de passe syst�me, un intrus
peut
se concentrer sur eux et peut �tre capable de deviner m�me un 'bon' mot
passe.

La section D contient une liste d'outils qui peuvent vous permettre de

vous
assurer que vos utilisateurs ont effectivement choisi de 'bons' mots de
passe
et que les mots de passe encrypt�s ne sont pas visibles pour les
utilisateurs
du syst�me.

2. Comptes sans mot de passe ou avec mot de passe par d�faut.

Les intrus utilisent les mots de passe par d�faut qui n'ont pas �t�
chang�s
depuis l'installation, y compris le comptes avec des mots de passe fournis
par
le distributeur. Assurez vous de changer tous les mots de passe par d�faut
lorsque
le logiciel est install�.
Soyez attentifs au fait que les mises � jour peuvent changer les mots de
passe
de comptes par de nouveaux mots de passe par d�faut.
Mieux vaut changer les mots de passe des comptes par d�faut apr�s mise �
jour.
Scrutez votre fichier passwd et rep�rez les comptes avec UID 0
suppl�mentaires,
les comptes sans mot de passe, tous les nouveaux comptes.
N'autorisez pas les comptes sans mot de passe.
Supprimez les comptes inutilis�s.
Pour interdire un compte, changez le champ mot de passe du fichier
/etc/passwd
avec une ast�risque '*' et changez le login shell par /bin/false afin �tre
s�r
qu'un intrus ne peut se 'loger' depuis une machine du r�seau.

3. Mots de passe r�utilisables.

M�me quand d'excellents mots de passe sont choisis, ils sont envoy�s en
clair
� travers les r�seaux (locaux ou publics), ils sont susceptibles d'�tre
capt�s
par des programmes 'sniffeurs/renifleurs'.
Nous recommandons de changer pour des mots de passe � usage unique,
sp�cialement pour les acc�s authentifi�s en provenance de r�seaux
ext�rieurs,
ou pour des acc�s � des ressources sensibles telles les serveurs de nom ou
 les routeurs. Pour plus d'information voir :

info.cert.org:/pub/tech_tidbits/one-time-passwords.
(n'existe pas , j'ai poste un mail au CERT)

4. Utilisation de TFTP (Trivial File Transfert Protocol) pour voler les

fichiers passwd.

Pour tester la vuln�rabilit� de votre syst�me, connectez-vous � votre

syst�me
en utilisant tftp et essayez

get /etc/motd

Si vous pouvez le faire, n'importe qui peut, � travers le r�seau obtenir

votre
fichier des mots de passe. Pour �viter ce probl�me, soit supprimez le
service
tftp s'il n'est pas n�cessaire, soit assurez vous de le configurer avec
des
acc�s restreints.
Si vous pensez que votre fichier passwd � pu �tre pris, la premi�re chose
�
faire est de changer tous les mots de passe sur ce syst�me.

5. Vuln�rabilit�s du sendmail.

Il y � eu, � propos de sendmail, un certain nombre de vuln�rabilit�s

identifi�es au cours des ann�es.
Le meilleur, � notre connaissance, est BSD 8.6.9 qui semble r�pondre � ces

vuln�rabilit�s.
Pour statuer sur la version de sendmail que vous utilisez, utilisez telnet

pour vous connecter sur le port SMTP (25)

telnet machine.domaine.pays 25

Nous vous recommandons de vous mettre � jour avec la derni�re version de

sendmail de votre vendeur, et qu'elle soit � jour des patches de s�curit�
et autres d�taill�s dans les avis des CERT et autre bulletins.

6. Vieilles versions de FTP et FTP anonymes mal configur�s.

Assurez vous que vous utilisez la derni�re version de ftpd.

Voyez avec votre vendeur pour les informations sur les mises � jour de
votre configuration.
Voyez aussi la configuration de votre FTP anonyme.
Il est important de suivre les instructions fournies avec le syst�me pour
configurer correctement l'accessibilit� via FTP anonyme � certains
fichiers
et r�pertoires (par exemple les droits sur les fichiers et r�pertoires
ainsi
que leur appartenance : (propri�taire et groupe).
� noter que vous ne devriez pas utiliser les fichiers standards
passwd group pour FTP. Le r�pertoire racine de FTP anonyme et ses 2
 sous-r�pertoires, etc et bin, devraient appartenir � ftp.
Pour des informations suppl�mentaires, voir :

info.cert.org:/pub/tech_tips/anonymous_ftp.

7. Configuration r�seau inad�quates.

Plusieurs constructeurs fournissent de fichiers /etc/hosts.equiv avec une

ligne comportant le signe '+'. Celle-ci doit �tre supprim�e car elle
signifie que le syst�me reconna�t/fait confiance � tous les autres
syst�mes.
Les autres fichiers susceptibles de contenir un '+' sont /etc/hosts.lpd et

tous les fichiers .rhosts.

Ces fichiers doivent �tre prot�g�s en �criture.
Si votre fichier /usr/lib/X11/xdm/Xseesion contient la ligne
/usr/bin/X11/xhost +
supprimez cette ligne. Si cette ligne reste ainsi, quiconque sur le r�seau

peut dialoguer avec le serveur X et potentiellement passer des commandes,

ou lire les frappes � la console.

8. Mauvaises configurations d'UUCP

Si votre machine supporte uucp, v�rifiez le fichier L.cmds (Permissions)

et assurez vous que seules les commandes n�cessaires y soient incluses.
Ce fichier doit appartenir � root (et pas � uucp) et doit �tre prot�g�
en �criture.
Le fichier L.sys doit appartenir � uucp et �tre prot�g� (mode 600) afin
que seuls les programmes tournant avec setuid uucp puissent y acc�der.

9. Param�tre 'secure' inappropri� dans le fichiers /etc/ttys et /etc/ttytab

Testez les fichiers /etc/ttys et /etc/ttytab selon la version de UNIX

utilis�e.
Le param�trage par d�faut est qu'aucun terminal, peudo-terminal ou
terminal
r�seau n'est 'secure' hormis la console.

10. Contenu du fichier /usr/lib/aliases.

Le fichier /usr/lib/aliases peut contenir un alias nomme 'uudecode' ou

'decode'.
Si cet alias existe sur votre syst�me et que vous n'en avez pas r�ellement

besoin, il doit �tre supprim�.

11. Protection des fichiers et r�pertoires inadapt�e.

Voyez dans votre documentation syst�me comment fixer correctement les

protections et appartenances des fichiers et r�pertoires syst�me.
V�rifiez en particulier le r�pertoires '/' (root) et '/etc' et tous
les fichiers de configuration syst�me et r�seau.
 V�rifiez les protections de fichiers et r�pertoires avant et apr�s
une installation logiciel ou l'utilisation d'un utilitaire de
v�rification,
ces proc�dures pouvant modifier ces protections.

12. Les vieilles versions d'O.S.

Les vieilles versions de syst�mes ont souvent des trous de s�curit�,

biens connus des pirates. Afin de minimiser votre vuln�rabilit�
aux attaques, mettez � jour votre version d'O.S. et appliquez les patchs
de s�curit� appropri�s � votre syst�me d�s qu'ils sont disponibles.

13. Usage des proc�dures shell de setuid.

Les proc�dures shell setuid (surtout setuid root), peuvent occasionner

des probl�mes de s�curit�, ceci � �t� bien document� dans de nombreux
textes sur l'administration syst�me UNIX.
Ne cr�ez pas et n'autorisez pas les scripts shell setuid et surtout pas
setuid root.

14. Param�trage export inappropri�.

Lorsque c'est possible, les syst�mes de fichiers doivent �tre export�s

prot�g�s en �criture.
Testez la configuration du fichier /etc/exports sur vos serveurs.
Ne permettez pas un serveur NFS de se r�f�rencer dans son propre
fichier export.
Ne permettez pas que les fichiers export contiennent une ligne
'localhost'.
N'exportez les syst�mes de fichiers que vers les machines qui en
ont besoin. N'exportez que vers des machines dont le nom est totalement
indiqu� (int�gralement pr�cis�). Assurez vous que les listes d'export
ne d�passent pas 256 caract�res, apr�s que l'alias ait �t� �tendu, ou que
tous les patches de s�curit� relatifs � ce probl�me aient �t� appliqu�s.
Utilisez l'utilitaire showmount pour tester si les exports sont corrects.

C. Vuln�rabilit�s du syst�me VMS.

1. Comptes avec des mots de passe par d�faut.

Les intrus utilisent souvent les mots de passe par d�faut qui n'ont pas
�t� chang�s depuis l'installation. Assurez vous de changer tous les mots
de passe par d�faut lorsque le syst�me est install�.
Soyez attentifs au fait que des mise � jour de logiciels peuvent,
sans pr�venir, remettre des mots de passe par d�faut. Il est pr�f�rable de

changer les mots de passe par d�faut apr�s mise � jour.

Les comptes inutilis�s doivent �tre supprim�s du fichier des autorisations

et de la base de donn�es des droits. Les comptes 'dormant' doivent �tre

mis � DISUSER. Les pirates essayent de deviner les mots de passe simples;
voir Section � le paragraphe sur les mauvais mots de passe pour les
 suggestion pour le choix d'un bon mot de passe.

2. Versions de fichiers syst�me non autoris�s.

Les pirates lorsqu'ils p�n�trent dans un syst�me modifient souvent les

programmes patch.exe, loginout.exe et show.exe.
Comparez ces fichiers avec les originaux du kit de distribution logiciel.

----------------------------------------------------------------------------------
---
La section D a �t� supprim�e de ce document.

Cliquez ici pour avoir l'�quivalent de cette section.