urbanisation et architecture des systèmes …mfworld42.free.fr/cnam/nfe107_urbanisation...

Urbanisation et architecture des systèmes d’information

Sécurité des systèmes d’information

David Eudelineeudeline.david@free.fr

Plan du Cours

ContexteLes risquesVulnérabilités des applicationsProtocoles de sécurité

Les FirewallsInterconnexion des réseauxLes évolutionsConclusions

Contexte

Evolution des réseaux d’entreprise : ⌧Raccordement à l’Internet⌧Décentralisation/filialisation⌧Multiplications des interfaces (PDA, GSM, WIFI, etc.)⌧Multiplication des supports => Internet, sans fil, DSl,

etc.⌧Partage et gestion du patrimoine informationnel de

l’entreprise⌧Prolifération de la menace et banalisation des outils

d’attaques

Les risques, les attaques

Les attaques réseau

Les attaques sur les protocoles de communication:

Exploiter les failles des protocoles IP, ICMP, TCP, UDP

Les attaques sur les applications standards:Attaquer les applications classiques mises en œuvre dans les Intranet et l’Internet.

Les attaques

Les attaques sur l’information:La propagation de virusL’écoute réseauLa modification de données

Les attaque sur les systèmes:Le vol des mots de passe L’exécution de processus non autorisésL’accès aux fichiers et aux répertoires non autorisés

Typologies des attaques

Familles d’attaqueCaptureInterception, InterruptionInjectionModificationUsurpation

Typologies des attaquesCapture

Flux d’informations Flux d’informations

Typologies des attaquesInterception

Flux d’informations

Typologies des attaquesInjection

Flux d’informations Flux d’informations modifié

Typologies des attaquesModification

Flux d’informations Flux d’informations modifié

Typologies des attaquesUsurpation

Flux d’informations modifié

Typologies des attaques

Familles d’attaqueattaque directe : l’attaquant se connecte directement àsa cible (ex : exploitation d’une faille sur un serveur vulnérable) ;attaque par rebond (bounce) : l’attaquant passe par un relais pour mener son attaque (ex : relais ouverts ou zombies) ;attaque aveugle (blind) : l’attaquant lance son action sans en voir les résultats, directement ou non.

=> Ces familles d’attaques se combinent pour permettre àl’attaquant d’élaborer des scénarii

La menace

menaces naturellespertes 26%

sinistres 20 000 / an

menaces humainespertes 74%

environnementpertes 15%

pannes systèmespertes 11%

erreurs humainespertes 17%

malveillancepertes 26%

13% incendies, explosion dégâts des eaux, pollution, catastrophe naturelle2% arrêt services électricité, télécoms

5% pannes informatiques2% pannes réseaux internes4% saturation des réseaux

8% erreurs conception et réalisation9% erreurs exploitation et utilisation

2% vol ou sabotage matériel18% fraude

12% indiscrétion, intrusion, virus14% copie de logiciel

10% vol de ressources1% démission, absence, grève

Statistiques APSADmodifiéesFrance 1995 (12 GF)

renseignement découvrir l'architecture du système, son plan d'adressageécoute, furetage, espionnage, cryptanalyse

préparation dégrader ou contourner la sécuritéleurrage, sabotage, bombe logique, parasitage, saturation

intrusion entrer par un point faibleusurpation de nom, d'adresse, cheval de Troie, essais exhaustifs

installation installer une entrée permanenteporte dérobée, canal caché

camouflage cacher l'entrée permanentecacher les répertoires et fichiers pirates, inhiber la surveillance

propagation attaquer les machines ou systèmes en mutuelle confiancerebond IP ou X25, rhosts, domaines WinNT, virus, ver

processus itératif sur plusieurs cibles successives

Scénario d'intrusion

Renseignement

Phase préalable à toute attaque informatiqueSources ouvertes (Internet, presse…)Renseignement actif (scans réseaux…)

Préparation

L’agresseur se configure pour une attaqueRécupération d’outils adaptés à la situation

Intrusion

Phase la plus « active »Mise en œuvre des outilsExploitation des vulnérabilitésLe processus devient ici itératif (retour à une phase de renseignement)

Installation

L’intrusion prend parfois du tempsUne vulnérabilité exploitable à un instant t peut avoir été patchéeRevenir sur sa cible dans le futur s’avère alors fastidieux :

Installer une entrée permanente dans le système

Camouflage

Cacher les entrées permanentesInhiber les systèmes de journalisationEffacer ses tracesExistence des « rootkits »

Propagation

Poursuivre l’intrusion dans d’autres systèmesA partir de ce premier système intrusé(rebond)

Exemple de scénario (1)

Renseignement :scan « nmap »

Préparation :vulnérabilité IIS

Intrusion :Exploitation du bug

Installation du cheval de Troie

Prise de contrôle de la cible

Installation :déploiement d’outils plus sophistiqués (VNC, Bo2k…)

Camouflagesuppression des traces, inhibition des logs

PropagationExploration du réseau interne

Vulnérabilités des applications

Les couches TCP/IP servent de support à des applications orientées utilisateur qui fournissent une certain nombre de services.Les vulnérabilités peuvent être:

De conception (Pas d’authentification)D’implémentation (buffer overflow RPC ou Sendmail)De configuration (Relayage SMTP…)

Vulnérabilités : DNS

Service de noms pour Internet.Le DNS est une ressource critique sur l’Internet => résolution de noms (approche infrastructure critique)Protocole utilisé:⌧UDP/53 et TCP/53 pour les paquets plus volumineux

Les données sont organisées hiérarchiquement en zone⌧A: nom des machines/adresse IP⌧MX : serveur SMTP du domaine⌧SOA: données administrative de la zone considérée⌧NS: serveur de la zone

Vulnérabilités : DNS

domaine

zone.orange.fr .gouv.fr

Paris.orange.fr

