Détection d anomalies dans les configurations de composants de sécurité réseau

Dimension: px
Commencer à balayer dès la page:

Download "Détection d anomalies dans les configurations de composants de sécurité réseau"

Transcription

1 Détection d anomalies dans les configurations de composants de sécurité réseau Réalisé par : Stere PREDA Encadrants : Frédéric CUPPENS Nora CUPPENS Février, 2006

2 Sommaire 1. Introduction La décomposition de politique de sécurité réseau Les anomalies dans la configuration des composants de sécurité Les firewalls Règles de filtrage Règles intrinsèquement respectées par un firewall Analyse d une configuration existante Génération d une configuration Les IDS Différentes approches de la Détection d Intrusion SNORT Configuration de SNORT Les VPN Technologie de réseaux privés virtuels La conception des VPN Configuration d un VPN Conclusion Bibliographie Détection d anomalies dans les configurations de composants de sécurité réseau 2

3 Abréviations : AH Authentication Header ATM Asynchronous Transfer Mode CIM Common Information Model CTL Computational tree logic DNS Domain Name System ESP Encapsulating Security Payload ftp file transfer protocol http HyperText Transfert Protocol ICMP Internet Control Message Protocol IDS Intrusion Detection System IKE Internet Key Exchange IMAP Internet Message Access Protocol IP Internet Protocol IPSec IP Security MPLS MultiProtocol Label Switching OSI Open System Interconnection Or-BAC Organization Based Access Control PE Provider Edge POP3 Post Office Protocol Version 3 RBAC Role-Based Access Control SA Security Association SMTP Simple Mail Transfer Protocol ssh Secure Shell TCP Transport Control Protocol VPN Virtual Private Network XML Extensible Markup Language XSLT extended Stylesheet Language Transformations Détection d anomalies dans les configurations de composants de sécurité réseau 3

4 1. Introduction La spécification et la gestion des règles de contrôle d accès est une tâche admise dans la communauté de la sécurité informatique comme étant difficile. Ces règles de contrôle d accès font partie d un ensemble plus global de règles appelé politique de sécurité organisationnelle. Cette politique doit être, à notre sens, raffinée et décomposée pour obtenir des packages de règles. Chaque package est mis en œuvre par un composant de sécurité. Les VPN, IDS et firewalls sont des exemples de composants de sécurité réseau. Pour assurer une sécurité optimale, il est impératif que la configuration de ces composants soit exempte d erreurs et traduise la politique de sécurité spécifiée. Une politique de sécurité définit ce qui doit être «sécurisé» dans un système. Un mécanisme de sécurité sert à mettre en place une ou plusieurs parties de la politique de sécurité. Parmi les plus connus, le contrôle d accès occupe une place privilégiée. Les composants de sécurité réseau qui l assurent, principalement les firewalls et les VPN doivent être configurés «sans anomalies». L existence d une anomalie peut être exploitée par un attaquant qui agira dans le but de violer la politique de sécurité. Une technique d audit aurait un rôle majeur dans la détection d une telle violation ; si l audit est une technique a posteriori pour la détermination des violations de la politique de sécurité, un IDS (qui est une forme d audit pour la détection des attaques) peut prendre en compte le facteur «temps» (voire «temps réel»). En ce qui concerne le contenu de la politique de sécurité, il peut y avoir plus ou moins de détails. Son expression dépend de l environnement pris en compte (on trouve un exemple dans [4]). Généralement, elle contient une partie qui décrit le contexte, ses objectifs, une autre qui contient la politique proprement dite et éventuellement une dernière qui décrit son implémentation et les résultats possibles de certaines violations. La politique comprend des aspects classiques de la sécurité (le contrôle d accès, la confidentialité, l intégrité, etc.) ; la différence entre la politique de sécurité et sa description abstraite (le modèle) est essentielle. Si la première abonde en détails, spécifications informelles, le modèle doit abstraire les exigences importantes, idéalement en éliminant les redondances et les ambiguïtés. Le modèle sur lequel on se focalise, Or-BAC [16], est considéré comme le plus adéquat pour résoudre les nombreux problèmes existants dans les autres modèles de contrôle d accès (par exemple, la définition du contexte, la gestion des conflits, la délégation, l administration, etc.). Les sections suivantes présenteront les principales problématiques de configurations liées aux différents composants de sécurité réseau. La section 2.1 traitera les firewalls, leurs anomalies et de différents travaux menés pour leur configuration en vue de réduire ces anomalies. La section introduit les principaux modèles d IDS ; on a choisi de détailler la configuration du SNORT, en raison de ses caractéristiques intéressantes pour notre travail de stage à venir. La section présente la forme générale d une signature du SNORT ; ensuite, une configuration basée sur l approche descendante sera proposée dans La partie VPN est traitée dans les sections 2.3. Divers travaux concernant la conception des VPN Détection d anomalies dans les configurations de composants de sécurité réseau 4

5 basée sur une politique de sécurité sont présentés dans Dans la section nous décrivons une méthode d implémentation de la politique de sécurité à déployer sur les VPN. 1.1 La décomposition de politique de sécurité réseau Pour que les configurations des différents composants de sécurité soient «sans anomalies», l approche prise en compte est illustrée par la figure 1. Spécifications informelles de la politique de sécurité (1) Abstraction de la politique de sécurité I (2) Transformations II (4) (3) Firewalls VPN IDS Configuration des composants de sécurité III Fig.1 : Implémentation de la politique de sécurité. Une des causes d anomalies est l implémentation directe (4) : à partir des spécifications informelles de la politique de sécurité, on configure directement les composants de sécurité. On perd facilement dans ce cas les besoins d interopérabilité entre composants. L approche qui nous intéresse est la suite (1), (2) et (3). Au niveau I on trouve, basée sur le modèle Or- BAC, l abstraction des spécifications informelles, matérialisée en pratique sous la forme d un fichier XML [6]. Le niveau II est un niveau dit intermédiaire : il correspond aux règles de sécurité exprimées indépendamment du langage du composant de sécurité (dans la syntaxe XML). La transformation (3) a comme résultat des règles de configuration dans le langage spécifique du composant de sécurité. Pour détecter les anomalies dans la configuration des composants, on pourrait envisager leur définition dans la relation «spécifications informelles» «niveau III». Dans ce cas, on déterminerait le degré de conformité de l implémentation courante vis-à-vis des spécifications de la politique de sécurité. L utilisation de la technique d audit est une façon pour faire cette vérification. Il est sous entendu qu une des tâches délicates sera la transformation (1), qui devra couvrir le plus de détails des spécifications, traduits ensuite dans le modèle Or-BAC ( des travaux allant dans ce sens ont été menés dans [12]). Cette transformation n est pas automatisable, car elle dépend de choix spécifique au concepteur de la politique de sécurité : Détection d anomalies dans les configurations de composants de sécurité réseau 5

6 la définition des entités (organisation, sujets, objets, rôles, etc.), les relations entre les diverses entités (hiérarchies), etc. Dans un autre cas (celui que l on aborde), les anomalies seront considérées dans la suite (2) et (3). Si les transformations (2) et (3) sont «correctes» il n y aura pas d anomalies. Ces transformations sont complètement automatisables. Si le modèle au niveau I est matérialisé sous la forme d un fichier XML, les transformations (2) et (3) peuvent être implantées en XSLT et doivent être «correctes», reflétant au niveau concret les objectifs de sécurité imposées au niveau I. Les passages (2) et (3) peuvent être vues comme un processus de raffinement ; nous cherchons à construire une méthodologie, éventuellement un catalogue de transformations qui traduisent le modèle de niveau I vers une implémentation concrète de la politique de sécurité (niveau III). Dans ce cas, surtout pour la transformation (3), nous devons tenir compte du langage, de la grammaire, de la signature du composant de sécurité. La variété des composants, des constructeurs qui constituent le marché (Cisco, Linksys, ) nous obligent à prendre toujours en compte la syntaxe et la sémantique de ces composants. L automatisation de ces transformations permettrait donc de simplifier la configuration des composants de sécurité tout en s appuyant sur le modèle Or-BAC. A la fin de ce processus, une technique d audit pourrait être mise en place pour des éventuelles vérifications. Dans certains cas, un raffinement peut être réalisé par des algorithmes de réécriture, au niveau III. ([7]). 2. Les anomalies dans la configuration des composants de sécurité Nous allons nous intéresser à plusieurs types de composants réseau : firewall, IDS et VPN. Leur configuration qui se veut conforme à la politique de sécurité réseau peut entraîner des anomalies. L objectif de cette section est de rappeler les fonctions de ces composants ainsi que les différentes problèmes d anomalie qui peut apparaître pour chacun. 2.1 Les firewalls Règles de filtrage Un firewall est une machine qui sert comme intermédiaire pour l accès à un réseau (interne), permettant ou interdisant certain type d accès avec le respect d une politique de sécurité ([4]). Il réalise le filtrage des paquets en se basant sur un ensemble de règles définies par l administrateur de sécurité : prenant en compte l adresse/port source ou destination du paquet, le flag acknowledge ou même la date. Il met en place une protection contre : des connexions indésirables et/ou non authentifiées, des attaques sur les points faibles des systèmes d exploitation internes, des attaques par déni de service sur les machines internes. Il ne protège pas contre le trafic qui ne passe pas par lui, contre des virus (sauf s il intègre un anti-virus), contre des attaques exploitant ses propres vulnérabilités ou si les machines internes sont mal administrées. Une règle de filtrage prend la forme illustrée par le tableau 1 (généralement, tout paquet n étant pas explicitement autorisé est rejeté, on dit alors que la politique est fermée) : Détection d anomalies dans les configurations de composants de sécurité réseau 6

