Compte-Rendu de la réunion du 24 mai 2004 ----------------------------------------- +--------------- ! Yannick FOURASTIER : Industrialisation de la gestion des patches. ! http://www.ossir.org/resist/supports/cr/20040524/GestionPatches.pdf +--------------- L'industrialisation d'un processus, quel qu'en soit le domaine, suppose la définition dudit processus (rationnel et reproductible), sa systématisation (standardisation et généralisation sur tout le périmètre concerné) et son contrôle (métrologie). Concernant les patches, il est nécessaire - de qualifier (quoi, pourquoi, comment), - de distribuer (rendre disponible là où c'est nécessaire), - d'appliquer (avec la possibilité d'un retour en arrière). L'industrialisation du processus signifie - que seuls les patches utiles sont concernés (rationalisation), - qu'ils sont systématiquement appliqués sur les cibles appropriées (standardisation, généralisation, reproductibilité) - que l'application, la non-application ou le retour en arrière sont tracés (métrologie), - et que les versions sont mises à jour (contrôle) Une grande partie du problème se situe au niveau de la qualification des patches (faut-il appliquer tel correctif ? pourrait-il y avoir des conséquences négatives ?). Cela suppose des expérimentations, et donc induit des délais initiaux. Une fois un correctif qualifié (à appliquer ou non, sur tels ou tels systèmes), le reste de la procédure doit pouvoir être déroulé sans délais supplémentaires. La procédure d'application des correctifs n'est pas sans risques : - sur la mise à jour, qui peut être + vulnérable (introduction de nouvelles défaillances), + corrompue (on n'a pas récupéré la version officielle mais une version altérée par un tiers), + perturbante (la stabilité ou le fonctionnement du système mis à jour peuvent être remis en question). - sur le processus, qui peut être + corrompu (la mise à jour récupéré est bonne, mais celle arrivant en bout de chaîne ne l'est pas), + pas rigoureux (les cibles ne sont pas toutes identifiées, les correctifs ne sont pas installés partout où ils le devraient, etc.). Il est donc nécessaire de prendre diverses précautions : - sur la mise à jour : + contrôles notamment de diffusion (sommes MD5 et autres), + analyse (du code source s'il est disponible, ou rétro-ingéniérie du binaire, avec les questions légales associées bien entendu), + étude d'impact de la mise à jour (systèmes de validation), + scellement et contrôle d'intégrité (lors de l'application du correctif sur un système cible). - sur le processus : + mise en place d'un environnement de qualification, + prise en compte du facteur humain lié à la qualification des correctifs, + bonne gestion du stockage et de la diffusion des correctifs une fois qu'ils sont qualifiés. - dans les deux cas : + analyse systématique des arrêts de cycle (pourquoi un correctif n'a-t-il pas été distribué ? pourquoi n'a-t-il pas été appliqué ? pourquoi y a-t-il eu un retour en arrière ?), + diffusion de l'information quant à l'existence d'une mise à niveau. - sur la distribution/diffusion : + faut-il stocker uniquement au point de départ (source unique de correctifs dans l'entreprise) ou utiliser des relais intermédiaires ? + les chemins de diffusion (transport) doivent être fiables, + ainsi que les canaux et outils utilisés pour la diffusion. - sur le système cible : + vérifier le système et les pré-requis avant l'application du correctif, + disposer d'instructions d'application (pré-correctif) et de vérification (post-correctif). +--------------- ! Matthieu CARAYON : Expérience d'un Honeypot à l'UT-1. ! http://www.ossir.org/resist/supports/cr/20040524/Honeypots.pdf +--------------- Quelques définitions préalables : - Un honeypot est une machine (réelle ou simulée) conçue pour être attaquée, analysée, voire compromise. - Un honeynet est un réseau (réel ou simulé) dans le même objectif. Toutefois, la présence/simulation de multiples machines nécessite de bien mettre en place les interactions entres celles-ci, afin d'être crédible pour un attaquant. - Un honeytoken est un appât, une information ayant pour objectif d'attirer la population visée par le honeypot/net. Ce peut être un document Word, un tableau Excel, une base de données, etc. Dans tous les cas, l'idée sous-jacente est de collecter des informations sur les actions, outils, procédures et modes opératoires des attaquants, afin de mieux les connaître et, généralement, de s'en protéger. On peut distinguer deux types de pots de miels, ceux destinés à la recherche (amélioration de la connaissance du modus operandi des attaquants, analyse des nouvelles attaques) et ceux destinés à la détection d'intrusions (l'objectif étant de disposer d'alarmes après divers systèmes de protection qui auraient été contournés). L'outil déployé à l'Université de Toulouse 1 par M. Carayon est honeyd. Il a été utilisé afin de simuler un réseau complet hébergeant divers hôtes virtuels. L'ensemble du réseau-leurre a été simulé sur une unique machine de faible puissance, sans que cela ne pose de problèmes de performances notables. Les possibilités de simulation sont assez étoffées, soit directement disponibles avec l'outil honeyd (serveurs telnet ou SMPT, agent SNMP, etc.), soit diffusées sur Internet par des tierces parties (simulation IIS, MSftp, Apache...). Cela permet de construire un réseau ou un système simulé cohérent, y compris dans les réponses sur le réseau. Si l'on met de côté les difficultés d'installation/exploitation (maîtrise de l'outil, paramétrage), le plus gros problème est la construction d'un environnement cohérent et réaliste, y compris dans les éléments de bas niveau (paquets renvoyés sur le réseau, etc.). Si une cartographie Nmap relève de nombreuses incohérences dans les signatures réseau par exemple, l'attaquant peut en conclure qu'il s'agit d'un leurre. Cela ne signifie pas toujours qu'il va aller voir ailleurs : il peut aussi se consacrer aux autres systèmes, réels ceux-ci... L'exploitation des résultats est une tâche nécessaire, voire indispensable : ce sont de ces données que l'on va extraire les informations recherchées. Cette exploitation peut se révéler longue, même si des outils comme HoneyView permettent d'en accélérer certaines phases. Etudier une intrusion et en faire l'analyse post-mortem est un travail délicat. Sur un système ou réseau totalement virtuels, cela peut devenir proche de la haute voltige. -- Pierre-Yves Bonnetain B&A Consultants - Sécurité informatique - www.ba-cst.com Tel. : +33 (0) 563 277 241 - Fax : +33 (0) 563 277 245