bdx.univ.frlyon.univ.fr

rennes.univ.fr

.univ.fr

.fr .com

defense.gouv.frsgdn-pm.gouv.fr

. root

top level

DNSEntités impliquées

Serveur maitre ou primaireserveur d’autorité d’une zone (SOA)responsable de la définition des correspondances nom/@IP pour sa zoneun seul par zone.

Serveurs esclaves ou secondairesrecopient tout ou partie des informations situés sur le serveur maître⌧ décharger le serveur maître et le suppléer en cas de problème⌧ utilisation des « transferts de zone » pour récupérer en masse les informations du serveur

maitre.Serveurs relais ou caches

proxys stockant les informations des serveurs de nom un certain temps.⌧ Stockage temporaire des résultats des requêtes émises par les clients pour réutilisation.

Les clients finauxdisposent d’un « resolver » installé en localDisposent eux aussi d’un cache DNS

DNSModes de fonctionnement des serveurs

Si Le serveur ne sait pas résoudre un nom, deux modes sont possibles:

Mode itératif⌧il renvoie l’adresse d’un autre serveur susceptible d’effectuer cette

résolution;⌧charge au client de se réitérer sa requête sur le nouveau serveur;

Mode récursif⌧le serveur effectue les différentes requêtes sur les autres serveurs à la

place du client⌧lui renvoie la réponse complète⌧Transparent pour le client⌧Charge non négligeable pour le serveur (attaques en déni de service plus

probables).

DNSVulnérabilités DNS: tunneling DNS

Fuite d’information via des canaux cachésTunneling autonome:

Utilisation des ports DNS pour établir un Tunnel (SSH, OpenVPN…)Parades: ⌧filtrer correctement les flux,⌧interdiction aux clients d’accéder directement aux serveurs externes (serveurs

relais)Tunneling évolué

Passage des données au dessus des requêtes DNS (NSTX, OzymanDNS)⌧Nécessite de disposer d’un serveur maitrisant une zone externe⌧Autorise les requêtes à être relayées

Parades:⌧:’(⌧Interdiction complète des flux DNS émis par les clients

• utilisation de proxys (HTTP/S, SMTP) avec authentification qui réécriront les requêtes DNS => pas d’attaques automatisées

DNSVulnérabilités DNS: corruption de

résolution

Objectif: Redirection du trafic d’un clientUsurpation de site web, sniff de flux, réalisation de man in the middle, etc.

Interception réseauDétournement des flux réseau (ARP cache poisoning, spoofingUDP…), Usurpation d’adresses d’autres serveurs (DHCP par exemple) si mises à jour dynamiquesParades:⌧Architecture mise en place

• Déploiement de serveurs internes et externes en DMZ• Passage obligé par des serveurs relais

⌧Cloisonnement réseau• Switchs, firewalls, routeurs, etc…

⌧Segmentation de l’arbre DNS et positionnement d’ACL (≠ mises à jour dynamiques)

⌧Authentification TSIG

DNSVulnérabilités DNS: corruption de

résolution

Objectif: Redirection du trafic d’un clientUsurpation de site web, sniff de flux, réalisation de man in the middle, etc…

Attaques des clientsModifier les paramètres locaux des clients (fichiers hosts, paramètres de conf DNS, etc…)Parades: sécurisation locale correcte (Droits utilisateur, ACL, etc…)

Failles des serveurs (exemples)DNS spoofing: envoi d’informations erronées en plus de celles demandéesId prédiction: répondre à la place du serveurGlue fetching: en cas de réception d’un enregistrement NS, tentative de récupérer un enregistrement de type A correspondantParades: utilisation de serveurs DNS récents

DNSVulnérabilités DNS: déni de service

Objectif: rendre indisponible ce service critiqueMéthodes d’attaque habituelles, saturation en requêtesParades:

Architecture bien pensée (serveurs relais, DMZ)Restriction des transferts de zoneInterdiction de récursion sur les serveurs exposésContrôle des requêtes simplesRestrictions des notifications

DNSArchitecture type

Internet

DNS Externe SOAAdresse internes publiées

DNS cache DMZPour sortir vers l’extérieur

DNS Interne SOAProtégé, les clientsn’y accèdent jamais

Proxy HTTP

ClientDNS cache interneCache du DNS Interne SOA

DNSMécanismes complémentaires: TSIG

Mécanisme d’authentification• Signature des échanges

• Entre serveurs primaires et secondaires• pour les mises à jour dynamique• entre un resolver et un serveur cache

éventuellement • cryptographie symétrique

• Gestion des clés difficile• empêche une utilisation à grande échelle (entre un

resolver et un serveur primaire par exemple).

DNSMécanismes complémentaires: DNSsec

Extensions de sécurité DNSBasé sur de la cryptographie asymétrique

Fournit:Gestion des clés interne au DNS⌧Stockage et diffusion des clés⌧Peut être utilisé par d’autres protocoles (TLS)Authentification de l’origine des données et intégritéAuthentification des requêtes

DNSMécanismes complémentaires: DNSsec

Principe:Signature des zonesStockage de clés publiques et certificats⌧Vérification de signatures⌧Distribution de certificats

Ajout de nouveaux enregistrements: ⌧KEY: stockage des clés⌧SIG: signatures⌧NXT: informations d’inexistence⌧DS: stockage de certificats (condensé)

Limites:Performances (nombre d’enregistrements, taille des messages, vérifications crypto)Phase transitoire (notion d’îlots de sécurité disjoints)Gestion difficile des révocations

Le protocole DHCP (Dynamic Host Configuration Protocol) est une évolution du protocole BOOTP. Gestion et l'attribution centralisée de la configuration IP des stations d'un réseau. (config par défaut de XP)Broadcast UDP sans mécanisme d'authentification. Vulnérabilités

L'épuisement d'adresses : l'attaque consiste à émettre des demandes d'adresses en rafale (en prenant bien garde de changer d'adresse MAC àchaque demande). Lorsque le serveur a délivré toutes ces adresses, les stations ne peuvent plus accéder au réseau Le faux serveur : le principe consiste à prendre la place du serveur DHCP officiel (après l'avoir mis hors service par un déni de service). Dans ce cas, il est facile de délivrer aux stations de fausses informations, telles que la passerelle par défaut, l'adresse IP du serveur DNS.

Vulnérabilités : SMTP

Protocole de messagerie électronique pour l’Internet.

Port utilisé: N°25.A été pendant longtemps une source intarissable de vulnérabilités.Ce protocole fonctionne en mode texte, il est facilement attaquable.Le protocole n’embarque pas de service de sécurité⌧Pas de garantie d’intégrité ni de non répudiation⌧Pas d’authentification

Vulnérabilités : SMTP

Vulnérabilités:⌧spoofing : Usurpation d’identité⌧Pièces jointes malveillantes : virus, ver, contenus actifs, type

MIME falsifiés⌧ bombing: Envoi d’un grand nombre de messages afin de saturer

le serveur et noyer le trafic réel, déni de service⌧ spamming: Envoi d’un message à un grand nombre de

personnes. Usurpation d’identité⌧Relayage⌧Logiciel client et serveur (Sendmail ,Exchange, Domino, etc.)

• Bug logiciel, relayage, exécution de code non autorisé (Outlook)⌧Web bug: une image est incorporé sous forme de lien html dans

le corps du message => donne des informations au serveur WEB.

Vulnérabilités SMTP

telnet sur le port 25 du serveur SMTP (serveur de son FAI)EHLO: pour dire de quelles machine on envoie le mail (le srvpeut faire une requête DNS pour vérifier l’adresse de l’attaquant)MAIL FROM : expéditeurRCPT TO: destinataireDATA: corps du message

NOTA: le serveur SMTP de neuf autorise le relayage pour son réseau interne.VRFY, EXPN, etc.

telnet smtp.neuf.fr 25smtp.neuf.fr OKEHLO my_pc@home.com250 OKMAIL FROM : chirac@elysee.org250 OKRCPT TO: eudeline.david@free.fr250 OKDATABonjour je lâche l’Elysée et on se fait

une bouffe.

Protocole de récupération des courriers électroniques des utilisateurs

Port 110Authentification des utilisateurs par login/mot de passe en clairCommande LIST pour récupérer les mails de l’utilisateur

POP: capture réseau

Mot de passe!

Protocole de gestion des équipements réseauxUDP, Port 161 et 162 (trap)Nom de communauté en clair (par défaut public et private)Vulnérabilités

Récupération d’informations de configuration et de supervision (SNMP-GET)Modifications du paramétrage voire réinitialisation de l’équipement (SNMP-SET)

Vulnérabilités : FTP

Protocole de transfert de fichiers pour Internet.Port utilisé: N°21 pour les commandes, N° 20 pour le transfert des données.Les serveurs peuvent gérer de l’authentification ou laisser passer les connexions anonymes.Le mot de passe transite en clair sur le réseau lors de l’authentification.Avec SMTP, a été une source importante de vulnérabilités.

L’attaque : « FTP bounce»

Principe : utiliser un serveur FTP vulnérable comme système de rebond ;

Connexion à un serveur FTP en mode PassifL’attaquant lance une commande PORT (conforme à la RFC) en précisant l’adresse IP de la victime et un numéro de port ouvert sur la machine de la victimeLe serveur FTP ouvre la connexion de DATA sur la victimeL’attaquant envoi des données sur cette connexionL’attaque semble venir du serveur FTP

L’attaque : « FTP bounce»

Attaquant

Victime

Serveur FTPVulnérable

1) Con

