



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 dterminer si votre systme  t "compromis" (attaqu avec succs ! ).

    1.  Examinez les fichiers log tels que 'last'-log, comptabilit des activits,
        syslog et security log, afin de dtecter des accs de provenance inhabituelle, 
        ou des activits 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 systme des fichiers inhabituels ou cachs 
        (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 systmes UNIX est de placer un rpertoire cach dans un 
        compte utilisateur ( son rpertoire ), avec un nom tel que "..." ou "..  ", 
        ou "..^G", (3points, 2points 2espaces, 2points controle-G). 
        Des fichiers '.xx' et '.mail' ont t galement utiliss.

    3.  Rechercher partout dans votre systme des fichiers ayant un setuid ( suid root surtout ).
        Les pirates laissent souvent des copies de /bin/sh avec setuid afin d'avoir un accs 
        root ultrieurement. 
        La commande UNIX find peut tre utilise pour "chasser" ces fichiers

                  find / -user root -perm -4000 -print

        Cette commande recherche sur tout le systme de fichier, sur toute l'arborescence, 
        y compris les systmes de fichiers NFS/AFS monts.
        Certaines commandes find supportent l'option -xdev pour viter de rechercher sur ces 
        rpertoires.

        Une autre faon 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 
        spciaux sur la partition /dev/rsd0g :

		ncheck -s /dev/rsd0g

    4.  Testez les binaires de votre systme afin tre sr qu'il n'ont pas t modifis. 
        Des fichiers tels que login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, 
        sync, et autres binaires viss par inetd.conf  ou tout autre programme 'critique' 
        rseau et systme ont t par le pass modifis par les pirates. 
        Sur les systmes VMS, voir les programmes loginout.exe et show.exe. 
        Comparez les versions sur votre systme 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 mmes 'checksumm' standard 
        et date que la version lgitime; c'est pourquoi la commande UNIX sum et les dates 
        associes aux programmes ne sont pas suffisants pour dterminer si les programmes 
        ont t remplacs.

        L'utilisation des outils de 'checksum' cryptographique tels que cmp, MD5, ou autre 
        est adapte pour dtecter ces programmes de cheval de Troie, la 'checksum' 
        fournie par ces outils n'tant pas modifiable par les intrus.

    5.  Examinez tous les fichiers lancs par cron et at : les pirates peuvent laisser des 
        entres de service dans les fichiers lancs par cron ou soumis  at. 
        Ces techniques peuvent permettre le retour des intrus mme aprs que vous les ayez 
        'chasss' de votre systme. 
        Vrifiez bien aussi que tous les fichiers rfrencs, directement ou indirectement, 
        par les 'jobs' cron et at ainsi que les fichiers 'jobs' (scripts) eux-mmes ne sont 
        pas accessibles en criture par tout le monde.

    6.  Examinez les additions ou modifications ventuellement non autorises dans le fichier 
        /etc/inetd.conf., en particulier les entres qui excutent un programme 'shell' 
        (par exemple /bin/sh, /bin/csh), et testez tous les programmes qui sont spcifis dans 
        /etc/inetd.conf pour vrifier qu'ils sont corrects et n'ont pas t remplacs par des 
        chevaux de Troie.

    7.  Vrifiez vos fichiers de configuration systme et rseau, pour ce qui concerne les 
        entres non autorises; en particulier le signe '+', ou des noms de machines 
        extrieures dans /etc/hosts.equiv, /etc/hosts.lpd et dans tous les fichiers .rhosts 
        (spcialement root, uucp, ftp et autre compte systme). 
        Ces fichiers doivent tre protgs en criture. 
        De plus, assurez vous que ces fichiers existaient avant toute intrusion et n'ont pas 
        t crs par un intrus.

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

    9.  Examinez le fichier /etc/passwd et vrifiez tout compte supplmentaire ou modifi. 
        En particulier, recherchez les crations de nouveaux comptes non autorises, les 
        comptes sans mot de passe, ou les changements d'UID (spcialement l'UID 0) sur les 
        comptes existants.


