FR2888695A1 - Detection d'une intrusion par detournement de paquets de donnees dans un reseau de telecommunication - Google Patents

Detection d'une intrusion par detournement de paquets de donnees dans un reseau de telecommunication Download PDF

Info

Publication number
FR2888695A1
FR2888695A1 FR0507532A FR0507532A FR2888695A1 FR 2888695 A1 FR2888695 A1 FR 2888695A1 FR 0507532 A FR0507532 A FR 0507532A FR 0507532 A FR0507532 A FR 0507532A FR 2888695 A1 FR2888695 A1 FR 2888695A1
Authority
FR
France
Prior art keywords
packet
entity
packets
network
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR0507532A
Other languages
English (en)
Inventor
Laurent Butti
Roland Duffau
Franck Veysset
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to FR0507532A priority Critical patent/FR2888695A1/fr
Priority to PCT/FR2006/001508 priority patent/WO2007010101A2/fr
Priority to US11/988,558 priority patent/US20090138971A1/en
Priority to EP06778701A priority patent/EP1902563A2/fr
Publication of FR2888695A1 publication Critical patent/FR2888695A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1466Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12Detection or prevention of fraud
    • H04W12/121Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122Counter-measures against attacks; Protection against rogue devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10Small scale networks; Flat hierarchical networks
    • H04W84/12WLAN [Wireless Local Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/04Interfaces between hierarchically different network devices
    • H04W92/10Interfaces between hierarchically different network devices between terminal device and access point, i.e. wireless air interface

Abstract

L'invention propose une détection d'intrusion de type "Man-In-The-Middle" entre une entité (CL) et un point d'accès (AP) d'un réseau notamment selon la norme IEEE-802.11. Elle propose à cet effet les étapes suivantes :a) lire les corps de trames (FRA-i,...,FRA-i+3) transmises entre l'entité et le point d'accès,b) détecter des trames (FRA-i, FRA-i+2) transmises à des instants respectifs distincts, mais comportant pourtant des corps de trames (fb) identiques,c) et déclencher une alarme en cas de détection positive à l'étape b).

Description