nexion

FTP passi

2) PORT @

IP Vict

ime, p

ort 25

3) Connexion vers le port 25 (SMTP)

4) Envoi des données

Dépose d’un fichier de commande sur le serveur FTPEnvoi d’une commande GET avec comme @source l’adresse de la cible

HELO ftp.vuln.comMAIL FROM : toto@ftp.vuln.comRCPT TO : victime@cible.comDATACeci est un faux mail

Vulnérabilités : Services interactifs

Les protocoles telnet, rlogin, et les r-commandes permettent de se connecter à distance.

Le mot de passe transite en clair sur le réseau lors de l’authentification pour telnet (1 lettre par paquet).Rlogin et r-cmd : Le mot de passe transite dans un seul paquet si un mécanisme de confiance (rhosts ou équivalent) n’est pas implémenté.Ces protocoles sont dangereux car les ordres et les données transitent en clair en mode texte.

Parade: SSH (Secure Shell) permet de signer/chiffrer entre le client et le serveur pour les service interactifs => administration à distance

Vulnérabilités : X Window

X Window : Standard pour l’IHM des systèmes UNIX, le protocole X11 permet de faire transiter les ordres sur le réseau.

X11 n’est pas sécurisé par défaut, il n’y a pas d’authentification à moins de mettre en œuvre Xauthority.Les utilisateurs ont la possibilité d’ouvrir des fenêtres à distance (commande xhosts)Magic cookies

Vulnérabilités : Web

Le protocole HTTP permet de transférer des fichiers au format HTML.

les serveurs sont très complexes, de nombreux problèmes de sécurité(bugs sur la gestion des chemins, buffer overflow, entre autres exemples)L’exécution de scripts CGI sur le serveur ou d’appliquettes JAVA sur le client peut entraîner des problèmes liés aux failles d’implémentation du protocole HTTP et de la machine virtuelle JAVA (crash machine, perte de données, etc.).Pistes de solutions : Utilisation d’un relais applicatif (proxy) et paramétrage correct.les Navigateurs peuvent transférer de l’information à l’insu de l’utilisateur (e.g. cookies)

