Embed Size (px)
DESCRIPTION
Etude théorique et pratique de RC5, RC6, SNORT et RADIUS & leurs applications
Citation preview
Etude théorique et pratique de
RC5, RC6, SNORT et RADIUS
&
leurs applications
Réalisé par :
Younes ASIMI
Yassine SADQI
Mohamed ZAOUI
Encadré par :
Prof. Ahmed ASIMI
2
Sommaire
RADIUS :
I. INTRODUCTION GENERALE .................................................................................................. 3
II. LE PROTOCOLE RADUIS ........................................................................................................ 4
III. FONCTIONNEMMENT DU PROTOCOLE RADUIS ................................................................ 11
IV. Configuration du RADIUS : cas Windows 2003 .................................................................. 14
Introduction ................................................................................................................................ 15
Configuration générale du serveur ............................................................................................ 17
Centralisation des clients d'accès distant à l'aide du serveur IAS ........................................... 21
Configuration des clients d'accès à distance et sécurisation de l'accès à distance................. 28
Conclusion .................................................................................................................................... 31
SNORT :
I. Introduction ...................................................................................................................... 32
II. Détection d'attaques : les IDS .......................................................................................... 32
III. Mise en oeuvre d'IDS ........................................................................................................ 36
RC5 : ………………………………………………………………………………………………………………………………45
RC6 :
I. Le chiffrement par bloc ...................................................................................................... 48
II. Présentation de l’algorithme RC6 ...................................................................................... 48
III. Principes de l’algorithme ................................................................................................... 48
3
RADIUS
I. INTRODUCTION GENERALE
Remote Authentication Dial-In User Service est un système qui fait de « l'AAA »
(Authentication,Authorization and Accounting). Utilisé depuis longtemps déjà par bon nombre de
fournisseurs d'accès à l'internet pour authentifier leurs clients et leur communiquer une configuration
IP. RADIUS est également très utile pour sécuriser un réseau Wi-Fi, ou même un réseau filaire, dans
certaines conditions.
• la sécurisation d'un réseau Wi-Fi (authentification WPA2-TLS),
• la sécurisation d'un réseau filaire (authentification des stations par adresse MAC).
Ce type de sécurisation s'avère fort intéressant si l'on dispose d'un réseau proposant un accès
filaire et Wi-Fi, avec des utilisateurs susceptibles de venir y connecter leur ordinateur portable. Par
définition, ce type de machine échappe totalement au contrôle de l'administrateur et peut être la source
de bien des soucis.
Les services présentés par RADUIS sont capables d'authentifier des utilisateurs distants,
suivant de multiples modes plus ou moins sécurisés, en s'appuyant sur une base connaissances allant
du simple fichier texte à l'annuaire LDAP, en passant par une base de données de type SQL,
4
d’enregistrer des informations sur chaque « login » et ainsi de renvoyer au demandeur des paramètres
variés pouvant, suivant le cas, être une configuration IP, un numéro de LAN virtuel etc.
Ainsi RADIUS a deux possibilités d’authentifier les stations soit depuis leur adresse MAC
connues sur notre réseau filaire, en utilisant un système de type « login/password », avec le protocole
CHAP (Challenge-Handshake Authentication Protocol), éventuellement en assignant un numéro de
VLAN suivant la machine et soit avec un certificat x.509 sur le réseau Wi-Fi, en utilisant EAP-TLS.
Le serveur RADIUS peut fonctionner en s'appuyant uniquement sur des fichiers texte. Mais
pour gérer des multiples clients on aura besoin d’utiliser une base MySQL pour stocker les adresses
MAC des clients. Outre la souplesse qu'apportent des outils comme phpmyadmin pour gérer la liste
des clients, cette solution offre l'avantage de ne pas nécessiter de redémarrage le serveur à chaque
modification de la base.
II. LE PROTOCOLE RADUIS
1. L’authentification
C’est le processus qui prouve qu’une identité appartient bien à celui qui l’a présente un
identifiant est proposé au serveur radius. Il doit vérifier qu’il est bien présent dans sa base et aussi il
faut vérifier que celui qui présente cet identifiant peut prouver qu’il en est bien le propriétaire. Il existe
plusieurs méthodes d’authentification on cite les plus courantes :
Adresse MAC (faible, pas de preuve)
Login/mot de passe
Certificat
Il s'agit d'authentifier une machine lorsqu'elle se branche sur le réseau afin de lui autoriser ou
refuser l'usage du réseau, Cette authentification est indépendante d'autres authentifications vers des
systèmes d'exploitation ou applications.
5
Authentification réseau :
Branchement physique sur le réseau
Authentification
Autorisation d'usage
Authentification applicatives :
Authentification sur le système d'exploitation (windows, Linux…)
Authentification sur une application
Les principaux objectifs d’authentification
Sécuriser un réseau filaire ou sans-fil
Pour interdire les postes inconnus
Pour placer les postes connus a des endroits spécifiques du réseau (vlan) de façon
dynamique.
Pour savoir quelle machine est connectée et où elle est connectée
Savoir qui se connecte sur quelle prise
Eviter une utilisation illicite du réseau par des « inconnus »
Affecter les machines sur des réseaux virtuels (cloisonnement)
Affecter une machine sur le même vlan que lorsqu’elle
Se connecte sur le réseau filaire.
Authentification + cryptage …
2. Mécanisme d’authentification
Afin de se connecter à l’équipement coté client, le client RADIUS récupère d’abord toutes les
informations nécessaires (login, mot de passe). La méthode de récupération de ces informations
dépend de la configuration du client. Il peut s’agir directement d’un prompt invitant l’utilisateur à
entrer ces informations, ou bien d’utiliser les valeurs transmises par le protocole de communication
(ex : PPP).
Le client RADIUS crée ensuite un paquet de type « Access-Request » contenant les
informations dont le serveur RADIUS a besoin (nom, mot de passe, ID du client, ID du port). Si un
mot de passe est présent, il sera haché en utilisant MD5.
Une fois que le serveur reçoit la requête, il vérifie d’abord que le client partage un secret avec
lui, puis récupère les informations concernant l’utilisateur. Celles-ci sont extraites d’une base de
données qui peut être locale au serveur RADIUS, ou bien appartenir à un autre serveur RADIUS (dans
ce cas, le serveur RADIUS jouera lui-même le rôle de client). Si un mot de passe doit être
communiqué, il sera vérifié par le serveur.
Dans le cas où l’une des informations transmises par le client s’avère incorrecte, le serveur
retourne un paquet « Access-Reject » indiquant au client que la connexion a été refusée et pouvant
contenir un message d’explication. Dans le cas contraire, le serveur retourne un paquet « Access-
Challenge ». Le paquet contient un nombre aléatoire que le client doit chiffrer.
En retour, le client émet de nouveau le paquet « Access-Request » mais contenant cette fois la
réponse au challenge. Le serveur peut alors renvoyer :
i. un paquet « Access-Accept » si l’authentification est validée ;
ii. un paquet « Access-Reject » dans le cas contraire ;
iii. un paquet « Access-Challenge » si un complément d’information est nécessaire.
6
b. L’autorisation
C’est le fait de déterminer quels sont les droits de l’utilisateur. Par exemple, après s’être logué,
l’utilisateur peut essayer d’utiliser certaines commandes. L’autorisation détermine alors si l’utilisateur
peut ou non les utiliser. Dans certaines implémentations, l’identification et l’autorisation sont
regroupés en une seule étape.
Lors de l’ “Access-Accept”, le serveur ajoute, dans le paquet, une liste de valeurs
correspondant aux paramètres de l’utilisateur. Elles sont utilisées par le NAS qui réalise la phase
d’autorisation. Si elles sont valides, l’utilisateur est alors connecté. Suivant la configuration du
Network Access Server, elle peut ne pas être réalisée, auquel cas, aucune autorisation ne sera
effectuée. Ainsi ce terme a un sens très large tel que :
i. Accès ou refus de la connexion au réseau
ii. Affecter un N°de VLAN
iii. Donner une adresse IP
iv. Positionner des ACLs
v. Exécuter une commande (filtrage, routage…)
Mais il faut voir ces autorisations comme des attributs de connexion (Reply-item)
c. Comptabilisation (accounting)
Cela consiste à mesurer les ressources qu’un utilisateur consomme, en terme d’échange
réseau, de ressources système,... Cela sert en fait à logguer un certain nombre d’informations sur
l’utilisateur. Cela permet de connaître à la fois les services demandés par l’utilisateur et la quantité de
ressources requises.
Les trois points définis ci-dessus sont importants pour une bonne gestion et une bonne sécurité
d’un réseau. Ils devraient être disponibles au point d’entrée d’un réseau.
Tous les utilisateurs distants accèdent au réseau au travers d’un NAS (Network Access
Server), aussi appelé Remote Access Server, ou Terminal Server. Un NAS est une interface qui
accepte un accès distant à travers une ligne téléphonique ou RNIS. Le NAS connecte les utilisateurs
distants au réseau interne (Local Area Network).
Après s’être connecté, l’utilisateur distant a accès à toutes les ressources du réseau interne
(serveurs, partages, communication avec les autres utilisateurs, ...)
Au démarrage d’un service, le NAS émet un paquet “Accounting-Start” au serveur RADIUS.
Le NAS centralise les informations, puis les envoie au serveur au moment de la fermeture du service
dans un paquet “Accounting Stop” (quantité transmise, débit, bande passante, temps d’émission, ...).
Lors de l’envoi du paquet « Access-Accept », le serveur ajoute, dans le paquet, une liste de
valeurs correspondant aux paramètres de l’utilisateur. Elles sont utilisées par le l’équipement coté
client qui réalise la phase d’autorisation. Si elles sont valides, l’utilisateur est alors connecté.
d. Principe du protocole RADIUS
Le standard RADIUS est basé sur un ensemble d’attributs relatifs aux utilisateurs. Ils sont tous
stockés dans la base RADIUS du serveur. Au cours d’une connexion, un échange d’information a lieu
7
entre le serveur et le client (NAS). Le standard RADIUS propose un certain nombre d’attributs qui
doivent être mis en œuvre. Mais beaucoup d’implémentations spécifiques du protocole apportent leur
propre jeu d’attributs.
Le protocole RADIUS permet une authentification utilisateur/mot de passe ou
utilisateur/challenge/réponse ou les deux, qui peuvent être configurée spécifiquement pour chaque
utilisateur. La vérification est réalisée par le serveur RADIUS, qui retourne alors un “authentication
reply” au NAS qui a émis la requête.
Tous les clients RADIUS communiquent généralement à travers le réseau local sur un serveur
unique, ce qui rend la tâche de l’administrateur plus simple. La gestion des utilisateurs et de leurs
droits est alors plus facile par rapport à plusieurs serveurs qu’il faudrait mettre à jour simultanément
sur le réseau.
Toutes les informations échangées entre le serveur Radius et le client Radius passent par des
attributs (Un nom et une valeur), on distingue deux types d’attributs :
1. Les attributs envoyés par les clients au serveur Radius(Request-Items)
ii. User-Name
iii. Calling-Station-Id
iv. Called-Station-Id
1. Envoyés par le serveur Radius aux clients(Reply-Items)
v. Tunnel-Private-Group-Id
vi. Framed-IP-Adress (Pas compatible avec EAP)
Le protocole RADIUS est basé sur un échange de paquets utilisant le protocole UDP. Le port
généralement employé est le 1645, bien qu’il devrait être normalement configuré sur le port 1812 pour
éviter des conflits avec le service Datametrics.
Le protocole utilise 4 types de paquets suffisants pour assurer toutes les transactions (hors
accounting) pour effectuer une authentification RADIUS :
8
Access-Request
Envoyé par le NAS contenant les informations sur le client qui souhaite se connecter
(login/mot de passe, adresse MAC…), ce paquet contient l'identité de l'utilisateur qui se connecte (
username/password ou CN du certificat ou MAC adresse)
Access-Accept
Envoyé par le serveur pour autorisé la connexion si la vérification des informations est correct
après l’interrogation de sa base d'authentification. Ce paquet peut contenir une liste d'attributs
correspondant aux services qui sont autorisés (par exemple le vlan).
Access-Reject
Envoyé par le serveur pour refuser une connexion en cas d’échec de l’authentification ou pour
mettre fin à une connexion et pour informer le client que sa requête est rejetée. En principe ce paquet
peut être émis à tout moment pour mettre fin à une connexion, mais certains équipement ne supporte
pas.
Access-Challenge
Envoyé par le serveur pour demander la réémission d’un access-request ou des informations
complémentaires.
Format des trames :
Code (1 octet):
access-request
access-accept
access-reject
accounting-request
accounting-response
access-challenge
Identifier (1 octet) : utilisé pour associer les requêtes et les réponses
Unique pour chaque authentification
Identique pour une retransmission
Longueur (2 octets):
Taille total du message (de 20 à 4096 octets)
Authentificateur (16):
Lorsque le client NAS envoi un paquet access-request il inclut un authentificateur appelé
request-authenticator qui est une séquence aléatoire. Le serveur répond par un paquet access-accept
ou accept-reject ou accept-challenge avec un response-authenticator composé avec les
informations contenues dans le paquet access-request, le request authenticator et un secret partagé
avec le NAS et le tout crypté MD5.
9
Le NAS est alors en mesure de vérifier que le serveur qui répond est bien celui qu'il a
contacté.
Request Authenticator (16 octets):
Un nombre aléatoire unique
Response Authenticator (16 octets):
MD5 (Code + ID + Length +RequestAuth + Attributes + Secret)
Les transactions RADIUS ont pour but de véhiculer des attributs et leur valeur entre le client
NAS et le serveur. Ces attributs et leur valeur sont appelés paires attribut-valeur (AVP= attribut-
value pair), Ils permettent au client de communiquer des informations au serveur (password, MAC
adresse…) et au serveur de communiquer les paramètres des autorisations qu'il délivre (vlan…) ou
bien demander des informations complémentaires.
Un attribut est caractérisé par son type et sa valeur (éventuellement nulle)
Integer
Enumerated
IP address
Chaîne de caractères
Date
Binaire
Vendor-specific
Il y a beaucoup d'attributs standards mais peu sont utilisables dans le cas d'une utilisation avec
802.1x. Par exemple l'attribut CALLBACK-NUMBER contient le numéro de téléphone sur lequel il
faut rappeler le client. Ce qui est inutile dans notre cas…
Les attributs standards :
Chaque attribut possède un numéro d'identification. Seul ce numéro est transmis dans les
paquets.
Called-Station-Id : Contient l'adresse MAC de l'équipement NAS
Calling-Station-Id : Contient l'adresse MAC de la machine de l'utilisateur.
NAS-IP-Address : Adresse IP de l'équipement NAS
NAS-Port : Port sur lequel est connecté le supplicant
User-Name
User-Password
Les attributs vendor :
Les fabricant de matériel réseau (NAS) ont parfois intégré à leurs équipements des attributs
spécifiques en plus des attributs standards définis dans le RFC. Ces attributs sont encapsulés dans
l'attribut standard vendor-specific qui a pour numero 26. Ils sont appelés VSA = Vendor Specific
Attribut.
10
Vendor ID:
N° d'immatriculation du fabricant (NMPECS= Network Management Private Enterprise
Codes (RFC1700)
Attribut number
Comme pour les attributs standards, les vendor-attributs possèdent un numéro d'identification.
Ce numéro est répertorié dans un dictionnaire spécifique au fabricant.
e. Modules et attributs programmables
Il est possible d’écrire des programmes qui s’exécuteront pendant le processus
d’authentification/autorisation.
Deux méthodes :
i. Au moyen de modules déclarés dans la configuration Radius
ii. Avec l’attribut Exec-Program-Wait dans la base de données.
Exemples :
Générer des lignes de logs spécifiques
Envoyer un mail avant expiration
Faire des vérifications supplémentaires
Modifier dynamiquement la base de données
Dans le fichier de configuration du daemon FreeRadius (radiusd.conf) on défini un module
spécifique.
Ce module est appelé dans une des sections de radiusd.conf.
Ecrire le programme appelé
11
Appel d’un programme dans les attributs stockés dans la base de données (utilisation de
l’attribut Exec-Program-Wait.)
Exemple : Envoi d’un mail avant date d’expiration
Ecriture du programme correspondant .
III. FONCTIONNEMMENT DU PROTOCOLE RADUIS
Le protocole RADIUS repose principalement sur un serveur (le serveur RADIUS), relié à une
base d’identification (base de données, annuaire LDAP, etc.), sur un client RADIUS, appelé NAS
(Network Access Server), faisant office d’intermédiaire entre l’utilisateur final et le serveur.
L’ensemble des transactions entre le client RADIUS et le serveur RADIUS est chiffré.
Le serveur RADIUS peut faire office de proxy, c’est-à-dire transmettre les requêtes du client à
d’autres serveurs RADIUS. Le serveur traite les demandes d’authentification en accédant si nécessaire
à une base externe : base de données SQL, annuaire LDAP, comptes d’utilisateurs, de machines ou de
domaines. Un serveur RADIUS dispose pour cela d’un certain nombre d’interfaces ou de méthodes.6
Un utilisateur envoie une requête au NAS afin d’autoriser une connexion à distance.
Le NAS achemine la demande au serveur RADIUS.
Le serveur RADIUS consulte sa base de données d’identification afin de connaître le type
de scénario d’identification demandé pour l’utilisateur.
Soit le scénario actuel convient, soit une autre méthode d’identification est demandée à
l’utilisateur. Le serveur RADIUS retourne ainsi une des quatre réponses suivantes :
ACCEPT : l’identification a réussi.
REJECT : l’identification a échoué.
12
CHALLENGE : le serveur RADIUS souhaite des informations supplémentaires de
la part de l’utilisateur et propose un « défi ».
Une autre réponse est possible : CHANGE PASSWORD où le serveur RADIUS demande à
l’utilisateur un nouveau mot de passe.
Change-password est un attribut VSA (Vendor-Specific Attributes), c’est-à-dire qu’il est
spécifique à un fournisseur.
Suite à cette phase dit d’authentification, débute une phase d’autorisation où le serveur
retourne les autorisations de l’utilisateur.
Donc la demande d’authentification contient un nom d'usager et un mot de passe (chiffré avec
MD5 ou un autre algorithme) dont la validité sera comparée avec le couple identifiant-mot de passe
enregistré dans un annuaire centralisé (généralement un service d'annuaire LDAP). L'identifiant et le
mot de passe sont déchiffrés au moyen d'un se-cret partagé entre le client et le serveur Radius. Si les
informations fournies sont correctes, le serveur Radius renvoie une chaîne numérique aléatoire que le
client utilisera pour faire sa demande d'accès au réseau. À réception de celle-ci, le serveur Radius
inscrit l'usager authentifié sur le réseau en lui attribuant une adresse IP par l'entremise du serveur
DHCP.
Le protocole Radius dispose également de fonctions pour comptabiliser le temps de
connexion. Le serveur Radius conserve au sein d'un fichier de traces la date et l'heure de connexion et
de déconnexion de l'utilisateur, ou transmet ces informations à une base de données. À noter, toutes
ces connexions s'effectuent en mode session grâce au protocole UDP.
EAP (Extended Authentication Protocol), un mécanisme de contrôle d'accès au niveau
d'Ethernet basé sur un service d’authentification RADUIS. Connu également sous le numéro 802.1x,
EAP intercepte la demande d'inscription d'un adaptateur Ethernet sur le segment du réseau dont il
dépend et la soumet à une authentification Radius. D'un intérêt limité pour les réseaux locaux
d'entreprise, ce protocole assure en revanche une sécurisation efficace pour les réseaux locaux radio.
EAP garantit en effet qu'un utilisateur non-autorisé ne puisse pas accéder à la zone de couverture dans
laquelle il se trouve. En théorie donc, Radius cumule presque tous les avantages.
Cependant, à l'exploitation, le protocole révèle non seulement des contraintes qui compliquent
son déploiement, mais aussi des failles de sécurité inquiétantes. Ainsi, une étude récente réalisée par
Infoguard, un cabinet d'experts américain, démontre que l'identifiant généré par le client, permettant au
serveur Radius de reconnaître l'origine d'une requête, autant que le secret partagé, utilisé pour chiffrer
et déchiffrer l'échange du mot de passe de l'utilisateur, sont vulnérables aux attaques de pirates
chevronnés. Cela permet à un pirate ayant observé et capturé une demande de requête et sa réponse, de
13
reproduire l'échange et d'obtenir ainsi frauduleusement un accès "légal" sur le réseau. " Le secret
partagé lui-même peut être décodé facilement dès que l'on est parvenu à se procurer un nom
d'utilisateur et un mot de passe valides. " Le protocole autorise l'utilisation du même secret partagé
pour un nombre illimité de clients, relève l'expert. Ce qui signifie que dans beaucoup de cas, la
découverte d'un seul secret partagé permet de collecter tous les identifiants d'utilisateurs qui seront
transmis au serveur Radius.
Les secrets partagés sont bien tous différents et suffisamment complexes pour ne pas être
trouvés trop facilement constitue pour l'instant la seule défense possible. Car il n'existe pas de réelle
solution disponible à ce jour. L'espoir ne semble pas même devoir venir de Diameter. Ce protocole
d'authentification, actuellement en cours de finalisation par l'IETF, prévoit certes des mécanismes de
sécurité, mais les limite à l'échange d'informations entre serveurs Diameter. Pour autant, cette version
révisée de Radius est attendue. Tournant le dos à l'architecture client-serveur classique qui handicape
Radius (un client doit émettre une requête pour démarrer le processus d'authentification), Diameter
permettra au serveur de détecter l'entrée d'usagers non encore autorisés sur le réseau. Plus important, le
protocole prévoit aussi des mécanismes d'échange, d'interrogation à distance et de délégation d'autorité
entre les serveurs d'authentification. L'autorisation délivrée par un serveur sera ainsi valable non
seulement pour son propre réseau, mais aussi pour tous les réseaux reliés, et ce, selon des permissions
prédéfinies dans le cadre des informations reçues de l'usager.
Radius centralise l'authentification
1. Accéder au serveur RAS
Access-Request : un paquet IP spécifique, émis par l'agent logiciel d'une passerelle RPV ou
d'un serveur d'accès. Celui-ci contient l'identifiant et le mot de passe de l'utilisateur chiffrés.Secret
partagé : une chaîne de 16 caractères alphanumériques utilisée par le serveur et les clients Radius pour
se reconnaître entre eux.Identifiant de requête : généralement limité à un simple compteur, ce champ
du paquet de requête permet l'ouverture d'une session d'authentification sur le serveur Radius.
2. Sécuriser le sans-fil
14
Avec l'avènement des connexions sans fil, l'IETF a mis au point le protocole EAP (Extensible
Authentification Protocol), un mode de négociation avec les serveurs d'authentification fondé sur
l'échange de clés communes et de certificats. Ce protocole, qui est proposé par Cisco, Microsoft et
RSA, serait plus fiable que WEP.
3. Authentifier
En recevant la requête, le serveur Radius vérifie auprès du serveur LDAP que l'utilisateur est
bien présent dans la base d'annuaire. La connexion s'effectue en utilisant le mode de transmission
UDP, plus souple que TCP. Ce choix d'UDP par l'IETF répond au besoin d'une connexion permanente
sans renégociation, comme c'est le cas avec TCP.
4. Attribuer l'adresse IP
Après avoir authentifié l'utilisateur en interrogeant un annuaire LDAP, le serveur Radius
retourne une autorisation d'accès chiffrée au client, sous la forme d'un numéro unique et aléatoire. De
cette façon, le serveur s'assure que le client Radius ayant émis la requête est bien celui qui est habilité
à traiter la réponse. À réception de celle-ci, le client émet à nouveau une requête d'accès grâce à
laquelle il obtiendra l'adresse IP dont l'usager à besoin pour être connecté au réseau.
Claude
IV. Configuration du RADIUS : cas Windows 2003
15
Introduction
Présentation du service routage et accès distant
Le service Routage et Accès Distant encore appelé RRAS (pour Routing and Remote Access Service)
possède deux fonctions principales :
Il permet de faire communiquer entre-eux des réseaux différents ou des sous-réseaux
différents (routage)
Il permet à des clients situé dans une zone géographiquement éloignée de l'entreprise
d'accéder au réseau interne de l'entreprise (accès à distance)
Dans cet article nous détailler la mise en place de l'accès à distance avec le service Routage et accès
distant de Microsoft Windows 2003 Server.
Infrastructure logicielle et matérielle de l'accès à distance
a/ infrastructure logicielle
¨Pour être mis en place dans un environnement Microsoft, l'accès à distance requiert la présence de
plusieurs services:
un logiciel d'accès distants client (intégré au système d'exploitation depuis la sortie de
Windows 95)
le service Routage et Accès distant
le service d'annuaire Active Directory
Comme nous le verrons ultérieurement, il est possible d'utiliser un service spécifique nommé IAS
(Internet Authentification Service) pour centraliser les demandes d'authentification des clients d'accès
distant.
b/ infrastructure matérielle
Généralement, une machine dédiée est utilisée pour jouer le rôle de contrôleur de domaine et une autre
machine est utilisée exécuter le service Routage et Accès Distant. Voici une topologie réseau type en
ce qui concerne l'accès à distance :
Comme le montre le schéma ci-dessus, divers types de réseau peuvent utilisés pour établir la
connexion entre l'ordinateur client et le serveur d'accès distant. Les trois principaux sont :
16
les connexions VPN (Virtual Private Network) qui utilisent un réseau public (le plus souvent
Internet).
les connexions d'accès à distance qui utilisent un Réseau Numérique à Intégration de Service
(RNIS), comme par exemple Numéris de l'opérateur téléphonique France Télécom.
les connexions sans fil (ou wireless) qui utilisent des technologies basées sur la propagation
d'ondes (infrarouge, bluetooth, WiFi, WiMAX,...).
En conséquence, plusieurs types de clients sont distinguables :
les clients VPN
les clients d'accès à distance
les clients sans fil
Principe de fonctionnement de l'accès à distance
L'établissement d'une connexion d'accès à distance passe par plusieurs étapes :
1. Un client contacte le serveur d'accès distant et lui envoie un identifiant avec un mot de passe
pour tenter de s'authentifier.
2. Le serveur d'accès distant commence par vérifier si l'identifiant et le mot de passe
correspondent à un utilisateur de l'annuaire Active Directory : c'est la phase d'authentification.
3. Si l'utilisateur s'est authentifié avec succès, alors le serveur d'accès distant compare les
paramètres de la demande de connexion avec toutes les stratégies d'accès distant existantes.
4. Si les conditions d'une stratégie d'accès distant correspondent avec les paramètres de la
demande de connexion, alors le serveur d'accès distant vérifie si l'utilisateur a l'autorisation de
se connecter à distance au réseau de l'entreprise : c'est la phase d'autorisation.
5. Si l'utilisateur est autorisé à se connecter à distance au réseau de l'entreprise, alors les
conditions du profil d'accès distant de la connexion sont vérifiées.
6. Si toutes les conditions du profil d'accès distant sont vérifiées alors la connexion est autorisée
et le client reçoit une adresse IP.
les étapes de l'établissement d'une connexion d'accès à distance
17
Configuration générale du serveur
Lancer la console et activer le service Routage et Accès distant
Il faut taper rrasmgmt.msc dans la boite de dialogue exécuter pour lancer la console Routage et Accès
Distant. Pour activer le service, il faut faire un clic droit sur le nom du serveur et cliquer sur
Configurer et activer le routage et l'accès distant.
L'assistant installation du serveur de routage et d'accès distant se lance.
18
On sélectionne les services nécessaires.
L'assistant se termine.
19
Une fois le service Routage et Accès Distant installé, l'arborescence se complète et on a accès à plus
d'options :
Interface Réseau : liste les cartes réseau et les modems actuellement connectés à la machine
et permet d'ajouter des connexions de numérotation à la demande.
Clients d'accès distant : liste le nombre de clients actuellement connectés au serveur d'accès
distant et offre la possibilité de forcer la fermeture des sessions d'accès distants.
Ports : Un port est un périphérique virtuel permettant aux clients de se connecter au serveur.
Le nombre de ports configurés est paramétrable pour chaque type de connexion (par exemple,
il est possible de définir un nombre de ports pour les connexions via le protocole PPTP). Cette
vue permet de constater l'état actif ou inactif de chaque port.
Routage IP : Permet de configurer le routage des paquets IP. Il est possible ici de configurer
les interfaces, d'ajouter des protocoles (comme le NAT, OSPF ou RIPv2) afin de permettre la
découverte automatique de routeurs. Cette fenêtre permet aussi de définir une interface en tant
qu'agent de relais DHCP.
20
Stratégies d'accès distant : Une stratégie d'accès distant est un ensemble de conditions
définissant qui pourra accéder à distance au réseau et quelles seront les caractéristiques de
cette connexion. Les critères d'acceptation ou de refus de connexions sont très variés. Il est
possible de configurer une stratégie pour refuser ou accepter un connexion suivant une plage
horaire, appartenance à un groupe, type de service, protocole utilisé, temps maximum de
connexion etc… L'ordre de placement des stratégies est très importante car c'est la première
stratégie concernée qui servira à accepter ou refuser la connexion. Les stratégies d'accès
distant ne sont pas stockées dans l'active Directory, mais dans le fichier local IAS.mdb. Une
solution pour appliquer les même stratégies d'accès distant à plusieurs serveur d'accès distant
est d'utiliser un serveur utilisant le protocole RADIUS. Le serveur RADIUS de Microsoft se
nomme IAS (Internet Authentification Service) et se présente sous la forme d'un service
optionnel.
Connexion par accès distant : Cette fenêtre permet de paramétrer la journalisation
(emplacement du journal, types d'évènements à enregistrer,...)
Les paramètres du serveur d'accès distant
Des paramètres généraux sont accessibles en faisant un clic droit sur le nom du serveur puis en
sélectionnant propriétés. Les options intéressantes au niveau de l'accès à distance (les autres options
concernent le routage) sont :
o le choix d'activer ou non l'accès à distance (onglet Général)
o le choix du protocole utilisé pour l'authentification des utilisateurs (onglet Sécurité)
o la possibilité de choisir comment le serveur d'accès distant va attribuer les adresses IP aux
clients (soit dans un pool d'adresses statique, soit via le protocole DHCP)
o la possibilité de choisir avec quelle interface réseau le serveur d'accès distant doit obtenir les
baux DHCP pour les clients.
21
o la possibilité de choisir quels sont les évènements qui seront stockés dans le journal (onglet
Enregistrement).
Les protocoles d'authentification
Le service Routage et accès distant propose plusieurs protocoles plus ou moins sécurisé pour
authentifier les utilisateurs distant :
PAP (Password Authentification Protocol) est un protocole non sécurisé car les identifiants
et les mots de passe sont envoyés en clair (c'est-à-dire sans cryptage) entre le client et le
serveur d'accès distant.
SPAP (Shiva Password Authentification Protocol) permet aux machines clientes équipées
avec du matériel de marque Shiva de se connecter au serveur d'accès distant. Les mots de
passe sont protégés par un cryptage réversible (faible sécurité).
CHAP (Challenge Handshake Authentification Protocol) autorise le cryptage des mots de
passe envoyés du client vers le serveur d'accès distant.
MS-CHAP (Microsoft CHAP) est un protocole propriétaire de Microsoft basé sur CHAP. Il
utilise le protocole de cryptage MPPE (Microsoft Point-to-Point Encryption) et est supporté
depuis Windows 95.
MS-CHAP V2 est une amélioration du protocole MS-CHAP avec des clés de cryptage plus
fortes et une authentification mutuelle entre le client et le serveur d'accès distant. Il a été
implémenté à partir de Windows 98.
EAP (Extensible Authentification Protocol) est un protocole évolutif qui permet
d'authentifier du matériel propriétaire de manière sécurisée.
Centralisation des clients d'accès distant à l'aide du serveur IAS
Présentation et installation d'IAS
Lorsque l'on dispose de plusieurs serveurs d'accès distant, il peut s'avérer fastidieux de mettre en place
une stratégie d'accès uniforme. La solution la plus simple reste de mettre en place un serveur utilisant
22
le protocole RADIUS (pour Remote Authentication Dial-In User Service) qui permet une autorisation
et une authentification des utilisateurs distant de manière centralisée. Microsoft a développé son
propre serveur RADIUS qui s'intègre à Windows 2003 Server sous la forme d'un service optionnel. Ce
service se nomme IAS pour Internet Authentification Service.
Une fois en place et correctement paramétré le serveur IAS joue le rôle d'intermédiaire entre les
serveurs d'accès distant et le contrôleur de domaine Ceci modifie donc les étapes lors de
l'établissement d'une connexion d'accès à distance :
1. Un client contacte le serveur d'accès distant et lui envoie un identifiant avec un mot de passe
pour tenter d'établir la connexion.
2. Le serveur d'accès distant (qui est un client RADIUS du point de vue du serveur IAS) envoie
la demande d'authentification au serveur IAS en UDP via les ports 1812 et 1813.
3. Le serveur IAS exécute les phases d'authentification et d'autorisation auprès d'un contrôleur de
domaine
4. Si l'utilisateur distant a correctement été identifié alors le serveur IAS compare les stratégies
d'accès distant configurées avec la demande de connexion du client.
5. Si les paramètres de la demande de connexion concordent avec une stratégie d'accès distant
alors le serveur IAS envoie un message au serveur d'accès distant qui fournit ensuite une
adresse IP au client.
Pour lancer l'installation du service IAS, allez dans le panneau de
configuration, puis sélectionnez ajout/suppression de programmes. Cliquez
ensuite sur le bouton Ajouter ou supprimer des composants de Windows.
23
Dans la première fenêtre de l'assistant Composants de Windows, sélectionnez l'option Services de mise
en réseau.
Enfin côchez la case Service d'authentification Internet puis cliquez sur OK. Enfin faites suivant pour
lancer l'installation d'IAS.
Une fois le service installé, vous pouvez y accéder en tapant ias.msc dans la boite de dialogue exécuter
ou bien en cliquant sur Service d'authentification Internet dans les outils d'administration.
Configuration d'IAS
Voici une capture d'écran de la console Service d'authentification Internet :
24
Client RADIUS
Le conteneur Clients RADIUS liste l'ensemble des serveurs d'accès distants qui sont des clients vis-à-
vis du serveur IAS. Pour qu'un serveur d'accès distant fasse partie de cette liste, il suffit de l'y ajouter
en utilisant l'assistant Ajouter un client RADIUS.
Pour ajouter un client RADIUS, il suffit d'entrer son nom de domaine pleinement qualifié (FQDN) ou
bien son adresse IP ainsi qu'une chaîne de caractère permettant de le reconnaître facilement.
25
Il faut ensuite choisir le type de technologie RADIUS à utiliser (ici RADIUS standard), une clé
partagée (optionnelle) pour crypter les échanges entre le client et le serveur IAS. On peut aussi côcher
la case Les requêtes doivent contenir l'attribut de l'authentificateur de message qui aura pour effet de
forcer le client RADIUS à s'authentifier à chaque connexion auprès du serveur IAS en envoyant une
signature numérique.
Connexion par accès distant
Le conteneur Connexion par accès distant permet de configurer la journalisation. Il est par exemple
possible de choisir les informations qui seront enregistrées.
26
Mais aussi, l'emplacement, le format et la fréquence d'actualisation du fichier journal.
Stratégie d'accès distant
Le conteneur Stratégie d'accès distant est identique à celui présent dans la console Routage et accès
distant. Il stocke l'ensemble des stratégies d'accès distant disponibles pour chaque serveur d'accès
distant.
3-) Configuration du serveur d'accès distant pour utiliser IAS
Pour que les serveur d'accès distant envoie les demandes d'authentifications vers le serveur IAS, il est
nécessaire de modifier leur configuration originelle. Pour cela il faut lancer la console Routage et
Accès distant (vous pouvez taper rrasmgmt.msc dans la boite de dialogue exécuter) puis faire un clic
27
droit sur le nom du serveur, puis propriétés. Sectionnez ensuite l'onglet Sécurité et vous devriez
accédez à la fenêtre ci-contre.
Choisissez Authentification RADIUS dans la liste déroulante Fournisseur d'authentifications, puis
cliquez sur le bouton Configurer.
Dans la fenêtre Authentification RADIUS, cliquez sur le bouton Ajouter.
28
Vous devez saisir le nom DNS pleinement qualifié du serveur IAS dans le champ réservé à cet effet.
Si vous avez choisi d'utilisé une clé pré-partagée lors de l'ajout du serveur d'accès distant dans la liste
des client RADIUS du serveur IAS, vous devez saisir la même clé en cliquant sur le bouton Modifier.
Si vous avez côché l'option Les requêtes doivent contenir l'attribut de l'authentificateur de message,
lors de l'ajout du serveur d'accès distant dans la liste des client RADIUS du serveur IAS, alors vous
devez aussi côcher la case Toujours utiliser l'authentificateur de messages. Ainsi à chaque demande
d'accès distant, le serveur d'accès distant enverra une signature numérique permettant de l'identifier en
tant que client RADIUS auprès du serveur IAS.
Vous pouvez éventuellement modifier le port par défaut pour envoyer les messages d'authentification
vers le serveur IAS.
Une fois toutes ces modifications effectuées vous devez redémarrer le service Routage et accès distant
pour que les modifications soient prises en compte.
Configuration des clients d'accès à distance et sécurisation de l'accès à distance
Présentation du réseau privé virtuel (VPN)
Une connexion réseau privé virtuel ou VPN (Virtual Private Network) permet à deux entités de
communiquer entres-elle de façon sécurisée en passant par un réseau public (non sécurisé) comme
Internet. Les réseaux privés virtuels sont souvent utilisés dans le cadre de l'accès à distance car ils
permettent à un utilisateur lambda d'accéder aux ressources internes de l'entreprise en utilisant un
réseau dont le coût de location est faible (Internet) de manière sécurisée. Pour cela les réseaux privés
virtuels utilisent des protocoles spécifiques comme PPTP ou bien encore L2TP/IPSec appelés
protocole de tunnel.
Les protocoles de tunnel chiffrent les trames de données puis encapsulent ces trames dans des
paquets IP qui sont envoyés sur Internet. La sécurité des données est maximale puisque les adresses IP
privées (celle du client et du serveur d'accès distant) sont chiffrées. Il est donc impossible pour un
utilisateur non autorisé d'avoir accès aux données circulant sur la toile.
29
Les protocoles de cryptage utilisés par PPTP et L2TP sont respectivement MPPE et IPSec.
2-) Configurer une connexion VPN sous Windows XP
Pour créer une connexion VPN sous Windows XP, affichez la page listant les connexions réseau (clic
droit / propriétés sur l'icône favoris réseau) puis lancez l'Assistant Nouvelle Connexion et cliquez sur
Suivant. Sélectionnez Connexion au réseau d'entreprise.
Cliquez sur Suivant, puis sur Terminer pour quitter l'assistant. Vous devez ensuite saisir l'identifiant et
le mot de passe à utiliser pour s'authentifier auprès du serveur d'accès distant. Vous pouvez choisir
d'enregistrer ces informations d'authentification ce qui évitera de les ressaisir à l'avenir.
Vous pouvez ensuite cliquer sur Se connecter pour établir la connexion VPN.
30
Les propriétés de la connexion permettent de modifier un grand nombre de paramètre comme le
protocole d'authentification à utiliser (MS-CHAP V2 est le protocole recommandé pour obtenir une
sécurité maximale), les paramètres TCP/IP, l'adresse IP du serveur d'accès distant, ...
Sécuriser les accès distants
Permettre à des utilisateurs distants d'accéder aux ressources internes de l'entreprise peut s'avérer
risqué du point de vue de la sécurité. Voici un ensemble de règles simples qui permettent de sécuriser
au mieux une connexion d'accès à distance :
o Centralisez les demandes d'authentifications à l'aide d'un serveur RADIUS.
31
o Sécurisez au maximum le trafic entre le serveur RADIUS et les serveurs d'accès distant
(utilisation d'une clé pré-partagée, de signatures numériques pour identifier les serveurs
d'accès distant, d'IPSec pour crypter les échanges de données,...).
o Configurez les stratégies d'accès distant les plus restrictives possibles (limitez les plages
horaires, paramétrez une durée d'inactivité de la connexion faible, utilisez uniquement les
protocoles MS-CHAP V2 ou EAP pour authentifier les utilisateurs, utilisez le cryptage
maximal,...)
o Si vous utilisez le protocole L2TP/IPSec mettez en place un système de certificats.
o Mettez en place une stratégie de groupe verrouillant le compte des utilisateurs distant après un
certain nombre de tentatives infructueuses.
Vous pouvez aussi envisager l'installation d'un pare-feu comme ISA Server afin d'augmenter le niveau
de sécurité du réseau interne de l'entreprise.
Conclusion
La console Routage et accès distant (RRAS) regroupe toutes les fonctionnalités nécessaires à la
création de connexions d'accès distant. Les méthodes d'accès distant proposées (réseau privé virtuel,
sans fil,...) permettent une adaptation à tout les cas de figure envisageables. L'association des profils
d'accès distant et des stratégies d'accès distant permet de sécuriser et de réglementer de façon très fine
une connexion à travers un réseau public comme Internet. De plus, la mise en place du service IAS
facilite la maintenance des stratégies d'accès distant grâce à l'utilisation du protocole RADIUS qui
permet la centralisation des requêtes d'authentification.
En conclusion, l'infrastructure intégrée à Windows 2000/2003 server permet de mettre en place
rapidement un service d'accès à distance fiable, sécurisé et hautement paramétrable.
32
SNORT
I. Introduction
Les systèmes d'information sont aujourd'hui de plus en plus ouverts sur Internet. Cette ouverture, a
priori bénéfique, pose néanmoins un problème majeur : il en découle un nombre croissant d'attaques.
La mise en place d’une politique de sécurité autour de ces systèmes est donc primordiale.
Outre la mise en place de pare-feux et de systèmes d'authentification de plus en plus sécurisés, il est
nécessaire, pour compléter cette politique de sécurité, d'avoir des outils de surveillance pour auditer le
système d'information et détecter d'éventuelles intrusions.
Ce que nous appelons intrusion signifie pénétration des systèmes d'information mais aussi tentatives
des utilisateurs locaux d'accéder à de plus hauts privilèges que ceux qui leur sont attribués, ou
tentatives des administrateurs d'abuser de leurs privilèges.
Les attaques d’intrusion peuvent être répertoriées selon trois types :
- les attaques réseau ;
- les attaques par portes dérobées (backdoors) et canaux de communication cachés
(cover channels) ;
- les attaques sur les services, qui gagnent une importance croissante (de nos jours, à peu près
60% des intrusions se font via le Web).
La détection d’intrusion est étudiée depuis plus de vingt-cinq ans Les systèmes dits “passifs” de
détection d’intrusion (IDS pour Intrusion Detection Systems) ont été déployés de plus en plus
largement, suivis aujourd’hui par des systèmes dits “actifs” de prévention d’intrusion (IPS pour
Intrusion Prevention Systems). La recherche en détection (et prévention) d’intrusion est toujours très
active, notamment en raison des évolutions rapides et incessantes dans les technologies de
l’information et de la communication.
Au cours de cette Partie nous verrons comment se protéger efficacement face à ces intrusions, mais
aussi les problèmes techniques déduits de ces outils, nouvellement apparus dans le monde
informatique.
II. Détection d'attaques : les IDS
1. Pourquoi utiliser un IDS ?
• La surveillance du trafic d’un (plusieurs) réseau(x) de machines en vue de la surveillance « Temps
Réel » du trafic, par opposition à la consultation des traces (« Logs ») qui se fait forcement en différé,
sans parler des difficultés de repérer des failles.
• Ce que qu’on peut attendre d’un IDS : l’émission d’alertes qui permettront la détection de la
préparation d’une attaque, (scans massifs à la recherche de failles sur un ensemble de machines…),
une attaque en cours (trafic sur des ports correspondants à des failles), et à posteriori, la détection
d’une machine compromise avant qu’elle ne puisse servir de base d’attaques vers d’autres systèmes.
• En outre, il permet d’éditer des rapports permettant d’avoir une vision globale du degré de sécurité
d’un réseau ou d’un ensemble de machines, et cela de différents niveaux. A titre d’exemple, un rapport
33
à destination du management sera synthétique et dégagera des tendances pour mettre en évidence le
niveau de vulnérabilité d’un réseau. Un des intérêts de ce rapport synthétique est de pouvoir suivre
l’évolution du niveau de sécurité d’un réseau dans le temps. Ce document est en quelque sorte un
indicateur qualitatif concernant la sécurité d’un réseau ou d’un ensemble de machines. C’est un moyen
d’aide à la définition d’une politique de sécurité, c’est aussi un moyen de suivi de son application, car
la mise en œuvre d’une politique de sécurité est un processus continu. Il peut être utile pour justifier
des investissements en matière de sécurité en présentant leur incidence sur le niveau global de sécurité.
Les rapports à destination du personnel technique présenteront les failles ainsi que les éventuels
remèdes à appliquer pour les supprimer.
2. La détection d’intrusion
En sécurité informatique, la détection d'intrusion est l'acte de détecter les actions qui essaient de
compromettre la confidentialité, l'intégrité ou la disponibilité d'une ressource. La détection d'intrusion
peut être effectuée manuellement ou automatiquement. Dans le processus de détection d'intrusion
manuelle, un analyste humain procède à l’examen de fichiers de logs à la recherche de tout signe
suspect pouvant indiquer une intrusion.
Un système qui effectue une détection d'intrusion automatisée est appelé système de détection
d’intrusion (IDS). Lorsqu’une intrusion est découverte par un IDS, les actions typiques qu’il peut
entreprendre sont par exemple d’enregistrer l’information pertinente dans un fichier ou une base de
données, de générer une alerte par e-mail ou un message sur un pager ou un téléphone mobile.
Déterminer quelle est réellement l'intrusion détectée et entreprendre certaines actions pour y mettre fin
ou l'empêcher de se reproduire, ne font généralement pas partie du domaine de la détection
d'intrusion. Cependant, quelques formes de réaction automatique peuvent être implémentées par
l'interaction de l'IDS et de systèmes de contrôle d'accès tels que les pare-feu
3. Les différents types d'IDS
Les attaques utilisées par les pirates sont très variées. Certaines utilisent des failles réseaux et d’autres
des failles de programmation. Nous pouvons donc facilement comprendre que la détection d’intrusions
doit se faire à plusieurs niveaux.
Ainsi, il existe différents types d’IDS dont nous détaillons ci-dessous les caractéristiques principales.
a. Les systèmes de détection d’intrusions (IDS)
Définition : ensemble de composants logiciels et matériels dont la fonction principale est de détecter et
analyser toute tentative d’effraction (volontaire ou non).
Fonctions : détection des techniques de sondage (balayages de ports, fingerprinting), des tentatives de
compromission de systèmes, d’activités suspectes internes, des activités virales ou encore audit des
fichiers de journaux (logs).
b. Les systèmes de détection d’intrusions « réseaux » (NIDS)
Objectif : analyser de manière passive les flux en transit sur le réseau et détecter les intrusions en
temps réel.
Un NIDS écoute donc tout le trafic réseau, puis l’analyse et génère des alertes si des paquets semblent
dangereux.
Les NIDS étant les IDS plus intéressants et les plus utiles du fait de l’omniprésence des réseaux dans
notre vie quotidienne, ce document se concentrera essentiellement sur ce type d’IDS en étudiant
SNORT.
c. Les systèmes de détection d’intrusions de type hôte (HIDS)
34
Un HIDS se base sur une unique machine, n’analysant cette fois plus le trafic réseau mais l’activité se
passant sur cette machine. Il analyse en temps réel les flux relatifs à une machine ainsi que les
journaux.
Un HIDS a besoin d’un système sain pour vérifier l’intégrité des donnés. Si le système a été
compromis par un pirate, le HIDS ne sera plus efficace. Pour parer à ces attaques, il existe des KIDS
(Kernel Intrusion Detection System) et KIPS (Kernel Intrusion Prevention
System) qui sont fortement liés au noyau. Ces types d’IDS sont décrits un peu plus loin.
d. Les systèmes de détection d’intrusions « hybrides »
Généralement utilisés dans un environnement décentralisé, ils permettent de réunir les informations de
diverses sondes placées sur le réseau. Leur appellation « hybride » provient du fait qu’ils sont capables
de réunir aussi bien des informations provenant d’un système HIDS qu’un NIDS.
L’exemple le plus connu dans le monde Open-Source est Prelude. Ce framework permet de stocker
dans une base de données des alertes provenant de différents systèmes relativement variés. Utilisant
Snort comme NIDS, et d’autres logiciels tels que Samhain en tant que HIDS, il permet de combiner
des outils puissants tous ensemble pour permettre une visualisation centralisée des attaques.
4. Les méthodes de détection
Pour bien gérer un système de détection d’intrusions, il est important de comprendre comment celui-ci
fonctionne. Une question simple se pose alors : comment une intrusion est elle détectée par un tel
système ? Quel critère différencie un flux contenant une attaque d’un flux normal ?
Ces questions nous ont amenés à étudier le fonctionnement interne d’un IDS. De là, nous en avons
déduit deux techniques mises en place dans la détection d’attaques. La première consiste à détecter des
signatures d’attaques connues dans les paquets circulant sur le réseau. La seconde, consiste quant à
elle, à détecter une activité suspecte dans le comportement de l’utilisateur. Ces deux techniques, aussi
différentes soient-elles, peuvent être combinées au sein d’un même système afin d’accroître la
sécurité.
a. L’approche par scénario (misuse detection)
Cette technique s’appuie sur la connaissance des techniques utilisées par les attaquants pour déduire
des scénarios typiques. Elle ne tient pas compte des actions passées de l’utilisateur et utilise des
signatures d’attaques (= ensemble de caractéristiques permettant d’identifier une activité intrusive :
une chaîne alphanumérique, une taille de paquet inhabituelle, une trame formatée de manière suspecte)
Recherche de motifs (pattern matching)
La méthode la plus connue et la plus à facile à comprendre. Elle se base sur la recherche de motifs
(chaînes de caractères ou suite d’octets) au sein du flux de données. L’IDS comporte une base de
signatures où chaque signature contient les protocole et port utilisés par l’attaque ainsi que le motif qui
permettra de reconnaître les paquets suspects.
Le principal inconvénient de cette méthode est que seules les attaques reconnues par les signatures
seront détectées. Il est donc nécessaire de mettre à jour régulièrement le base de signatures.
Un autre inconvénient est que les motifs sont en général fixes. Or une attaque n’est pas toujours
identique à 100%. Le moindre octet différent par rapport à la signature provoquera la non détection de
l’attaque.
Pour les IDS utilisant cette méthode, il est nécessaire d’adapter la base de signatures en fonction du
système à protéger. Cela permet non seulement de diminuer les ressources nécessaires et donc
augmenter les performances ; mais également réduire considérablement le nombre de fausses alertes et
donc faciliter le travail des administrateurs réseaux qui analyseront les fichiers d’alertes. Cette
technique est également utilisée dans les anti-virus.
35
Analyse de protocoles
Cette méthode se base sur une vérification de la conformité (par rapport aux RFC) des flux, ainsi que
sur l’observation des champs et paramètres suspects dans les paquets. Cependant, les éditeurs de
logiciels et les constructeurs respectent rarement à la lettre les RFC et cette méthode n’est pas toujours
très performante.
L’analyse protocolaire est souvent implémentée par un ensemble de préprocesseurs, où chaque
préprocesseur est chargé d’analyser un protocole particulier (FTP, HTTP, ICMP, ...). Du fait de la
présence de tous ces préprocesseurs, les performances dans un tel système s’en voient fortement
dégradées.
L’intérêt fort de l’analyse protocolaire est qu’elle permet de détecter des attaques inconnues,
contrairement au pattern matching qui doit connaître l’attaque pour pouvoir la détecter.
Analyse heuristique et détection d’anomalies
Le but de cette méthode est, par une analyse intelligente, de détecter une activité suspecte ou toute
autre anomalie.
Par exemple : une analyse heuristique permet de générer une alarme quand le nombre de sessions à
destination d’un port donné dépasse un seuil dans un intervalle de temps prédéfini.
b. L’approche comportementale (Anomaly Detection)
Cette technique consiste à détecter une intrusion en fonction du comportement passé de l’utilisateur.
Pour cela, il faut préalablement dresser un profil utilisateur à partir de ses habitudes et déclencher une
alerte lorsque des événements hors profil se produisent.
Cette technique peut être appliquée non seulement à des utilisateurs mais aussi à des applications et
services. Plusieurs métriques sont possibles : la charge CPU, le volume de données échangées, le
temps de connexion sur des ressources, la répartition statistique des protocoles et applications utilisés,
les heures de connexion, … Cependant elle possède quelques inconvénients :
- peu fiable : tout changement dans les habitudes de l’utilisateur provoque une alerte.
- nécessite une période de non fonctionnement pour mettre en oeuvre les mécanismes d’auto-
apprentissage : si un pirate attaque pendant ce moment, ses actions seront assimilées à un
profil utilisateur, et donc passeront inaperçues lorsque le système de détection sera
complètement mis en place.
- l’établissement du profil doit être souple afin qu’il n’y ait pas trop de fausses alertes : le pirate
peut discrètement intervenir pour modifier le profil de l’utilisateur afin d’obtenir 18 après
c. Les méthodes répandues
En général, les IDS mélangent les différentes techniques de détection par scénario en proposant du
pattern matching, de l’analyse protocolaire et de la détection d’anomalies.
De nombreuses techniques et algorithmes sont utilisés dans la détection d’intrusions :
Pattern Matching :
- algorithmes de recherche de motifs (ex : Boyer-Moore) ,
- algorithmes de comptage
- algorithmes génétiques
Analyse Protocolaire :
- conformité aux RFC
Détection d’anomalies :
- méthodes heuristiques
Analyse statistique :
- modèles statistiques
Analyse probabiliste :
- réseaux bayésiens
36
Autre analyse comportementale :
- réseaux de neurones,
- systèmes experts + data mining
- immunologie, graphes, ...
Il est bien sûr impossible de détailler chacun des algorithmes mis en oeuvre dans les IDS.
III. Mise en oeuvre d'IDS
1. Historique du SNORT :
C’est en 1998 que Martin Roesch décide de publier un logiciel de sa conception, développé autour du
milieu Open Source : un programme qu’il appellera finalement ”Snort”, ce qui correspond au verbe
ainsi qu’à l’onomatopée anglaise du reniflement (sniffing, qui est d’ailleurs un principe informatique
bien connu dans le domaine de l’étude approfondie des paquets réseau).
Au commencement, il trouvait son système de détection anti intrusion ”plutôt léger” comparé aux
logiciels disponibles au marché à l’époque. Aujourd’hui, ce modeste personnage commence seulement
à témoigner de l’envergure des fonctionnalités proposées par Snort, et se met à en parler comme l’une
des technologies anti intrusions les plus répandues dans le monde. Depuis toutes ces années, le projet
Snort a beaucoup mûri, et a évolué vers un concept plutôt riche, ce qui l’a ainsi fait devenir un outil
standard pour la sécurité système et la détection d’intrusions. Des innovations récentes dans les règles
de comportement, ainsi que dans les fonctions de perception, ont permis de rendre la détection des
processus plus flexible et plus pointue, ce qui fait désormais de Snort un champion ”poids lourd” de la
sécurité dans ce domaine. . .
De ce fait, le projet Snort s’appuie lourdement sur cette méthodologie, et il est prouvé, que test après
test, Snort est en conclusion largement à la hauteur, comparé aux autres technologies dans ce domaine
sur le marché.
La puissance actuelle de Snort est principalement due à la grande efficacité de la communauté
d’utilisateurs. Sans parler des développeurs à plein temps sur ce logiciel, il faut compter un bon millier
de programmeurs expérimentés qui revoient et testent le code sans cesse, et mettent ainsi à l’épreuve
un nombre impressionnant de fonctionnalités, de stratégies, et de jeux de règles. Cependant,
aujourd’hui, il semble que le moteur de Snort ne soit plus libre, ce qui appelle donc à un certain
bouleversement dans l’optique de développement qui s’en trouve alors grandement controversée.
2. Ressources humaines du projet :
L’équipe de Snort est composée de 47 développeurs réguliers (on peut trouver leurs noms ici, cf.
http://www.snort.org/about snort/team.html) ainsi que d’un nombre très important de contributeurs
occasionnels, pour la plupart, réunis dans un des 21 groupes actifs d’utilisateur gravitant autour du
projet (cf. http ://www.snort.org /community/usergroups.html).
Créateur et superviseur : Marty Roesch.
Manager du produit Snort : Jennifer Steffens.
Responsable de la section ”Snort Rules” : Brian Caswell.
Responsable Win32 : Chris Reid.
Responsables RPM : JP Vossen, Daniel Wittenberg.
Responsable du développement de Snort : Marc Norton.
Developpeurs principaux : Marc Norton, Andrew Mullican, Steve Sturges
3. Présentation du Snort :
37
Snort est un système de détection d'intrusions réseau en ' Open Source ', capable d'effectuer l'analyse
du trafic en temps réel. On l'utilise en général pour détecter une variété d'attaques et de scans tels que
des débordements de tampons, des scans de ports furtifs, des attaques CGI, des scans SMB, des
tentatives d'identification d'OS grâce à l’analyse des signatures et des réponses caractéristiques
(fingerprinting), et beaucoup d’autres choses encore. Il peut fonctionner selon trois modes principaux :
il peut être utilisé comme un simple sniffer de paquets, comme un logger de trafic réseaux (ce qui est
fort utile pour déboguer un réseau par exemple puisque ce mode d’enregistrement des activités
répertorie toutes les interactions entre les machines d’un même réseau), ou comme un véritable
système complet de prévention contre les attaques et les intrusions de tout genre.
C'est un très puissant outil, il est connu comme un des meilleurs IDS sur le marché, même quand il est
comparé à des IDS commerciaux.
De nombreuses personnes dans la cette communauté très active partagent leurs règles de sécurité, ce
qui est très utile si on n'est pas un expert de la sécurité et si on veut des règles à jour.
La compagnie SourceFire délivre très régulièrement de nouvelles règles de sécurité. Elles peuvent être
téléchargées, soit gratuitement mais malheureusement que quelques jours après leurs sorties, soit
immédiatement pour des espèces sonnantes et trébuchantes.
4. Architecture du Snort :
Architecture du snort
Un noyau de base : (Packet Decoder) au démarrage, ce noyau charge un ensemble de règles, les
compile, les optimise et les classe. Durant l’exécution, le rôle principal du noyau est la capture des
paquets.
Une série de pré–processeurs: (Detection Engine) ces derniers améliorent les possibilités de SNORT
en matière d’analyse et de recomposition du trafic capturé. Ils reçoivent les paquets directement
capturés et décodés, les retravaillent éventuellement puis les fournissent au moteur de recherche des
signatures pour les comparer avec la base des signatures.
Une série de « Detection plugins »: Ces analyses se composent principalement de comparaison entre
les différents champs des headers des protocoles (IP, ICMP, TCP et UDP) par rapport à des valeurs
précises.
Une série de « output plugins »: permet de traiter cette intrusion de plusieurs manières : envoie vers
un fichier log, envoie d’un message d’alerte vers un serveur syslog, stocker cette intrusion dans une
base de données SQL.
5. Positionnement de SNORT dans le réseau
L’emplacement physique de la sonde SNORT sur le réseau a un impact considérable sur son efficacité.
Dans le cas d’une architecture classique, composée d’un Firewall et d’une
DMZ, trois positions sont généralement envisageables :
38
a. Avant le Firewall ou le routeur filtrant :
Positionnement du snort avant le firewall
Dans cette position, la sonde occupe une place de premier choix dans la détection des attaques de
sources extérieures visant l’entreprise. SNORT pourra alors analyser le trafic qui sera éventuellement
bloqué par le Firewall.
Les deux inconvénients de cette position du NIDS sont:
Primo, le risque engendré par un trafic très important qui pourrait entraîner une perte de fiabilité et
secondo, étant situé hors du domaine de protection du firewall, le NIDS est alors exposé à
d'éventuelles attaques pouvant le rendre inefficace.
b. Sur la DMZ :
39
Positionnement du snort après le firewall
Dans cette position, la sonde peut détecter tout le trafic filtré par le
Firewall et qui a atteint la zone DMZ. Cette position de la sonde permet de surveiller les attaques
dirigées vers les différents serveurs de l’entreprise accessible de l’extérieur.
c. Sur le réseau interne :
Positionnement du snort sur le réseau interne
Le positionnement du NIDS à cet endroit nous permet d’observer les tentatives d’intrusion parvenues
de l’intérieur du réseau d’entreprise ainsi que les tentatives d’attaques à partir de l'intérieur. Dans le
cas d’entreprises utilisant largement l'outil informatique pour la gestion de leur activités ou de réseaux
fournissant un accès à des personnes peu soucieuses de la sécurité (réseaux d’écoles et d’universités),
cette position peut revêtir un intérêt primordial.
6. Les règles de SNORT :
Les règles de SNORT sont composées de deux parties distinctes : le header et les options.
Le header permet de spécifier le type d’alerte à générer (alert, log et pass) et d’indiquer les champs de
base nécessaires au filtrage : le protocole ainsi que les adresses IP et ports sources et destination.
Les options, spécifiées entre parenthèses, permettent d’affiner l’analyse, en décomposant la signature
en différentes valeurs à observer parmi certains champs du header ou parmi les données.
Composition du règles de snort
Action de la règle : alert, log, pass
Protocole : tcp, udp, icmp
Adresses source et destination : src, dest, any
Port src / dest : any, nb port, plage de ports avec p1:pn
40
Opérateur de direction : > unidirectionnel, ou <> bidirectionnel
Syntaxe des options :
– combinaison de règles avec le séparateur « ; »
– séparation des mots clefs et des arguments avec « : »
– mots clefs : msg, logto, minfrag, ttl, id, dsize, content, offset, depth, flags, seq, ack, itype, idecode,
nocase, session
7. Installation & configuration
a. Installation du Snort:
Donc pour initialiser SNORT sous UBUNTU on peut utiliser la commande aptget install pour
télécharger et installer les paquets nécessaires automatiquement.
apache2
Pour le serveur web : #aptget install apache2
MySQLserver
pour la base de données : #aptget install mysqlserver
php5
pour le script orienté serveur : #aptget install php5
php5MySQL
pour la configuration du php avec mysql : #aptget install php5mysql
php5gd
pour la librairie graphique : #aptget install php5gd
PEAR
pours 'PHP Extension' et 'Application Repository' : #aptget install phppear
Iptables
est un parefeu sous linux : #aptget install iptablesdev
Clamav
Antivirus : #aptget install clamav
snortmysql :
#aptget install snortmysql
outils de compilation :
#aptget install buildessential
Libnet
est une interface de programmation générique réseau qui fournit unaccès à plusieurs protocoles.
#aptget install libnet1dev
Libpcap
Libcap est une librairie pour capturer des paquets réseaux: #aptget install libpcap0.8dev
Pcre
Pcre est une librairie de fonctions utilisant la même syntaxe et sémantique que Perl 5.
#aptget install libpcre3dev
mysqlclient
Librairies de développement MySQL et fichiers header: #aptget install libmysqlclient16-dev
CHECKINSTALL
Pour installer ou désinstaller facilement les programmes depuis la source: #aptget install checkinstall
Après le téléchargement du snort-2.9.0.5, on crée deux dossiers, un pour stocker les fichiers de
configuration et l'autre pour stocker les règles Snort.
#mkdir /etc/snort
#mkdir /etc/snort/rules
Ensuite on copie les fichiers de configuration de Snort dans le dossier /etc/snort/ :
#cp snort-2.9.0.5/etc/* /etc/snort/
41
Les deux fichiers de configuration dans notre dossier /etc/snort/rules:
#cp snor snort-2.9.0.5/etc/classification.config /etc/snort/rules/
#cp snort/ etc/reference.config /etc/snort/rules/
- classification.config: définit des URLs pour les références trouvées dans les règles.
- reference.config: inclus de l'information pour la prioritisation des règles.
On peut créer un utilisateur appelé snort pour lancer Snort:
#useradd snort d /var/log/snort -s /bin/false -c SNORT_IDS
Un dossier de log appartenant à l'utilisateur snort:
#mkdir /var/log/snort
#chown -R snort /var/log/snort
Ensuite :
#tar –xzf snort2.8.3.1 (décompression du paquet)
#cd snort2.8.3.1
#./configure withmysql enableinline enableclamav –enable --dynamicplugins
Configuration du snort avec la base de donnée et activation des plugins
tel que:
--enableinline: pour activer la communication avec le parefeu (iptable) et rendre Snort un IPS
(intrusion prevention system) qui réagit lors de la détection d'une intrusion.
--enableclamav: pour améliorer la base des signatures du snort par la configuration avec l'antivirus
Clamav, dans ce cas, snort jouera le rôle d'un IDS et un antivirus en même temps.
--enabledynamicplugins : pour rendre snort configurable avec les nouveaux plugins même après
installation.
#make : (compilation du paquet)
Erreur dans make :
42
#checkinstall (exécution de l’installation)
b. Configuration de la base de données MYSQL:
Premièrement, il faut créer la base de données MySQL et les tables pour
recevoir les logs de Snort:
#mysql -u root p
>create database snort;
Comme il est dangereux d'accéder à la base de données avec l'utilisateur root, il est nécessaire de créer
un utilisateur avec des permissions sur la base de données snort uniquement:
#grant all on snort.* to snortuser@localhost identified by 'pwd'
Puis on recharge les privilèges MySQL:
#flush privileges
>exit;
Maintenant, nous devons créer les tables dans la base de données snort:
Par chance, les tables sont déjà créées et nous devons juste les trouver et les installer dans la base de
données:
#mysql -u root –p snort < schemas/create_mysql
c. Configuration du snort pour SQL:
Nous devons dévier les logs de Snort dans la base de données:
Il est juste nécessaire de configurer le login et mot de passe pour accéder à la base de données snort.
Dans le fichier /etc/snort/snort.conf, nous devons ajouter ou modifier les lignes entre (#DBSTART#)
et (#DBEND#):
output database: log, mysql, user=snortuser password=pwd
dbname=snort host=localhost
Toujours dans le même fichier, il faut décommenter les lignes suivantes:
ruletype redalert
{
type alert
output alert_syslog: LOG_AUTH LOG ALERT
output database: log, mysql, user=snortuser password=pwd
dbname=snort host=localhost
}
Configuration de Snort est maintenant terminée Pour lancer snort :
#snort -u snort -c /etc/snort/snort.conf
Cela veut dire que snort est démarré avec l'utilisateur snort et va charger la configuration stockée dans
le fichier /etc/snort/snort.conf. Pour des raisons de sécurité, il est toujours conseillé de démarrer des
programmes sans l'utilisateur root.
43
Pour lancer snort automatiquement au démarrage du système, on peut ajouter une ligne dans le fichier
/etc/crontab.
@reboot root snort u
snort c
/etc/snort/snort.conf >> /dev/null
44
RC5 RC5 est un algorithme de chiffrement par blocs avec de nombreux paramètres : taille des
blocs, taille de la clef, et nombre de rondes. Ron Rivest en est l’inventeur et il a été analysé par les
laboratoires RSA.
Il y a deux opérations : ou exclusif, addition et rotation. Les rotations prennent un temps
constant sur la plupart des processeurs et les rotations variables sont des fonctions non linéaires. Ces
rotations qui dépendent à la fois de la clef et des données constituent la partie intéressante.
La longueur des blocs est variable dans RC5, mais on se concentrera dans l’exemple qui suit
sur une taille de 64 bits. Le chiffrement nécessaire 2 2r mots de 32 bits dépendants de la clef,
0 1 2 2 2, , ,...., rS S S S , où r est le nombre de rondes. Pour chiffrer, diviser d’abord tout le bloc de texte
en clair en mots de 32 bits : A et B. Il faut alors procéder ainsi :
0A A S
1B B S
Pour i variant de 1 à r, effectuer :
2(( ) ) iA A B B S
2 1(( ) ) rB B A A S
La sortie est constituée des registres A et B.
Le déchiffrement est tout aussi facile. Partager le texte chiffré en deux mots A et B, et effectuer :
2 1
2
(( ) )
(( ) )
r
r
B B S A A
A A S B B
1
0
B B S
A A S
45
Avec la fonction ROTL de chiffrement et la fonction ROTR de déchiffrement sont défini
respectivement :
( , ) ((( ) ( &( 1))) | (( )>>( -( &( -1)))))
( , )=((( )>>( &( -1))) | (( ) ( ( &( 1)))))
ROTL x y x y w x w y w
ROTR x y x y w x w y w
La création du tableau de clef est plus compliquée mais directe aussi. Commencez par copier
les bits de la clef dans un tableau L de c mots de 32 bits (en remplissant si nécessaire le dernier mot
avec des zéro). Initialisez alors le tableau en utilisant un générateur congruentiel modulo 322 :
0
32
1
i variant de 1 à 2(r+1)-1, effectuer:
( ) mod 2i i
S P
Pour
S S Q ulo
P=0xB7E15163 et Q=0x9E3779B9 sont des constantes basées sur e.
Pour finir, mélangez L et S :
46
0
0
Effectuer n fois (où n est le maximum de 2(r+1) et c):
( ) 3
( ) ( )
( 1) modulo 2( 1)
( 1) modulo c
i i
i i
i j
A B
A S S A B
B L L A B A B
i i r
j j
RC5 est en fait une famille d’algorithme. Nous avons défini RC5 avec des mots de 32 bits de
long et des blocs de 64 bits de long : rien n’empêche l’algorithme de fonctionner avec des mots de 64
bits de long et des blocs de 128 bits de long. Rivest désigne les réalisations particulières de RC5 par
5 / /RC w r b où w est la taille des mots, r le nombre de rondes, et b la longueur de la clef en octets.
Pour w =64, P et Q valent respectivement
0 7 151628 2 6 ET 0 9 3779 9 4 7 15P xB E AED A B Q x E B F A C .
RC5 est nouveau, mais les laboratoires RSA ont passé un temps considérable à l’analyser avec
une taille de bloc de 64 bits. Après 5 rondes, les statistiques paraissent très bonnes. Après 8 rondes,
chaque bit du texte en clair affecte au moins une rotation. Il existe une attaque différentielle avec 242
textes en clair choisis pour 5 rondes, 452 pour 10 rondes, et
682 pour 15 rondes. Il n’y a bien sûr que 642 textes en clair possibles. Aussi cette attaque ne marchera pas pour 15 rondes ou plus. Des
estimations en cryptanalyse linéaire indiquent que l’algorithme est sûr après 6 rondes. Rivest
recommande au moins 12 rondes et 16 si possible. Ce nombre pourrait changer.
Le code de RC5 :
47
Le résultat de l’exécution :
48
RC6
I. Le chiffrement par bloc
Le chiffrement par bloc (en anglais block cipher) est une des deux grandes catégories de chiffrements
modernes en cryptographie symétrique, l'autre étant le chiffrement par flot. La principale différence
vient du découpage des données en blocs de taille généralement fixe. La taille de bloc est comprise
entre 32 et 512 bits, dans le milieu des années 1990 le standard était de 64 bits mais depuis 2000 et le
concours AES le standard est de 128 bits. Les blocs sont ensuite chiffrés les uns après les autres. Il est
possible de transformer un chiffrement de bloc en un chiffrement par flot en utilisant un mode
d'opération comme ECB (chaque bloc chiffré indépendamment des autres) ou CFB (on chaîne le
chiffrement en effectuant un XOR entre les résultats successifs).
Une liste non-exhaustive de chiffrements par bloc :
DES, l'ancêtre conçu dans les années 70, a été passablement étudié
AES, le remplaçant de DES
Blowfish, Serpent et Twofish, des alternatives à AES
Il y en a encore bien d'autres qui sont adaptés à des besoins particuliers. Certains consomment plus de
mémoire ou sont plus gourmands en puissance de calcul. Un chiffrement par bloc peut également être
utilisé comme une fonction de hachage, c'est-à-dire une fonction à sens unique. Une variante de DES
est employée pour le système de mots de passe dans Unix. Une chaîne contenant uniquement des zéros
est chiffrée avec une clé correspondant au mot de passe (une composante aléatoire appelée "sel" est
encore intégrée à l'algorithme). Ce chiffrement est itératif et se fait 25 fois avant d'obtenir le résultat
final.
II. Présentation de l’algorithme RC6
Le RC6 a été créé en 1998. Il propose des améliorations au RC5 et, comme celui-ci, est fortement
dépendant de la transformation de décalage de bits (rotation). Comme le RC5, il a l'avantage d'avoir
une longueur de bloc de données variable, un nombre de rounds variable et une clé de longueur
variable.
Toutefois, il utilise la multiplication, ce qui augmente la diffusion dans chacun des rounds, donc la
sécurité, et il a dû se conformer à des spécifications : opérer des blocs de 128 bits divisés en quatre
dans le traitement et être hautement sécuritaire par rapport à sa complexité.
RC6 a été soumis au NIST pour devenir le nouveau standard de la cryptographie avancée (Advanced
Encryption Standard - AES).
III. Principes de l’algorithme
49
RC6–w/r/b décrit une famille d’algorithmes de cryptage dont chaque membre est caractérisé par la
largeur des mots traités (w bits), le nombre de rondes r et la taille de la clef (b octets). La version
proposée pour AES utilise par exemple les paramètres w = 32, r = 20 et b = 16, 24 ou 32.
Quatre opérations distinct.es interviennent lors du cryptage avec RC6–w/r/b. La réalisation matérielle
des deux premières, déjà rencontrées lors de notre étude de l’algorithme IDEA, n’offre plus aucune
difficulté:
❶ Le OU exclusif bit à bit de deux mots de w bits, noté ⊕.
❷ L’addition entière modulo 2w de deux opérandes de w bits, notée _.
❸ La rotation à gauche, notée ≪. En étudiant l’algorithme, nous constatons toutefois que le nombre de
positions des deux premières rotations est constant
Schéma descriptif de l’algorithme de chiffrement RC6.
50
(lignes 4 et 5), alors que celui des deux suivantes varie en fonction des log2w bits de poids faibles des
opérandes u et t (lignes 6 et 7). Il faut donc co. ncevoir deux opérateurs distincts. La rotation de log2w
positions ne requiert évidemment aucune ressource matérielle particulière. En effet, comme
il suffit de permuter les log2w bits de poids forts avec les bits restants lors de leur connexion à
l’opérateur ⊕. Si le nombre de positions est variable, la rotation s’effectue à l’aide d’un barrel-shifter.
❹ La fonction f (X) = (X(2X +1)) mod 2w = (2X2+X) mod 2w. La conception d’un opérateur calculant
efficacement f (X) s’avère cruciale afin de restreindre le temps de cycle d’une ronde de calcul. Le
prochain paragraphe est consacré à l’étude de ce problème.
Contrairement à IDEA, l’architecture utilisée pour le décryptage (algorithme 4.8) diffère légèrement
de celle intervenant lors du chiffrement des données. Nous constatons en particulier l’apparition de la
soustraction entière modulo 2w, notée _, et de la rotation à droite, désignée par≫.
Le calcul des sous-clefs, décrit par l’algorithme 4.9, nécessite deux constantes
Pw et Qw. P32 = b7e15163 et Q32 = 9e3779b9 sont respectivement définies à partir des
représentations binaires de e−2 et du nombre d’or diminué de un. Ces valeurs arbitraires peuvent être
choisies par le concepteur d’un système proposant RC6. Il faut toutefois que l’auteur d’un message et
le destinataire utilisent les mêmes coefficients Pw et Qw.