Détection d'une intrusion par détournement de paquets de données
dans un réseau de télécommunication La présente invention concerne, de manière générale, la détection d'une intrusion entre une entité communicante via un réseau et un point d'accès de ce réseau.
En particulier dans les réseaux sans fil, spécifiés notamment dans les normes [IEEE802.11-1997] et [IEEE802.11-1999] et largement utilisés dans les io réseaux dits "Hot-Spots", Entreprises et Résidentiels, des techniques de piratage sont apparues et l'un des risques les plus importants pour de tels réseaux est de créer un faux point d'accès afin d'intercepter les communications d'entités légitimes dites "clients" et récupérer ainsi des données privées (ou "Payload" en anglais). Cette catégorie d'attaque est alors dite "attaque par point d'accès illégitime".
Le point d'accès est en effet un élément primordial de la communication entre un client et un réseau. Une attaque connue mettant en oeuvre un faux point d'accès consiste, pour l'attaquant, à se retrouver entre un client légitime et un point d'accès légitime du réseau. Dans cette position, l'attaquant est alors capable d'intercepter toutes les communications. On parle d'attaque de type "Man-ln-The-Middle".
Dans le contexte de la présente invention, la communication a lieu par paquets de données comportant, de manière générale, un champ dans lequel peuvent être identifiées au moins les adresses de départ et de destination des paquets (dites aussi "adresse source" et "adresse destination"). Il peut typiquement s'agir d'adresses MAC (pour "Medium Access Contro!') ou IP (pour "Internet Protocof').
D'une manière générale, les attaques de type "Man-ln-The-Middle" sont difficilement détectables car elles peuvent mettre en oeuvre une technique d'usurpation d'adresse MAC notamment. II devient difficile alors de distinguer deux équipements différents émettant à partir d'une même adresse MAC.
Ce type d'attaque est particulièrement efficace et intéressant pour l'attaquant lorsque la connexion légitime, par exemple dans un réseau sans fil, n'est pas chiffrée et a lieu en mode dit "infrastructure", c'est-à-dire entre un client et un point d'accès. C'est typiquement le cas de la technologie "hot-spot' déployée to par les opérateurs de téléphonie mobile, et celui de la majorité des réseaux d'accès sans fil aux entreprises (même si ces derniers utilisent des mécanismes de sécurité des couches supérieures (au dessus de niveau 2) tels que IPsec, SSH (Secure Shell) ou TLS (Transport Layer Security) pour l'accès des collaborateurs). is
La présente invention vise en particulier une détection efficace d'une attaque de type "Man-In-The-Middle" pour les réseaux de type "hot-spot" ou entreprise. L'efficacité de l'attaque, dans ce dernier cas, dépend beaucoup des mécanismes de sécurité utilisés par l'entreprise, en particulier leur vulnérabilité à des attaques actives.
On décrit ci-après de façon détaillée une attaque de type "Man-ln-TheMiddle" (notée ci-après MITM).
En référence aux figures générales 1 et 2, lors d'une communication classique en mode infrastructure, le client CL est directement connecté au point d'accès AP via un réseau de télécommunication RES. Dans une connexion standard telle que représentée sur la figure 1, il accède alors aux services offerts par un second réseau qui est situé derrière le(s) point(s) d'accès, par exemple à un accès Internet dans le cas de l'utilisation d'un hot-spot WiFi.
Malheureusement, le client légitime CL n'a que peu d'informations sur le point d'accès légitime auquel il se connecte. En pratique, ces informations sont souvent le nom de réseau (ESSID, pour "Extended Service Set Identifie?' en anglais), voire l'adresse MAC (BSSID, pour "Basic Service Set Identifier" en anglais). Toutefois, ces éléments peuvent habituellement être usurpés facilement.
Dans de nombreux environnements, un pirate est généralement en mesure de mener une attaque de type MITM en usurpant la fonction de point d'accès pour le client, et la fonction de client pour le point d'accès. En référence à la figure 2 illustrant une attaque de type MITM, le pirate PI se positionne ainsi en relais "transparent" et intercepte donc l'ensemble des paquets émis par le to client et par le point d'accès légitime.
Pour émuler un faux point d'accès, l'attaquant choisit un nom de réseau (identifiant "ESSID"), une adresse MAC pour son interface sans fil (identifiant "BSSID"), et un canal radio sur lequel émettre. Ces trois éléments peuvent éventuellement être choisis de manière à être les mêmes que ceux du point d'accès légitime, de manière à réduire au maximum les chances pour l'attaquant d'être détecté facilement car, en effet, des outils de détection d'intrusion appropriés pourraient facilement repérer un écart, tel que l'apparition d'un nouveau point d'accès avec d'autres caractéristiques que celles des points d'accès légitimes. Toutefois, pour des raisons d'interférence et donc d'efficacité de l'attaque, l'attaquant devra généralement choisir un canal différent de celui du point d'accès légitime.
La présente invention ne se limite pas à l'un des cas particuliers relatifs à ces variantes de l'attaque. On comprendra par conséquent que ces différentes variantes ne sont pas décrites en détail.
Par ailleurs, pour que l'attaque se déroule sans être détectée facilement par le client, le pirate retransmet l'ensemble des informations reçues entre le client légitime et le point d'accès légitime. En référence à la figure 2, le pirate PI relaye par la flèche 2 les données qu'il reçoit de la flèche 1 et inversement.
Actuellement, aucune technique, unique et sûre, pour la détection d'attaque de type MITM n'a apparemment été proposée. En général, on utilise la conjonction de plusieurs techniques permettant de détecter les différentes phases de cette attaque. Puis, via une corrélation des différents résultats obtenus (typiquement mettant en oeuvre un mécanisme de détection de séquence d'événements), on procède à l'identification de l'attaque proprement dite Les techniques suivantes peuvent être utilisées simultanément: détection d'une dé-association (ou dé-authentification) d'un client qui a to pour but de déconnecter un client légitime du point d'accès légitime auquel il est associé ; détection d'une (ou de plusieurs) usurpation(s) d'adresse(s) MAC(s), selon que l'attaquant usurpe l'adresse MAC du point d'accès seulement ou également celle du client, via l'analyse des identifiants "Sequence Number"
par exemple;
détection de la création d'un point d'accès illégitime (par exemple un même BSSID et un même ESSID qu'un point d'accès légitime, mais le canal radio est différent) ; et éventuellement détection d'un nombre de messages EAP ("Extensible Authentication Protocot') supérieur au nombre normalement utilisé par un client pour se connecter à un point d'accès. Dans ce type d'attaque, le client légitime s'associe au point d'accès illégitime et l'attaquant usurpe l'identité du client légitime pour s'associer au point d'accès légitime. On comprendra ainsi que deux fois plus de trames EAP sont diffusées avec les mêmes adresses MAC source et destination. Le critère des adresses MAC peut varier selon que l'attaquant usurpe également l'adresse MAC du client légitime ou bien uniquement celle du point d'accès légitime.
Ainsi, on détecte habituellement une attaque à l'aide d'une succession logique d'événements. Toutefois, ces événements peuvent être chacun sujet à des faux positifs (alarmes levées à tort), mais aussi et surtout à des faux négatifs (attaques non détectées) dans le cas où l'on décide de ne détecter l'attaque que si toutes les conditions précitées sont remplies.
La technique basée sur l'analyse du Sequence Number nécessite la gestion de seuils très précis et délicats à positionner. Par conséquent, cette technique seule est difficile à mettre en oeuvre afin de s'assurer de l'absence de faux to positifs et faux négatifs. La difficulté principale réside dans la gestion des pertes de paquets lors, par exemple, d'une transmission à longue distance. En effet, certains paquets seront perdus, ce qui entraînera des problèmes de faux positifs car les Sequence Number varieront fortement d'un paquet à l'autre. Il est donc nécessaire de gérer des seuils de manière très fine.
Les techniques d'identification de dé-association d'un client et d'analyse du nombre de trames EAP utilisées lors de la reconnexion d'un client sont également soumises au risque de perte de paquets. En effet, la dé-authentification d'un client ne repose que sur un seul paquet (trame de dé-association ou dé-authentification), qui, par exemple en cas d'une surcharge des capacités de calcul d'une sonde, peut ne pas être vu par cette sonde. De même, la méthode d'énumération des paquets EAP ne tolère pas la perte de paquets.
En outre, l'attaque de type MITM peut aussi se dérouler lors de l'arrivée initiale du client sur le réseau. Ce nouveau client se connecte alors sur un faux point d'accès qui attendait son arrivée et ce faux point d'accès peut ensuite effectuer la deuxième partie de l'attaque, en usurpant les informations du client pour se connecter au point d'accès légitime. Dans ce cas, aucune trame de dé-association ou dé-authentification n'est échangée, rendant la détection de l'attaque encore plus improbable.
La présente invention vient améliorer la situation.
Elle propose à cet effet un procédé de détection d'une intrusion dans une communication de données privées entre une première entité et une seconde entité, communicantes via un réseau de télécommunication, * la communication étant effectuée par transmission de paquets successifs, chaque paquet comportant au moins: un champ d'en-tête incluant au moins une adresse de source du paquet et/ou une adresse de destination du paquet pour un routage approprié des paquets, to et un corps de paquet incluant des données privées, * ladite intrusion consistant au moins à : s'interconnecter entre la première et la seconde entité, usurper l'adresse de la première entité et/ou l'adresse de la seconde entité en tant qu'adresse de source et/ou de destination, et détourner ainsi les paquets pour récupérer notamment les données privées, le procédé comportant les étapes: a) détecter au moins un premier paquet et un second paquet, transmis à des instants respectifs distincts entre la première et la deuxième entité, et comportant des corps de paquet identiques, b) et déclencher une alarme si un nombre de paquets dont le corps est identique et détectés à l'étape a) est supérieur à un seuil prédéterminé.
La présente invention trouve une application avantageuse dans sa mise en oeuvre dans un réseau de télécommunication sans fil, avantageusement configuré selon la norme IEEE-802.11, ce réseau sans fil pouvant être relié à un réseau étendu, notamment dans un contexte de type "hot-spot', pour une détection d'intrusion du type "Man-ln-The-Middle". La seconde entité précitée peut alors être un point d'accès du réseau sans fil.
D'ailleurs, d'autres caractéristiques et avantages de l'invention apparaîtront à 5 l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels: la figure 1, présentée ci-avant, illustre schématiquement un exemple d'une situation de communication normale entre une entité client et un point d'accès d'un réseau de télécommunication, to la figure 2 illustre schématiquement la situation d'une attaque de type "Man-ln-The-Middle" dans le contexte de la figure 1, la figure 3 représente à titre d'exemple la structure d'un paquet ou "trame" de données transmis selon le standard IEEE 802.11, la figure 4A illustre les principales étapes du procédé au sens de l'invention, dans un premier exemple de réalisation, correspondant à un organigramme d'un programme d'ordinateur dans ledit premier exemple de réalisation, la figure 4B illustre partiellement les étapes d'une variante du procédé de la figure 4A, dans un second exemple de réalisation, correspondant à un organigramme d'un programme d'ordinateur dans ledit second exemple de réalisation, et la figure 5 illustre l'opération d'une sonde, par exemple d'un système de contrôle d'un réseau, pour la mise en oeuvre de la présente invention.
Dans les exemples de réalisation donnés dans la description détaillée ciaprès, on considère un réseau sans fil selon la norme IEEE 802.11 en mode infrastructure (entre un client et un point d'accès) et sans chiffrement des données au niveau radio. On décrit, dans ce contexte, une détection, au sens de l'invention, d'attaques de type "Man-In-The-Middle" entre un point d'accès considéré comme légitime et le client. L'invention s'adapte tout particulièrement au contexte des hot-spots.
Pour réaliser cette détection, il est avantageux de prévoir une infrastructure d'écoute de la voie radio. Les clients et les points d'accès légitimes ne sont pas capables de voir les attaques et en particulier ne peuvent repérer des attaques du type MITM. L'infrastructure d'écoute peut être déployée en sus d'une architecture de type IEEE 802.11 existante.
io L'invention utilise, dans ce contexte, le principe suivant.
Dans un réseau local sans fil de type IEEE 802.11, composé d'au moins un point d'accès légitime et d'un client légitime, on suppose qu'un attaquant a réalisé une attaque de type "Man-In-The-Middle" entre le client légitime et le point d'accès légitime, et qu'il retransmet donc les paquets reçus du client vers le point d'accès légitime.
Lorsque le client légitime émet un paquet de données IEEE 802.11, ce paquet est composé d'un en-tête IEEE 802.11 et d'une partie "données". L'en-tête contient des informations relatives au réseau IEEE 802.11 et permettant le bon acheminement du paquet de la source jusqu'à la destination. Lorsque l'attaquant ré-émet ce paquet à destination du point d'accès légitime, un certain nombre de champs de cet en-tête sont modifiés (on peut même dire que l'en-tête est totalement recréé par l'attaquant). En revanche, la partie "données" ne change pas. Cette partie "données" du paquet contient les en-têtes des couches réseaux supérieures (par exemple IP, TCP, UDP, ICMP) ainsi que les données des couches applicatives.
L'invention se base alors sur le principe suivant. II est possible, à partir d'une sonde, d'effectuer une capture puis une analyse des variations de ces champs de "données" des paquets. Lorsque deux champs de "données" ont été identifiés comme identiques dans des paquets distincts à l'intérieur d'un intervalle de temps relativement court, on peut supposer qu'il s'agit d'une attaque de type "Man-ln-The-Middle".
La sonde écoute avantageusement la voie radio sur différents canaux. Ainsi, en termes plus génériques, le réseau comporte une pluralité de canaux de communication, et les étapes du procédé de détection sont menées sur au moins deux de ces canaux et, de préférence, sur chacun des canaux.
On décrit ci-après le contenu d'un paquet ou "trame" de données selon le standard IEEE 802.11, en référence à la figure 3.
to La trame comporte d'abord un champ d'en-tête MAC (ou "MAC Header") qui est défini par la norme précitée IEEE 802.11. Elle comporte également un champ CRC associé à un code détecteur d'erreurs.
Ensuite, le contenu des données privées transportées est inclus dans un corps de paquet fb ou "corps de trame" (selon la dénomination anglosaxonne "frame body'). Ce champ "frame body' comporte aussi les données utiles des communications (en particulier TCP/IP). Le contenu applicatif du "frame body' peut généralement être de la forme: Couche Liaison, par exemple "LLC" (pour "Logical Link Control") ; - Couche Réseau, généralement IP (pour "Internet Protocol") ; - Couche Transport, généralement TCP (pour "Transport Control Protocol") ou UDP (pour "User Datagram Protocol") ; puis un protocole applicatif particulier, encapsulé dans le protocole de transport.
Dans le cas des trames IEEE 802.11 transitant sur la voie radio, on cherche à mener une écoute sur cette voie radio. En particulier, le contenu des trames de données (en fait tout ou partie du "frame body') est comparé à chaque fois avec le contenu des trames de données précédemment reçues de manière à détecter les trames reçues en double quant à leur 'frame body'. Si de telles 2888695 io trames sont repérées sur la voie radio, et ce, de manière régulière, alors une attaque de type "Man-ln-The-Middle" est en cours.
Un principe de la présente invention consiste en ce que les paquets appartenant aux protocoles des couches supérieures à la couche MAC (notamment dans le modèle OSI) sont généralement sujet à d'importantes variations. En effet, ces différents protocoles utilisent pour la plupart des mécanismes d'identification des paquets émis, par exemple un identifiant codé sur 2 octets pour le protocole IP, un numéro de séquence codé sur 2 octets to pour le protocole ICMP ("lnternet Control Message Protocof' en anglais), un numéro de séquence et un numéro d'acquittement codés sur 4 octets pour le protocole TCP. Ainsi, en pratique, les paquets, en particulier les corps de trame ne sont généralement jamais égaux, même s'ils correspondent à une ré-émission de trame (changement d'un champ spécifiant qu'il s'agit d'une ré- émission, ou changement d'un numéro de séquence). Par conséquent, l'invention est particulièrement adaptée pour réaliser une analyse efficace avec un taux de faux positifs et faux négatifs très faible.
En termes plus génériques, on retiendra que les paquets peuvent être transmis selon un protocole de communication qui utilise des données identifiant les paquets émis, ces données étant incluses dans les corps de paquet, ce qui permet de détecter assurément alors une intrusion de type MITM si les corps des paquets sont identiques.
On indique en outre qu'il existe toutefois un mode de la norme 802.11 particulier dénommé "mode répéteur" et visant à utiliser un point d'accès 802.11 pour retransmettre à l'identique les trames reçues. Ce mode est très peu utilisé en pratique. Son utilisation serait détectée comme une attaque par la précédente invention. Toutefois, une simple utilisation de "liste blanche" réglerait facilement le problème.
La présente invention vise aussi une sonde pour la mise en oeuvre du procédé ci-avant et qui sera définie plus loin en termes génériques. Il peut s'agir avantageusement d'une sonde de détection d'intrusion adaptée aux réseaux sans fils et localisée sur un site géographique à surveiller. Cette sonde est capable de lever des alarmes en fonction de certains événements repérés. Une analyse particulière du contenu des trames émises ou même des séquences de trames constitue une signature qu'un outil de détection d'intrusion est capable de repérer. Cette signature caractérise un événement, tel qu'une attaque ou simplement un comportement normal.
io La sonde a préférentiellement des capacités spécifiques qui lui permettent "d'écoute?' sur plusieurs canaux en même temps en assurant, de préférence, qu'il n'y pas ou peu de pertes de trames de données durant l'écoute.
On décrit ci-après deux réalisations possibles dans la mise en oeuvre de l'invention.
Un premier mode de réalisation comporte les étapes illustrées sur la figure 4A et susceptibles de représenter un exemple d'organigramme d'un programme d'ordinateur pour la mise en oeuvre de l'invention.
En écoutant un réseau typiquement selon la norme IEEE 802.11 à l'aide d'une sonde du type précité, on récupère des paquets de données successifs FRA-i (étape 40). On analyse alors un paquet reçu FRA-i en récupérant en particulier son corps de trame fb-i ou "frame body" (étape 41) qui inclut des données privées qu'une entité cliente souhaitait par exemple transmettre vers un point d'accès. L'étape 42 consiste à calculer une signature sgn-i par une fonction de hachage H de tout ou partie du corps de trame fb-i. Le résultat peut par exemple se présenter par un nombre sur 128 bits (en utilisant la fonction MD5 pour "Message Digest 5 ou 160 bits (en utilisant la fonction SHA1 pour "Secure Hash Algorithm 1 ") ou sur n bits (avec une autre fonction de hachage). Cette valeur, notée sgn-i sur la figure 4A est appelée RASH FRAMEBODY ci-après. La partie du corps de trame hachée pour le calcul de la signature peut être un élément important pour des raisons de performances. En effet, l'invention peut être optimisée de manière à ne faire un calcul du haché que sur les 100 premiers octets par exemple. II peut alors s'agir d'un paramétrage de la sonde implémentant l'invention. Ce point peut aussi avoir son importance sur certaines catégories d'attaques qui peuvent entraîner des modifications de certains octets fixes du corps de trame fb- i. Il est alors possible de définir les octets à ne pas vérifier de manière à pouvoir détecter certaines classes d'attaques. Ce point peut aussi être un paramétrage to de l'outil implémentant l'invention.
Ainsi, en termes plus génériques, pour chaque paquet reçu: - on calcule une signature du corps du paquet en appliquant une fonction de hachage à tout ou partie des données du corps de paquet, - on stocke en mémoire ladite signature, et - on compare ladite signature à des signatures de corps de paquet précédemment stockées dans ladite mémoire.
Préférentiellement, la fonction de hachage est appliquée à une partie des données du corps de paquet, cette partie des données étant choisie en fonction de la configuration du réseau et/ou en fonction de la pertinence de ces données pour la détection d'intrusion.
A l'étape 43, les informations d'adresses (dans l'en-tête du paquet principalement), par exemple au moins du type @MAC_source (adresse MAC de départ), @MAC_destination (adresse MAC de destination), et avantageusement du type @MAC_BSSID, ainsi, éventuellement, qu'un drapeau TO_DS/FROM_DS (nommé STATE_DS) sont archivées en même temps que la signature du frame body. On indique que le drapeau précité TO_DS est un champ indiquant que le paquet en provenance du client est à destination du réseau derrière le point d'accès (typiquement un réseau filaire). Le drapeau FROM_DS est un champ indiquant que la trame en provenance du point d'accès provient d'un équipement situé derrière le point d'accès (dans le réseau filaire). Ces identifiants sont couramment utilisés en contexte Wi-Fi, comme on le verra en référence à un troisième mode de réalisation décrit plus loin.
On stocke ces cinq données (@MAC_source, @MAC_destination, @MAC_BSSID, STATE_DS, HASH_ FRAMEBODY) avantageusement dans une mémoire de type FIFO (pour "First In First Out"), en tant que quintuplé préférentiellement pendant une durée prédéfinie, les plus anciens quintuplés étant automatiquement effacés et remplacés lors de l'arrivée à leur fin de durée de vie. Cette durée peut être fixée en pratique à une valeur de l'ordre de la dizaine de secondes. En effet, il n'est pas nécessaire de garder un historique important du frame body des trames hachées dans la mémoire précitée car l'attaque doit être réalisée en direct par l'attaquant et ce dernier ne peut se permettre de ralentir fortement le relais des trames.
Au test 44, on compare le nouveau HASH_ FRAMEBODY sgn-i avec ceux présents dans la mémoire en faisant préférentiellement cette comparaison de manière séquentielle. Si il existe dans la mémoire un HASH_ FRAMEBODY sgn-j égal au HASH_ FRAMEBODY courant sgn-i (les indices i et j étant différents), ce qui correspond à la flèche o en sortie du test 44, alors il est levé une alarme de type "Man-In-The-Middle" à l'étape 45. Sinon (flèche n en sortie du test 44), le procédé se poursuit en analysant une trame FRA-i suivante (étape 46) et le procédé est réitéré pour cette nouvelle trame à l'étape 40.
L'organigramme ci-avant présente le procédé le plus optimisé en terme de rapidité de traitement des informations IEEE 802.11 reçues par la sonde.
Il est possible de limiter les faux positifs avec la réalisation plus sophistiquée qui est présentée en figure 4B. Dans cette réalisation, à l'issue du test 44 de la figure 4A, on compte le nombre K de fois où le nouveau HASH_ FRAMEBODY est égal à ceux présents dans la mémoire en faisant la comparaison 44 de manière séquentielle (étape 47). Dès que ce compteur dépasse un seuil prédéfini KTH (flèche o en sortie du test 48), alors il peut être levé une alarme de type "Man-ln-The-Middle" (étape 45 de la figure 4A). La valeur du seuil KTH peut être un paramètre de la sonde au sens de l'invention. En termes plus génériques, on retiendra que le déclenchement de l'étape b) du procédé général défini ci-avant est conditionné par la détection d'un nombre de paquets dont le corps est identique à l'étape a), ce nombre (correspondant en pratique au seuil KTH+ 1) étant préférentiellement choisi selon une configuration donnée du réseau. Dans le cas particulier de la figure 4A, ce seuil KTH a simplement une valeur de 1.
L'organigramme de la figure 4B présente le procédé le plus optimisé en terme de réduction de faux positifs dans le traitement des informations IEEE 802.11 reçues par la sonde. L'outil peut implémenter les deux méthodes et sélectionner de manière dynamique la plus adaptée en fonction du contexte. Il est bien entendu possible de paramétrer la fenêtre de temps d'écoute pour optimiser le processus de détection. Ainsi, en termes plus génériques, le déclenchement de l'alarme à l'étape b) est effectif si des premier et second paquets de même corps sont détectés à l'étape a) dans un intervalle de temps inférieur à une durée prédéterminée, cette durée étant préférentiellement choisie en fonction d'une configuration du réseau.
En effet, selon les environnements, il peut être possible que des reémissions normales entraînent des faux positifs (par exemple en mode répétitif de la norme 802.11). Cependant, ce comportement est rare en principe, et ne peut en soi impliquer des problématiques importantes car une attaque de type "Man-In-The-Middle" entraînerait un nombre important d'alertes contrairement à des re-émissions sporadiques dans la fenêtre de temps qui peut être définie comme étant courte car il est rappelé que l'attaquant a la contrainte de devoir re-émettre le paquet rapidement.
L'alarme levée par la sonde peut indiquer les cinq données précitées @MAC_source, @MAC_destination, @MAC_BSSID, TO_DS/FROM_DS et HASH_ FRAMEBODY associées à la trame actuelle, et à celle d'une trame précédemment stockée en mémoire. Il est alors possible de donner des s informations supplémentaires telles que les adresses MAC source, destination et BSSID. Même si, en principe, elles ne sont pas nécessaires pour réaliser la détection d'attaque, elles peuvent en revanche aider l'opérateur à tracer l'événement de manière plus précise.
io On décrit ci-après un troisième mode de réalisation dans un contexte spécifique correspondant à des communications entre clients Wi-Fi.
Dans plusieurs hot-spots et réseaux d'accès sans fil d'entreprise, une fonctionnalité est activée sur les points d'accès légitimes pour interdire les connexions inter-clients d'un même point d'accès. Il s'agit d'un fonctionnement dit en mode relais (ou "bridge' du point d'accès. Un exemple concret est la fonction PSPF (pour "Publicly Secure Packet Forwarding') proposée par les points d'accès CISCO (marque déposée). Lorsque cette fonctionnalité est activée, l'invention s'avère particulièrement efficace. En revanche, en l'absence d'une telle fonctionnalité, un paquet émis par
un client à destination d'un autre client du même point d'accès est retransmis par le point d'accès légitime sans modification du "frame body". Ce phénomène serait détecté comme une possible attaque de MITM au sens de l'invention. II est donc possible d'ajouter une étape de vérification supplémentaire à effectuer sur les paquets identifiés dans ces conditions. Cette étape de vérification supplémentaire peut être par exemple activable par l'administrateur du réseau sans fil selon la configuration choisie pour son réseau.
Elle se décrit comme suit. Lorsqu'une trame est émise par un client A à destination d'un autre client B du même point d'accès, le drapeau "To DS" décrit ci-avant de cette trame est mis à 1, tandis que le drapeau "From DS" est mis à zéro. Les champs @MAC_destination et @MAC_source sont remplis respectivement avec l'adresse MAC de B et l'adresse MAC de A, et le champ BSSID présente l'adresse MAC du point d'accès.
Puis, lorsque ce paquet est retransmis par le point d'accès à destination du client B, le champ "To DS" est mis à zéro tandis que le champ "From DS" est mis à 1. Les champs @MAC_destination et @MAC_source sont remplis respectivement avec l'adresse MAC de B et l'adresse MAC de A, et le champ BSSID présente l'adresse MAC du point d'accès.
Ainsi, il suffit de vérifier que les deux paquets identifiés comme possédant un même 'frame body' ont les mêmes @MAC_destination, @MAC_source, et BSSID, mais en particulier des drapeaux "To DS" et "From DS" de valeurs opposées, ce qui permet de lever une alarme sans pratiquement aucun risque de faux positifs.
En termes plus génériques, on retiendra que lorsque l'intrusion comporte en outre une étape de modification de données (telles que les valeurs de 15 drapeaux TO DS/FROM DS) dans le champ d'en-tête: à l'étape a), on compare en outre les champs d'en-tête des premier et second paquets, et à l'étape b), on déclenche l'alarme si les corps de paquet sont identiques et si les champs d'en-tête sont différents.
Ainsi, l'invention s'adapte avantageusement à un contexte non dépendant d'une contrainte de type "pas de communications entre clients via un point d'accès". II suffit à cet effet de rajouter un test sur les valeurs de drapeaux To DS/ From DS en sortie du test 44 sur le HASH_ FRAMEBODY représenté sur la figure 4A.
Une fois déployée, une sonde mettant en oeuvre le procédé, se retrouve dans la situation représentée sur la figure 5. La sonde S écoute les deux voies 1 et 2 reliant l'attaquant AU au client CL, d'une part, et l'attaquant AU au point d'accès AP d'autre part. Elle stocke dans la mémoire MEM et lit les paquets transitant sur ces deux chemins et détecte en particulier ceux qui ont le même corps de trame en déclenchant, le cas échéant, une alarme.
La présente invention vise aussi une telle sonde S, agencée pour détecter une intrusion dans une communication de données privées entre une première entité et une seconde entité (telle qu'un point d'accès), ces entités étant communicantes via un réseau de télécommunication, la sonde comportant: io de préférence, des moyens de lecture au moins des corps des paquets transmis entre la première entité et la seconde entité, par exemple dans la mémoire MEM, des moyens de comparaison des corps de paquet pour détecter au moins un premier paquet et un second paquet, transmis à des instants respectifs distincts entre la première entité et la seconde entité, et comportant des corps de paquet identiques, et des moyens SA pour déclencher une alarme si le nombre de paquets détectés dont le corps est identique est supérieur à un seuil KTH.
La présente invention vise aussi un programme d'ordinateur pouvant être téléchargé via un réseau de télécommunication et/ou destiné à être stocké dans une mémoire d'une sonde du type décrit ci-avant et/ou stocké sur un support mémoire destiné à coopérer avec un lecteur de cette sonde. En particulier, le programme comporte des instructions pour la mise en oeuvre du procédé du type décrit ci-avant. La présente invention vise aussi un support de stockage de données comportant des instructions de code de programme informatique pour l'exécution des étapes du procédé au sens de l'invention.
La présente invention vise aussi un système pour la mise en oeuvre d'un procédé de détection d'une intrusion dans une communication de données privées, typiquement entre une pluralité d'entités communicantes via un réseau de télécommunication et une pluralité de points d'accès du réseau. A cet effet, il comporte une pluralité de sondes formant une architecture déployée sur le réseau et de contrôle du réseau, chaque sonde comportant les moyens énoncés ci-avant.
Selon l'un des avantages que procure l'invention, la détection au sens de 10 l'invention est entièrement passive. Elle ne nécessite aucune interaction avec les équipements constituant le réseau sans fil (point d'accès, clients).
Selon un autre avantage que procure l'invention, la détection en cours n'est pas décelable par un attaquant.
Selon un autre avantage encore que procure l'invention, la détection est indépendante du fait que les adresses MAC soient usurpées ou non puisque l'on s'attache au contenu du corps de trame. Elle est aussi indépendante du fait que les noms de réseaux ESSID soient usurpés ou non.
Un autre avantage majeur est qu'elle est indépendante du fait que les canaux radio soient les mêmes ou non.
La détection est facile à implémenter en pratique. Elle tolère en particulier que l'équipement en écoute de la voie radio perde des paquets. En effet, cet effet n'a aucun impact en terme de faux positifs. Comme une attaque de type MitM nécessite de nombreux paquets successifs, elle sera nécessairement détectée.
Le procédé au sens de l'invention peut être implémenté très simplement dans un outil de détection d'intrusion dans les réseaux sans fil IEEE 802. 11, des équipements capables d'écouter la voie radio IEEE 802.11 étant courants.

Claims (16)

Revendications
1. Procédé de détection d'une intrusion dans une communication de données privées entre une première entité et une seconde entité, communicantes via 5 un réseau de télécommunication, la communication étant effectuée par transmission de paquets successifs, chaque paquet comportant au moins: un champ d'en-tête incluant au moins une adresse de source du paquet et/ou une adresse de destination du paquet pour un routage 10 approprié des paquets, et un corps de paquet incluant des données privées, * ladite intrusion consistant au moins à : - s'interconnecter entre la première et la deuxième entité, usurper l'adresse de la première entité et/ou l'adresse de la 15 deuxième entité en tant qu'adresse de source et/ou de destination, et détourner ainsi les paquets pour récupérer notamment les données privées, caractérisé en ce qu'il comporte les étapes: a) détecter au moins un premier paquet et un second paquet, transmis à des 20 instants respectifs distincts entre la première et la deuxième entité, et comportant des corps de paquet identiques, b) et déclencher une alarme si un nombre de paquets dont le corps est identique et détectés à l'étape a) est supérieur à un seuil prédéterminé (KTH).
2. Procédé selon la revendication 1, caractérisé en ce que le réseau de télécommunication est un réseau sans fil. to
3. Procédé selon la revendication 2, caractérisé en ce que le réseau sans fil est configuré selon la norme IEEE-802.11.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit réseau est un réseau sans fil relié à un réseau étendu-
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que la seconde entité est un point d'accès du réseau.
6. Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit réseau comporte une pluralité de canaux de communication, et en ce que les étapes a) et b) sont menées sur au moins deux de ces canaux.
7. Procédé selon l'une des revendications précédentes, caractérisé en ce que le déclenchement de l'étape b) est effectif si lesdits premier et second paquets sont détectés à l'étape a) dans un intervalle de temps inférieur à une durée prédéterminée, ladite durée étant préférentiellement choisie en fonction d'une configuration du réseau.
8. Procédé selon l'une des revendications précédentes, caractérisé en ce que, au cours de ladite étape a) : on calcule une signature du corps d'au moins un second paquet en appliquant une fonction de hachage à tout ou partie des données du corps 25 de paquet, on stocke en mémoire ladite signature, et on compare ladite signature à la signature de corps d'au moins un premier paquet précédemment stockée dans ladite mémoire.
9. Procédé selon la revendication 8, caractérisé en ce que ladite fonction de hachage est appliquée à une partie des données du corps de paquet, ladite partie des données étant choisie en fonction de la configuration du réseau et/ou en fonction de la pertinence de ces données pour la détection d'intrusion.
10. Procédé selon l'une des revendications précédentes, dans lequel ladite intrusion comporte en outre une étape de modification de données (TO DS/FROM DS) dans le champ d'en-tête, caractérisé en ce que: à l'étape a), on compare en outre les champs d'en-tête des premier et second paquets, et à l'étape b), on déclenche l'alarme si les corps de paquet sont identiques et si les champs d'en-tête sont différents.
11. Procédé selon l'une des revendications précédentes, caractérisé en ce que les paquets sont transmis selon un protocole de communication qui utilise des données identifiant les paquets émis, lesdites données étant incluses dans les corps de paquet.
12. Procédé selon l'une des revendications précédentes, caractérisé en ce que le seuil prédéterminé (KTH) est choisi selon une configuration donnée du réseau.
13. Sonde, pour la mise en oeuvre du procédé selon l'une des revendications 1 à 12, de détection d'une intrusion dans une communication de données privées entre une première entité et une seconde entité, communicantes via un réseau de télécommunication, * la communication étant effectuée par transmission de paquets successifs, chaque paquet comportant au moins: un champ d'en-tête incluant au moins une adresse de source du paquet et/ou une adresse de destination du paquet pour un routage approprié des paquets, et un corps de paquet incluant des données privées, * ladite intrusion consistant au moins à : to - s'interconnecter entre la première entité et la seconde entité, usurper l'adresse de la première entité et/ou l'adresse de la seconde entité en tant qu'adresse de source et/ou de destination, et détourner ainsi les paquets pour récupérer notamment les données privées, caractérisée en ce que la sonde comporte: des moyens de comparaison des corps de paquet pour détecter au moins un premier paquet et un second paquet, transmis à des instants respectifs distincts entre la première et la seconde entité, et comportant des corps de paquet identiques, et des moyens pour déclencher une alarme si un nombre de paquets dont le corps est identique et détectés par les moyens de comparaison est supérieur à un seuil prédéterminé (KTH).
14. Système, pour la mise en oeuvre du procédé selon l'une des revendications 1 à 12, pour détecter une intrusion dans une communication de données privées entre une pluralité d'entités communicantes via un réseau de télécommunication, la communication étant effectuée par transmission de paquets successifs, chaque paquet comportant au moins: un champ d'en-tête incluant au moins une adresse de source du paquet et/ou une adresse de destination du paquet pour un routage 5 approprié des paquets, et un corps de paquet incluant des données privées, ladite intrusion consistant au moins à : s'interconnecter entre une première et une seconde entité, usurper l'adresse de la première entité et/ou l'adresse de la seconde to entité en tant qu'adresse de source et/ou de destination, et - détourner ainsi les paquets pour récupérer notamment les données privées, caractérisé en ce qu'elle comporte une pluralité de sondes formant une architecture de contrôle du réseau, chaque sonde comportant: des moyens de comparaison des corps de paquet, propres à détecter au moins un premier paquet et un second paquet, transmis à des instants respectifs distincts entre les première et seconde entités, et comportant des corps de paquet identiques, et des moyens de déclenchement d'une alarme si un nombre de paquets 20 dont le corps est identique et détectés par les moyens de comparaison est supérieur à un seuil prédéterminé (KTH).
15. Programme d'ordinateur, pour la mise en oeuvre du procédé selon l'une des revendications 1 à 12, téléchargeable via un réseau de télécommunication 25 et/ou destiné à être stocké dans une mémoire d'une sonde et/ou stocké sur un support mémoire destiné à coopérer avec un lecteur de ladite sonde, ladite sonde étant agencée pour détecter une intrusion dans une communication de données privées entre une première et une seconde entité, communicantes via un réseau de télécommunication, * la communication étant effectuée par transmission de paquets successifs, 5 chaque paquet comportant au moins: un champ d'en-tête incluant au moins une adresse de source du paquet et/ou une adresse de destination du paquet pour un routage approprié des paquets, et un corps de paquet incluant des données privées, to * ladite intrusion consistant au moins à : s'interconnecter entre la première et la seconde entité, usurper l'adresse de la première entité et/ou l'adresse de la seconde entité en tant qu'adresse de source et/ou de destination, et détourner ainsi les paquets pour récupérer notamment les données 15 privées, caractérisé en ce que le programme comporte des instructions pour, lorsqu'il est exécuté à partir d'une mémoire de la sonde: a) détecter au moins un premier paquet et un second paquet, transmis à des instants respectifs distincts entre la première et la seconde entité, et 20 comportant des corps de paquet identiques, b) et déclencher une alarme si un nombre de paquets détectés dont le corps est identique est supérieur à un seuil prédéterminé (KTH).
16. Support de stockage de données comportant des instructions de code de 25 programme informatique pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 12.
FR0507532A 2005-07-13 2005-07-13 Detection d'une intrusion par detournement de paquets de donnees dans un reseau de telecommunication Withdrawn FR2888695A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR0507532A FR2888695A1 (fr) 2005-07-13 2005-07-13 Detection d'une intrusion par detournement de paquets de donnees dans un reseau de telecommunication
PCT/FR2006/001508 WO2007010101A2 (fr) 2005-07-13 2006-06-28 Detection d’une intrusion par detournement de paquets de donnees dans un reseau de telecommunication
US11/988,558 US20090138971A1 (en) 2005-07-13 2006-06-28 Detecting Intrusion by Rerouting of Data Packets in a Telecommunications Network
EP06778701A EP1902563A2 (fr) 2005-07-13 2006-06-28 Detection d une intrusion par detournement de paquets de donnees dans un reseau de telecommunication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0507532A FR2888695A1 (fr) 2005-07-13 2005-07-13 Detection d'une intrusion par detournement de paquets de donnees dans un reseau de telecommunication