Vulnérabilités: Service Web

Domaine marqué par l’ouverture, la standardisation et le BtoB

Sécurisation des transactions distribuées sur InternetGestion de transactions longue duréeOuverture et exposition des services aux travers des annuaires en font des cibles privilégiéesLa sécurité des WS doit être traitée à plusieurs niveaux (Web, transactions, SGBS, etc.)Sécurisation transverse : responsabilité partagée, standards à définir

Vulnérabilités: Service Web

Besoin de disposer de technologies spécialement conçues pour gérer la sécurité des Services WebNécessité de répondre aux besoins de sécurité en traitant la sécuritédirectement au niveau des messages en conservant un contexte de sécurité de bout en bout, de l’expéditeur au destinataireTrois niveaux de sécurisation des Services Web peuvent être envisagés :

Au niveau transport, pour répondre aux besoins de confidentialité, d’intégrité et d’authentification du message point à point,Au niveau échange, pour répondre aux besoins de confidentialité, d’intégrité et d’authentification de message bout en bout,Au niveau application, pour répondre aux besoins d’authentification et

d’autorisation des participants.Les nouvelles technologies de sécurité pour les Services Web tendent àcouvrir la gestion de la sécurité au niveau échange et application

Vulnérabilités: VoIP

Protocole utilisés:SIP: signalisationRTP: transport des informationsPas de mécanismes de sécurité embarqués dans ces protocolesVuln⌧Redirection par corruption du call manager⌧Spoofing DHCP, firmware/configuration

Vulnérabilités: peer to peer

BitTorrent, EdonkeyPas d’authentification, pas de chiffrement, pas d’intégritéSupporte mal les pare feux.

JXTADispose d’une infrastructure pour la prise en compte de la sécurité.

Protocoles de sécurité

Protocoles sécurisés

S/MIME SHTTP

SSL/TLS

IPv6IETF

IPSecIETF

Lotus Notes

L2TP, 802.1xIETF

PPTPMicrosoft

niveau OSI 7 - application

niveau OSI 3 - réseau - routeurs - tunnel

niveau OSI 2 - liaison - ponts - tunnel

niveau OSI 4 - transport

802.1x

standard pour l’authentification des machines sur le réseau développé par l’IEEE en 2001Phase obligatoire avant tout accès au réseau filaire ou wi-fiS’appuie sur le protocole EAP (Ppp Extensible Authentification Protocol) (RFC 2283)Le protocole EAP transporte les informations d’authentification vers un serveur d’authentificationSupporte plusieurs méthodes d’authentification

Login/mot de passeRadiusPki, etc.

Permet d’attribuer automatiquement un VLAN ou un accès réseau à un utilisateurUtilisé par les commutateurs et les points d’accès WI-FI

802.1x

ComposantsSupplicant :Client du protocoleAuthenticator System : contrôle le PAE (Port Access Entry) objet de convoitise du supplicantAuthenticator server : serveur traitant l’authentif (Radius par exemple ou autre)

EAP sur support niv 2 EAP sur radius

802.1x