7 action destination port source Port commentaire accept adr. IP dest. N port dest adr. IP source N port source connexion Tableau 1 : règle de filtrage Les règles sont analysées les unes après les autres, jusqu à ce qu une règle applicable soit trouvée. L ordre des règles dans la configuration d un firewall compte et peut être une cause d anomalies. Etant donné que l objectif est de réduire ce risque d anomalies, de les détecter et de les éliminer, la démarche que l on propose est la suivante : politique (modèle OR-BAC) filtre en langage indépendant de la grammaire du firewall traduction dans le langage du firewall (la suite (2) et (3) dans la figure1) Règles intrinsèquement respectées par un firewall Les règles qui apparaissent dans la configuration des firewalls doivent être vérifiées périodiquement. Pour cela, soit on extrait les fichiers de configuration des firewalls et on fait leur analyse vis-à-vis de la politique de sécurité, soit on met en place des techniques d audit dans les architectures qui comprennent des firewalls. Le but est d assurer que la configuration est en totale conformité avec la politique de sécurité. Même si, pour l implantation des règles dans un firewall il est recommandé de suivre l approche décrite dans 2.1.1, il y a un jeu de règles qui devraient être toujours respectées, indifféremment de la politique de sécurité (elles apparaissent implicitement dans tous les cas), concernant : Le trafic entrant provenant d une source (voire usager) non authentifiée, ayant comme destination le firewall lui-même ; cette fonctionnalité d authentification d usager n est pas présente dans tous les firewalls. Le trafic entrant avec une source appartenant au réseau privé protégé par le firewall ; Le trafic ICMP (on sait qu il peut servir à la découverte de la topologie du réseau) ; Le trafic entrant SNMP (l intrus probe le réseau) ; Le trafic entrant contenant de l IP Source Routing Information (des cas très rares) ; Trafic entrant ou sortant contenant comme adresse source ou destination ou ; Une liste complète se trouve dans [17]. La section traite les principales anomalies et leur détection dans les firewalls. Ensuite, présente des travaux portant sur leur configuration Analyse d une configuration existante La première remarque que l on peut faire est que la configuration directe (4), fig.1, est fréquemment source d erreurs de configuration. N ayant pas une base solide reposant sur des règles bien établies au niveau abstrait, il est peu probable qu une telle démarche soit exempte d erreurs. L un des aspects qui n est pas pris en compte par une telle approche est l interopérabilité des différents composants réseau dans la mise en œuvre de la politique de sécurité. Une anomalie apparaît dès qu un paquet qui arrive au niveau du firewall trouve plusieurs règles qui peuvent lui être appliquées (deny, accept, drop) avec la même priorité (la Détection d anomalies dans les configurations de composants de sécurité réseau 7

8 règle R1 est prioritaire par rapport à la règle R2 si R1 et R2 s appliquent toutes deux au paquet traité et c est la décision associée à R1 qui est privilégiée). Une fois les règles définies, les interactions entre celles-ci doivent être gérées. Plus le nombre de règles est grand, plus aisément des contradictions, conflits, ou redondances surgissent. Dans ce cas, des outils de vérification, d analyse de la configuration s avèrent utiles. Les principales anomalies sont la redondance et le shadowing (le masquage) ; ces anomalies sont définies de la façon suivante : On dit qu une règle est redondante, si on peut la supprimer sans changer la décision de filtrage, quel que soit le paquet présenté en entrée. [7] donne une définition formelle de la redondance. La redondance est considérée comme une erreur, elle ne contribue pas à la décision du firewall, par contre elle augmente la taille du tableau de règles ainsi que le temps de calcul. On dit qu une règle est masquée (shadowed) si la règle ne s applique jamais parce que des règles ayant des priorités plus grandes sont toujours applicables. La règle R2 est masquée par la règle R1 si R1 est plus prioritaire que R2 et R2 représente un sous ensemble de la règle R1 mais leurs décisions sont contradictoires. Le shadowing est critique car la règle masquée ne sera jamais utilisée. La conséquence est qu un paquet peut être accepté alors qu il aurait peut-être du être rejeté ou inversement (un paquet va peut-être être rejeté alors qu il aurait du être accepté). Une définition complète se trouve dans [7]. La littérature introduit d autres anomalies : la corrélation et la généralisation ([1]) ; selon leurs définitions, on remarque qu elles correspondent aux cas des règles «partiellement» redondantes, respectivement masquées. On réduit donc dans la suite ces cas considérés à de la redondance et à du shadowing. [14] et [11] offre une vision intéressante de la politique de sécurité mise en place par un firewall, en montrant ses anomalies. Elle consiste en un graphe où chaque noeud représente un champ de la règle de filtrage (par exemple, adresse IP source), chaque branche étant une valeur possible du champ ; les feuilles sont les actions pouvant être prises (accept, deny, drop). Une règle de filtrage sera un chemin commençant par la racine et se terminant par une seule feuille. L intérêt d une telle représentation est la simplicité d ajouter d autres règles (d autres branches) ; bien entendu, l ajout d une règle ne se traduit pas toujours par un simple ajout d une branche, il implique parfois une modification plus complexe de l arbre si on ne veut pas avoir des anomalies. Détection d anomalies dans les configurations de composants de sécurité réseau 8

9 Fig. 2 l arbre de la politique de sécurité [14] propose des algorithmes pour la découverte des anomalies, ainsi que pour l insertion (la mise à jour) de nouvelles règles ; ils sont développés en ayant cette vision - le graphe de la politique de sécurité. L idée de base est de vérifier si deux règles s appliquent au même chemin ; ce cas est saisi par l administrateur et des choix pour une correction lui sont offerts. C est sur ce mécanisme que certains analyseurs de la politique de sécurité fonctionnent. Parfois on désire des algorithmes qui font la correction, la réécriture automatique des règles, tout en préservant la politique de sécurité. Ils font la découverte des anomalies et prennent directement la bonne décision de réécriture. Ces algorithmes doivent être plus puissants, car ce n est plus l administrateur qui prend la décision en ce qui concerne la réécriture. L approche que l on a dans ce cas est basée, intuitivement, sur la projection d une règle ayant n attributs sur un espace à n dimensions (par exemple, fig. 3). En considérant deux règles de filtrage qui impliquent des adresses IP de la même sous-classe, l abscisse constitue un intervalle d adresses source, l ordonnée est un intervalle d adresses destinations. Une règle apparaîtra dans cet espace comme un rectangle ; une anomalie existe si deux (ou plusieurs) rectangles sont superposés [3]. Si on se limite à la redondance, l algorithme de réécriture s articule autour de la redéfinition des règles rectangles, qui n auront aucune portion commune (totalement disjointes), conservant la même «figure» dans l espace 2D. La figure suivante explique la démarche : Détection d anomalies dans les configurations de composants de sécurité réseau 9

10 d R1 R2 d R1 R2 d1 d2 s1 s2 s s a) b) Fig.3 : réécriture en cas de redondance Au début, les règles R1 et R2 ont une «portion» commune (redondance partielle), sur l espace d adressage source [s1, s2], respectivement destination [d1, d2] (fig.3.a). Les algorithmes de réécriture détectent la redondance et réalisent les règles R1, R2 qui sont disjointes dans l espace 2D (fig.3.b). La démarche complète est expliquée dans [7], ainsi que les algorithmes (qui ont été implémentés). Il s agit donc d un raffinement au niveau III, fig.1. Jusqu ici, le type d anomalies décrites était intra-firewall. Bien entendu, on peut envisager des architectures de réseau comportant plusieurs firewalls qui doivent coopérer, en délimitant des zones (par exemple, DMZ) dans le réseau. Un nouveau type d anomalie apparaît dans le cas d une mauvaise configuration des machines : des anomalies inter-firewall. Même si localement, les firewalls sont bien configurés (sans redondance ni masquage), un conflit entre ces firewalls peut apparaître dans la mesure où un firewall laisse passer les paquets (car localement la politique de sécurité le leur permet) et un autre les bloque. Des travaux existent et proposent des algorithmes d analyse des règles dans ce cas d anomalie inter-firewall ([1]) Génération d une configuration La première référence, [12], introduit un nouveau concept, celui de tactique de sécurité. C est un niveau d abstraction intermédiaire entre la politique de sécurité (modèle RBAC [19]) et son implémentation. Pour l exprimer, un langage de spécification est introduit. Il devrait assurer la description des éléments constitutifs d un réseau, les différentes technologies, la topologie du réseau, etc. Cette tactique de sécurité implique l identification des diverses fonctionnalités qui doivent répondre aux besoins de sécurité. Les composants ne sont plus traités sous leur forme réelle, car une première architecture comprend des composants particuliers, classés en fonction de leur comportement dans le réseau : des composants qui consomment les flux de données (les terminaux), des composants qui propagent les flux (des canaux), d autres qui le transforment (par exemple NAT, VPN), respectivement qui filtrent les flux (des modules de contrôle d accès au niveau du système d exploitation, des firewalls, etc.). Ceci est décrit dans le langage de la tactique. L approche proposée est très intéressante Détection d anomalies dans les configurations de composants de sécurité réseau 10

11 car elle serait utile dans le cas où il faudrait implémenter une politique de sécurité qui ne serait spécifiée que par des règles informelles (fig. 1) et aucune architecture réseau. Bien qu elle raisonne sur différents plans, (au niveau applicatif, on retrouve le modèle RBAC qui s appuie sur une infrastructure réseau résultant de l interconnexion de différentes fonctionnalités consommation des flux, filtrage, transformation), la procédure par laquelle l auteur explique le passage : [ règle informelle modélisation RBAC règles écrites dans le langage de la tactique de sécurité ] est dépourvue de continuité. On observe le manque de précision des étapes. D autre part, la tactique de sécurité est évaluée par des simulation en logique CTL visant (1) son exactitude : les mécanismes (par exemple, contrôle d accès) doivent répondre aux objectifs de sécurité définis dans RBAC, (2) sa consistance vis-à-vis des incompatibilités entre les mécanismes et (3) sa faisabilité : la tactique doit pouvoir être dérivée vers des technologies existantes (implémentation concrète dans les composants de sécurité). Ce processus formel de transformation entre les trois niveaux (les objectifs de sécurité spécifiés dans le modèle Or-BAC, la tactique de sécurité et la configuration des équipements), est abordé en exploitant le modèle CIM (Common Information Model) qui assurerait une représentation uniforme des informations des ressources gérées : il y a divers schémas CIM pour décrire le modèle RBAC, la tactique de sécurité (les fonctionnalités de base et leur interconnexion ; par exemple, la classe CIM_LogicalElement), les technologies (firewalls, VPN, etc.), ainsi que pour les relations entre ces trois niveaux. Un outil pour l automatisation de l analyse de l exactitude et de la consistance de la tactique de sécurité a été développé ; quant à l analyse de faisabilité, elle dépend de la technologie employée dans l architecture réseau mise en place ([12] donne un exemple pour des VPN et des firewalls). Cette approche d unification de l information (sous CIM), est intéressante, vu la diversité des composants réseau (l hétérogénéité réseau) mais elle est contrecarrée par une complexité croissante en terme de gestion, de la modélisation du processus de raffinement présenté ci-dessus; d autre part, la démarche proposée dans [12] manque de consistance au niveau théorique (saut des étapes lors du passage entre les 3 niveaux rappelés). Cependant, on peut retenir cette approche, qui permet de donner une représentation formelle de la politique de sécurité à un niveau intermédiaire, indépendamment de la technologie des composants sécurité. Firmato «A Novel Firewall Management Toolkit» ([2]) se veut un outil de configuration des firewalls dans lequel on retrouve une séparation entre le modèle de la politique de sécurité et les spécifications technologiques des composants de sécurité. L un de ses objectifs, en phase préliminaire de conception, et de permettre l implémentation de la politique de sécurité indépendamment de la topologie du réseau. Ainsi, face à des changements dans la topologie, la politique de sécurité serait maintenue et la génération des règles concrètes pour les firewalls serait, évidemment, automatique et accompagnée par un debugger qui permettrait à l administrateur de réseau de raisonner sur les fichiers des configurations des firewalls. L outil réalisé est basé sur un Modèle Entité-Association (niveau «abstrait») qui prend en compte la topologie du réseau (donc pas d indépendance claire entre la politique de sécurité et la topologie du réseau) par un concept nouveau, rôle, qui définit «les capacités du réseau» («positive capabilities») et que les auteurs utilisent sans une sémantique claire et non ambiguë. L instanciation du Modèle Entité-Association est faite par un langage de définition du modèle et un Compilateur de Modèle qui réalise la traduction (du Modèle Entité-Association) vers les fichiers de configuration du firewall. Par ce concept de rôle, on constate un mélange entre la topologie du réseau (niveau concret) et la politique de sécurité, d où l ambiguïté. Une nouvelle notion, celle de groupe est introduite qui, elle aussi, n est pas claire. En effet, cette notion de groupe désigne parfois un ensemble de machines, parfois un rôle. Celle-ci conduit inévitablement à des difficultés d affecter des entités réseau Détection d anomalies dans les configurations de composants de sécurité réseau 11