Publications (1)

Publication Number Publication Date
FR2888695A1 true FR2888695A1 (fr) 2007-01-19

Family

ID=36297263

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0507532A Withdrawn FR2888695A1 (fr) 2005-07-13 2005-07-13 Detection d'une intrusion par detournement de paquets de donnees dans un reseau de telecommunication

Country Status (4)

Country Link
US (1) US20090138971A1 (fr)
EP (1) EP1902563A2 (fr)
FR (1) FR2888695A1 (fr)
WO (1) WO2007010101A2 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120030759A1 (en) * 2010-07-28 2012-02-02 Alcatel-Lucent Usa Inc. Security protocol for detection of fraudulent activity executed via malware-infected computer system
US9313655B2 (en) * 2011-10-31 2016-04-12 Nokia Corporation Location privacy in communication networks
US10620241B2 (en) 2012-02-17 2020-04-14 Perspecta Labs Inc. Method and system for packet acquisition, analysis and intrusion detection in field area networks
EP2815360A4 (fr) 2012-02-17 2015-12-02 Vencore Labs Inc Adaptateur de compteur électrique multi-fonction et son procédé d'utilisation
US10097417B2 (en) 2013-01-24 2018-10-09 Vencore Labs, Inc. Method and system for visualizing and analyzing a field area network
CN106790299B (zh) * 2017-03-20 2020-06-23 京信通信系统(中国)有限公司 一种在无线接入点ap上应用的无线攻击防御方法和装置
US10853457B2 (en) * 2018-02-06 2020-12-01 Didi Research America, Llc System and method for program security protection

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003065186A1 (fr) * 2002-01-31 2003-08-07 3Com Corporation Systeme de surveillance de reseau

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020166063A1 (en) * 2001-03-01 2002-11-07 Cyber Operations, Llc System and method for anti-network terrorism
US7134143B2 (en) * 2003-02-04 2006-11-07 Stellenberg Gerald S Method and apparatus for data packet pattern matching
US7454499B2 (en) * 2002-11-07 2008-11-18 Tippingpoint Technologies, Inc. Active network defense system and method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003065186A1 (fr) * 2002-01-31 2003-08-07 3Com Corporation Systeme de surveillance de reseau

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HAIDONG XIA ET AL: "Detecting and blocking unauthorized access in Wi-Fi networks", LECTURE NOTES IN COMPUTER SCIENCE, SPRINGER VERLAG, NEW YORK, NY, US, May 2004 (2004-05-01), pages 795 - 806, XP002306583, ISSN: 0302-9743 *
WRIGHT J: "Detecting wireless LAN MAC address spoofing", ACADEMIC PAPER, 21 January 2003 (2003-01-21), XP002330231 *