PAE : le port est scindé en deux entités logiquesUne supportant uniquement le protocole EAP pour la phase d’authentification (ouvert)Une offrant la connexion logique au commutateur (état dépendant de la phase d’authentification

Vulnérabilités: cascade avec des concentrateurs

Source: [Saccavini]

RADIUS

Remote Authentification Dial In User Service Protocole d’authentification réseausoumis en 1996 à l'IETF

RFC 2058 pour l'authentification RFC 2059 pour la journalisationDernière version : RFC 2865 de juin 2000

Acteurs du protocolele poste utilisateur ; il s’agit de la station de travail à partir duquel est émis la requête d’authentification,le client RADIUS ; il s’agit du point d’accès au réseau (serveur RAS, Firewall, routeur…)le serveur RADIUS ; le point central où les clients transmettent les données d’authentification.

RADIUS

RADIUS utilise le port UDP 1812Connexion du poste utilisateur au client RADIUS avec fourniture des éléments d’authentification, le client transmet ensuite les éléments au serveur qui valide ou non les éléments présentésNOTA: Phase 1 en clair, phase 2 et 3 chiffrée par un secret pré partagé entre le client et le serveur RADIUS.

PosteUtilisateur

ClientRADIUS

ServeurRADIUS

Connexion

Request Authenticator

Response Authenticator3

Response Authenticator = f(Request Authenticator, )

Clair Chiffré

Internet Protocol Security (IPSec)Standard IETFLes RFC spécifie les en-têtes AH (RFC 2402) et ESP (RFC 2406)

Services:Authentification (des hosts)Intégrité des donnéesConfidentialitéNon répudiationAnti rejeu

ModesLe mode transport protège uniquement le contenu du paquet IP sans toucher à l’en-tête ; ce mode n’est utilisable que sur les équipements terminaux (postes clients, serveurs).Le mode tunnel permet la création de tunnels par « encapsulation » de chaque paquet IP dans un nouveau paquet. Ainsi, la protection porte sur tous les champs des paquets IP arrivant à l’entrée d’un tunnel, y compris sur les champs des en-têtes (adresses source et destination par exemple). Ce mode est celui utilisé par les équipements réseau (routeurs, gardes-barrières...).

IPSEC: en têtes

Les services de sécurité d’IPSEC sont fournis au travers de deux extensions du protocole IP appelées AH (Authentication Header) et ESP (Encapsulating Security Payload).Authentication Header (RFC 2402)

AH est conçu pour assurer l’authenticité des paquets IP sans chiffrement des données. Le principe d’AH est d’adjoindre aux paquets IP un champ supplémentaire permettant à la réception de vérifier l’authenticité des données. Un numéro de séquence permet de détecter les tentatives de rejeu.

Encapsulating Security Payload (RFC 2406)ESP a pour rôle premier d’assurer la confidentialité des données mais peut aussi être utilisé pour assurer l’authenticité de celles-ci. Le principe d’ESP consiste à encapsuler dans un nouveau paquet IP le paquet d’origine mais sous une forme chiffrée. L’authenticité des données peut être obtenue par l’ajout d’un bloc d’authentification et la protection contre le rejeu par celui d’un numéro de séquence.

IPSEC: en têtes

AH en mode transport: Un en-tête AH est inséréentre l’en-tête IP et les données du paquet.

En-tête IP Données

En-tête IP DonnéesAH

IPSEC: en têtes

AH en mode tunnel: Le paquet d’origine est encapsulé dans le champ de DATA d’un nouveau paquet, possédant son propre en-tête, et auquel on adjoint un AH.

En-tête IP DonnéesAHNouvel En-tête IP

IPSEC: en têtes

ESP en mode transport: On conserve l’en-tête IP d’origine, auquel on ajoute un en-tête ESP suivi du champ de DATA du paquet d’origine sous forme chiffrée et d’un trailer ESP, puis on complète le paquet avec les données d’authentification (ce champ n’est présent que si l’option d’authentification a été sélectionnée).Le « trailer ESP » contient éventuellement des octets de bourrage, la taille des octets de bourrages et un pointeur sur l’en-tête suivant

En-tête IPd’origine DonnéesESP Trailer ESP Données

d ’authentification

Chiffré

Authentifié

IPSEC: en têtes

ESP en mode tunnel: On chiffre intégralement le paquet d’origine suivi d’un trailer ESP, puis on insère ce flux dans un nouveau paquet disposant de son propre en-tête, suivi d’un en-tête ESP et se terminant par des données d’authentification (ce champ n’est présent que si l’option d’authentification a été sélectionnée).

Chiffré

Authentifié

NouvelleEn-tête IP DonnéesESP Trailer ESP Données

d ’authentificationEn-tête IPd ’origine

IPSEC: en têtes

OriginalIP Header

HeaderESP

Authentication / Integrity

Encrypted

OriginalIP Header

HeaderAH

TransportMode

TunnelMode

Encrypted

New IPHeader

HeaderESP

OriginalIP Header

New IPHeader

HeaderAH

OriginalIP Header

Architectures de sécuritéLe protocole IPSec permet plusieurs combinaisons d'ESP et d'AH en plusieurs niveaux d'encapsulation. Quatre architectures sont décrites par la RFC 2401. ⌧dialogue entre deux hôtes⌧dialogue entre deux réseaux locaux à l'aide de passerelles de

sécurité⌧dialogue entre deux hôtes traversant deux passerelles de sécurité⌧dialogue entre un hôte et une passerelle de sécurité

Modes d’utilisations d’IPsec

Mode transport Cryptage/authentification entre le client et le serveur

Crypté

Mode tunnelCryptage/authentification uniquement entre les extrémités du tunnel

Crypté

IPSec – Gestion des clés

IKE: Internet Key Exchange (RFC 2409)Protocole de négociation global des AS (associations de sécurité)Comprend ISAKMP, OAKLEY et SKEMEISAKMP Protocole pour la négociation, l’établissement, la modification et la destruction des associations de sécurité et de leurs attributs. ISAKMP est défini dans la RFC 2408.SKEME et Oakley, protocoles d’échange de clés de session.IKE peut s’appuyer sur une infrastructure PKI pour la gestion et la distribution des clés.

IPSec – Gestion des clés

IKE: Internet Key Exchange (RFC 2409)Permet de construire des associations de sécurité en s’appuyant sur les politiques de sécurité et les algorithmes de chiffrement disponibles chez les acteurs (ainsi que les tailles de clefs disponibles).ISAKMP se déroule en deux phases⌧1. La première phase permet de vérifier l’identité des entités en présence.

Les machines décident des algorithmes de cryptographie utilisés pour les futures négociations ISAKMP. À la fin de cette phase, chaque entité doit disposer d’une clé de chiffrement, d’une clé d’authentification et d’un secret partagé.

⌧2. La seconde phase permet de négocier les attributs plus spécifiques àIPSec (utilisation d’AH ou d’ESP par exemple). Ces échanges sont chiffrés et authentifiés grâce aux éléments décidés lors de le première phase.

Evolution du protocole IPV4Extension du routage et de l’adressageFacilite la migrationPeut intégrer des mécanismes de sécurité tels qu’IPSecFacilite les extensions protocolaires

SSL/TLS

SSL (Secure Socket Layer) est un protocole développé par Netscape en 1994 (en relation avec MasterCard, Bank of America, MCI et SiliconGraphics), existant actuellement en version V3 et repris par l'IETF sous le nom TLS V1 depuis 1999.Propose des services de sécurisation de la couche transport en s’appuyant sur une couche fiable (ie: TCP)Utilisé par les applications pour sécuriser les échanges entre client et serveur.

SSL/TLS: Architecture

TCP/IP

SSL/TLS

HTTP POP IMAP R-cmd LDAP

SSL/TLS: Services

AuthentificationDu serveur en SSL 2.0 (présentation du certificat serveur)Du client et du serveur en SSL 3.0 (échange de certificat)

ConfidentialitéCréation d’un tunnel sécurisé entre le client et le serveur via l’élaboration d’une clef de session

IntégritéPar le hachage des messages

SSL/TLS: Protocole

Trois protocoles sont définis:Handshake protocol : Authentification des parties, négociation des éléments secrets (les parties échangent les algorithmes qu’ils supportent)Record protocol : Permet le fractionnement et le transport des informations.Alarm protocol: envoie de messages d’alerte entre client et serveur.

SSL/TLSHandshake Protocol 2.0

SSL/TLSHandshake Protocol 3.0

client_hello

server_hello

change_cipher_spec

certificate

server_key_exchange

certificate_request

server_hello_done

certificate

client_key_exchange

certificate_verify

finished

change_cipher_spec

finished

Version, alea, id session,Cipher suite, algo compression

Certificat X509

Paramètres, signature

Genre, autorités

Paramètres, signature

Signature

condensat

Phase 1

Phase 2

Phase 3

Phase 4

KERBEROS

KERBEROS - Rappels

Développé initialement au MIT, dans le cadre du projet Athena au début des années 80Version courante : Kerberos V5V4 et V5 sont non-interopérablesWindows 2000/2003 implémente Kerberos V5

Kerberos - Généralités

PrincipesBasé sur la notion de « Ticket »Cryptographie à clefs secrètesAuthentification mutuelleTickets limités dans le tempsMécanismes anti-rejeux

Kerberos V5Améliorations par rapport à V4 (tickets transferrables, time stamps…)Standards IETF : RFCs 1510 et 1964

Architecture

L’architecture de Kerberos constitue une architecture 3 tiers :

un clientun serveur de ressourcesune autorité approuvée

L’autorité approuvée :est un serveur dit « de confiance », reconnu comme tel par le client et le serveuret dont on présuppose qu’il est parfaitement sécurisé

Terminologie (1/2)

Un « principal » Kerberos :est un client du protocole Kerberos, identifiable par un nom unique.Un utilisateur, un client, un serveur ou une application sont des « principaux » Kerberos

Une autorité approuvée (AA):stocke les informations de sécurité relatives aux principauxgénère et gère les clefs de session

Terminologie (2/2)

Un « royaume » Kerberos :est une organisation logique dans laquelle s'exécute au moins une AA,est capable d’authentifier les principaux déclarés sur ce serveur.

Un KDC (Key Distribution Center):est le nom donnée dans Windows 2000 àl’autorité approuvée.

Notion de ticket

Un ticket est une structure de données constituée d’une partie chiffrée et d’une partie claire.Les tickets servent à authentifier les requêtes des principauxDeux type de Tickets :

Ticket Granting Ticket (TGT)Ticket Granting Service (TGS)

Services Kerberos

Deux types de services sont requis :un service d’authentification (AS ou Authentication Service)un service d’octroi de tickets (TGS ou Ticket Granting Service)

Ces services ne tournent pas nécessairement sur le même serveur

Clefs cryptographiques

Dans Kerberos, une AA (ie un KDC) génère et stocke les clefs secrètes (Ksec) des principaux qui lui sont rattachés.Pour des raisons de sécurité, ces clefs secrètes ne servent que lors de la phase initiale d’authentificationDans toutes les autres phases, on utilise des clefs de session « jetables »

KERBEROSAuthentification et accès aux ressourcesDescription des échanges

Authentification initiale

1 : Requête d’authentification

2 : Emission d’un Ticket TGT

La requête initiale contient (en clair) l’identité du requérant et le serveur pour lequel on demande un TGT.Le serveur émet un TGT pour le clientLa partie chiffrée l’est avec la clef Ksec du client => seul le bon client peut déchiffrer cette partie

Demande d’un TGS

1 : Requête de ticket de service

2 : Emission d’un Ticket TGS

On utilise le TGT obtenu précédemment pour requérir un TGSLe serveur émet un TGS pour le client et pour le service considéré

Accès au service

1 : Requête de service

2 : Poursuite des échanges

On utilise le TGS obtenu précédemment pour accéder au serviceLe serveur de ressources valide alors (ou non) la requête

Résumé

Connexion

3 Demande deTGS

5 Demande d ’accèsau service

6Validation

AS Service TGS Service

Serveur deressource

Kerberos - limitations

Mécanismes de chiffrement symétriques: nécessitent un partage et une mise à jour des clefs entre les différents serveurs d’administration et les clients. Kerberos ne prend pas en compte les aspects d’autorisation : c’est à chaque système de s’adapter à Kerberos pour traiter la problématique de l’accès aux ressources.L’utilisation des horodatages permet d’éviter le rejeu sauf si les horloges locales sont trop désynchronisées, ou si le service d’horloge est piraté. Dans ce cas, il y a un risque de rejeu ou de refus de service de la part du serveur. Kerberos nécessite donc un service de temps fiable.

Structure d’un Ticket Kerberos

Champ Descriptiontkt-vno Version (5)realm Royaume d'origine du ticketsname Nom de l'AA ayant délivré le ticketflags Drapeaux d'états du ticketkey Clef de session pour l'échange futurcrealm Royaume d'origine du clientcname Nom du client

transited Liste des royaumes ayant pris part dans le schéma d'authentification

authtime Horodatage de l'authentificationstarttime Indique à partir de quand le ticket est valideendtime Indique l'expiration du ticket

renew-till Pour ticket renouvelables ; indique jusqu'à quand le ticket peut être renouvelé

caddr Contient 0 ou une liste d'adresses depuis lesquelles le ticket est utilisable

authorization-data Champ utilisé par les applications pour passer des données spécifiques

Chiffré

Structure d’un authentifiant (authenticator)

Champ Descriptionauthenticator-vno Version (5)crealm Royaume d'origine du clientcname Nom du clientchksum Somme de contrôle d'intégrité (optionnel)

cusec Contient la partie en microsecondes de l'horodatage client

ctime Horodatage client

subkeyPeut préciser une clef de session pour protéger l'échange (optionnel. Par défaut, contient la clef de session fournie par l'AA)