12 aux entités du modèle. Les auteurs utilisent l héritage des privilèges parmi les hiérarchies des groupes pour dériver automatiquement des permissions. Pour l héritage des permissions, ils introduisent la notion de «groupe ouvert» et pour les interdictions de «groupe fermé». Cette notion de groupe induit des confusions, alors qu elle n est pas nécessaire à ce niveau d abstraction. Les firewalls actuels ont des langages de configuration avec des sémantiques diverses. Chaque firewall implémente son algorithme qui s appuie sur un certain langage. L existence d une telle diversité de langages rend la tâche de gestion des composants de sécurité difficile. L implémentation d une politique de sécurité, dans les cas de certains outils (Cisco PIX, IpFilter, etc.), commence en prenant en compte le langage de configuration du firewall. Avec cette approche ascendante, il est fort probable qu on obtienne des non-conformités avec les spécifications de la politique de sécurité. D où l intérêt de l approche descendante (fig. 1) mentionnée auparavant. [6] offre une démarche très détaillée et claire du processus d implémentation de la politique de sécurité, en se basant sur le modèle Or-BAC (Organization Based Acces Control). Par rapport à RBAC, Or-BAC évite de nombreux inconvénients (d ailleurs vus aussi dans d autres modèles classiques) parmi lesquels la complexité rapide des règles à exprimer, l absence de structuration des règles, l absence de gestion de contextes et de conflits. Or- BAC est basé sur le concept d organisation qui désigne toute entité qui prend en charge une partie de la politique de sécurité (par exemple, un firewall) ([8]). Il s appuie sur deux niveaux d abstraction : un niveau organisationnel (avec les entités rôle, activité et vue) et un niveau concret (sujet, action, objet). Il permet d écrire (dans un formalisme articulé autour de la logique du premier ordre) des permissions, des interdictions et des obligations, indépendamment de l implémentation de la politique de sécurité. La gestion des contextes assure la prise en compte d une large variété de contextes (temporel, spatial, défini par l utilisateur, etc.). Il est possible de spécifier des contraintes sur les entités et les prédicats définis. L administration du modèle Or-BAC se fait par l intermédiaire du modèle AdOr- BAC qui assure une «auto-administration» du modèle Or-BAC ([16]). Les rôles standard et ceux administratifs ne sont pas séparés, les règles administratives ont le même format que celles standard. Alors que d autres modèles basés sur les «rôles» ne contrôlent pas la délégation, un composant du modèle AdOr-BAC le permet. [6] présente en détail le processus de génération automatique de règles de filtrage pour des firewalls à partir d une spécification formelle de la politique de sécurité réseau, exprimée avec Or-BAC. Habituellement, celle-ci sera déployée sur plusieurs composants de sécurité. L approche prise en compte est illustrée par la figure 4. Détection d anomalies dans les configurations de composants de sécurité réseau 12

13 Politique de sécurité Or-BAC (xml) XSLT Langage de Politique de sécurité XSLT IDS, Snort NetFilter Cisco PIX Autres composants Fig. 4 : approche descendante Au niveau du modèle Or-BAC, la politique de sécurité est exprimée en XML. Toutes les entités organisationnelles du modèle (rôle, activité et vue) et concrètes (sujets, objets, actions) sont décrites en XML. Par exemple, les firewalls sont considérés comme des organisations/sous-organisations (ils implémentent chacun une partie de la politique de sécurité). Les terminaux sont des sujets, à qui l on peut affecter des rôles (des serveurs), les services sont vus comme des activités (ftp, https, ssh, etc). Avec une première transformation XSLT, on génère des règles génériques dans un langage «multi-target», indépendamment du langage du composant de sécurité visé, on spécifie les entités (rôles, activités, vues) significatives dans chaque sous-organisation (dans ce cas les sous-organisations sont des firewalls) et on attribue à chacune les permissions/interdictions appropriées. Ensuite, avec la deuxième transformation XSLT, on génère des règles concrètes dans le langage de configuration du composant de sécurité cible. Pour le cas particulier de NetFilter, grâce à ses chaînes de filtrage, l ordre des règles concrètes, générées après la deuxième transformation XSLT, n est pas important (ce qui, généralement, n est pas le cas pour d autres types de firewalls pour lesquels cette transformation doit respecter un certain ordre des règles de filtrage, [16]). Le niveau d abstraction offert, la flexibilité concernant les règles à ce niveau, le modèle d administration existant, le fait de pouvoir spécifier une politique de sécurité indépendamment de la technologie employée font de Or-BAC le modèle sur lequel notre configuration des composants de sécurité sera basée. Détection d anomalies dans les configurations de composants de sécurité réseau 13

14 2.2 Les IDS Différentes approches de la Détection d Intrusion L audit est une technique a posteriori pour la détection des violations de la politique de sécurité. Le but de l IDS (Intrusion Detection System) est de détecter une grande variété d intrusions (des attaques connues ou inconnues), de préférence en temps réel (même si l analyse des commandes a un impact sur le temps de réponse du système), de représenter les résultats de l analyse dans un format simple et compréhensible et surtout d éliminer les «anomalies» concernant de fausses alarmes, faux négatifs et faux positifs. L IDS doit être efficace et fiable étant donnée la politique de sécurité mise en place. Il existe une grande variété d IDS principalement basés sur l un de ces trois modèles : la détection par seuil, la détection de comportement anormaux («anomaly detection») et la détection par scénarios d attaques («misuse models»). La détection par seuil analyse le comportement du système. Lorsqu un certain événement se produit trop souvent, dépassant un certain seuil qui a été fixé par ailleurs, une alarme est déclanchée. Par exemple, un nombre trop élévé de logins ayant échoués peut révéler une attaque réseau par cracking de mot de passe. La détection de comportements anormaux analyse un ensemble de caractéristiques du système et compare ses valeurs avec d autres, attendues. L approche basée sur un profil définit le comportement comme un ensemble de métriques (fréquence de logins, utilisation des commandes et d applications système, CPU, etc.) associées aux activités. Le profil correspond à une combinaison de ces métriques. Le profil courant est comparé au profil normal, si la déviation dépasse un seuil, une alarme est déclanchée. L approche neuronale [20] introduit une fonction d apprentissage. Ainsi, on essaie de prédire le comportement futur. Si la différence entre le comportement prédit et celui courant dépasse un seuil, une alarme est générée. L un des avantages de la détection par comportement est que la base de données de comportements normaux est créée au fur et à mesure, pendant une phase d apprentissage. L inconvénient est qu il faut assurer tout au long de cette période un comportement stable du système. La mise à jour de celle-ci, périodiquement, est l occasion pour un attaquant d y insérer son attaque qui sera ensuite traitée comme un comportement normal. En plus, en cas de profonde modification de l environnement, un flot ininterrompu d alarmes peut être généré (risques de faux positifs). Par rapport à l approche par scénarios discutée ci-après, la détection d intrusions inconnues est possible. La détection par scénarios est la plus courante. Elle nécessite la construction d une base de données d attaques. La recherche des attaques dans les données se fait généralement par application des techniques d analyse de signatures («pattern matching»). Elles déterminent si une séquence d instructions exécutée viole la politique de sécurité. La prise en compte des comportements exacts des attaquants (la définition précise des signatures d attaques) induit peu de faux positifs. La difficulté est de maintenir à jour une base de signatures, provoquant sinon le risque de faux négatifs. La détection d attaques inconnues n est pas possible, d où le même risque de faux négatifs. Les IDS «hôte» (par exemple, AAFID [26], ASAX [22], GASSATA [23]) obtiennent leurs informations des fichiers «logs». Ils détectent des violations de la politique de sécurité correspondant à des tentatives d exécution de l application dans un mode privilégié, des tentatives d accès à un fichier non autorisé ou la fourniture d un mot de passe erroné pour cet accès, le changement des droits d accès à des fichiers sensibles, etc. Les IDS «network based» (par exemple, BlackICE, Centrax, CyberCop Monitor, Dragon, Intruder Alert, NetProwler, NetRranger, NFR, RealSecure, etrust, SNORT, BRO, EMERALD, GrIDS, Shadow [24]) détectent des attaques orientées réseau ; ils peuvent surveiller le trafic Détection d anomalies dans les configurations de composants de sécurité réseau 14

15 («network sniffing») du réseau, généralement s il n est pas chiffré, pour un grand nombre d hôtes. Parmi cette multitude de IDS, en raison de nombreuses fonctionnalités qu il offre, SNORT sera celui sur lequel on va se focaliser par la suite SNORT SNORT est un logiciel IDS «ouvert» qui peut être utilisé en mode «sniffer», en mode de «journalisation des paquets» («packet logger») ou en mode «Détection d intrusions». La détection des paquets malveillants est basée sur une base de signatures d attaques. Il est capable de détecter un grand nombre d attaques comme des DoS (déni de service), Portscans, des attaques orientées http, DNS, SMTP, IMAP, POP3, même des attaques de vers. La communauté Internet offre de nombreuses bases de signatures. Comme elles sont complètement ouvertes (en «open source»), il est possible d écrire de nouvelles signatures. De nombreux outils pour la gestion de règles existent (par exemple, «IDS Policy Manager» [25]). Ils comprennent une interface graphique simple pour saisir de nouvelles règles, pour activer/désactiver un jeu de règles de la même famille (par exemple, signatures DNS), etc. Bien entendu, la configuration de l IDS doit être fondée sur une politique de sécurité. L analyse des paquets est réalisée en examinant l en-tête IP et le contenu du paquet pour rechercher des commandes, ou des chaînes représentatives de l attaque. Un IDS «hôte» n est pas capable de détecter les attaques présentées dans le contenu du paquet IP. La réponse de SNORT est en temps-réel, ce qui n est pas toujours le cas pour un IDS «hôte». Pour ce dernier, la notification d un certain événement peut être détectée après le déroulement de l attaque. Dans le cas d une attaque DoS (déni de service), la connexion TCP est instantanément arrêtée par SNORT (TCP «reset»), avant que le système ne tombe. SNORT peut être employé en complément des autres composants de sécurité. S il est placé «devant» un firewall, il peut détecter des attaques orientées vers les ressources situées derrière ce firewall. A l intérieur du réseau local, l IDS vérifie si la configuration du firewall est en conformité avec les spécifications de la politique de sécurité (si le trafic et les adresses que le firewall devrait rejeter le sont vraiment). [13] décrit différentes implémentations architecturales des IDS (SNORT) sur le réseau, en relevant les avantages et les inconvénients surtout du point de vue IP, c est-à-dire comment et où implanter l IDS dans le réseau. Bien que cet aspect soit important, l aspect majeur (principal) reste la manière d implémenter concrètement la politique de sécurité, la partie dédiée à l IDS, sous la forme de signatures. [4] présente de manière informelle la politique de sécurité dédiée IDS pour un réseau local qui contient des postes UNIX et qui partagent des fichiers en utilisant le protocole NFS. Ces spécifications qui décrivent la journalisation («logging») des paquets, les actions qui déclenchent des alertes et d autres actions caractéristiques de l IDS (drop, reject, etc.) devront être saisies et exemptes de redondance. Ensuite, elles doivent être implémentées sous la forme d un jeu de règles d IDS. La fiabilité et l efficacité de l IDS ainsi configuré, étant donnée la politique de sécurité (peu de faux négatifs/positifs), dépendent des définitions des signatures, de leurs précisions. La forme générale d une règle du SNORT est la suivante : <Action> <Protocole> <Adresse_IP_Source><N _Port_Source> -> <Adresse_Ip_Cible><N _Port_Cible> Détection d anomalies dans les configurations de composants de sécurité réseau 15

