Note: Descriptions are shown in the official language in which they were submitted.
WO 2023/036846 PCT/EP2022/074915
1
Description
Titre de l'invention : PROCÉDÉ ET SYSTEME D'ANALYSE DE FLUX DE
DONNÉES
knRRIE RE-P LAN
[0001] Les développements technologiques en matière de mise en
réseau ont
entrainé une augmentation des vitesses de mise en réseau au-delà des capacités
de
supervision du réseau et de l'équipement de gestion du trafic utilisé.
L'équipement
connu de supervision du réseau et de gestion du trafic comprend généralement
des
sondes réseau, conçues pour surveiller un flux de données reçu via un réseau
de
communication.
[0002] En pratique, les sondes réseau sont conçues pour traiter un
flux fixe de
données et surveiller des mesures spécifiques de ces données. En conséquence,
chaque fois que le flux de données augmente et/ou qu'une nouvelle mesure de
flux
de données est identifiée pour la surveillance, ces sondes réseau doivent être
repensées pour modifier leurs capacités de traitement afin de gérer le flux
modifié de
données.
[0003] Pour atténuer les inefficacités associées aux sondes réseau
matérielles, on
connait des solutions logicielles de supervision réseau et de gestion du
trafic dans
lesquelles on exécute une inspection approfondie des paquets (DPI) sur
seulement
quelques paquets, cette solution technique est appelée Packet Sampling
(c'est-à-
dire le fait de prendre des paquets complètement au hasard dans un flux réseau
pour
en réaliser un échantillonnage). Une telle solution connue permet d'éviter une
surcharge de traitement élevée et des latences réseau plus élevées. Toutefois,
une
telle solution antérieure n'est pas totalement satisfaisante, car l'analyse
est exécutée
limitativement sur des chaines de protocoles ou session de communication
comprenant cinq champs fixes (champ source, champ destinataire, port source,
port
destinataire, protocole de communication). Il en résulte qu'une telle analyse
selon l'art
antérieur ne permet pas de traiter des chaines ou session de protocoles dont
le socle
d'identification se base sur une valeur de 5-tuple (IP source, IP Destination,
Port
Source, Port destination et application), ni sur des protocoles de tunneling à
détection
retardée, ni dans les couches 2 à 7 du modèle d'interconnexion des systèmes
ouverts
(0S1).
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
2
[0004] On connait aussi une autre solution telle que celle
présentée par le
document EP 1 788 490 A (APPTITUDE INC), enseignant une architecture reposant
sur l'implémentation d'une partie hardware spécifique FPGA et AS ICs, et d'une
partie
logicielle impliquant un découpage de paquet (packet slicing en anglais)
[0005] Selon la solution décrite dans EP 1 788 490 A, le payload
ou contenu
attaché d'une couche protocolaire est au moins en partie gardé en mémoire
d'abord dans le FPGA, puis délégué au processeur et à la RAM. L'architecture
matérielle ne permet pas de retenir l'état d'une session suffisamment
longtemps.
Le système est fortement ralenti lors d'une analyse d'un flux de données de
débit
important et empêche une identification a posteriori des protocoles. De plus,
le
FPGA ayant une mémoire limitée, celui-ci doit vider son cache périodiquement,
ce
qui entraine la perte d'informations et de paquets de données, et peut mener à
des
statistiques d'analyse inexactes. De plus, l'utilisation du découpage de
paquet
(packet slicing), le réassemblage pour analyse implique donc un risque de
perte
d'informations. En outre, la gestion de la table d'empreintes numériques
calculées
sur la base de cinq tuples (adresse IP source/un numéro de port, une adresse
IP/un numéro de port de destination et le protocole utilisé) implique
l'identification
d'une session sur la base d'un calcul d'empreinte numérique ne prenant en
compte
qu'une seule couche d'identification alors que dans le cas de sessions
construites
sur plusieurs protocoles tunnelés ou multiplexés, l'encapsulation crée
plusieurs
sessions cachées qu'il devient impossible d'identifier avec un 5-tuple. De
plus, le
chiffrement des communications ajoute de la variation qui va également fausser
les comparaisons avec une base d'empreintes numériques de malware. Enfin, la
solution selon EP 1 788 490 prend en compte le payload dans le calcul du hash
ce qui entrainera trop de variations des valeurs d'analyse pour rester
pertinentes
dans le cadre d'une comparaison, et l'approche de calcul de 5-tuple.
[0006] De plus, à très haut débit, l'utilisation pour le calcul de
l'empreinte
numérique ou hash selon une méthode de 5-tuple combinant des techniques
matérielles (FPGA ou ASIC) et Racket Slicing (découpage du paquet sur les
couches
inférieures ou supérieures) pour accélérer le traitement des paquets, provoque
nativement une perte de visibilité et des erreurs en cascades.
[0007] De plus, l'approche 5-tuple pour deux sessions ayant le
même 5-tuple, mais
dont la couche inférieure est différente, (c'est-à-dire un réseau virtuel
différent) sera
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
3
interprété comme si les deux sessions identiques alors que ce n'est pas le
cas, et
entraine alors une perte d'information pouvant lourdement affecter les
résultats
d'analyse de données.
[0008] On entend par la suite par le terme hash , une empreinte
numérique
calculée.
[0009] La présente invention remédie aux inconvénients et améliore
la situation.
[0010] La présente invention porte sur un procédé d'analyse d'un
flux de données
de paquets de données reçus via un réseau de communication, le flux de données
comprenant des lots de paquets définis chacun par une chaine de protocoles de
communication rattachée à au moins une session.
[0011] Selon une définition générale de l'invention, le procédé
comprend une
analyse de protocoles selon les étapes suivantes :
-analyser le premier protocole Pi d'une chaine de protocoles de communication
selon une étape de classification par détection explicite configurée pour
vérifier si
le premier protocole Pi annonce le protocole de communication suivant Pi+1 de
la chaine de protocoles :
-en cas d'annonce, le protocole suivant Pi+1 ainsi annoncé est identifié ;
-tandis qu'en cas de non-annonce, analyser le protocole suivant Pi+1 selon une
étape de classification par détection de session ;
-analyser selon une étape de classification par détection de session,
configurée
pour vérifier si le protocole Pi+1 est attaché à une chaine de protocoles
connue
selon un arbre de décision dynamique par interrogation d'une base de données
dynamique de session comprenant des chaines de protocoles identifiées:
-en cas d'attache, le protocole Pi+1 est identifié, et le protocole Pi+2
est analysé par répétition des étapes de classification par détection
explicite,
de classification par détection de session;
- tandis qu'en cas de non-attache, analyser le protocole Pi+1 selon une
étape de classification par inspection profonde de paquet ;
-analyser le protocole Pi+1 selon une étape de classification par inspection
profonde de paquet, configurée pour identifier le protocole de communication
du paquet Pi+1 selon un arbre de décision dynamique corrélé à une base de
données de connaissances comprenant des paramètres d'analyse de
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
4
protocoles et une base de marqueurs spécifiques à chaque protocole connu;
- en cas de défaut d'identification du protocole Pi+1, émettre une liste de
candidats de protocoles potentiels à prendre en compte selon au moins deux
branches de détection, chaque détection étant rattachée à une sous-session
déterminée pour analyser le ou les protocoles suivants Pi+n avec
par
répétition des étapes de classification par détection explicite, de
classification
par détection de session, et de classification par inspection profonde de
paquet
jusqu'à identifier au moins un protocole dont l'identité est certaine ;
-en cas d'identification d'un protocole Pi+n dont l'identité est certaine sur
une
branche de détection, valider rétroactivement la branche de détection, et
écarter les branches de détection restantes non validées ;
-en cas d'absence d'identification d'un protocole Pi+n dont l'identité est
certaine
sur une branche de détection, classifier le protocole PH-1 comme inconnu
rétroactivement ; et
-associer une étiquette aux paquets de données en fonction de chaque session
pour lesquels les protocoles ont été identifiés.
[0012]
Il est à noter que l'analyse des caractéristiques binaires de chaque
paquet
d'une session de communication (ou chaine de protocoles) est mise en oeuvre
selon
l'invention jusqu'à être en mesure (ou non) de déterminer (identifier) le
protocole utilisé
dans cette session.
[0013]
Une telle approche selon l'invention a l'avantage de permettre d'avoir
un
taux de labellisation plus élevé que les approches antérieures, dans la mesure
où elle
peut être exécutée depuis la couche 2 jusqu'à la couche 7 du modèle OSI, en
une
seule passe d'analyse des paquets. Elle permet aussi d'identifier des chaines
de
protocoles dans le cas de protocoles de tunneling, ou de protocoles à
détection
retardée ainsi qu'une détection continue, et ce, même si un protocole n'est
pas
identifié immédiatement, la détection des protocoles suivants continue.
[0014]
De plus, grâce à l'usage de la base de données dynamique de sessions
stockant les sessions de communication précédemment identifiées, la présente
invention est plus rapide que les solutions antérieures basées sur une
inspection de
tous les paquets.
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
[0015] Selon un autre aspect de l'invention, le procédé comprend
en outre après
chaque étape de classification, une étape de calcul d'une empreinte numérique
de
session à partir d'une fonction de hachage choisie, ladite empreinte numérique
de
session étant calculée sur la base du premier protocole identifié, et sur
l'empreinte
numérique précédemment calculée de la chaîne de protocoles déjà identifiée
sans
prise en compte du contenu attaché, chaque empreinte numérique étant calculée
sur
la base de paramètres (ou tuple) choisis et spécifiques à chaque type de
protocole,
chaque type de protocole disposant d'un nombre propre de marqueurs définit ;
et une étape d'enregistrement de l'empreinte numérique de session calculée
après
chaque étape d'identification de protocole suivant l'étape de classification
de chaque
protocole par inspection profonde de paquet ou après l'étape de validation
rétroactive,
dans une table de hash intégrée dans la base de données dynamique de session,
chaque empreinte numérique étant liée à au moins une session choisie, lesdites
empreintes numériques calculées après chaque étape de classification de chaque
protocole par inspection profonde de paquet étant apte à être mis à jour
rétroactivement en cas d'identification retardée d'un protocole selon l'étape
de
vérification.
[0016] Avantageusement, le Demandeur a observé que la gestion
dynamique des
empreintes numériques selon l'invention permet à l'empreinte numérique d'un
protocole non validé d'être mise à jour a posteriori, celui-ci évoluant à
mesure que le
paquet est lu.
[0017] Cette algorithmie unique permet de pouvoir détecter tous
les types de
protocoles avec une seule sonde, soit non limitativement les enchainements
protocolaires simples, complexes, tunnelés et multiplexés.
[0018] La gestion des empreintes numériques du procédé selon
l'invention
présente également l'avantage de s'affranchir d'une étape de découpage de la
chaine
protocolaire (slicing en anglais) et ainsi éliminer le risque de perte
d'information, et
permet en outre d'obtenir des identifiants réellement uniques sur la chaine de
protocole, peu importe la longueur de ladite chaine de protocoles qui compose
le ou
les paquets.
[0019] En pratique, en cas de détection de protocoles tunnelés,
multiplexés,
multicanaux détectés de manière certaine, le procédé selon l'invention
comprend les
sous-étapes suivantes :
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
6
-Générer au moins une branche de détection par protocole vérifié à prendre en
compte pour la détection ultérieure,
-Calculer une empreinte numérique de session à partir d'une fonction de
hachage
choisie pour chaque branche de détection, chaque branche de détection étant
rattachée à une sous-session déterminée pour analyser le ou les protocoles
suivants
Pi+n ; et
-Enregistrer l'empreinte numérique de session de chaque branche de détection
rattachée à une chaine de protocole, l'étape d'enregistrement étant configurée
pour
attribuer un identifiant unique à chaque branche de détection du/des
protocoles
tunnelés, multiplexés, ou multicanaux détectés.
[0020] Avantageusement, le procédé selon l'invention permet
d'obtenir une
empreinte numérique unique par canal, ou branche de protocoles détectés, et
ainsi
éviter une perte d'information telle que deux canaux disposant du même
identifiant.
[0021] A titre d'exemple, la table de hash est mise à jour si la
détection d'au moins
un protocole d'une session nécessite la mise en oeuvre d'une détection
retardée
sur plusieurs paquets.
[0022] En pratique, la base de données de connaissances comprend
une base de
données de connaissances statiques, dans laquelle la base de données de
connaissances statiques comprend des marqueurs basés sur une connaissance
empirique des caractéristiques des protocoles, et dans lesquels la
connaissance
empirique comprend des moyens algorithmiques de détection de protocoles basés
sur des normes de localisation, des liens logiques entre les protocoles de
communication, les requêtes pour commentaires et les modèles de fréquence des
protocoles de communication.
[0023] En outre, le procédé selon l'invention comprend l'exécution
d'une analyse
de données suivie d'une extraction de données pour les paquets de données sur
la base de l'étiquette associée.
[0024] Selon un premier mode de réalisation de l'invention,
l'exécution de l'analyse
de protocoles et l'exécution, de l'analyse et de l'extraction des données pour
un
paquet de données sont effectuées de manière dynamique sur un seul coeur de
traitement d'un processeur multicceur.
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
7
[0025] Selon un second mode de réalisation de l'invention,
l'exécution de l'analyse
et l'extraction des données pour le paquet de données sont effectuées sur
plusieurs coeurs de traitement d'un processeur multicceur.
[0026] En pratique, le procédé selon l'invention comprenant la
séparation du flux
de données en une pluralité de files d'attente de traitement dans laquelle
l'analyse
de protocoles suivie de l'analyse et de l'extraction des données sont
effectuées sur
des paquets de données dans chacune des files d'attente de traitement.
[0027] En outre, la séparation du flux de données dans la
pluralité des files
d'attente de traitement est basée sur un algorithme RSS de mise à l'échelle
côté
réception.
[0028] Selon un mode de réalisation du procédé selon l'invention, l'analyse de
protocole est exécutée de manière dynamique sur les couches 2 à 7 du modèle
de couches OSI.
[0029] L'invention a également pour objet un système informatique
d'analyse d'un
flux de données de paquets de données reçu via un réseau de communication, le
flux de données comprenant des lots de paquets définis chacun par une chaine
de
protocoles de communication rattachée à au moins une session.
[0030]Selon une autre définition générale de l'invention, le système comprend
un
processeur comprenant au moins un coeur de traitement pour traiter un nombre
prédéterminé de paquets de données par minute et un moteur d'analyse de
protocole sur au moins un coeur de traitement, dans lequel le moteur d'analyse
de
protocole
-analyse du premier protocole d'une chaine de protocoles de communication
selon
une étape de classification par détection explicite configurée ? Pour vérifier
si le
premier protocole annonce le protocole de communication suivant de la chaine
de
protocoles, en cas d'annonce, le protocole suivant ainsi annoncé est
identifié,
tandis qu'en cas de non-annonce, le moteur d'analyse est apte à analyser le
protocole selon une étape de classification par détection de session ;
-analyse selon une étape de classification par détection de session,
configurée
pour vérifier si le protocole PH-1 est attaché à une chaine de protocoles
connue
selon un arbre de décision dynamique par interrogation d'une base de données
dynamique de session comprenant des chaines de protocoles identifiées:
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
8
-en cas d'attache, le protocole Pi+1 est identifié, et le moteur d'analyse
est apte à analyser le protocole PH-2 par répétition des étapes de
classification
par détection explicite, de classification par détection de session ;
- tandis qu'en cas de non-attache, le moteur d'analyse est apte à
analyser le protocole Pi+1 selon une étape de classification par
inspection profonde de paquet ;
-analyse le protocole Pi+1 selon une étape de classification par inspection
profonde de paquet, configurée pour identifier le protocole de communication
du paquet Pi+1 selon un arbre de décision dynamique corrélé à une base de
données de connaissances comprenant des paramètres d'analyse de
protocoles et une base de marqueurs spécifiques à chaque protocole connu;
- en cas de défaut d'identification du protocole Pi-F1, le moteur d'analyse
est
apte à émettre une liste de candidats de protocoles potentiels à prendre en
compte selon au moins deux branches de détection, chaque détection étant
rattachée à une sous-session déterminée pour analyser le ou les protocoles
suivants Pi+n avec r-12 par répétition des étapes de classification par
détection
explicite, de classification par détection de session, et de classification
par
inspection profonde de paquet jusqu'à identifier au moins un protocole dont
l'identité est certaine ;
-en cas d'identification d'un protocole Pi+n dont l'identité est certaine sur
une
branche de détection, le moteur d'analyse est apte à valider rétroactivement
la
branche de détection, et écarter les branches de détection restantes non
validées ;
-en cas d'absence d'identification d'un protocole Pi+n dont l'identité est
certaine
sur une branche de détection, le moteur d'analyse est apte à classifier le
protocole Pi+1 comme inconnu rétroactivement ; et
-un moteur d'étiquetage apte à associer une étiquette aux paquets de données
en fonction des protocoles ainsi identifiés.
[0031] En pratique, le moteur d'analyse de protocole :
-calcule une empreinte numérique de session à partir d'une fonction de hachage
choisie après chaque étape de classification, ladite empreinte numérique étant
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
9
calculée sur la base du premier protocole identifié, et sur l'empreinte
numérique
précédemment calculée de la chaîne de protocoles déjà identifiée sans prise en
compte du contenu attaché, chaque empreinte numérique est calculée sur la base
de
paramètres (ou tuple) choisis et spécifiques à chaque type de protocole,
chaque type
de protocole disposant d'un nombre propre de marqueurs définit (n-Tuples) ;
-enregistre l'empreinte numérique de session calculée après chaque étape
d'identification de protocole suivant étape de classification de chaque
protocole par
inspection profonde de paquet ou après l'étape de validation rétroactive, dans
une
table de hash intégrée dans la base de données dynamique de session, chaque
empreinte numérique étant liée à au moins une session choisie, lesdites
empreintes
numériques calculées après chaque étape de classification de chaque protocole
par
inspection profonde de paquet étant apte à être mise à jour rétroactivement en
cas
d'identification retardée d'un protocole selon l'étape de vérification.
[0032] Le moteur d'analyse de protocole du système selon l'invention comprend
en
outre en cas de détection de protocoles tunnelés, multiplexés, multicanal, ou
multicanal multiplexés détectés de manière certaine,
-Génère au moins une branche de détection par protocole vérifié à prendre en
compte pour la détection ultérieure,
-Calcule une empreinte numérique de session à partir d'une fonction de hachage
choisie pour chaque branche de détection, chaque branche de détection étant
rattachée à une sous-session déterminée pour analyser le ou les protocoles
suivants ; et
-Enregistre l'empreinte numérique de session de chaque branche de détection
rattachée à une chaine de protocole, l'enregistrement étant configuré pour
attribuer
un identifiant unique à chaque branche de détection dufdes protocoles
tunnelés,
multiplexés, ou multicanaux détectés.
[0033] Le système selon l'invention comprend, en outre, une base
de données de
connaissances comportant une base de données de connaissances statiques dans
laquelle la base de données de connaissances statiques comprend des marqueurs,
aussi appelés labels, basés sur une connaissance empirique des
caractéristiques des
protocoles, et dans lesquels la connaissance empirique comprend des moyens
algorithmiques de détection de protocoles basés sur des normes sur la
localisation,
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
des liens logiques entre les protocoles de communication, les requêtes pour
commentaires et les modèles de fréquence des protocoles de communication.
[0034] En pratique, le système selon l'invention comprend un
moteur d'analyse de
contenu exécutable sur au moins un c ur de traitement pour analyser et
extraire le
paquet de données sur la base de l'étiquette associée.
[0035] Selon un mode de réalisation de l'invention, le moteur
d'analyse de
protocole et le moteur d'analyse de contenu effectuent consécutivement
l'analyse de
protocoles suivie de l'analyse et de l'extraction de données pour le flux de
données
de paquets de données, et dans lequel le moteur d'analyse de contenu effectue
séparément l'analyse et l'extraction de données pour des paquets de données
étiquetés différemment.
[0036] Le système selon l'invention comprend, en outre, une carte
d'interface
réseau couplée au processeur, dans laquelle la carte réseau sépare le flux de
données des paquets de données en une pluralité de files d'attente de
traitement, et
dans laquelle le moteur d'analyse de protocole et le moteur d'analyse de
contenu
effectuent l'analyse des paquets et l'extraction de données des paquets sur
chacune
des pluralités de files d'attente de traitement.
[0037]A titre d'exemple, la carte réseau (NIC) sépare le flux de données des
paquets de données en fonction de l'algorithme RSS de mise à l'échelle côté
réception.
[0038] Le procédé et système selon l'invention permettent
avantageusement
d'identifier des couches protocolaires qui n'ont pas été annoncées. Dans le
cas où ces
protocoles ne s'annoncent pas, ou n'annoncent pas ceux qui suivent, et
permettent
de chercher un ensemble de marqueurs susceptibles de valider l'identification
d'un
protocole en particulier.
[0039] Avantageusement, le système et procédé selon l'invention
permettent
également de procéder à une validation par rebonds multiples et logiques des
protocoles analysés si une couche décrétée comme "sûre" est validée, ladite
couche
sûre permettant ainsi de valider l'ensemble des choix de classification
effectués.
En d'autres termes, les empilements de protocoles qui précèdent pourrons être
déduits correctement.
[0040] De manière surprenante, le procédé et le système selon
l'invention
permettent de pouvoir attendre plusieurs paquets pour valider une chaine
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
11
d'empilement de protocoles pour une session donnée, et de pouvoir garder une
unicité
de session par branche tout en garantissant une empreinte numérique unique par
session et par branche de détection en procédant à des calculs d'empreintes
numériques continus sur chaque couche de protocoles contenus dans un paquet.
[0041] Enfin, le procédé et le système selon l'invention
permettent de maintenir
une granularité très profonde de l'analyse des données réseau, et ainsi
limiter les
erreurs d'identification de protocole et garantir des données d'analyse
fiables.
BREVE DESCRIPTION DES DESSINS
[0042] La figure 1 illustre un système informatique d'analyse d'un
flux de données
de paquets de données reçus via un réseau de communication, conformément à un
exemple de mise en uvre de la présente invention,
[0043] La figure 2 illustre les schémas du système informatique,
conformément à
un exemple de mise en oeuvre de la présente invention,
[0044] La figure 3 illustre le système informatique d'analyse d'un
flux de données
de paquets de données reçus via un réseau de communication, conformément à un
exemple de mise en oeuvre de la présente invention,
[0045] La figure 4 illustre le flux d'événements à l'intérieur
d'un noyau de
traitement du système informatique, conformément à un exemple de mise en
oeuvre
de la présente invention,
[0046] La figure 5 illustre l'étape de réception et de
distribution des paquets par
une carte d'interface réseau conformément à l'invention,
[0047] Les figures 6, 7 et 8 illustrent les étapes d'analyse d'un
flux de données de
paquets de données reçus via un réseau de communication, conformément à un
exemple de mise en uvre de la présente invention, et
[0048] Les figures 9, 10 et 11 illustrent des exemples d'analyse
linéaire
conformément à l'invention ;
[0049] Les figures 12, 13, et 14 illustrent un exemple d'analyse
appliquée à une
détection de protocoles à détection retardée conformément à l'invention ;
[0050] La figure 15 illustre un exemple d'analyse appliquée à une
détection de
protocoles avec gestion d'une table de hash associée conforme à l'invention ;
[0051] Les figures 16 et 17 illustrent la gestion des empreintes
numériques lors de
la détection conforme à l'invention ; et
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
12
[0052] La figure 18 illustre un exemple d'analyse appliquée à une
détection de
protocoles multiplexés et multicanal avec gestion d'une table de hash associée
conforme à l'invention.
[0053] D'autres avantages et caractéristiques de l'invention apparaitront à
l'examen
de la description et des dessins.
DESCRIPTION DÉTAILLÉE
[0054] Les techniques ci-dessus sont décrites plus en détail en
référence aux
figures 1 à 18. Il convient de noter que la description et les chiffres ne
font qu'illustrer
les principes du présent objet ainsi que les exemples décrits dans le présent
document
et ne doivent pas être interprétés comme une limitation au présent objet. Il
est donc
entendu que divers arrangements peuvent être conçus qui, bien qu'ils ne soient
pas
explicitement décrits ou montrés dans le présent document, les énoncés ci-
après
faisant état de principes, d'aspects et de mises en oeuvre du présent objet,
ainsi que
des exemples spécifiques de ceux-ci, sont destinés à englober des équivalents
de
ceux-ci.
[0055] La figure 1 illustre un système informatique 100 pour
l'analyse d'un flux de
données de paquets de données reçus via un réseau de communication (non
illustré),
conformément à un exemple de la présente invention. Le système informatique
100
peut être soit un ordinateur autonome, soit une combinaison de plusieurs
systèmes
informatiques fonctionnant ensemble dans un environnement informatique
distribué.
Des exemples de système informatique 100 peuvent inclure, sans s'y limiter,
les
ordinateurs de bureau, les ordinateurs portables et les smartphones, ainsi que
les
assistants numériques personnels (PDA).
[0056] Le réseau de communication peut être un réseau sans fil ou
câblé, ou une
combinaison de ceux-ci. Le réseau de communication peut être un ensemble de
réseaux individuels, interconnectés les uns aux autres et fonctionnant corn me
un seul
grand réseau. Des exemples de tels réseaux individuels comprennent, sans
toutefois
s'y limiter, le réseau du Système mondial de communication mobile (GSM), le
réseau
du Système universel de télécommunications mobiles (UMTS), le réseau LTE (Long
Term Evolution), le réseau de services de communications personnelles (PCS),
le
réseau d'accès multiple par répartition dans le temps (AMRC), le réseau CDMA
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
13
(Code-Division Multiple Access), le réseau de nouvelle génération (NGN), le
réseau
téléphonique public commuté (RTPC) et le réseau numérique à intégration de
services
(RNIS). Selon la terminologie, le réseau de communication comprend diverses
entités
de réseau, telles que des passerelles et des routeurs ; toutefois, ces détails
ont été
omis pour maintenir la brièveté de la description.
[0057] Il convient de noter que, bien que les dispositions
suivantes soient fournies
en ce qui concerne le système informatique 100, les exemples de mise en oeuvre
de
la présente invention peuvent également être mis en oeuvre sur divers
dispositifs ou
réseaux utilisés par un fournisseur de services de réseau, fournissant une
connectivité
réseau à un ou plusieurs abonnés, tels que des organisations gouvernementales,
des
sociétés multinationales, des sociétés, des entreprises et d'autres
établissements. Le
fournisseur de services de réseau peut servir de canal de connexion entre le
réseau
de communication et les dispositifs informatiques de ses abonnés. Il convient
de noter
que le fournisseur de services de réseau peut mettre en oeuvre divers autres
équipements, dispositifs, noeuds de réseau interconnectés par une ou plusieurs
liaisons de réseau câblées ou sans-fil pour fournir une connectivité réseau
aux
abonnés. Les noeuds du réseau peuvent généralement inclure des commutateurs,
des
routeurs, des points d'accès et des liaisons de données qui peuvent faciliter
la
communication entre divers hôtes d'abonnés (par exemple, des ordinateurs
serveur,
des ordinateurs clients, des appareils mobiles, etc.) qui peuvent produire et
consommer du trafic de données. Dans un autre exemple, les exemples peuvent
être
mis en oeuvre sur divers périphériques réseau utilisés par des établissements
/
organisations individuels, fournissant une connectivité et une sécurité réseau
à un ou
plusieurs de ses utilisateurs.
[0058] En référence aux figures 1 à 18, le système informatique
100 peut inclure
un processeur 102, lorsque le processeur 102 comprend au moins un coeur de
traitement 104. Le système informatique 100 peut en outre comprendre un moteur
d'analyse de protocole 106 et un moteur d'étiquetage 108. Dans un exemple, le
moteur d'analyse de protocole 106 et le moteur d'étiquetage 108 peuvent être
exécutables sur au moins un coeur de traitement 104.
[0059] Le terme moteur d'analyse 106 sera utilisé pour
désigner le terme
moteur d'analyse de protocole 106 .
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
14
[0060] Le processeur 102 comprend au moins un coeur de traitement
104
configuré pour traiter un nombre prédéterminé de paquets de données par minute
et
un moteur d'analyse de protocole 106 sur au moins un c ur de traitement 104.
[0061] Dans un exemple d'implémentation, le moteur d'analyse de
protocole 106
analyse le flux de données comprenant des lots de paquets définis chacun par
une
chaine de protocoles de communication rattachée à au moins une session. Ledit
moteur d'analyse de protocole 106 est configuré pour analyser le premier
protocole Pi
d'une chaine de protocoles de communication selon une classification par
détection
explicite S10, S11, S12, S13 pour vérifier si ledit premier paquet Pi annonce
le
protocole de communication du paquet de données suivant Pi+1 de la chaîne de
protocoles.
[0062] En cas d'annonce, le protocole du paquet suivant, ainsi
annoncé, est
identifié S100.
[0063] En cas de non-annonce, le moteur d'analyse 106 est propre à
analyser le
paquet suivant Pi+1 pour vérifier s'il est attaché à une chaine de protocoles
connue et
stockée dans la base de données dynamique BDDS comprenant des chaines de
protocoles déjà identifiées, selon une classification par détection de session
S20, S21,
S22.
[0064] Le moteur d'analyse de protocole 106 est configuré pour
appliquer une
méthode de classification par détection de session S20 consistant à vérifier
si le
protocole PH-1 est attaché à une chaine de protocoles connue selon un arbre de
décision dynamique par interrogation d'une base de données dynamique de
session
BDDS comprenant des chaines de protocoles identifiées.
[0065] En pratique, le système informatique 100 est, en outre,
couplé à la base de
données de connaissances 110 sur les paquets de données comprenant un étage
dynamique BDDS propre à stocker les sessions, comme on le décrira plus en
détail
ci-après, et un étage BDC propre à stocker des connaissances relatives aux
protocoles. Il convient de noter que si la base de données de connaissances
110 sur
les paquets de données a été illustrée comme ainsi distincte du système
informatique
100, la base de données de connaissances 110 sur les paquets de données peut
également être hébergée dans le système informatique 100 en fonction de ses
capacités.
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
[0066] En cas d'attache, les protocoles de la chaine de protocole
connue sont
identifiés (étape S100), le protocole PH-1 est identifié, et le moteur
d'analyse 106 est
apte à analyser le protocole Pi+2 par répétition des étapes de classification
par
détection explicite S10, de classification par détection de session S20.
[0067] En cas de non-attache, le moteur d'analyse 106 est apte à
analyser le
protocole suivant Pi-i-1 selon une classification par inspection profonde de
paquet S40,
S42, S44, S46.
[0068] Selon une classification par inspection profonde de paquet
S40, le moteur
d'analyse 106 est configuré pour identifier le protocole de communication du
paquet
Pi+1 selon un arbre de décision dynamique corrélé à une base de données de
connaissances B D C comprenant des paramètres d'analyse de protocoles et une
base
de marqueurs spécifiques, aussi appelés labels (voir figure 11 et figure 15) à
chaque
protocole connu.
[0069] En cas de défaut d'identification du protocole PH-1, le moteur
d'analyse 106 est
apte à émettre une liste de candidats de protocoles potentiels à prendre en
compte
selon au moins deux branches de détection possible, chaque détection étant
rattachée à une sous-session déterminée pour analyser le ou les protocoles
suivants Pi+n avec r-i2 par répétition des analyses selon la classification
par
détection explicite S10, par détection de session S20, et par inspection
profonde
de paquet S40 jusqu'à identifier au moins un protocole dont l'identité est
certaine.
[0070] En cas d'identification d'un protocole Pi+n dont l'identité est
certaine par le
moteur d'analyse 106, sur une branche de détection, ledit moteur d'analyse 106
est apte à valider rétroactivement S60 la branche de détection, et à écarter
les
autres branches de détection restantes non validées.
[0071] En cas d'absence d'identification d'un protocole Pi+n dont l'identité
est certaine
sur une branche de détection, le moteur d'analyse 106 est apte à classifier le
protocole Pi+1 comme inconnu S60 rétroactivement et continuer l'analyse des
paquets de données suivants.
[0072] Le moteur d'analyse de protocole 106 est en outre apte à calculer une
empreinte numérique de session Hi+n à partir d'une fonction de hachage choisie
après chaque étape de classification S10, 320, S40, ladite empreinte numérique
Hi+n étant calculée sur la base du premier protocole identifié, et sur
l'empreinte
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
16
numérique précédemment calculée Hi+n-1 de la chaîne de protocoles déjà
identifiée sans prise en compte du contenu attaché ou payload.
[0073]Chaque empreinte numérique Hi+n est ainsi calculée sur la base de
paramètres ou tuple choisis et spécifiques à chaque type de protocole, chaque
type de protocole disposant d'un nombre propre de tuple défini, soit n-Tuples.
[0074] Pour chaque protocole, un choix des paramètres pertinents est fait de
manière
dynamique, permettant ainsi de gérer les sessions complètes hors TCP/UDP.
[0075] Le moteur d'analyse 106 est ensuite apte à enregistrer
l'empreinte
numérique de session Hi+n calculée après chaque étape d'identification de
protocole
suivant l'étape S40 ou après l'étape de validation rétroactive S60, dans une
table de
hash intégrée dans la base de données dynamique de session BDDS, chaque
empreinte numérique Hi+n étant liée à au moins une session choisie, lesdites
empreintes numériques Hi+n calculées après chaque étape de classification de
chaque protocole par inspection profonde de paquet S40 étant apte à être mise
à jour
rétroactivement en cas d'identification retardée d'un protocole selon l'étape
de
vérification S60.
[0076] En pratique, lorsque le moteur d'analyse 106 n'identifie
pas un protocole
Pi+1, et émet une liste de candidats de protocoles potentiels à prendre en
compte
selon au moins deux branches de détection possible B1, B2 pour détection
retardée,
chaque détection étant rattachée à une sous-session déterminée pour analyser
le ou
les protocoles suivants Pi+n avec r-12 par répétition des analyses selon la
classification par détection explicite S10, par détection de session S20, et
par
inspection profonde de paquet S40 jusqu'à identifier au moins un protocole
dont
l'identité est certaine, le moteur d'analyse 106 calcule une empreinte
numérique de
session Hi+n à partir d'une fonction de hachage choisie, pour chaque branche
de
détection B1, B2 étant rattachée à une sous-session déterminée pour analyser
le ou
les protocoles suivants Pi+n.
[0077] Les empreintes numériques de session Hi+n ainsi calculées
permettent
l'identification a posteriori d'un ou plusieurs protocoles préalablement non
identifiés,
même si la détection de la session nécessite plusieurs paquets, la table de
hash
pourra être remise à jour pour prendre en compte ces nouveaux éléments et
ainsi ne
jamais perdre un seul paquet ou données associées.
CA 03226756 2024- 1-23
WO 2023/036846
PCT/EP2022/074915
17
[0078] En outre, le moteur d'analyse 106 enregistre l'empreinte
numérique de
session Hi+n de chaque branche de détection B1 , B2 rattachée à une chaine de
protocole, l'enregistrement étant configuré pour attribuer un identifiant
unique à
chaque branche de détection_
[0079] En référence à la figure 8, à titre d'exemple, les
empreintes numériques H1,
H2, et 1-13 sont calculées respectivement après identification des protocoles
Pi, PH-1
et Pi+2 de la chaîne de protocole, et lorsque la classification selon une
inspection
profonde de paquets S40 échoue à identifier le protocole PH-1, une empreinte
numérique H2T est calculée, et dans le cas où l'identification du protocole
Pi+3 valide
la chaine de protocole, et que PH-1 peut être déduit, alors, Pi+1 est validé
et
l'empreinte numérique H2T est mise à jour par calcul et enregistrement d'une
nouvelle
empreinte numérique H2.
[0080] Selon un mode de réalisation particulier de l'invention, le
moteur d'analyse
106, en cas de détection de protocoles tunnelés, multiplexés, ou multicanaux
détectés de manière certaine, est apte à générer au moins une branche de
détection Ai, A2, Bi, B2, Cl, 02 par protocole vérifié à prendre en compte
pour la
détection ultérieure.
[0081] Pour chaque branche de détection générée Ai, A2, Bi, B2,
Cl, C2, le
moteur d'analyse 106 calcule une empreinte numérique de session Hi+n à partir
d'une fonction de hachage choisie, chaque branche de détection étant rattachée
à
une sous-session déterminée pour analyser le ou les protocoles suivants PH-n;
et
[0082] -Enregistre l'empreinte numérique de session Hi+n de chaque
branche de
détection rattachée à une chaine de protocole, l'enregistrement étant
configuré
pour attribuer un identifiant unique à chaque branche de détection du/des
protocoles tunnelés, multiplexés ou multicanaux détectés.
[0083]Avantageusement, le hash calculé évolue à mesure que le paquet de
données est lu, permettant de pouvoir faire analyser et détecter tous les
protocoles avec une seule sonde (c'est-à-dire les enchainements simples,
complexes, tunnelés, multicanaux et multiplexés), et grâce à cette répétition
de
calcul de hash, sur chaque couche, chacun des identifiants est réellement
unique, peu importe la longueur de la chaine de protocoles qui compose le ou
les
paquets.
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
18
[0084] Le système 100 comprend, en outre, le moteur d'étiquetage
108, propre à
associer une étiquette aux paquets de données en fonction des protocoles ainsi
identifiés.
[0085] Le moteur d'analyse 106 est apte à enregistrer l'état de
session si la
session courante est inconnue avec une empreinte numérique calculée avec n-
tuples
S31, 32 et S33.
[0086] La figure 2 illustre les schémas du système informatique
100 pour l'analyse
du flux de données des paquets de données reçus via le réseau de
communication,
conformément à un exemple de mise en uvre de la présente invention.
[0087] Comme déjà décrit, le système informatique 100 peut inclure
le processeur
102, ou le processeur 102 peut inclure plusieurs coeurs de traitement 104-1,
104-2,
104-3, ..., 104-n. Les fonctions du bloc fonctionnel étiqueté comme
processeur(s) ,
peuvent être fournies par l'utilisation de matériel dédié ainsi que de
matériel capable
d'exécuter des instructions. Lorsqu'elles sont fournies par un processeur, les
fonctions
peuvent être fournies par un seul processeur dédié, par un seul processeur
partagé
ou par une pluralité de processeurs individuels, dont certains peuvent être
partagés.
En outre, l'utilisation explicite du terme processeur ne serait pas
interprétée
comme se référant exclusivement au matériel capable d'exécuter des
instructions et
peut implicitement inclure, sans s'y limiter, le matériel de processeur de
signal
numérique (DSP), le processeur réseau, le circuit intégré spécifique à
l'application
(AS IC), le FPGA (field programmable gate array), la mémoire en lecture seule
(ROM)
pour le stockage des instructions, la mémoire vive (RAM), le stockage non
volatil.
D'autres matériels, standard et/ou personnalisés, peuvent également être
inclus.
[0088] Le système informatique 100 peut en outre inclure une
mémoire 202
couplée au processeur 102, où la mémoire 202 peut inclure tout support lisible
par
ordinateur, y compris, par exemple, la mémoire volatile (par exemple, la RAM)
et/ou
la mémoire non volatile (par exemple, EPROM, mémoire flash, etc.).
[0089] En outre, le système informatique 100 peut inclure une
carte d'interface
réseau (NIC) 204 couplée au processeur 102 et à la mémoire 202. La carte
réseau
204 peut être un composant intégré du système informatique 100 ou peut être un
composant séparé, couplé à l'extérieur au système informatique 100.
[0090] Le système informatique 100 peut, en outre, inclure les
moteurs 206, ou les
moteurs 206 peuvent inclure le moteur d'analyse de protocole 106, le moteur
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
19
d'étiquetage 108 et le moteur d'analyse de contenu 112. Dans un exemple, les
moteurs 206 peuvent être implémentés comme une combinaison de matériel et de
firmware. Dans les exemples décrits ici, de telles combinaisons de matériel et
de
micrologiciels peuvent être mises en oeuvre de plusieurs manières différentes.
Par
exemple, le micrologiciel du moteur peut être des instructions exécutables du
processeur, stockées sur un support de stockage non transitoire, lisible par
machine
et le matériel du moteur peut inclure une ressource de traitement (par
exemple,
implémentée en tant que processeur unique ou une combinaison de plusieurs
processeurs) pour exécuter ces instructions.
[0091] Dans les présents exemples, le support de stockage lisible
par machine
peut stocker des instructions qui, lorsqu'elles sont exécutées par la
ressource de
traitement, implémentent les fonctionnalités du moteur. Dans de tels exemples,
le
système informatique 100 peut inclure le support de stockage lisible par
machine
stockant les instructions et la ressource de traitement pour exécuter les
instructions.
Dans d'autres exemples du présent sujet, le support de stockage lisible par
machine
peut être situé à un endroit différent, mais accessible au système
informatique 100 et
au processeur 102.
[0092] Le système informatique 100 peut, en outre, inclure les
données 208, qui
servent, entre autres, de référentiel pour stocker des données qui peuvent
être
récupérées, traitées, reçues ou générées par le moteur d'analyse de protocole
106, le
moteur d'étiquetage 108 et le moteur d'analyse de contenu 112. Les données 208
peuvent inclure les données d'analyse de protocole 210, les données
d'étiquetage
212, les données d'analyse de contenu 214 et d'autres données 216. Dans un
exemple, les données 208 peuvent être stockées dans la mémoire 202.
[0093] Dans un exemple d'implémentation, la carte réseau 204 peut
recevoir le
flux de données des paquets de données via le réseau de communication. La
carte
réseau 204 peut séparer le flux de données en plusieurs files d'attente RX de
traitement et allouer chaque file d'attente de traitement à au moins un coeur
de
traitement 104-1, 104-2, 104-3, ..., 104-n. Dans un exemple, la carte réseau
204 peut
séparer le flux de données dans les files d'attente de traitement multiples en
fonction
de l'algorithme RSS (Receive Side Scaling) mise à l'échelle côté réception. Un
tel
algorithme permet de distribuer des paquets sur plusieurs files d'attentes
Psa, Psb
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
(queues de réception). Il existe plusieurs algorithmes de distribution, le
plus utilisé se
nomme Toeplitz de microsoft (marque déposée).
[0094] Il convient de noter que chacun des multiples coeurs de
traitement 104-1,
104-2, 104-3, .., 104-n peut permettre d'exécuter différentes instances des
multiples
moteurs sur ceux-ci. Par exemple, des instances distinctes du moteur d'analyse
de
protocole 106, du moteur d'étiquetage 108 et du moteur d'analyse de contenu
112
peuvent être exécutées en parallèle sur chacun des coeurs de traitement 104-1,
104-
2, 104-3 104-n. Toutefois, pour faciliter la compréhension,
l'exemple
d'implémentation suivant a été expliqué en ce qui concerne un seul coeur de
traitement
104-1 du processeur 102, ci-après dénommé le coeur de traitement 104.
[0095] En référence à la figure 5, on a représenté un exemple de
réception et de
distribution des paquets.
[0096] La carte réseau 204 reçoit les paquets selon l'étape S200.
[0097] Selon l'étape S202 la carte réseau envoie directement les
paquets vers la
mémoire cache 202.
[0098] Selon l'étape S204, la carte réseau envoie les champs des
paquets sur de
multiples queues RX (files d'attente) et choisit la queue correcte selon
l'algorithme
RSS (receive side scaling) mise à l'échelle côté réception.
[0099] Selon l'étape S206, chaque coeur de CPU est lié à une queue
RX.
[00100] Selon l'étape S208, chaque coeur de CPU récupère un lot LOT de paquets
depuis la mémoire cache (RAM) 202.
[00101] Selon l'étape S210, le paquet Pn est reçu par un coeur de CPU, le
premier
protocole dans la chaine de protocole (ou pile) est analysé selon l'analyse
DAP (S212)
conforme à l'invention.
[00102] Dans un exemple, la base de données de paquets dynamiques de sessions
BDDS peut être stockée dans les données d'analyse de protocole 210. Dans un
autre
exemple, la base de données BDDS peut être incluse dans la base de données de
connaissances 110 sur les paquets de données.
[00103] Dans cet exemple, en plus de la base de données dynamique de sessions
BDDS, la base de données de connaissances de paquets de données 110 peut
également inclure une base de données de paquets de données statiques. La base
de données statique sur les paquets de données peut inclure des marqueurs
basés
sur une connaissance empirique des caractéristiques des protocoles, et dans
lesquels
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
21
la connaissance empirique comprend des moyens algorithmiques de détection de
protocoles basés sur des normes sur la localisation, des liens logiques entre
les
protocoles de communication, les requêtes pour commentaires RFC et les modèles
de fréquence des protocoles de communication_
[00104] Le moteur d'analyse de protocole 106 peut également stocker le
protocole
de communication ainsi identifié dans les données d'étiquetage 212. Le moteur
d'étiquetage 108 peut alors accéder aux données d'étiquetage 212 et associer
une
étiquette sur les paquets de données ainsi analysés et dont les protocoles
sont ainsi
identifiés.
[00105] Le moteur d'étiquetage 108 transmet ensuite les paquets de données
étiquetés au moteur d'analyse de contenu 112. Le moteur d'analyse de contenu
112
analyse et extrait les paquets de données en fonction de l'étiquette qui leur
est
associée. Par exemple, le moteur d'analyse de contenu 112 peut analyser et
extraire
un premier paquet de données avec une étiquette indiquant un premier protocole
de
communication basé sur le premier protocole de communication. De même, le
moteur
d'analyse de contenu 112 peut analyser et extraire un deuxième paquet de
données
avec l'étiquette indiquant un deuxième protocole de communication différemment
du
premier paquet de données. Le moteur d'analyse de contenu 112 peut ensuite
stocker
les paquets de données analysés et extraits dans les données d'analyse de
contenu
214.
[00106] Dans un exemple, le moteur d'analyse de contenu 112 peut analyser et
extraire les paquets de données (ou des métadonnées desdits paquets) pour
surveiller
et visualiser le trafic de données, détecter une réduction de la qualité de
service,
détecter les cyberattaques et identifier toute incohérence dans la
configuration du
réseau. Si le moteur d'analyse de contenu 112 détecte l'un des événements
mentionnés ci-dessus sur la base de l'analyse et de l'extraction de données,
le moteur
d'analyse de contenu 112 peut générer un déclencheur indiquant l'occurrence de
l'événement lors de l'analyse des données et de l'extraction d'un ensemble de
paquets
de données du flux de données. Dans une telle situation, l'ensemble des
paquets de
données peut être stocké pour un traitement ultérieur. Dans un exemple,
l'ensemble
des paquets de données peut être stocké dans les autres données 216.
[00107] La figure 3 illustre le système informatique 100, conformément à un
autre
exemple de mise en oeuvre de la présente invention. Comme déjà décrit, le
système
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
22
informatique 100 peut inclure le processeur 102 ayant plusieurs coeurs de
traitement
104-1, 104-2, 104-3, ..., 104-n. Le système informatique 100 peut, en outre,
inclure la
carte réseau 204 couplée au processeur 102 et les multiples coeurs de
traitement 104-
1, 104-2, 104-3, ..., 104-n qui y sont inclus. En outre, chacun des coeurs de
traitement
multiples 104-1, 104-2, 104-3, ..., 104-n peut permettre d'exécuter des
instances
distinctes du moteur d'analyse de protocole 106, du moteur d'étiquetage 108 et
du
moteur d'analyse de contenu 112. En outre, le système informatique 100 peut
être
couplé à la base de données de connaissances sur les paquets de données 110.
[00108] Le moteur d'analyse de contenu 112, exécuté sur le coeur de traitement
104-1, peut ensuite analyser et extraire le premier paquet de données en
fonction de
l'étiquette de données qui lui est associée.
[00109] Dans un exemple, le moteur d'analyse de protocole 106 et le moteur
d'analyse de contenu 112 peuvent effectuer de manière séquentielle l'analyse
de
protocole DAP comme illustrée en figures 6 et 7, suivie de l'analyse et de
l'extraction
de données DAC pour le flux de données reçu via le réseau de communication.
Par
exemple, une fois que le moteur d'analyse de protocole 106 a identifié le
protocole de
communication pour le premier paquet de données, le premier paquet de données
peut être étiqueté et transmis au moteur d'analyse de contenu 112 pour
l'analyse et
l'extraction de données.
[00110] En alternative, alors que le moteur d'analyse de contenu 112 effectue
l'analyse et l'extraction de données sur le premier paquet de données Pn, le
moteur
d'analyse de protocole 106 peut simultanément commencer à exécuter l'analyse
DAP
pour un deuxième paquet de données Pn+1 suivant le premier paquet de données
dans le flux de données Pn.
[00111] En pratique, l'exécution de l'analyse DAP peut être suivie de manière
séquentielle par l'analyse et de l'extraction DAC des données pour les paquets
de
données sur un seul coeur de traitement du processeur.
[00112] En alternative, l'analyse DAP et de l'extraction DAC des données qui
suit
l'analyse DAP peut être traitée en parallèle sur un ou plusieurs coeurs ou
machines
dédiées, ce qui facilite l'évolutivité pour gérer un flux plus élevé de
données reçues du
réseau de communication. Ainsi, les techniques décrites ci-dessus peuvent
faciliter le
traitement des flux de données ayant un trafic de données supérieur à 100
Gbps.
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
23
[00113] Dans un autre exemple, comme illustré à la figure 4, une instance du
moteur d'analyse de protocole 106 ainsi que plusieurs instances du moteur
d'analyse
de contenu 112 peuvent être exécutées sur le coeur de traitement 104-1.
Autrement
dit, une fois que le moteur d'analyse de protocole 106 a effectué l'analyse
DAP sur
les paquets de données du flux de données et identifié le protocole de
communication
pour les paquets de données, le noyau de traitement 104-1 peut permettre
l'exécution
parallèle de plusieurs instances du moteur d'analyse de contenu 112 pour
traiter des
paquets de données basés sur différentes étiquettes associées aux paquets de
données, les différentes étiquettes étant associées en fonction du protocole
de
communication identifié pour les paquets de données du flux de données.
[00114] En pratique, un seul coeur de processeur traite de manière consécutive
l'analyse de protocole DAP suivie de l'analyse et extraction de contenu DAC.
[00115] Dans une optique de scalabilité, il est possible de dédier des coeurs,
des
processeurs complets ou des machines dédiées dont l'objectif est de faire
tourner
plusieurs DAC, dans le cas où l'analyse et l'extraction des métadonnées sont
trop
lourds pour être fait sur un seul coeur de processeur
[00116] De cette manière, plusieurs paquets de données ayant des étiquettes
associées différentes peuvent être traités en parallèle par le noyau de
traitement 104-
1, augmentant ainsi le débit global des paquets de données analysés et
extraits par
le système informatique 100 dans un laps de temps donné.
[00117] En alternative, la conception d'une solution basée sur un traitement
asynchrone, en deux temps, des paquets (DAP d'une part et DAC d'autre part)
permet
une cassure physique, en séparant le traitement DAP du traitement DAC (ici le
traitement DAC est à la suite du traitement DAP pour le même paquet de
données).
Sur la base des besoins requis par l'utilisateur, les ressources allouées aux
DAC
peuvent se trouver congestionnées. Cette cassure permet alors de dédier
certains
coeurs à un travail unique du DAC. Au-delà des coeurs d'un seul processeur
CPU, il
est alors possible de dédier des Processeurs complets au DAC, voire même des
machines entières.
[00118] En référence aux figures 6 à 18, l'invention porte également sur un
procédé
d'analyse d'un flux de données de paquets de données reçus via un réseau de
communication, le flux de données comprenant des lots de paquets définis
chacun
par une chaine de protocoles de communication rattachés à au moins une
session.
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
24
[00119] Le procédé selon l'invention comprend une analyse de protocoles DAP
selon une première étape d'analyse du premier protocole Pi d'une chaine de
protocoles de communication selon une étape de classification par détection
explicite S10 configurée pour vérifier si le premier protocole Pi annonce le
protocole de communication suivant Pi+1 de la chaine de protocoles.
[00120] En pratique, en cas d'annonce, le protocole suivant Pi+1 ainsi annoncé
est
identifié, tandis qu'en cas de non-annonce, le procédé selon l'invention est
configuré pour analyser le protocole suivant Pi+1 selon une étape de
classification
par détection de session S20.
[00121] L'étape de classification par détection de session S20 conforme à
l'invention est configurée pour vérifier si le protocole Pi+1 est attaché à
une chaine
de protocoles connue selon un arbre de décision dynamique par interrogation
d'une base de données dynamique de session BDDS comprenant des chaines de
protocoles identifiées.
[00122] Selon un mode de réalisation de l'invention, après identification d'un
protocole lors de l'étape de classification par détection de session S20, la
base de
données dynamique de session BDDS est mise à jour.
[00123] En cas d'attache, le protocole Pi+1 est identifié, et le
protocole Pi+2 est
analysé par répétition des étapes de classification par détection explicite
S10, de
classification par détection de session S20.
[00124] Alternativement, en cas de non-attache, le protocole Pi+1 est analysé
selon
une étape de classification par inspection profonde de paquet S40.
[00125] L'étape de classification par inspection profonde de paquet S40 est
configurée pour identifier le protocole de communication du paquet Pi+1 selon
un
arbre de décision dynamique corrélé à une base de données de connaissances
BDC comprenant des paramètres d'analyse de protocoles et une base de
marqueurs spécifiques à chaque protocole connu.
[00126] En pratique, en cas de détection des marqueurs spécifiques d'un
protocole
testé, le protocole Pi+1 est alors identifié.
[00127] Selon un mode de réalisation de l'invention, après identification d'un
protocole lors de l'étape de classification par inspection profonde de paquets
S40,
la base de données dynamique de session BDDS est mise à jour.
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
[00128] Alternativement, en cas de défaut d'identification du protocole Pi+1,
le
procédé selon l'invention comprend une sous-étape d'émission d'une liste de
candidats de protocoles potentiels pour PH-1, à prendre en compte selon au
moins
deux branches de détection B1, B2, chaque détection étant rattachée à une sous-
session déterminée pour analyser le ou les protocoles suivants Pi+n avec n2
par
répétition des étapes de classification par détection explicite S10, de
classification
par détection de session S20, et de classification par inspection profonde de
paquet S40 jusqu'à identifier au moins un protocole dont l'identité est
certaine.
[00129] En d'autres termes, une branche de détection B1, B2 sera générée sur
la
base d'une hypothèse d'un protocole potentiel donné, et l'identification de
protocole Pi+n après Pi+1 sera mise en uvre par répétition des étapes de
classification S10, S20 et S40.
[00130] Si un protocole Pi+n dont l'identité est certaine est identifié sur
une branche
de détection B1, B2, la branche de détection B1, B2 sera rétroactivement
validée,
et les branches de détection restantes non validées seront écartées.
[00131] Selon un mode de réalisation de l'invention, après identification d'un
protocole lors des étapes de classification par détection de session S20 et
classification par inspection profonde de paquets S40, ou par identification a
posteriori, la base de données dynamique de session BDDS est mise à jour.
[00132] Dans le cas ou l'identification d'un protocole Pi+n dont
l'identité est certaine
n'est pas possible sur une branche de détection, le protocole Pi-i-1 est alors
classifié comme inconnu S60 rétroactivement.
[00133] Avantageusement, la mise à jour de la base de données dynamique de
session BDDS permet une accélération du procédé d'identification, et de
limiter les
protocoles étiquetés comme inconnus.
[00134] Le procédé comprend, en outre, une étape d'étiquetage comprenant
l'association d'une étiquette aux paquets de données en fonction de chaque
session pour lesquels les protocoles ont été identifiés.
[00135] Le procédé selon l'invention comprend, en outre, après chaque étape de
classification S10, S20, S40, une étape de calcul d'une empreinte numérique de
session H i+n à partir d'une fonction de hachage choisie, ladite empreinte
numérique Hi+n étant calculée sur la base du premier protocole identifié, et
sur
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
26
l'empreinte numérique précédemment calculée Hi+n-1 de la chaine de protocoles
déjà identifiée sans prise en compte du contenu attaché.
[00136] En pratique, chaque empreinte numérique Hi+n est calculée sur la base
de
paramètres ou tuples dynamiques choisis et spécifiques à chaque type de
protocole, chaque type de protocole disposant d'un nombre propre de marqueurs
définit aussi appelés n-Tuples.
[00137] A titre d'exemple, les marqueurs définit aussi appelés n-Tuples
peuvent
non lim itativement au groupe formé par IP destinataire, IP source, Port
destinataire,
Port Source, protocole, adresse IP, port, paramètres de qualité de service
QoS,
Tag de réseau, Volume de la session, taille des paquets, nombre de répétition
(retry en anglais), version, type et version de l'algorithme de chiffrement,
type de
chiffrement, CERT (Computer Emergency Response Team en anglais) du
certificat , valeur du SNI (indication du nom du serveur ou Server Name
Indication
en anglais), Taille des paquets, IP retournée, drapeau d'erreurs (flag error
en
anglais), nom de domaine, version du client, version du serveur, version
d'algorithme de chiffrement, algorithme de compression, horodatage, Version
d'IP,
nom d'hébergeur (hostname en anglais), durée de bail (lease-time en anglais),
URL, agent d'utilisateur, nombre d'octet du contenu attaché, type de contenu,
code
d'état, entête de cookie, nom du client, service de la requête, valeur du code
d'erreur, type de requête, valeur du protocole, horodatage de réponse, niveau
de
privilège, type et langue du clavier, identification du produit, taille
d'écran, ou toute
autres métadonnées spécifiques analogues extraites des protocoles dans un ou
plusieurs paquets de données de la session validée, métadonnées spécifiques
analogues extraites du contenu attaché à un ou plusieurs paquets de données de
la session validée
[00138] A titre d'exemple conforme à l'invention, chaque protocole peut avec
un
ensemble de n-tuples spécifique :
PROTOCOLES EXEMPLES DE METADONNEES EXTRAITES
VLAN et VxLAN Tag de réseau
MPLS Id
TCP Volume de la session, taille des paquets, nombre de
retry
TLS version, type et version de l'algorithme de
chiffrement, CERT du
certificat, valeur du SNI
CA 03226756 2024- 1-23
WO 2023/036846
PCT/EP2022/074915
27
DNS
m Taille des paquets, IP retournée, Flag d'erreurs, no de domaine,
rcode
SSH Version du client, version du serveur, version
d'algorithme de
chiffrement, algorithme de compression
Timestamp, Version d'IP, Adresses IP du serveur, adresse IP de
DHCP endpoint, le port/protocole d'origine ¨ TCP ou UDP ¨ le hostname
du serveur ou du endponit, lease-time,...
HTTP Url, user-agent,
nombre d'octet du payload, content-type, status
code, header de cookie,
nom du client, service requested, valeur du code d'erreur, type de
Kerberos requête, valeur du protocole, timestamp de réponse,
niveau de
privilège, type de chiffrement, ...
LDAP durée de session, nombre de logon-errors, flag de fin de session,
code de résultat de query, code d'erreur, ...
RDP cookie username, type et langue du clavier, version
du client,
product ID, taille d'écran, ...
Tableau d'exemples de métadonnées extractibles pour une liste de protocoles
choisis.
[00139] L'étape de
calcul d'empreinte numérique Hi+n est suivie d'une étape
d'enregistrement de ladite empreinte numérique de session Hi+n calculée après
chaque étape d'identification de protocole suivant l'étape S40 ou après
l'étape de
validation rétroactive S60.
[00140]
L'enregistrement est effectué dans une table de hash intégrée dans la
base de données dynamique de session BDDS, chaque empreinte numérique
Hi+n étant liée à au moins une session choisie.
[00141] En
pratique, les empreintes numériques Hi+n calculées après chaque
étape de classification de chaque protocole par inspection profonde de paquet
S40
étant apte à être mis à jour rétroactivement en cas d'identification retardée
d'un
protocole selon l'étape de vérification S60.
[00142] En d'autres termes, la table de hash est mise à jour si la détection
d'au
moins un protocole d'une session nécessite la mise en oeuvre d'une détection
retardée sur plusieurs paquets S60.
[00143] Selon un
mode de réalisation de l'invention, en cas de détection de
protocoles tunnelés, multiplexés, multicanaux de manière certaine, le procédé
selon l'invention comprend une première sous-étape de génération d'au moins
une
branche de détection Ai, A2, B1, B2, Ci, C2 par protocole vérifié à prendre en
compte pour l'analyse ultérieure.
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
28
[00144] Selon une seconde sous-étape, chaque branche de détection AI, A2, B1 ,
B2, Ci, C2 sera traitée comme une chaine de protocole unique et apte à être
analysée, et comprend une sous-étape de calcul d'une empreinte numérique
unique de session Hi+n à partir d'une fonction de hachage choisie, rattachée à
une
sous-session déterminée pour chaque branche de détection AI, A2, B1 , B2, CI,
C2, et permettant d'analyser le ou les protocoles suivants Pi+n.
[00145] Enfin, la détection de protocoles tunnelés, multiplexés, ou
multicanaux
comprend une dernière sous-étape d'enregistrement de l'empreinte numérique de
session Hi+n de chaque branche de détection Ai, A2, Bi, B2, Cl, C2, rattachée
à
une chaine de protocole, l'étape d'enregistrement étant configurée pour
attribuer
un identifiant unique à chaque branche de détection Ai, A2, Bi, B2, Cl, C2
du/des
protocoles tunnelés, multiplexés, multicanaux, détectés, et ainsi
avantageusement
ne pas confondre deux sous-sessions pouvant mener à des informations d'analyse
erronées.
[00146] En référence aux figures 9, et 10 est représentée, à titre d'exemple,
une
implémentation du procédé selon l'invention selon une analyse linéaire
conformément
à l'invention.
[00147] Ici le lot LOTI comprend quatre paquets individualisés PO, Pi, P2, et
P3.
Le paquet PO supporte le protocole ETHERNET ETH. Le paquet P1 supporte le
protocole INTERNET IP. Le paquet P2 supporte le protocole TCP et le paquet P3
supporte le protocole http.
[00148] Après réception du lot LOTI de paquets, le paquet PO est lu (étape
SDL1 ),
ici PO = ETH. A l'étape SLD2, le moteur d'analyse vérifie si le paquet PO
annonce le
protocole du paquet suivant Pi. Ici, on sait que ETH annonce toujours le
protocole qui
suit. Ici Pl = IP.
[00149] A l'étape SDL3, le moteur vérifie si le paquet P1 annonce le protocole
du
paquet suivant P2. Ici on sait qu' IP annonce TCP.
[00150] A l'étape SDL4, le moteur vérifie si TCP annonce le protocole du
paquet
suivant P3. La réponse est négative, mais les connaissances sur les protocoles
indiquent que si TCP port = 80 alors il est fort probable que P3 = http. Si le
test http
en P3 est vérifié ou non, alors la session est connue ou inconnue.
[00151] En étape SLD5, si la session est inconnue (par exemple P3 n'est pas
http)
alors création d'une empreinte numérique des IP de la source A, du
destinataire B,
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
29
des ports A et B et d'un identifiant de protocole. Ensuite la session ainsi
reconnue
pour la première fois est stockée dans la base de données dynamique de session
pour analyse ultérieure.
[00152] En référence à la figure 11 on a représenté un exemple d'analyse
appliquée
à une détection de protocoles linéaire pour laquelle le protocole UDP est
identifié,
mais n'annonce pas le protocole suivant, le moteur d'analyse 106 mettant en
uvre
une analyse selon un classification par détection de session S20 et par
inspection
profonde S40, dont le port identifié est le port :53, et pour lequel l'un des
protocoles
les plus probables est le protocole DNS.
[00153] Le protocole DNS est identifié comme le plus probable, et sera donc
testé
par tentative d'identification des marqueurs propres au protocole DNS.
[00154] Selon le mode de réalisation, tous les marqueurs (ou labels) pour le
protocole DNS ne sont pas retrouvés.
[00155] Selon la figure 11, le protocole QU IC est identifié à l'aide de ses
marqueurs
propres par le moteur d'analyse 106.
[00156] En pratique, l'identification des protocoles probables et leurs tests
en cas
d'échec d'identification sont répétés jusqu'à ce qu'une limite du nombre de
tests
choisis soit atteinte.
[00157] En référence à la figure 14, on a représenté un second exemple
d'analyse
appliquée à une détection de protocoles linéaire à identification a posteriori
pour
laquelle le protocole MPLS est identifié sur une chaine de protocole, mais
n'annonce
pas le protocole suivant,
[00158] L'analyse par classification par inspection profonde S40 ne permet pas
d'identifier le protocole associé si le protocole ne comprend pas de marqueurs
suffisants pour être identifié.
[00159] En référence aux figures 12, et 13 on a représenté, à titre d'exemple,
une
implémentation du procédé selon l'invention pour une analyse appliquée à une
détection de protocoles de tunneling, nécessitant une détection retardée
conformément à l'invention.
[00160] Ici le lot LOT2 comprend quatre paquets individualisés PO, P1, P2, et
P3.
Le paquet PO supporte le protocole ETHERNET ETH. Le paquet P1 supporte le
protocole MPLS. Le paquet P2 supporte le protocole ETH CW et le paquet P3
supporte le protocole IP.
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
[00161] Après réception du lot LOT2 de paquets (étape SPT1), le paquet PO est
lu
(étape SPT2), ici PO = ETH. A l'étape SPT3, le moteur d'analyse 106 vérifie si
le
paquet PO annonce le protocole du paquet suivant P1 selon l'étape de
classification
explicite S10. Ici, on sait ici que ETH annonce toujours le protocole qui
suit. Ici P1 =
MPLS.
[00162] A l'étape SPT4, le moteur vérifie si le paquet P1 annonce le protocole
du
paquet suivant P2. Ici on sait que MPLS n'annonce pas forcément le protocole
du
paquet suivant.
[00163] L'analyse de protocole selon l'invention met en uvre une analyse
selon
une classification par détection de session S20 et par inspection profonde de
paquet
S40, pour lequel les protocoles les plus probables sont testés.
[00164] On suppose alors que P2 est suivi d'un mot de contrôle ETH CW.
[00165] Le procédé selon l'invention comprendra, en outre, une étape de
supposition du protocole restant le plus probable, et continuera la détection
sur le
protocole suivant en testant le ou les protocoles suivant normalement le
premier
protocole supposé.
[00166] A l'étape SPT5, si P2 = ETW CW alors il est probable que P3 = ETH, les
étapes S20 et S40 de classification seront alors répétées pour vérifier si ETH
est bien
identifié et validé.
[00167] A l'étape SPT6, si P3 = ETH alors P3 annonce P4 qui est ici IP.
[00168] A l'étape SPT7, P4 est confirmé par la sonde comme IP.
[00169] A l'étape SPT8, la chaine d'enchainement de protocoles est validée, P2
est
rétroactivement validé comme ETH CW.
[00170] En pratique, l'identification des protocoles probables et leurs tests
en cas
d'échec d'identification est répétée jusqu'à ce qu'une limite du nombre de
tests choisis
soit atteinte.
[00171] Avantageusement, le procédé de détection selon l'invention, comprenant
une gestion d'une table de hash dynamique sur une base de n-tuples, associée à
une
identification de protocole selon des classifications explicites S10, par
détection de
session S20, par inspection profonde de paquet S40, et par détection a
posteriori,
permet de limiter fortement la perte de visibilité et éliminer les erreurs en
cascades
lors de l'analyse d'un flux de données à très haut débit, contrairement aux
systèmes
CA 03226756 2024- 1-23
WO 2023/036846 PCT/EP2022/074915
31
de l'art antérieur et notamment ceux se basant sur un calcul d'empreinte
numérique
de type 5-tuple.
[00172] Le Demandeur a également observé que les systèmes de l'art antérieur
nécessitent souvent des techniques matérielles (FPGA ou ASIC) qui permettent
de
faire du Packet Slicing (découpage du paquet sur les couches inférieures ou
supérieures) pour accélérer le traitement des paquets, alors que la solution
selon
l'invention est un procédé ne nécessitant pas de techniques matérielles pour
être
implémenté et conserver une vitesse de traitement de paquets stable pour des
débits
supérieurs à 100 Gb/s à titre d'exemple non limitatif.
[00173] Bien que des exemples aient été décrits dans un langage spécifique aux
méthodes et/ou aux caractéristiques structurelles, il faut comprendre que la
présente
invention ne se limite pas aux méthodes ou caractéristiques spécifiques
décrites. Au
contraire, les méthodes et les caractéristiques spécifiques sont divulguées et
expliquées à titre d'exemples de la présente invention.
CA 03226756 2024- 1-23