seq-number Numéro de séquence (optionnel)

authorization-data Champ utilisé par les applications pour passer des données spécifiques

KERBEROSAccès à un autre domaineAuthentication accrossboundaries

Principe

Quand un utilisateur d’un royaume A souhaite atteindre un serveur d’un royaume B :

il contacte sa propre AA,qui lui transmet un Refferal Ticket (TGT chiffré

avec une clef partagée inter-royaume)qui servira à obtenir auprès de l’AA de B un TGS

pour le serveur souhaité.

Schéma de principe

Royaume A Royaume B

Clef partagée

ServeurClient

1 : demande d’accès

2 : renvoi d’un ticket pour B

4 : renvoi d’un ticket pour le serveur

6 : accès autorisé

Contraintes

S’il existe plusieurs royaumes Kerberos, la distribution des clefs suit une complexitéexponentielle !Solution retenue :

une structure hiérarchique des royaumes, autorisant l’accès aux ressources par rebonds successifs

Structure hiérarchique

• Chaque lien entre royaumes indique le partage d’une clef inter-royaume.

• L’obtention d’un ticket se fait de proche en proche.

Avantages d’une telle architecture

Préserve l’isolement des royaumes entre eux.Tout client d’un royaume peut accéder aux ressources de n’importe quel serveur (si ce dernier l’autorise)……même si ce serveur ne fait pas partie du royaume du client.Les relations entre royaumes sont donc :

