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 ! ). 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�. 1. 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. 2. 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. standard Les programmes des chevaux de Troie peuvent produire les m�mes 'checksumm'

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) euxm�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 se concentrer sur eux et peut �tre capable de deviner m�me un 'bon' mot La section D contient une liste d'outils qui peuvent vous permettre de assurer que vos utilisateurs ont effectivement choisi de 'bons' mots de

peut passe. vous passe

et que les mots de passe encrypt�s ne sont pas visibles pour les utilisateurs du syst�me. 2. chang�s par lorsque passe jour. 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� depuis l'installation, y compris le comptes avec des mots de passe fournis le distributeur. Assurez vous de changer tous les mots de passe par d�faut le logiciel est install�. Soyez attentifs au fait que les mises � jour peuvent changer les mots de 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 �

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. clair capt�s Mots de passe r�utilisables. M�me quand d'excellents mots de passe sont choisis, ils sont envoy�s en � travers les r�seaux (locaux ou publics), ils sont susceptibles d'�tre

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. syst�me Pour tester la vuln�rabilit� de votre syst�me, connectez-vous � votre en utilisant tftp et essayez get /etc/motd votre service des � Si vous pouvez le faire, n'importe qui peut, � travers le r�seau obtenir fichier des mots de passe. Pour �viter ce probl�me, soit supprimez le tftp s'il n'est pas n�cessaire, soit assurez vous de le configurer avec 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 et r�pertoires (par exemple les droits sur les fichiers et r�pertoires 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

fichiers ainsi

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.