B.  Les problmes de configuration des systmes UNIX qui ont t exploits.


    1.  Les mots de passe dfectueux.

        Les intrus utilisent souvent finger ou ruser pour dcouvrir 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 
        clbres rels ou imaginaires, pas d'acronymes qui sont communs aux professionnels 
        de l'informatique, pas de variations simples du nom ou du prnom). 
        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 mmorise, 
        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, mlangez majuscules et minuscules ... 
        Pour la phrase prcdente, 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 
        mme sur des machines lentes. La plupart des systmes o on n'a mis aucun 
        contrle 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 systme, un intrus peut 
        se concentrer sur eux et peut tre capable de deviner mme 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 encrypts ne sont pas visibles pour les utilisateurs 
        du  systme.


    2.  Comptes sans mot de passe ou avec mot de passe par dfaut.

        Les intrus utilisent les mots de passe par dfaut qui n'ont pas t changs 
        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 dfaut 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 dfaut. 
        Mieux vaut changer les mots de passe des comptes par dfaut aprs mise  jour.
        Scrutez votre fichier passwd et reprez les comptes avec UID 0 supplmentaires, 
        les comptes sans mot de passe, tous les nouveaux comptes. 
        N'autorisez pas les comptes sans mot de passe. 
        Supprimez les comptes inutiliss. 
        Pour interdire un compte, changez le champ mot de passe du fichier /etc/passwd
        avec une astrisque '*' et changez le login shell par /bin/false afin tre sr 
        qu'un intrus ne peut se 'loger' depuis une machine du rseau.


    3.  Mots de passe rutilisables.

        Mme quand d'excellents mots de passe sont choisis, ils sont envoys en clair 
         travers les rseaux (locaux ou publics), ils sont susceptibles d'tre capts
        par des programmes 'sniffeurs/renifleurs'. 
        Nous recommandons de changer pour des mots de passe  usage unique, 
        spcialement pour les accs authentifis en provenance de rseaux extrieurs, 
        ou pour des accs  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 vulnrabilit de votre systme, connectez-vous  votre systme 
        en utilisant tftp et essayez

		get /etc/motd 

        Si vous pouvez le faire, n'importe qui peut,  travers le rseau obtenir votre 
        fichier des mots de passe. Pour viter ce problme, soit supprimez le service 
        tftp s'il n'est pas ncessaire, soit assurez vous de le configurer avec des 
        accs restreints.
        Si vous pensez que votre fichier passwd  pu tre pris, la premire chose  
        faire est de changer tous les mots de passe sur ce systme.


    5.  Vulnrabilits du sendmail.

        Il y  eu,  propos de sendmail, un certain nombre de vulnrabilits 
        identifies au cours des annes. 
        Le meilleur,  notre connaissance, est BSD 8.6.9 qui semble rpondre  ces 
        vulnrabilits. 
        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 dernire version de 
        sendmail de votre vendeur, et qu'elle soit  jour des patches de scurit 
        et autres dtaills dans les avis des CERT et autre bulletins.


    6.  Vieilles versions de FTP et FTP anonymes mal configurs.

        Assurez vous que vous utilisez la dernire 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 systme pour 
        configurer correctement l'accessibilit via FTP anonyme  certains fichiers 
        et rpertoires (par exemple les droits sur les fichiers et rpertoires ainsi 
        que leur appartenance : (propritaire et groupe). 
         noter que vous ne devriez pas utiliser les fichiers standards 
        passwd group pour FTP. Le rpertoire racine de FTP anonyme et ses 2 
        sous-rpertoires, etc et bin, devraient appartenir  ftp. 
        Pour des informations supplmentaires, voir :

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


    7.  Configuration rseau inadquates.

        Plusieurs constructeurs fournissent de fichiers /etc/hosts.equiv avec une 
        ligne comportant le signe '+'. Celle-ci doit tre supprime car elle 
        signifie que le systme reconnat/fait confiance  tous les autres systmes. 
        Les autres fichiers susceptibles de contenir un '+' sont /etc/hosts.lpd et 
        tous les fichiers .rhosts. 
        Ces fichiers doivent tre protgs 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 rseau 
        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, vrifiez le fichier L.cmds (Permissions) 
        et assurez vous que seules les commandes ncessaires y soient incluses. 
        Ce fichier doit appartenir  root (et pas  uucp) et doit tre protg 
        en criture. 
        Le fichier L.sys doit appartenir  uucp et tre protg (mode 600) afin 
        que seuls les programmes tournant avec setuid uucp puissent y accder.


    9.  Paramtre 'secure' inappropri dans le fichiers /etc/ttys et /etc/ttytab

        Testez les fichiers /etc/ttys et /etc/ttytab selon la version de UNIX utilise. 
        Le paramtrage par dfaut est qu'aucun terminal, peudo-terminal ou terminal 
        rseau 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 systme et que vous n'en avez pas rellement 
        besoin, il doit tre supprim.


    11. Protection des fichiers et rpertoires inadapte.

        Voyez dans votre documentation systme comment fixer correctement les 
        protections et appartenances des fichiers et rpertoires systme. 
        Vrifiez en particulier le rpertoires '/' (root) et '/etc' et tous 
        les fichiers de configuration systme et rseau. 
        Vrifiez les protections de fichiers et rpertoires avant et aprs 
        une installation logiciel ou l'utilisation d'un utilitaire de vrification, 
        ces procdures pouvant modifier ces protections.


    12. Les vieilles versions d'O.S.

        Les vieilles versions de systmes ont souvent des trous de scurit, 
        biens connus des pirates. Afin de minimiser votre vulnrabilit 
        aux attaques, mettez  jour votre version d'O.S. et appliquez les patchs 
        de scurit appropris  votre systme ds qu'ils sont disponibles.


    13. Usage des procdures shell de setuid.

        Les procdures shell setuid (surtout setuid root), peuvent occasionner 
        des problmes de scurit, ceci  t bien document dans de nombreux 
        textes sur l'administration systme UNIX. 
        Ne crez pas et n'autorisez pas les scripts shell setuid et surtout pas 
        setuid root.


    14. Paramtrage export inappropri.

        Lorsque c'est possible, les systmes de fichiers  doivent tre exports 
        protgs en criture. 
        Testez la configuration du fichier /etc/exports sur vos serveurs. 
        Ne permettez pas un serveur NFS de se rfrencer dans son propre 
        fichier export.  
        Ne permettez pas que les fichiers export contiennent une ligne 
        'localhost'. 
        N'exportez les systmes de fichiers que vers les machines qui en 
        ont besoin. N'exportez que vers des machines dont le nom est totalement 
        indiqu (intgralement prcis). Assurez vous que les listes d'export 
        ne dpassent pas 256 caractres, aprs que l'alias ait t tendu, ou que 
        tous les patches de scurit relatifs  ce problme aient t appliqus. 
        Utilisez l'utilitaire showmount pour tester si les exports sont corrects.



C. Vulnrabilits du systme VMS.


    1.  Comptes avec des mots de passe par dfaut.

        Les intrus utilisent souvent les mots de passe par dfaut qui n'ont pas 
        t changs depuis l'installation. Assurez vous de changer tous les mots 
        de passe par dfaut lorsque le systme est install. 
        Soyez attentifs au fait que des mise  jour de logiciels peuvent, 
        sans prvenir, remettre des mots de passe par dfaut. Il est prfrable de 
        changer les mots de passe par dfaut aprs mise  jour. 
        Les comptes inutiliss doivent tre supprims du fichier des autorisations 
        et de la base de donnes 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 systme non autoriss.

        Les pirates lorsqu'ils pntrent dans un systme 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 supprime de ce document.




Cliquez ici pour avoir l'quivalent de cette section. 