transitivesbidirectionnelles

Une « certaine » ressemblance avec une architecture bien connue ???

Essai de morphing...

AA AAAA

Royaume

Royaume Royaume

Clefs partagées inter-royaume

Structure hiérarchique Kerberos

Essai de morphing...

KDC KDCKDC

KDC KDC

Domaine

Domaine Domaine

Relation d ’approbation

Forêt Windows 2000

S/MIME

Secure Multipurpose Mail ExtensionEnveloppe de sécurisation des messages électroniquesServices proposés: signature/chiffrementMécanisme de triple enveloppeBasé sur la crypto asymétrique et les IGC

Les Firewalls

Firewall : Introduction

Firewall est un terme anglais désignant dans son sens premier une porte coupe-feuxUn Firewall assure une fonction de filtrage :

Il s’assure du respect d’une politique de contrôle d’accès entre deux réseaux.

Plusieurs technologies existent pour atteindre cet objectifPlusieurs architectures sont possibles pour sécuriser un réseau

Firewall : définitionUne définition formelle est proposée par Cheswicket Bellovin:« Un Firewall est un élément ou un ensemble d'éléments placé entre deux réseau et possédant les caractéristiques suivantes :

tous les flux (entrant et sortant) passent au traversseuls les flux autorisés par une politique locale peuvent passerle système lui-même est résistant aux agressions »

Firewall

Contre quoi se protège-t-on ?Le Firewall n'est pas l'outil de protection universelIl ne pare que certaines catégories de menaces⌧ne protège pas du "social engineering"⌧ne protège pas (tel quel) des virus et codes mobiles agressifs

Il ne protège que si le flux réseau transite par lui⌧problème des attaques internes⌧problème des connexions pirates (volonté délibérée de l'utilisateur

de contourner la politique mise en place, ligne de maintenance, modem, ...)

Application

Transport

Internet

Réseau

Physique

Firewall : Les types

Filtrage couche basserouteurs filtrants

Filtrage applicatifNotion de proxy

Stateful InspectionFirewalls

Frontière de plus en plus floue

Firewall : filtrage couche basse

Routage en même tempseffectue le routage des flux simultanément

Performance et transparencegénéralement sur des composant hardwareblocage / autorisation des flux sans authentification, donc transparent pour l’utilisateur

Limitation au niveau du filtrageconnaissance des couches basses du réseaux uniquement

Filtrage paquet (sur les couches 3 et 4), protocole TPC/IP

Firewall : filtrage applicatif

Pas de trafic direct entre les réseauxmédiation entre les réseauxrelayage applicatif (Proxy), service dit « de confiance » qui répond à la place du service demandé.

Authentification élaborée des utilisateurspar mot de passepar calculette / jetonpar carte à puce

Filtrage fin connaissance des protocoles applicatifs (telnet, rlogin, FTP, X-Windows, HTTP et NNTP)filtrage de commandes au niveau des protocoles (flux FTP, blocage de cookies, désactivation des applets java, analyse des headers SMTP, etc.)

Firewall : filtrage applicatif

Journalisation et audit finpossibilité de journaliser l’ensemble des flux transitant par le Firewallstatistiques sur les fluxen option, gestion de quota de flux par utilisateur (pour limiter la navigation sur Internet par exemple)remontée d’alertes par différents média

Possibilité de traduction d’adresses (NAT)masquer totalement son réseau au monde extérieur, en utilisant des plages d ’adresses privées

Moins performants et transparentsinteraction directe avec l’utilisateur lors des phases d’authentificationnécessité de « décortiquer » les protocoles

Firewall : StatefulInspection

Mariage des couches hautes et bassesimplémentation totale des couches protocolairesmaîtrise des flux d’information « du fil à l’application »

Capacité à gérer l’état dynamique des connexionsAlliance des fonctionnalités des deux modèles présentés précédemment

Permet de gérer la fragmentation

Liaison données

Physique

Application

Présentation

Session

Transport

Liaison données

Physique

Application

Présentation

Session

Transport

Liaison données

Physique

Réseau

Présentation

Session

Transport

MoteurMoteurd'inspectiond'inspection

Application

Tables d’étatDyn amique

Réseau

Firewall : StatefulInspection

Problème de la fragmentation (1/2)

Soient :1 machine interne A1 machine externe Bun firewall

On interdit les connexions de B vers A sur le protocole HTTP (port 80) et on autorise le reste.

Problème de la fragmentation (2/2)

B envoie à A un paquet IP de très grande taille contenant un segment TCP adressant le port 80Les routeurs intermédiaires vont filtrer le premier segment car l’en-tête TCP du fragment 1 contient l’adressage du port 80)…...mais les autres fragments vont passer car il ne contiennent pas d’en-tête TCP !=> le problème peut ici être résolu par le mécanisme de « Stateful inspection »

Firewall : granularité des contrôles

