View
5
Download
0
Category
Preview:
Citation preview
1
Urbanisation et architecture des systèmes d’information
Sécurité des systèmes d’information
David Eudelineeudeline.david@free.fr
2
Plan du Cours
ContexteLes risquesVulnérabilités des applicationsProtocoles de sécurité
Les FirewallsInterconnexion des réseauxLes évolutionsConclusions
3
Urbanisation et architecture des systèmes d’information
Contexte
4
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
5
Urbanisation et architecture des systèmes d’information
Les risques, les attaques
6
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.
7
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
8
Typologies des attaques
Familles d’attaqueCaptureInterception, InterruptionInjectionModificationUsurpation
9
Typologies des attaquesCapture
Flux d’informations Flux d’informations
10
Typologies des attaquesInterception
Flux d’informations
11
Typologies des attaquesInjection
Flux d’informations Flux d’informations modifié
12
Typologies des attaquesModification
Flux d’informations Flux d’informations modifié
13
Typologies des attaquesUsurpation
Flux d’informations modifié
14
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
15
La menace
menaces naturellespertes 26%
sinistres 20 000 / an
menaces humainespertes 74%
sinistres 17 000 / an
environnementpertes 15%
pannes systèmespertes 11%
erreurs humainespertes 17%
sinistres 15 000 / an
malveillancepertes 26%
sinistres 2 000 / an
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)
16
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
17
Renseignement
Phase préalable à toute attaque informatiqueSources ouvertes (Internet, presse…)Renseignement actif (scans réseaux…)
18
Préparation
L’agresseur se configure pour une attaqueRécupération d’outils adaptés à la situation
19
Intrusion
Phase la plus « active »Mise en œuvre des outilsExploitation des vulnérabilitésLe processus devient ici itératif (retour à une phase de renseignement)
20
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
21
Camouflage
Cacher les entrées permanentesInhiber les systèmes de journalisationEffacer ses tracesExistence des « rootkits »
22
Propagation
Poursuivre l’intrusion dans d’autres systèmesA partir de ce premier système intrusé(rebond)
23
Exemple de scénario (1)
24
Exemple de scénario (2)
Renseignement :scan « nmap »
Préparation :vulnérabilité IIS
25
Exemple de scénario (3)
Intrusion :Exploitation du bug
Installation du cheval de Troie
Prise de contrôle de la cible
26
Exemple de scénario (4)
Installation :déploiement d’outils plus sophistiqués (VNC, Bo2k…)
Camouflagesuppression des traces, inhibition des logs
PropagationExploration du réseau interne
27
Urbanisation et architecture des systèmes d’information
Vulnérabilités des applications
28
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…)
29
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
30
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
31
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
32
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).
33
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
34
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
35
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
36
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
37
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
38
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).
39
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
40
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
41
DHCP
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.
42
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
43
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.
44
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.
45
POP
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
46
POP: capture réseau
Mot de passe!
47
SNMP
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)
48
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.
49
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
50
L’attaque : « FTP bounce»
Attaquant
Victime
Serveur FTPVulnérable
1) Con
nexion
FTP passi
ve
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
51
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
52
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
53
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)
54
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
55
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
56
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
57
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é.
58
Urbanisation et architecture des systèmes d’information
Protocoles de sécurité
59
Protocoles sécurisés
S/MIME SHTTP
SSL/TLS
IPv6IETF
SOCKS
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
60
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
61
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)
PAE
EAP sur support niv 2 EAP sur radius
62
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]
63
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.
64
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
21
Response Authenticator = f(Request Authenticator, )
Clair Chiffré
65
IPSec
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
66
IPSec
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...).
67
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.
68
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
69
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ées
En-tête IP DonnéesAHNouvel En-tête IP
70
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 IP Données
En-tête IPd’origine DonnéesESP Trailer ESP Données
d ’authentification
Chiffré
Authentifié
71
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).
En-tête IP Données
Chiffré
Authentifié
NouvelleEn-tête IP DonnéesESP Trailer ESP Données
d ’authentificationEn-tête IPd ’origine
72
IPSEC: en têtes
OriginalIP Header
HeaderESP
Authentication / Integrity
Encrypted
OriginalIP Header
HeaderAH
Authentication / Integrity
TransportMode
ESPAH
TunnelMode
Authentication / Integrity
Encrypted
New IPHeader
HeaderESP
OriginalIP Header
Authentication / Integrity
New IPHeader
HeaderAH
OriginalIP Header
73
IPSec
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é
74
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é
75
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.
76
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.
77
IPv6
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
78
Urbanisation et architecture des systèmes d’information
SSL/TLS
79
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.
80
SSL/TLS: Architecture
TCP/IP
SSL/TLS
HTTP POP IMAP R-cmd LDAP
81
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
82
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.
83
SSL/TLSHandshake Protocol 2.0
84
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
condensat
Phase 1
Phase 2
Phase 3
Phase 4
85
Urbanisation et architecture des systèmes d’information
KERBEROS
86
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
87
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
88
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é
89
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
90
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.
91
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)
92
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
93
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 »
94
Urbanisation et architecture des systèmes d’information
KERBEROSAuthentification et accès aux ressourcesDescription des échanges
95
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
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
96
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é
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é
97
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
On utilise le TGS obtenu précédemment pour accéder au serviceLe serveur de ressources valide alors (ou non) la requête
98
Résumé
1
Connexion
2 TGT
3 Demande deTGS
4 TGS
5 Demande d ’accèsau service
6Validation
AS Service TGS Service
Serveur deressource
99
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.
100
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
Clair
Chiffré
101
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
102
Urbanisation et architecture des systèmes d’information
KERBEROSAccès à un autre domaineAuthentication accrossboundaries
103
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é.
104
Schéma de principe
Royaume A Royaume B
Clef partagée
AA AA
ServeurClient
1
2 34
5
6
1 : demande d’accès
2 : renvoi d’un ticket pour B
3 : demande d’accès
4 : renvoi d’un ticket pour le serveur
5 : demande d’accès
6 : accès autorisé
105
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
106
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.
107
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 ???
108
Essai de morphing...
AA
AA AAAA
AA
AA AA
Royaume
Royaume
Royaume
Royaume
Royaume Royaume
Clefs partagées inter-royaume
Structure hiérarchique Kerberos
109
Essai de morphing...
KDC
KDC KDCKDC
KDC
KDC KDC
Domaine
Domaine
Domaine
Domaine
Domaine Domaine
Relation d ’approbation
Forêt Windows 2000
110
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
111
Urbanisation et architecture des systèmes d’information
Les Firewalls
112
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
113
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 »
114
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, ...)
115
Application
Transport
Internet
Réseau
Physique
Cou
che
bass
eFi
ltre
appl
icat
if
Sta
tefu
lIns
pect
ion
Firewall : Les types
Filtrage couche basserouteurs filtrants
Filtrage applicatifNotion de proxy
Stateful InspectionFirewalls
Frontière de plus en plus floue
116
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
117
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.)
118
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
119
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
120
Liaison données
Physique
Application
Présentation
Session
Transport
Liaison données
Physique
Application
Présentation
Session
Transport
Liaison données
Physique
Réseau
Réseau
Présentation
Session
Transport
MoteurMoteurd'inspectiond'inspection
Application
Tables d’étatDyn amique
Réseau
Firewall : StatefulInspection
121
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.
122
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 »
123
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
124
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
125
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
126
Firewall : exemple
127
Urbanisation et architecture des systèmes d’information
Interconnexion de réseaux
128
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.
129
Interconnexion de réseaux
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.
130
Interconnexion de 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.
131
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
132
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)
133
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
134
Détection d’intrusion (1)
IDS: Intrusion Detection Systemapproche temps réelapproche temps différé
PositionnementEn tête de pontEn DMZSur réseau Interne
135
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
136
Principe de la DMZ (1)
Réseau « tampon »Pas de lien direct entre l’intérieur et l’extérieurHébergement de services « publics »
137
Principe de la DMZ (2)
Réseau privé
DMZ
PARE-FEUContrôle
des accès entrants
PARE-FEUInterdiction
des accès entrants
accès contrôlés accès interdits
Collecte et diffusion
138
Architectures type
Internet
139
Architectures typeInternet
140
Architectures typeInternet
141
Architectures type
Internet
Proxy
ServeurWeb
142
Architectures type
ProxyServeurWeb
Serveur Mail
143
Architectures type
Internet
Proxy ServeurWeb
ProxyServeurWeb
Serveur Mail
Internet
144
Architecturestype
Réseau interne
Internet
Routeur
Hub/switch
Switch
Firewall
Switch
VRPP
VRPP
Hub/switch
145
Architectures type
146
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
147
Urbanisation et architecture des systèmes d’information
La sécurité est un comportement quotidien!
Recommended