16 [(<option 1> ; < option 2> ; <option k>)] Exemple (extrait du manuel Snort) : alert tcp! [ /24, /24] any -> [ /24, /24] 111 (content : " a5 " ; msg : "external mountd access";) Cette règle déclenche une alerte, en renvoyant le message «external mountd access» lorsqu un paquet qui contient la chaîne « a5» est trouvé (sniffé). L opérateur «!» indique que la règle concernant les paquets ayant comme adresse source une adresse différente de /24, ou /24. L option «content» est l une des plus importantes. Elle permet la définition d une règle qui cherche, en s appuyant sur l algorithme de Boyer-Moore (voir manuel Snort), une chaîne spécifique (texte et/ou codes hexadécimaux) dans le paquet IP, chaîne considérée comme représentative d une attaque. SNORT offre une multitude d options dont dépend la précision des règles. Cependant, leur définition et leur gestion restent des tâches difficiles Configuration de SNORT [6] applique le modèle Or-BAC pour la configuration des firewalls (NetFilter). Dans 2.1.4, on a vu l importance de l approche descendante pour implémenter la politique de sécurité. On a souligné les avantages d Or-BAC par rapport aux autres modèles (Firmato) et on pourrait envisager d appliquer une démarche similaire pour configurer les IDS (tels que SNORT). Les «objets» dans le modèle Or-BAC correspondent aux messages échangés par les hôtes. Un message est représenté par deux éléments : le contenu du message et la station qui le recoit. Pour l IDS, le contenu du message (du paquet) sera pris en compte pour définir des règles, signatures. Certaines «vues» en Or-BAC incluront des conditions sur ce contenu. Les «sujets» étaient des hôtes et on leur attribuait des «rôles». Dans ce cas, la station qui implémentera l IDS aura le rôle d IDS (SNORT) tout comme certains hôtes auront le rôle de dns_server, ou de firewall ([6]). Bien entendu, étant donnée qu une «organisation» implémente une partie de la politique de sécurité, l IDS lui-même sera une organisation. Les actions réalisées par le sujet ayant le rôle d IDS sur les objets (messages), en fonction de leur contenu, pourraient être les actions qui apparaissent dans la définition de signatures IDS (alert, log, pass, activate, drop, reject, sdrop, etc.). La seule difficulté sera la création des «vues» appropriées, au niveau abstrait, car les messages (les contenus) peuvent contenir différents détails qu on doit saisir. Une fois pris en compte, ils renforcent la fiabilité et l efficacité de l IDS. Comme spécifié en 2.1.4, le modèle Or-BAC de la politique de sécurité réseau (y compris la partie IDS), spécifié sous la forme d un fichier XML, aura subi une première transformation XSLT (on a vu l objectif d une telle transformation dans la section 2.1.4). La deuxième transformation XSLT sera conforme à la technologie envisagée. Pour l IDS, bien évidemment, celle-ci sera différente de celle correspondant aux firewalls. Cette approche offre la possibilité de manipuler des données dans un format XML à tous les niveaux (fig.1). Par exemple, extraire la politique de sécurité, niveau III (fig.1) pour certaines vérifications ultérieures ou pour des échanges d information vers d autres systèmes. [5] et Détection d anomalies dans les configurations de composants de sécurité réseau 16

17 [18] donnent des modèles pour représenter les données pouvant être exportées à partir de la configuration d un IDS (SNORT). 2.3 Les VPN Technologie de réseaux privés virtuels Les réseaux privés virtuels (VPN Virtual Private Networks) peuvent être vus comme des services réseaux délivrés à travers une infrastructure de réseaux publics. Dans une première approche, le VPN connecte deux points à travers un réseau public pour obtenir une liaison logique. Cette liaison se fait soit au niveau 2 du modèle OSI, soit au niveau 3. En principe, il n y a pas de différence conceptuelle entre les VPN de niveau 2 et ceux de niveau 3. Les deux impliquent l ajout d un nouvel en-tête au paquet de données pour atteindre la destination. Implémenter un VPN de niveau 2 dans un routeur est similaire à implémenter un VPN en utilisant une technologie comme ATM ou Frame Relay. Un tel réseau établit une connectivité de bout-en-bout entre deux sites sur un circuit virtuel qui est une liaison logique de type PVC (circuit virtuel permanent). Un VPN de niveau 2 peut généralement transporter du trafic indépendamment du protocole de niveau 3 OSI, tout en assurant une certaine qualité de service (QoS). Pour relier les deux sites à travers un tunnel, le fournisseur du service VPN peut utiliser la technologie MPLS [21] à travers son réseau. Il ne connaît pas la topologie des sites, il configure les routeurs du cœur du réseau et les deux routeurs de bordure (PE provider edges) connectés respectivement à chacun des sites pour qu ils réalisent un tunnel MPLS. La topologie du VPN est déterminée par les configurations des PE. Pour les VPN de niveau 3 OSI, la technologie la plus répandue est l IPSec (IP Security). Elle comprend un ensemble de mécanismes destinés à garantir au trafic IP une sécurité de basée sur la cryptographie. Les services proposés par IPSec offrent le contrôle d accès, l intégrité en mode non connecté, l authentification de l origine des données, la protection contre le rejeu et la confidentialité. IPSec utilise deux protocoles pour assurer la sécurité du trafic : AH (Authentication Header) et ESP (Encapsulating Security Payload). Ils supportent deux modes d utilisation : le mode transport (qui propose une protection seulement pour les protocoles supérieurs à l IP) et le mode tunnel, où l on trouve une sécurisation de la couche Transport et IP. L en-tête original du datagramme est remplacé par un autre pour servir au routage tout au long du tunnel VPN. L en-tête d authentification (AH), un champ supplémentaire ajouté au datagramme IP, répond aux besoins d intégrité des données en mode non connecté, l authentification de l origine de données et éventuellement pour l anti-rejeu. L ESP assure de plus la confidentialité des données. Le principe est de générer un nouveau datagramme, à partir de celui d origine qui aura contenu les données et/ou l en-tête d origine chiffrés. Ce que l on trouve souvent est l ESP en mode tunnel. Les fonctions de chiffrement ne sont pas mises en œuvre de bout-en-bout, mais uniquement sur le réseau dit «non confiance», entre les deux correspondants VPN. Sur cette portion, le paquet original IP est entièrement chiffré, signé et encapsulé dans un nouveau datagramme qui aura comme contenu pour les adresses IP source et destination, celles des correspondants VPN les extrémités du tunnel. Avant l échange de l information, un certain nombre de paramètres sont négociés entre les deux parties communicantes (algorithmes de chiffrements, les clefs, etc). Ce contexte est placé dans une SA (Security Association), qui est unidirectionnelle. Concernant la gestion des SA, le protocole de gestion de clefs pour IPSec est par défaut IKE (Internet Key Exchange). Il Détection d anomalies dans les configurations de composants de sécurité réseau 17

18 se déroule en deux phases ayant comme but la négociation de certains paramètres (durée de vie de la SA, algorithmes d authentification, algorithmes de chiffrement, etc.), l élaboration de clefs d authentification et de chiffrement, l authentification mutuelle des correspondants VPN (mode d authentification, par clefs pré-partagées, ou par certificats X509). Une politique de sécurité IPSec décrit un jeu de règles pour assurer la sécurité du trafic IP ([15]). IPSec peut être implémenté au niveau des routeurs, passerelles, hôtes ou n importe quel autre système demandant une connexion sécurisée. De tels systèmes fournissent un large ensemble de protections. Si un firewall réalise le contrôle d accès en analysant les paquets IP et en décidant lesquels laisser passer, par IPSec on contrôle l intégrité, l authenticité, l antirejeu et la confidentialité des données. La gestion des composants implémentant l IPSec est une tâche difficile La conception des VPN Supposons une politique IPSec, pour un VPN entre plusieurs domaines ou sites. La politique est bien spécifiée et fonctionne correctement si, globalement, on n enregistre pas de brèches de sécurité et si le traffic IP ne souffre pas des blocages. Même si la politique est bien spécifiée, localement, dans chaque domaine, l ensemble des politiques doit pouvoir interagir de façon non conflictuelle. Ainsi, ([9] et [15]) argumentent la nécessité d un système de management pour assurer un service de sécurité de bout-en-bout. Ils introduisent deux niveaux pour spécifier la politique du VPN IPSec : un niveau «haut» (high level policy) qui représente les objectifs du VPN (les requis vis-à-vis d un certain trafic) et un niveau «bas» (low level policy), l implémentation de la politique dans les composants de sécurité. Un processus de transformation entre les niveaux devrait être défini tout en gardant la conformité entre ceux-ci. Un même niveau «haut» peut se traduire en diverses configurations concrètes au niveau réseau, en se basant sur certaines hypothèses (par exemple, de confiance : une passerelle a le droit d analyser le trafic, en le déchiffrant, car on lui fait confiance). Les spécifications au niveau «haut» comprennent : (1) la désignation du trafic (par un attribut flow id (src-addr, dst-addr, src-port, dst-port, proto, [user id] )) qui sera permis (allow) ou rejeté (deny), (2) les fonctions appliquées sur le trafic (sec functions qui peuvent être de l authentification, du chiffrement, etc), (3) certains nœuds ayant le droit d analyser le trafic (des firewalls, des IDS, etc.), éventuellement de le modifier et des nœuds pouvant accepter ou refuser des SA. Une politique de sécurité P sera une règle de la forme : P = (if condition) (actions) où condition comprendra les champs flow id, sec functions access nodes et différents nœuds concernés pour une SA donnée, actions spécifie les actions à entreprendre (sec functions) sur le trafic désigné, des algorithmes utilisés pour la protection du trafic (2.3.1), sur que les réseaux ces fonctions sont maintenues (from sous-réseau1 to sousréseau2, le trafic doit être protégé), éventuellement les nœuds qui ont le droit d analyser le trafic (trusted nodes). Au niveau «bas», condition vérifie les champs src-addr, dst-addr, src-port, dst-port, proto, ah-hdr (en-tête AH), esp-hdr (en-tête ESP). Quant à actions, elles peuvent être de trois types : deny (rejeter les paquets qui ne vérifient pas condition), allow, ou ip-sec action (secprot, algorithm, mode, from/to) où sec-prot indique le type de protocole AH ou ESP, algorithm, voir la section 2.3.1, mode précise si c est transport ou tunnel, from/to sont les deux nœuds qui créent la SA. Détection d anomalies dans les configurations de composants de sécurité réseau 18