Filtres sur les fluxsens : Entrant / Sortantadresses sources et destinations, notions de groupe de machinesservices demandésautres champs protocolaires (service de proxy)établissement de connexion, état dynamiques des connexions

Authentificationgestion de groupes d’utilisateursplusieurs méthodes d’authentificationen fonction de la source et/ou destination et du service

Data Data Validée

Vérification

Firewall : granularité des contrôles

Filtrage de contenucode mobile (Java, ActiveX, …) et virus par scan à l’aide de programmes externesURL : blocage de l’accès àcertains sites externes / internesURL : cloisonnement logique de l’accès à certaines zones par certains utilisateurse-mail, possibilité de vérification des messages par programme externe

Firewall : état de l’art

Ce que l’on peut fairefiltrer quasiment tous les protocoles (plus ou moins finement)forcer des authentifications fortesétablir des canaux de communication sécurisésfaire de la journalisation et de l’analyse de traficadministration centralisée (et avec IHM) de plusieurs Firewalls

Ce que l’on ne sait pas faireanalyse sémantique du contenu des flux (« backdoors »)s’affranchir du système d’exploitationgarantir à 100% l’étanchéité du filtrese protéger contre les attaques internes

Firewall : exemple

Interconnexion de réseaux

un axe "stratégie sécurité" (enjeux, organisation, etc.)un axe "architecture d'accès"un axe "sécurité des échanges"un axe "sécurité des services (serveurs / postes)"

Ces quatre axes, très différents, doivent être analysés de façon cohérente.

Souvent associée à Internet et aux moyens de s’en protéger.Les actions à mener lors d’une interconnexion :

Identifier les utilisateurs concernés.Identifier les flux autorisés.Protéger les machines exposées.Définir une zone tampon dans laquelle transite l’information entre les deux réseaux.

Il existe des solutions types d’interconnexion entre les réseaux (« Building Internet Firewalls », recommandation OTAN pour le domaine militaire...).La charge d’administration liée à l’interconnexion n’est pas négligeable.Principe de base : « Tout ce qui n’est pas autorisé est interdit. » Seuls les flux nécessaires doivent pouvoir passer entre les réseaux.

L’authentification

INTRANETRéseau B

Réseau C

Réseau A

Utilisateur distant

Politique d ’authentification•permet de s ’assurer de l ’identité d ’un utilisateur.•Authentification par mot de passe : firewall, routeur, serveurs d ’accès distants...•Authentification forte : utilisation destokens (calculettes), des cartes à puce

•Attention à l ’impact utilisateur des solutions retenues (possibilitéd ’utiliser des applets Java)

Serveurd ’authentification

Analyse de contenu et décontamination virale (1)

Généralement associé à la messageriefonctionnement de type « proxy »Technologie au point pour le mail……mais encore délicate pour d’autres protocoles (HTTP notamment)

Analyse de contenu et décontamination virale (2)

outil de décontamination de la messagerie•Décontamination virale du message et des pièces jointes•Préférer les solutions permettant d ’utiliserplusieurs anti-virus•Analyse du contenu sémantique des messages

INTRANET

Détection d’intrusion (1)

IDS: Intrusion Detection Systemapproche temps réelapproche temps différé

PositionnementEn tête de pontEn DMZSur réseau Interne

Détection d’intrusion (2)

INTRANET

Réseau B

Réseau A

outils de tests de la sécurité•tests d’intrusion en utilisant des outils

de simulation d ’intrusion

Audit temps réel•analyse du trafic •détection temps réel des attaques•neutralisation de l’attaque

Principe de la DMZ (1)

Réseau « tampon »Pas de lien direct entre l’intérieur et l’extérieurHébergement de services « publics »

Principe de la DMZ (2)

Réseau privé

PARE-FEUContrôle

des accès entrants

PARE-FEUInterdiction

des accès entrants

accès contrôlés accès interdits

Collecte et diffusion

Architectures type

Internet

Architectures typeInternet

Architectures type

Internet

ServeurWeb

Architectures type

ProxyServeurWeb

Serveur Mail

Architectures type

Internet

Proxy ServeurWeb

ProxyServeurWeb

Serveur Mail

Internet

Architecturestype

Réseau interne

Internet

Routeur

Hub/switch

Switch

Firewall

Switch

Hub/switch

Architectures type

ConclusionsImportance de l’architecture :

choix du type d’architecturedimensionnement matérielutilisation de répartition de charge et tolérance aux pannes

Importance de la configuration :connaître les flux de donnéesdéfinir une politique de sécuritéprogrammer les (bonnes) règles

Charge d’administration in fine :maintenance du système, évolution de la politique de sécuritéanalyse des journaux d’audit

La sécurité est un comportement quotidien!

urbanisation et architecture des systèmes …mfworld42.free.fr/cnam/nfe107_urbanisation...

Documents

crashos recherche de vulnérabilités système dans les

gestion des vulnérabilités informatiques : vers une

authentification smtp

fp - utiliser sa messagerie en mobilitÉ · dans...

hotspots wifi. plan généralités sur les hotspots 1...

tutorial serveur de messagerie debian -...

vulnÉrabilitÉs sociales, santÉ et recours … ·...

vulnérabilités et réponses urbaines au sida en

enjeux de la sécurité informatique - cours · jean-marc...

audit de vulnérabilités...

audit de vulnérabilités réseau

l’observatoire des vulnÉrabilitÉs

présentation exhaustive des protocoles smtp, imap, pop3 et...

evaluation participative des vulnérabilités et des...

vulnérabilités les cahiers de l’espace Éthique...

configurez votre outil de messagerie · 2011. 2. 17. ·...

simple message transfert protocol · du @. si le domaine du...

evaluation participative des vulnérabilités et des...

evaluation de vulnérabilités - dgssi

i ® p - oracle · is part of windows 2008. to use...