Also Published As

Publication number Publication date
WO2007010101A3 (fr) 2007-03-29
US20090138971A1 (en) 2009-05-28
WO2007010101A2 (fr) 2007-01-25
EP1902563A2 (fr) 2008-03-26

Similar Documents

Publication Publication Date Title
US8918875B2 (en) System and method for ARP anti-spoofing security
CN113132342B (zh) 方法、网络装置、隧道入口点装置及存储介质
US20150312307A1 (en) Method for streaming packet captures from network access devices to a cloud server over http
EP1733539B1 (fr) Dispositif et procédé de détection et de prévention d'intrusions dans un réseau informatique
EP2721857B1 (fr) Procédé de traitement d'un paquet de données a l'émission, procédé de traitement d'un paquet de données à la réception, dispositifs et équipements de noeuds associés
WO2006111635A1 (fr) Procede et systeme de transmission d’un flux multicast en reseau d’echange de donnees
EP3556130B1 (fr) Procédé de surveillance d'un réseau de télécommunications mis en oeuvre par un point d'accès
EP1842389B1 (fr) Procédé, dispositif et programme de détection d'usurpation d'adresse dans un réseau sans fil
FR2888695A1 (fr) Detection d'une intrusion par detournement de paquets de donnees dans un reseau de telecommunication
EP1931105A1 (fr) Procédé et système de gestion de sessions multimédia, permettant de contrôler l'établissement de canaux de communication
EP1758338B1 (fr) Procédé et équipement de communication sécurisé pour le traitement des paquets de données selon le mécanisme SEND
EP1849261A1 (fr) Procede, dispositif et programme de detection d'usurpation d'adresse dans un reseau sans fil
EP1905194B1 (fr) Detection de double attachement entre un reseau filaire et au moins un reseau sans-fil
FR2717334A1 (fr) Vérification d'intégrité de données échangées entre deux stations de réseau de télécommunications.
EP3087719A1 (fr) Procédé de ralentissement d'une communication dans un réseau
US9712323B2 (en) Detection of unauthorized entities in communication systems
EP3747238B1 (fr) Agrégation d'une pluralité de connexions radio dans un réseau sans fil
Jiang et al. Real-Time Identification of Users under the New Structure of Skype
CN116032807A (zh) 一种探测方法、装置、电子设备及存储介质
WO2022238644A1 (fr) Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe
KR101252811B1 (ko) 아이알씨 계열 웜 차단 장치 및 방법
Casey et al. Network investigations
CN114363083A (zh) 智能网关的安全防范方法、装置、设备
FR2888432A1 (fr) Procedes de protection des trames de gestion echangees entre deux equipements sans fil, de reception et d'emission de telles trames, programmes d'ordinateur et supports de donnees contenant ces programmes d'ordinateur
FR2866496A1 (fr) Procede de controle d'acces a un reseau d'un terminal source utilisant un tunnel en mode bloquant

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20070330