19 Une politique de sécurité est «correcte» si le niveau «bas» est en parfaite conformité avec le niveau «haut». Elle présente des anomalies (des conflits) si, globalement (pour tous les nœuds où l on déploie la politique VPN) le trafic n est pas traité comme spécifié au niveau «haut». [9] présente quelques exemples où les spécifications du niveau «haut» ne sont plus respectées à cause d un enchevêtrement de tunnels IPSec. On arrive dans certains cas à des situations où le trafic parcourt deux fois le même chemin, circulant finalement vers la destination (le deuxième correspondant VPN) sans aucune protection, alors qu au niveau «haut» la politique requérait un certain service tout au long du tunnel IPSec. D où l importance pour le système de gestion de la politique VPN de résoudre de tels conflits ([9], [15]). Dans [15], le système de gestion de la politique VPN inclut un serveur qui définit, garde et traduit les objectifs de la politique de sécurité dans une configuration des composants réseaux. Au lieu d expliciter la politique de sécurité pour chaque composant réseau, [15] utilise le concept de rôle dont l intérêt est de spécifier la politique conformément aux fonctionnalités de chaque composant (et une meilleure gestion d un grand nombre de composants). Le modèle de la politique de sécurité IPSec est une représentation objet. Le rôle est une simple chaîne de caractères associée à chaque interface du composant. La classe SACondition et PolicyAction apparaissent en association avec une classe, SARule. Lorsque les attributs de la SACondition, associée à la classe SARule sont évalués à TRUE, les actions associées dans SAActions sont appliquées. Si [15] et [10] discutent sur un tel système de gestion de la politique de sécurité VPN, déployé sur un seul domaine, [9] présente CELESTIAL, un système de gestion inter-domaine Configuration d un VPN Cependant, un aspect important est toujours négligé : généralement, on ne peut pas séparer la politique de sécurité en une partie axée sur le VPN, une autre sur le contrôle d accès réseau et enfin une troisième sur les signatures de détection d intrusions sans le risque de conflits. Il faut envisager la configuration de tous les composants de sécurité (firewalls, IDS, VPN) comme un ensemble. Ainsi, le modèle Or-BAC avec son modèle d administration peut être utilisé pour fédérer les différentes phases de la politique de sécurité (fig. 4). Toutes les spécifications d une politique de sécurité seront présentes au niveau abstrait (I, fig.1). Les sujets, une fois identifiés, se voient attribuer des rôles. Ils auront ainsi le droit (Is_Permitted) de réaliser certaines actions sur des objets (des messages, leurs contenus, etc.). Par exemple, un routeur avec le sous-rôle IPSec_ESP réaliserait l action encapsulation sur des paquets (objets) ayant certains attributs et dans un certain context (par exemple, un intervalle temporel). Ensuite, seulement après la première transformation XSLT (fig. 4) vers le niveau intermédiaire, il faudra définir le deuxième ensemble de transformations en tenant compte de chaque technologie employée (firewall, IDS et VPN). Avec une telle approche, le risque de conflits inter composants et inter technologies peut être éliminé. Détection d anomalies dans les configurations de composants de sécurité réseau 19

20 3. Conclusion Cet état de l art met en exergue la difficulté de mettre en œuvre une politique de sécurité sur les composants réseau de manière à ce qu aucune anomalie ne puisse apparaître. Parmi les travaux présentés durant cet état de l art figurent ceux basés sur le modèle Or-BAC, apparaissant comme les plus prometteurs de par les résultats obtenus ou bien les outils d administration. Par dessus tout, son niveau d abstraction lui permet de s appliquer à des composants hétérogènes, parmi lesquels les firewalls, les IDS et les VPN. Concernant les perspectives et les objectifs du stage, elles seront liées à cette approche descendante : l expression d une politique de sécurité réseau basée sur Or-BAC, intégrant les exigences de filtrage sur les entités, des paquets IP, d analyse du contenu et de protection des communications. La politique de sécurité sera décomposée pour produire les configurations de différents composants de sécurité, en particulier des firewalls, IDS et VPN. Lors de la phase de déploiement, la topologie du réseau sera prise en compte. Avec cette stratégie de mise en place de la politique de sécurité réseau, le risque potentiel d anomalie de composants de sécurité devrait être diminué, voire éliminé. Détection d anomalies dans les configurations de composants de sécurité réseau 20

Détection d anomalies d configurations de composants de. stere.preda@enst-bretagne.fr

Détection d anomalies d configurations de composants de. stere.preda@enst-bretagne.fr Détection d anomalies d dans les configurations de composants de sécurité réseau Stere Preda stere.preda@enst-bretagne.fr 8 février 2006 Plan Contexte de l étude Anomalies dans la configuration des composants

Plus en détail

Détection d anomalies d configurations de composants de sécurité réseau

Détection d anomalies d configurations de composants de sécurité réseau Détection d anomalies d dans les configurations de composants de sécurité réseau Stere Preda stere.preda@enst-bretagne.fr 2 février 27 mars 2007 2007 Plan Contexte Problématique : gestion des anomalies

Plus en détail

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free.

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free. 2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES 2.2 Architecture fonctionnelle d un système communicant Page:1/11 http://robert.cireddu.free.fr/sin LES DÉFENSES Objectifs du COURS : Ce cours traitera essentiellement

Plus en détail

Sensibilisation à la sécurité informatique

Sensibilisation à la sécurité informatique Sensibilisation à la sécurité informatique Michel Salomon IUT de Belfort-Montbéliard Département d informatique Michel Salomon Sécurité 1 / 25 Sensibilisation à la sécurité informatique Généralités et

Plus en détail

La sécurité des Réseaux Partie 6.1 Les pare-feus

La sécurité des Réseaux Partie 6.1 Les pare-feus La sécurité des Réseaux Partie 6.1 Les pare-feus Fabrice Theoleyre Enseignement : INSA Lyon / CPE Recherche : Laboratoire CITI / INSA Lyon Références F. Ia et O. Menager, Optimiser et sécuriser son trafic

Plus en détail

Plan. Les pare-feux (Firewalls) Chapitre II. Introduction. Notions de base - Modèle de référence OSI : 7 couches. Introduction

Plan. Les pare-feux (Firewalls) Chapitre II. Introduction. Notions de base - Modèle de référence OSI : 7 couches. Introduction Plan Introduction Chapitre II Les pare-feux (Firewalls) Licence Appliquée en STIC L2 - option Sécurité des Réseaux Yacine DJEMAIEL ISET Com Notions de base relatives au réseau Définition d un pare-feu

Plus en détail

Chapitre 5 : IPSec. SÉcurité et Cryptographie 2013-2014. Sup Galilée INFO3

Chapitre 5 : IPSec. SÉcurité et Cryptographie 2013-2014. Sup Galilée INFO3 Chapitre 5 : IPSec SÉcurité et Cryptographie 2013-2014 Sup Galilée INFO3 1 / 11 Sécurité des réseaux? Confidentialité : Seuls l émetteur et le récepteur légitime doivent être en mesure de comprendre le

Plus en détail

Audit et Sécurité Informatique

Audit et Sécurité Informatique 1 / 69 Audit et Sécurité Informatique Chap 2: Firewall et Règles de Filtrage ACL Rhouma Rhouma https://sites.google.com/site/rhoouma Ecole superieure d Economie Numerique 3ème année Licence 2 / 69 Plan

Plus en détail

Tunnels et VPN. 20/02/2008 Formation Permanente Paris6 86. Sécurisation des communications

Tunnels et VPN. 20/02/2008 Formation Permanente Paris6 86. Sécurisation des communications Tunnels et VPN 20/02/2008 Formation Permanente Paris6 86 Sécurisation des communications Remplacement ou sécurisation de tous les protocoles ne chiffrant pas l authentification + éventuellement chiffrement

Plus en détail

PROBLÉMATIQUE D INTERCONNEXION DES RÉSEAUX IP

PROBLÉMATIQUE D INTERCONNEXION DES RÉSEAUX IP PREMIER MINISTRE Secrétariat général de la défense nationale Direction centrale de la sécurité des systèmes d information Sous-direction scientifique et technique Laboratoire Technologies de l Information

Plus en détail

Les pare-feux : concepts

Les pare-feux : concepts Les pare-feux : concepts Premier Maître Jean Baptiste FAVRE DCSIM / SDE / SIC / Audit SSI jean-baptiste.favre@marine.defense.gouv.fr CFI Juin 2005: Firewall (2) 15 mai 2005 Diapositive N 1 /19 C'est quoi

Plus en détail

Protection contre les menaces Prévention

Protection contre les menaces Prévention Protection contre les menaces Prévention Jean-Marc Robert Génie logiciel et des TI Plan de la présentation Introduction Prévention Routeurs Pare-feu Systèmes de prévention d intrusion Conclusions Jean-Marc

Plus en détail

Héritage de privilèges dans le modèle Or-BAC Application dans un environnement réseau

Héritage de privilèges dans le modèle Or-BAC Application dans un environnement réseau Héritage de privilèges dans le modèle Or-BAC Application dans un environnement réseau Frédéric Cuppens, Nora Cuppens-Boulahia et Alexandre Miège SSTIC 02-04 juin 2004 Plan Introduction Or-BAC dans la famille

Plus en détail

Firewall IDS Architecture. Assurer le contrôle des connexions au. nicolas.hernandez@univ-nantes.fr Sécurité 1

Firewall IDS Architecture. Assurer le contrôle des connexions au. nicolas.hernandez@univ-nantes.fr Sécurité 1 Sécurité Firewall IDS Architecture sécurisée d un réseau Assurer le contrôle des connexions au réseau nicolas.hernandez@univ-nantes.fr Sécurité 1 Sommaire général Mise en oeuvre d une politique de sécurité

Plus en détail

Administration réseau Introduction

Administration réseau Introduction Administration réseau Introduction A. Guermouche A. Guermouche Cours 1 : Introduction 1 Plan 1. Introduction Organisation Contenu 2. Quelques Rappels : Internet et le modèle TCP/ Visage de l Internet Le

Plus en détail

PCI (Payment Card Industry) DSS (Data Security Standard )

PCI (Payment Card Industry) DSS (Data Security Standard ) PCI (Payment Card Industry) DSS (Data Security Standard ) Jean-Marc Robert Génie logiciel et des TI PCI-DSS La norme PCI (Payment Card Industry) DSS (Data Security Standard) a été développée dans le but

Plus en détail

CONFIGURATION P 2 P 3 P 3 P 10 P 11 P 13 P 14 P 16

CONFIGURATION P 2 P 3 P 3 P 10 P 11 P 13 P 14 P 16 CONFIGURATION 1 Présentation 2 Topologie du projet 3 Installation 4 Configuration 4.1 Création de la DMZ publique 4.2 Accès vers l Internet 4.3 Publication d Exchange 4.4 Rapports d activité et alertes

Plus en détail

Jonathan DERQUE - Jean-Francois SMIGIELSKI. XVPND extended VPN Dæmon p.1/53

Jonathan DERQUE - Jean-Francois SMIGIELSKI. XVPND extended VPN Dæmon p.1/53 XVPND extended VPN Dæmon Jonathan DERQUE - Jean-Francois SMIGIELSKI XVPND extended VPN Dæmon p.1/53 Plan Introduction Présentation Implémentation Tests Perspectives d évolution Conclusion XVPND extended

Plus en détail

Architectures de communication. «Architecture protocolaire réseau» «protocolaire»

Architectures de communication. «Architecture protocolaire réseau» «protocolaire» Architectures de communication C. Pham Université de Pau et des Pays de l Adour Département Informatique http://www.univ-pau.fr/~cpham Congduc.Pham@univ-pau.fr «Architecture protocolaire réseau» Architecture

Plus en détail

MÉTHODES ET OUTILS DE LA DÉTECTION D INTRUSIONS

MÉTHODES ET OUTILS DE LA DÉTECTION D INTRUSIONS MÉTHODES ET OUTILS DE LA DÉTECTION D INTRUSIONS http://www.supelec-rennes.fr/rennes/si/equipe/lme/ Supélec BP28 35511 Cesson-Sévigné Cedex tél.: 02.99.84.45.00 Prévention et correction des problèmes de

Plus en détail

La sécurité des Réseaux Partie 6.2 VPN

La sécurité des Réseaux Partie 6.2 VPN La sécurité des Réseaux Partie 6.2 VPN Fabrice Theoleyre Enseignement : INSA Lyon / CPE Recherche : Laboratoire CITI / INSA Lyon Références F. Ia et O. Menager, Optimiser et sécuriser son trafic IP, éditions

Plus en détail

UE31 - M3102 : Services Réseaux

UE31 - M3102 : Services Réseaux UE31 - M3102 : Services Réseaux Enoncé du TP 4 NAT/PAT, Pare-Feu C. Pain-Barre Table des matières 1 Simulateur : Nat/Pat et firewall 2 Exercice 1 (Simulation Nat/Pat et firewall).................................

Plus en détail

Les RPV (Réseaux Privés Virtuels) ou VPN (Virtual Private Networks)

Les RPV (Réseaux Privés Virtuels) ou VPN (Virtual Private Networks) Les RPV (Réseaux Privés Virtuels) ou VPN (Virtual Private Networks) TODARO Cédric Table des matières 1 De quoi s agit-il? 3 1.1 Introduction........................................... 3 1.2 Avantages............................................

Plus en détail

Sécurité et Firewall

Sécurité et Firewall TP de Réseaux IP pour DESS Sécurité et Firewall Auteurs: Congduc Pham (Université Lyon 1), Mathieu Goutelle (ENS Lyon), Faycal Bouhafs (INRIA) 1 Introduction: les architectures de sécurité, firewall Cette

Plus en détail

Couche réseau : autour d IP. Claude Chaudet

Couche réseau : autour d IP. Claude Chaudet Couche réseau : autour d IP Claude Chaudet 2 ICMP : Signalisation dans IP Positionnement et rôle d'icmp IP est, en soi, un mécanisme simple dédié à l'acheminement de trames Il ne définit pas de messages

Plus en détail

Sécurité des réseaux IPSec

Sécurité des réseaux IPSec Sécurité des réseaux IPSec A. Guermouche A. Guermouche Cours 4 : IPSec 1 Plan 1. A. Guermouche Cours 4 : IPSec 2 Plan 1. A. Guermouche Cours 4 : IPSec 3 Pourquoi? Premier constat sur l aspect critique

Plus en détail

Tunnels et VPN. 22/01/2009 Formation Permanente Paris6 86

Tunnels et VPN. 22/01/2009 Formation Permanente Paris6 86 Tunnels et VPN 22/01/2009 Formation Permanente Paris6 86 Sécurisation des communications Remplacement ou sécurisation de tous les protocoles ne chiffrant pas l authentification + éventuellement chiffrement

Plus en détail

VPN L2TP/IPsec en utilisant un certificat X.509 v3

VPN L2TP/IPsec en utilisant un certificat X.509 v3 VPN L2TP/IPsec en utilisant un certificat X.509 v3 Installer une autorité de certification d entreprise : Dans notre cas de figure nous sommes dans un domaine qui s appelle «konoha.com». Une autorité de

Plus en détail

Sécurité des systèmes d information les firewalls

Sécurité des systèmes d information les firewalls Sécurité des systèmes d information les firewalls 1 Plan Définition et notions générales L offre Firewall actuelle Conception d une architecture sécurisée par firewall Administration et maintenance 2 Aperçu

Plus en détail

SSL ET IPSEC. Licence Pro ATC Amel Guetat

SSL ET IPSEC. Licence Pro ATC Amel Guetat SSL ET IPSEC Licence Pro ATC Amel Guetat LES APPLICATIONS DU CHIFFREMENT Le protocole SSL (Secure Socket Layer) La sécurité réseau avec IPSec (IP Security Protocol) SSL - SECURE SOCKET LAYER Historique

Plus en détail

Réseaux. Virtual Private Network

Réseaux. Virtual Private Network Réseaux Virtual Private Network Sommaire 1. Généralités 2. Les différents types de VPN 3. Les protocoles utilisés 4. Les implémentations 2 Sommaire Généralités 3 Généralités Un VPN ou RPV (réseau privé

Plus en détail

Travaux pratiques 8.4.2 Configuration des stratégies d accès et des paramètres de la zone démilitarisée (DMZ)

Travaux pratiques 8.4.2 Configuration des stratégies d accès et des paramètres de la zone démilitarisée (DMZ) Travaux pratiques 8.4.2 Configuration des stratégies d accès et des paramètres de la zone démilitarisée (DMZ) Objectifs Se connecter au périphérique multi-fonction et afficher les paramètres de sécurité

Plus en détail

Présentation du modèle OSI(Open Systems Interconnection)

Présentation du modèle OSI(Open Systems Interconnection) Présentation du modèle OSI(Open Systems Interconnection) Les couches hautes: Responsables du traitement de l'information relative à la gestion des échanges entre systèmes informatiques. Couches basses:

Plus en détail

TECHNICAL NOTE. Configuration d un tunnel VPN entre un firewall NETASQ et le client VPN. Authentification par clé pré-partagée. Version 7.

TECHNICAL NOTE. Configuration d un tunnel VPN entre un firewall NETASQ et le client VPN. Authentification par clé pré-partagée. Version 7. TECHNICAL NOTE TECHNICAL NOTE Configuration d un tunnel VPN entre un firewall NETASQ et le client VPN. Authentification par clé pré-partagée Version 7.0 1 TECHNICAL NOTE : SOMMAIRE SOMMAIRE SOMMAIRE 2

Plus en détail

Partagez plus avec Christie Brio

Partagez plus avec Christie Brio Partagez plus avec Christie Brio Plus de productivité. Plus de travail en équipe. Plus de choix Sommaire Christie Brio Enterprise Guide de déploiement Présentation..2 Où installer le boitier sur le réseau..

Plus en détail

TP4 : Firewall IPTABLES

TP4 : Firewall IPTABLES Module Sécurité TP4 : Firewall IPTABLES Ala Rezmerita François Lesueur Le TP donnera lieu à la rédaction d un petit fichier texte contenant votre nom, les réponses aux questions ainsi que d éventuels résultats

Plus en détail

Services réseau. 6.1 Clients, serveurs et leur interaction. 6.1.1 Relation client-serveur

Services réseau. 6.1 Clients, serveurs et leur interaction. 6.1.1 Relation client-serveur Page 1 sur 35 Services réseau 6.1 Clients, serveurs et leur interaction 6.1.1 Relation client-serveur Tous les jours, nous utilisons les services disponibles sur les réseaux et sur Internet pour communiquer

Plus en détail

Présentation et portée du cours : CCNA Exploration v4.0

Présentation et portée du cours : CCNA Exploration v4.0 Présentation et portée du cours : CCNA Exploration v4.0 Profil des participants Le cours CCNA Exploration s adresse aux participants du programme Cisco Networking Academy diplômés en ingénierie, mathématiques

Plus en détail

Aperçu technique Projet «Internet à l école» (SAI)

Aperçu technique Projet «Internet à l école» (SAI) Aperçu technique Projet «Internet à l école» (SAI) Contenu 1. Objectif 2 2. Principes 3 3. Résumé de la solution 4 4. Adressage IP 4 5. Politique de sécurité 4 6. Mise en réseau Inhouse LAN 4 7. Organisation

Plus en détail

Sécurité dans la couche Réseau. Daniel Wasserrab Andreas Wundsam

Sécurité dans la couche Réseau. Daniel Wasserrab <dwasserr@ens-lyon.fr> Andreas Wundsam <awundsam@ens-lyon.fr> Sécurité dans la couche Réseau Daniel Wasserrab Andreas Wundsam Articulation 1. Introduction a) Définition b) IPsec vs. protocoles de la couche application

Plus en détail

Règles de Firewall. Exemple de configuration ZyXEL Série ZyWALL USG. Mars 2010 / SRU

Règles de Firewall. Exemple de configuration ZyXEL Série ZyWALL USG. Mars 2010 / SRU Règles de Firewall Exemple de configuration ZyXEL Série ZyWALL USG Mars 2010 / SRU DEFINIR ET CONFIGURER LES REGES DE FIREWALL Mode de fonctionnement Les règles de firewall sont traitées par le ZyWALL

Plus en détail

DIFF DE BASE. Serendip serendip@via.ecp.fr. Samy samy@via.ecp.fr

DIFF DE BASE. Serendip serendip@via.ecp.fr. Samy samy@via.ecp.fr DIFF DE BASE Serendip serendip@via.ecp.fr Samy samy@via.ecp.fr I. INTRODUCTION AU RÉSEAU RÉSEAU : /ʁE.ZO/ N.M. DÉR., AU MOYEN DU SUFF. -EAU, DE L'A. FR. REIZ, REZ «FILET» (RETS); RÉSEAU A ÉTÉ EN CONCURRENCE

Plus en détail

Formation A2IMP. Acquisition d information sur les autres équipements du réseau. Frédéric Bongat IPSL Formation A2IMP 1

Formation A2IMP. Acquisition d information sur les autres équipements du réseau. Frédéric Bongat IPSL Formation A2IMP 1 Formation A2IMP Acquisition d information sur les autres Frédéric Bongat IPSL Formation A2IMP 1 Idée : corréler des informations via d autres Informations de base Connaître l horodatage (date, heure) des

Plus en détail

Page 1 2 La présente invention concerne le domaine des architectures informatiques, et en particulier un procédé pour le développement d applications destiné à un fonctionnement en réseau, par exemple

Plus en détail

Organisation du parcours M2 IR Les unités d enseignements (UE) affichées dans la partie tronc commun sont toutes obligatoires, ainsi que le stage et

Organisation du parcours M2 IR Les unités d enseignements (UE) affichées dans la partie tronc commun sont toutes obligatoires, ainsi que le stage et Organisation du parcours M2 IR Les unités d enseignements (UE) affichées dans la partie tronc commun sont toutes obligatoires, ainsi que le stage et l'anglais. L'étudiant a le choix entre deux filières

Plus en détail

MÉTHODES ET OUTILS DE LA DÉTECTION D INTRUSIONS

MÉTHODES ET OUTILS DE LA DÉTECTION D INTRUSIONS MÉTHODES ET OUTILS DE LA DÉTECTION D INTRUSIONS http://www.supelec-rennes.fr/rennes/si/equipe/lme/ Supélec BP28 35511 Cesson-Sévigné Cedex tél.: 02.99.84.45.00 Prévention et correction des problèmedesécurité

Plus en détail

Description des UE s du M2

Description des UE s du M2 Parcours en deuxième année Unités d Enseignement (UE) ECTS Ingénierie des réseaux haut 4 débit Sécurité des réseaux et 4 télécoms Réseaux mobiles et sans fil 4 Réseaux télécoms et 4 convergence IP Infrastructure

Plus en détail

Figure 1a. Réseau intranet avec pare feu et NAT.

Figure 1a. Réseau intranet avec pare feu et NAT. TD : Sécurité réseau avec Pare Feu, NAT et DMZ 1. Principes de fonctionnement de la sécurité réseau Historiquement, ni le réseau Internet, ni aucun des protocoles de la suite TCP/IP n était sécurisé. L

Plus en détail

Cours de sécurité. Pare-feux ( Firewalls ) Gérard Florin -CNAM - - Laboratoire CEDRIC -

Cours de sécurité. Pare-feux ( Firewalls ) Gérard Florin -CNAM - - Laboratoire CEDRIC - Cours de sécurité Pare-feux ( Firewalls ) Gérard Florin -CNAM - - Laboratoire CEDRIC - 1 Plan pare-feux Introduction Filtrage des paquets et des segments Conclusion Bibliographie 2 Pare-Feux Introduction

Plus en détail

Réseaux CPL par la pratique

Réseaux CPL par la pratique x CPL par la pratique X a v i e r C a r c e l l e A v e c l a c o n t r i b u t i o n d e D a v o r M a l e s e t G u y P u j o l l e, e t l a c o l l a b o r a t i o n d e O l i v i e r S a l v a t o

Plus en détail

Devoir Surveillé de Sécurité des Réseaux

Devoir Surveillé de Sécurité des Réseaux Année scolaire 2009-2010 IG2I L5GRM Devoir Surveillé de Sécurité des Réseaux Enseignant : Armand Toguyéni Durée : 2h Documents : Polycopiés de cours autorisés Note : Ce sujet comporte deux parties. La

Plus en détail

IPSec peut fonctionner selon deux modes, transport ou tunel.

IPSec peut fonctionner selon deux modes, transport ou tunel. Infrastructure PKI (public key infrastructure) Le cryptage symétrique Utilise la même clé pour crypter et décrypter un document Le cryptage asymétrique Utilise une paire de clé public et privée différente

Plus en détail

Plan. École Supérieure d Économie Électronique. Plan. Chap 9: Composants et systèmes de sécurité. Rhouma Rhouma. 21 Juillet 2014

Plan. École Supérieure d Économie Électronique. Plan. Chap 9: Composants et systèmes de sécurité. Rhouma Rhouma. 21 Juillet 2014 École Supérieure d Économie Électronique Chap 9: Composants et systèmes de sécurité 1 Rhouma Rhouma 21 Juillet 2014 2 tagging et port trunk Création des via les commandes sur switch cisco 1 / 48 2 / 48

Plus en détail

Bibliographie. Gestion des risques

Bibliographie. Gestion des risques Sécurité des réseaux informatiques Bernard Cousin Université de Rennes 1 Sécurité des réseaux informatiques 1 Introduction Risques Attaques, services et mécanismes Les attaques Services de sécurité Mécanismes

Plus en détail

Cours de Réseau et communication Unix n 6

Cours de Réseau et communication Unix n 6 Cours de Réseau et communication Unix n 6 Faculté des Sciences Université d Aix-Marseille (AMU) Septembre 2013 Cours écrit par Edouard Thiel, http://pageperso.lif.univ-mrs.fr/~edouard.thiel. La page du

Plus en détail

Services d infrastructure réseaux

Services d infrastructure réseaux Services d infrastructure réseaux Cours de Réseaux Tuyêt Trâm DANG NGOC Université de Cergy-Pontoise 2012-2013 Tuyêt Trâm DANG NGOC Services d infrastructure réseaux 1 / 30 Plan 1 Adressage

Plus en détail

Introduction. Licence MASS L3 Inf f3

Introduction. Licence MASS L3 Inf f3 Le modèle client serveur Introduction Licence MASS L3 Inf f3 Encapsulation : rappel Données Données Application En-tête En-tête Transport UDP Données TCP Données Paquet UDP Segment TCP En-tête IP Données

Plus en détail

Relier deux sites distants par un tunnel sécurisé. Nous utiliserons les technologies de cryptage :

Relier deux sites distants par un tunnel sécurisé. Nous utiliserons les technologies de cryptage : TUNNEL IPSEC OBJECTIF Relier deux sites distants par un tunnel sécurisé. Nous utiliserons les technologies de cryptage : AH : Authentification Header, protocole sans chiffrement de données ESP : Encapsulation

Plus en détail

MARCHE A PROCEDURE ADAPTEE

MARCHE A PROCEDURE ADAPTEE MARCHE A PROCEDURE ADAPTEE Pouvoir adjudicateur : Centre Hospitalier de Béziers 2 rue Valentin Haüy BP 740 34525 BEZIERS Libellé de la consultation : REMPLACEMENT DU PAREFEU-PROXY Objet du marché : Acquisition

Plus en détail

MASTER SIS PRO : logique et sécurité DÉTECTION D INTRUSIONS. Odile PAPINI, LSIS. Université de Toulon et du Var. papini@univ-tln.

MASTER SIS PRO : logique et sécurité DÉTECTION D INTRUSIONS. Odile PAPINI, LSIS. Université de Toulon et du Var. papini@univ-tln. MASTER SIS PRO : logique et sécurité DÉTECTION D INTRUSIONS Odile PAPINI, LSIS. Université de Toulon et du Var. papini@univ-tln.fr Plan Introduction Généralités sur les systèmes de détection d intrusion

Plus en détail

Table des matières AVANT-PROPOS... MODULE 1 : ENVIRONNEMENT... 1-1 MODULE 2 : ATTAQUES COURANTES... 2-1

Table des matières AVANT-PROPOS... MODULE 1 : ENVIRONNEMENT... 1-1 MODULE 2 : ATTAQUES COURANTES... 2-1 Table des matières AVANT-PROPOS... MODULE 1 : ENVIRONNEMENT... 1-1 Problématiques de la sécurité... 1-2 Domaines de la sécurité... 1-4 Buts de la sécurité informatique... 1-6 Niveaux de sécurité... 1-7

Plus en détail

Profil de protection d un pare-feu industriel

Profil de protection d un pare-feu industriel Version 1.0 court-terme GTCSI 13 juillet 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne le composant qui est l objet de l évaluation. Les passages en

Plus en détail

Services Réseaux - Couche Application. TODARO Cédric

Services Réseaux - Couche Application. TODARO Cédric Services Réseaux - Couche Application TODARO Cédric 1 TABLE DES MATIÈRES Table des matières 1 Protocoles de gestion de réseaux 3 1.1 DHCP (port 67/68)....................................... 3 1.2 DNS (port

Plus en détail

Cisco IDS Network Module pour les routeurs des gammes Cisco 2600, 3600 et 3700

Cisco IDS Network Module pour les routeurs des gammes Cisco 2600, 3600 et 3700 Fiche Technique Cisco IDS Network Module pour les routeurs des gammes Cisco 2600, 3600 et 3700 Cisco IDS Network Module fait partie des solutions intégrées de sécurité de réseau Cisco IDS (système de détection

Plus en détail

Le protocole SSH (Secure Shell)

Le protocole SSH (Secure Shell) Solution transparente pour la constitution de réseaux privés virtuels (RPV) INEO.VPN Le protocole SSH (Secure Shell) Tous droits réservés à INEOVATION. INEOVATION est une marque protégée PLAN Introduction

Plus en détail

Réseaux - Cours 3. IP : introduction et adressage. Cyril Pain-Barre. Semestre 1 - version du 13/11/2009. IUT Informatique Aix-en-Provence

Réseaux - Cours 3. IP : introduction et adressage. Cyril Pain-Barre. Semestre 1 - version du 13/11/2009. IUT Informatique Aix-en-Provence Réseaux - Cours 3 IP : introduction et adressage Cyril Pain-Barre IUT Informatique Aix-en-Provence Semestre 1 - version du 13/11/2009 1/32 Cyril Pain-Barre IP : introduction et adressage 1/24 TCP/IP l

Plus en détail

RESEAUX TCP/IP: NOTIONS AVANCEES. Preparé par Alberto EscuderoPascual

RESEAUX TCP/IP: NOTIONS AVANCEES. Preparé par Alberto EscuderoPascual RESEAUX TCP/IP: NOTIONS AVANCEES Preparé par Alberto EscuderoPascual Objectifs... Répondre aux questions: Quelles aspects des réseaux IP peut affecter les performances d un réseau Wi Fi? Quelles sont les

Plus en détail

Tunnels. Plan. Pourquoi? Comment? Qu est-ce? Quelles solutions? Tunnels applicatifs ESIL INFO 2005/2006. Sophie Nicoud Sophie.Nicoud@urec.cnrs.

Tunnels. Plan. Pourquoi? Comment? Qu est-ce? Quelles solutions? Tunnels applicatifs ESIL INFO 2005/2006. Sophie Nicoud Sophie.Nicoud@urec.cnrs. Tunnels ESIL INFO 2005/2006 Sophie Nicoud Sophie.Nicoud@urec.cnrs.fr Plan Pourquoi? Comment? Qu est-ce? Quelles solutions? Tunnels applicatifs 2 Tunnels, pourquoi? Relier deux réseaux locaux à travers

Plus en détail

LINUX - Sécurité. Déroulé de l'action. - 3 jours - Contenu de formation

LINUX - Sécurité. Déroulé de l'action. - 3 jours - Contenu de formation Objectif : Tout administrateur système et réseau souhaitant avoir une vision d'ensemble des problèmes de sécurité informatique et des solutions existantes dans l'environnement Linux. Prérequis : Connaissance

Plus en détail

Protocoles et services

Protocoles et services Protocoles et services Introduction Présentation Principaux protocoles PPTP GRE L2TP IPSec MPLS SSL Comparatif Démonstration Conclusion Besoins d une entreprise Avoir accès a un réseau local de n importe

Plus en détail

Topologies et Outils d Alertesd

Topologies et Outils d Alertesd Topologies et Outils d Alertesd IDS / IDP DEFINITIONS IDS : SDI / Système de détection d intrusion IDP : SPI / Système de protection d intrusion IDS / IDP Statfull matriciels ACTIVITE IDP : Coupe circuit

Plus en détail

Cours d histoire VPN MPLS. Les VPN MPLS B. DAVENEL. Ingénieurs 2000, Université Paris-Est Marne la Vallée. B. DAVENEL Les VPN MPLS

Cours d histoire VPN MPLS. Les VPN MPLS B. DAVENEL. Ingénieurs 2000, Université Paris-Est Marne la Vallée. B. DAVENEL Les VPN MPLS Les B. DAVENEL Ingénieurs 2000, Université Paris-Est Marne la Vallée B. DAVENEL Les Sommaire 1 2 3 4 B. DAVENEL Les Bibliographie PUJOLLE, Guy. Les réseaux, Quatrième édition, Eyrolles HARDY, Daniel. MALLEUS,

Plus en détail

IDS snort. Rémi JACHNIEWICZ et Romain GEGOUT 6 décembre 2008

IDS snort. Rémi JACHNIEWICZ et Romain GEGOUT 6 décembre 2008 IDS snort Rémi JACHNIEWICZ et Romain GEGOUT 6 décembre 2008 1 Table des matières 1 Les différents IDS 3 1.1 Les NIDS (Network IDS ou IDS Réseau)..................... 3 1.2 Les HIDS (Host IDS ou IDS Machine)......................

Plus en détail

CENTRE DE RESSOURCES INFORMATIQUES IFMA -------

CENTRE DE RESSOURCES INFORMATIQUES IFMA ------- CENTRE DE RESSOURCES INFORMATIQUES IFMA ------- CONSULTATION POUR DEMANDE DE DEVIS CAHIER DES CHARGES RELATIF AU CHANGEMENT DU FIREWALL DE L IFMA --------------- Date limite d envoi de l'offre : 3 septembre

Plus en détail

Alexis Lechervy Université de Caen. M1 Informatique. Réseaux. Filtrage. Bureau S3-203 mailto://alexis.lechervy@unicaen.fr

Alexis Lechervy Université de Caen. M1 Informatique. Réseaux. Filtrage. Bureau S3-203 mailto://alexis.lechervy@unicaen.fr M1 Informatique Réseaux Filtrage Bureau S3-203 mailto://alexis.lechervy@unicaen.fr Sécurité - introduction Au départ, très peu de sécurité dans les accès réseaux (mots de passe, voyageant en clair) Avec

Plus en détail

IPSec Internet Protocol Security

IPSec Internet Protocol Security IPSec Internet Protocol Security Rapport A4 Responsable : Richard Terrat SOMMAIRE 1. Introduction... 2 2. Services offerts par IPSec... 3 3. Les sous-protocoles... 4 3.1. Le sous-protocole AH... 4 3.2.

Plus en détail

Quelques propositions pour une organisation des ressources réseaux prenant en compte les besoins du LACL

Quelques propositions pour une organisation des ressources réseaux prenant en compte les besoins du LACL Quelques propositions pour une organisation des ressources réseaux prenant en compte les besoins du LACL Document de travail proposé par Olivier Michel LACL - P2 240 - olivier.michel@univ-paris12.fr Version

Plus en détail

Profil des participants Le cours CCNA Exploration s adresse aux participants du programme Cisco

Profil des participants Le cours CCNA Exploration s adresse aux participants du programme Cisco Présentation et portée du cours : CNA Exploration v4.0 Networking Academy Profil des participants Le cours CCNA Exploration s adresse aux participants du programme Cisco diplômés en ingénierie, mathématiques

Plus en détail

LINUX FIREWALL. Le firewall opèrera en fonction de règles de filtrage, appelées des ACL (Access Control Lists).

LINUX FIREWALL. Le firewall opèrera en fonction de règles de filtrage, appelées des ACL (Access Control Lists). 1 LINUX FIREWALL Introduction Un firewall ou pare-feu est un des composants essentiel à la sécurité informatique d un réseau. Il va permettre d isoler une ou plusieurs machines ou réorienter les requêtes

Plus en détail

Cisco Certified Network Associate

Cisco Certified Network Associate Cisco Certified Network Associate Version 4 Notions de base sur les réseaux Chapitre 6 01 Regardez le schéma d adressage IP illustré. Quel préfixe réseau y est adapté? /24 /16 /20 /27 /25 /28 02 Parmi

Plus en détail

Cisco Certified Network Associate

Cisco Certified Network Associate Cisco Certified Network Associate Version 4 Notions de base sur les réseaux Chapitre 3 01 Quel protocole de la couche application sert couramment à prendre en charge les transferts de fichiers entre un

Plus en détail

Réseaux. Moyens de sécurisation. Plan. Evolutions topologiques des réseaux locaux

Réseaux. Moyens de sécurisation. Plan. Evolutions topologiques des réseaux locaux Réseaux Evolutions topologiques des réseaux locaux Plan Infrastructures d entreprises Routeurs et Firewall Topologie et DMZ Proxy VPN PPTP IPSEC VPN SSL Du concentrateur à la commutation Hubs et switchs

Plus en détail

Installation et configuration de ZeroShell

Installation et configuration de ZeroShell Master 2 Réseaux et Systèmes informatiques Sécurité Réseaux Installation et configuration de ZeroShell Présenté par: Mor Niang Prof.: Ahmed Youssef PLAN 1. Présentation 2. Fonctionnalités 3. Architecture

Plus en détail

INF4420: Éléments de Sécurité Informatique

INF4420: Éléments de Sécurité Informatique : Éléments de Module III : Sécurité des réseaux informatiques José M. Fernandez M-3109 340-4711 poste 5433 Où sommes-nous? Semaine 1 Intro Semaines 2, 3 et 4 Cryptographie Semaine 6, 7 Sécurité dans les

Plus en détail

PACK SKeeper Multi = 1 SKeeper et des SKubes

PACK SKeeper Multi = 1 SKeeper et des SKubes PACK SKeeper Multi = 1 SKeeper et des SKubes De plus en plus, les entreprises ont besoin de communiquer en toute sécurité avec leurs itinérants, leurs agences et leurs clients via Internet. Grâce au Pack

Plus en détail

VPN Virtual PrivateNetworks

VPN Virtual PrivateNetworks VPN Virtual PrivateNetworks Préparé par: Ayoub SECK Ingénieur-Chercheur en Télécommunications Spécialiste en Réseaux IP et Télécoms mobiles Certifié: JNCIA, CCNA-SECURITY, CCNP,CCDP Suggestions: seckayoub@gmail.com

Plus en détail

L3 informatique Réseaux : Configuration d une interface réseau

L3 informatique Réseaux : Configuration d une interface réseau L3 informatique Réseaux : Configuration d une interface réseau Sovanna Tan Septembre 2009 Révision septembre 2012 1/23 Sovanna Tan Configuration d une interface réseau Plan 1 Introduction aux réseaux 2

Plus en détail

Présentation et portée du cours : CCNA Exploration v4.0

Présentation et portée du cours : CCNA Exploration v4.0 Présentation et portée du cours : CCNA Exploration v4.0 Dernière mise à jour le 3 décembre 2007 Profil des participants Le cours CCNA Exploration s adresse aux participants du programme Cisco Networking

Plus en détail

Sujet 2 : Interconnexion de réseaux IP (routeurs CISCO). Sujet 3 : Implémentation d un serveur VPN avec OpenVPN.

Sujet 2 : Interconnexion de réseaux IP (routeurs CISCO). Sujet 3 : Implémentation d un serveur VPN avec OpenVPN. UFC CENTRE DE BAB EZZOUAR EXEMPLES DE SUJETS POUR LE PROJET DE FIN D ETUDE OPSIE PROPOSES PAR M. NACEF (ENSEIGNANT) Sujet 1 : Management des risques par la méthode MEHARI. Type : étude, audit. MEHARI est

Plus en détail

PACK SKeeper. Descriptif du Pack SKeeper : Equipements

PACK SKeeper. Descriptif du Pack SKeeper : Equipements PACK SKeeper Destinée aux entreprises et aux organisations de taille moyenne ( 50 à 500 users ) fortement utilisatrices des technologies de l'information (messagerie, site web, Intranet, Extranet,...)

Plus en détail

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES Aristote ----- Cloud Interopérabilité Retour d'expérience L A F O R C E D E L I N N O V A T I O N Résumé Les systèmes d'information logistique (SIL) sont des outils qui amènent des gains de productivité

Plus en détail

Indicateur et tableau de bord

Indicateur et tableau de bord Agenda Indicateur et tableau de bord «La sécurité n est pas une destination mais un voyage» 1. Jean-François DECHANT & Philippe CONCHONNET jfdechant@exaprobe.com & pconchonnet@exaprobe.com +33 (0) 4 72

Plus en détail

Mettre en place un accès sécurisé à travers Internet

Mettre en place un accès sécurisé à travers Internet Mettre en place un accès sécurisé à travers Internet Dans cette partie vous verrez comment configurer votre serveur en tant que serveur d accès distant. Dans un premier temps, les méthodes pour configurer

Plus en détail

Expression, analyse et déploiement de politiques de sécurité - Application réseau -

Expression, analyse et déploiement de politiques de sécurité - Application réseau - Expression, analyse et déploiement de politiques de sécurité - Application réseau - Frédéric Cuppens Nora Cuppens-Boulahia Le contexte actuel Nombreux outils permettant de réaliser automatiquement des

Plus en détail

Cours réseaux Modèle OSI

Cours réseaux Modèle OSI Cours réseaux Modèle OSI IUT 1 Université de Lyon Introduction: le modèle OSI Un modèle théorique : le modèle OSI (Open System Interconnection) A quoi ça sert: Nécessité de découper/classifier l ensemble

Plus en détail

MISE EN PLACE DU FIREWALL SHOREWALL

MISE EN PLACE DU FIREWALL SHOREWALL MISE EN PLACE DU FIREWALL SHOREWALL I INTRODUCTION Administrateur réseau dans une petite entreprise, vous devez, suite à la mise en place d une ligne ADSL, offrir l accès à l internet à tous les utilisateurs

Plus en détail

Pile de protocoles TCP / IP

Pile de protocoles TCP / IP Pile de protocoles TCP / IP Fiche de cours La pile de protocoles TCP/IP est le standard de fait le plus utilisé au monde comme ensemble protocolaire de transmission dans les réseaux informatiques. La raison

Plus en détail

MINI-PROJET : ETUDE D UN MECANISME DE REDIRECTION DE PAGES WEB POUR AUTHENTIFIER UN UTILISATEUR WIFI

MINI-PROJET : ETUDE D UN MECANISME DE REDIRECTION DE PAGES WEB POUR AUTHENTIFIER UN UTILISATEUR WIFI Claire Billaud - 3ème année IS MINI-PROJET : ETUDE D UN MECANISME DE REDIRECTION DE PAGES WEB POUR AUTHENTIFIER UN UTILISATEUR WIFI Page 1 sur 9 Principe : On veut faire en sorte que le réseau interne

Plus en détail

TP réseau Les ACL : création d'une DMZ

TP réseau Les ACL : création d'une DMZ 1 But TP réseau Les ACL : création d'une DMZ Le but de se TP est de se familiariser avec l'utilisation des listes de contrôle d'accès étendues. Pour illustrer leur utilisation, vous allez simuler la mise

Plus en détail

SÉCURISATION DES CONNEXIONS À DISTANCE SUR LES RÉSEAUX DE CONTRÔLE

SÉCURISATION DES CONNEXIONS À DISTANCE SUR LES RÉSEAUX DE CONTRÔLE PUBLICATION CPA-2011-102-R1 - Mai 2011 SÉCURISATION DES CONNEXIONS À DISTANCE SUR LES RÉSEAUX DE CONTRÔLE Par : François Tremblay, chargé de projet au Centre de production automatisée Introduction À l

Plus en détail