Conception de filtre d'un réseau d'objets connectés par apprentissage profond

4. Conception des modèles

4.1. Conception des modèles d'apprentissage profond

La création de nos modèles d'apprentissage profond suit une succession d'étapes. Nous avons suivi les étapes ci-après :

1- Acquisition de données : l'algorithme se nourrissant des données en entrée, c'est une étape importante.

2- Préparation et nettoyage des données : les données recueillies doivent être retouchées avant utilisation.

3- Création du modèle : Nous créons les différentes couches avec le nombre de neurones pour chaque couche et en spécifiant la fonction d'activation.

4- Évaluation : une fois l'algorithme d'apprentissage automatique entraîné sur un premier jeu de données, nous évaluerons sur un deuxième ensemble de données qui sert de test afin de vérifier que le modèle ne fasse pas de « sur apprentissage ».

5- Déploiement : le modèle est déployé en production pour faire des prédictions, et potentiellement utiliser les nouvelles données en entrée pour se ré-entraîner et être amélioré.

Nous aborderons les trois premières étapes dans ce chapitre et les deux autres dans le dernier chapitre.

4.1.1. Acquisition du jeu de données

La première étape de conception de nos modèles consiste en l'acquisition des jeux de données. Il nous fallait obtenir les jeux de données des deux modèles proposés. L'un pour identifier les objets du réseau et l'autre pour déterminer la nature du trafic.

D'une part, nous avons commencé par obtenir un jeu de données afin d'entraîner l'algorithme de réseau de neurones détectant la nature du trafic d'objets connectés, bénins ou malicieux.

Nous avons utilisé le jeu de données d'IoT-23. IoT-23 est un nouvel ensemble de données sur le trafic réseau des objets connectés. Il dispose de 20 captures de logiciels malveillants exécutées sur des appareils connectés et de 3 captures pour le trafic d'appareils connectés bénins.

Il a été publié pour la première fois en janvier 2020, avec des captures allant de 2018 à 2019. Ce trafic réseau a été capturé dans le laboratoire Stratosphère, groupe AIC, FEL, Université CTU, de la République tchèque [32]. Son objectif est de proposer un vaste ensemble de données d'infections de logiciels malveillants réels et étiquetés et de trafic bénin aux chercheurs pour développer des algorithmes d'apprentissage automatique. Cet ensemble de données et ses recherches sont financés par Avast Software [33].

Cet ensemble de données possède deux types d'ensembles de données: Il contient du trafic réseau mixte (malveillant et bénin) et du trafic bénin uniquement. Les flux de trafic bénins et malveillants ont des colonnes pour les étiquettes de description du comportement du réseau. Ces étiquettes sont attribuées suivant le processus suivant:

? Analyse : Le fichier pcap d'origine est analysé manuellement. Les flux suspects sont détectés et les libellés sont attribués dans un tableau de bord d'analyse.

? Étiquetage : Un fichier labels.csv est généré par l'analyste. Ce fichier labels.csv contient un ensemble de règles utilisées par un script python pour ajouter des étiquettes à chaque flux.

? Ajout des étiquettes : Le script python lit les données de chaque flux dans le fichier conn.log (jeu de données non étiqueté) et compare ces données avec les règles trouvées dans le fichier labels.csv. Le script compare chaque flux avec les données du fichier csv et si les données de flux correspondent aux critères d'étiquetage, l'étiquette correspondante est ajoutée.

Nous avons utilisé le jeu de données étiquetés conn.log.labeled. Il s'agit du fichier Zeek conn.log obtenu en exécutant l'analyseur de réseau Zeek sur le fichier pcap d'origine.

Le trafic réseau capturé pour les scénarios bénins a été obtenu en capturant le trafic réseau de trois appareils connectés différents: une lampe LED intelligente Philips HUE, un assistant personnel intelligent pour la maison Amazon Echo et une serrure de porte intelligente Somfy. Il est important de mentionner que ces trois objets connectés sont du matériel réel et non simulé dans le laboratoire.

Figure 21 : Appareil Amazon echo[32]

Figure 22 : Dispositif de verrouillage de porte Somfy[32]

Durant l'entraînement et le test, nous n'avons utilisé que 05 captures. Nous avons utilisé 02 ensembles de données capturées comme trafic bénin et 03 autres ensembles de données capturés majoritairement comme trafic malicieux.

Nous avons utilisé la lampe intelligente Philips HUE et la serrure de porte intelligente Somfy pour l'entraînement et le test.

Sur chaque scénario malveillant, un échantillon de malware spécifique dans un Raspberry Pi a été exécuté et utilisait plusieurs protocoles et effectuait différentes actions.

Le tableau ci-dessous montre le numéro de scénario (ID), le nom de l'ensemble de données, la durée en heure, le nombre de paquet, le nombre de flux d'ID Zeek dans le fichier conn.log (obtenu en exécutant le framework d'analyse de réseau Zeek sur le pcap d'origine file), la taille du fichier pcap d'origine et le nom éventuel de l'échantillon de logiciel malveillant utilisé pour infecter l'appareil ainsi que les protocoles utilisés et leurs quantité.

Tableau 2 : Ensemble du jeu de donnée obtenu grâce à des logiciels malveillants sur des objets connectés

#	Nom du Dataset	Durée (heure)	Nombre de paquets	Nombre de flux d'ID Zeek	Taille pcap	Nom du logiciel malveillant	Protocole et quantité
1	CTU-IoT-Malware-Capture-34-1	34	233000	23140	121 MB	Mirai	http (12), dns(192), dhcp(2), irc (1641) et non reconnu (21290)
19	CTU-IoT-Malware-Capture-3-1	36	496000	156104	56 MB	Muhstik	dns (1), dhcp(3), irc (6), ssh(5898) et non reconnu (150195)
20	CTU-IoT-Malware-Capture-1-1	112	1686000	1008749	140 MB	Hide and Seek	http (32328), dns(1), dhcp(1) et non reconnu (1005507)

Ensuite pour les scénarios bénins La colonne avec le nom du malware a été modifiée pour spécifier le nom de l'appareil.

Tableau 3 : Ensemble du jeu de donnée du trafic normal et bénin d'objets connectés

#	Nom du jeu de donnée	Durée (heure)	Nombre de paquets	Nombre de flux d'ID Zeek	Taille fichier pcap	Objet	Protocole et quantité
1	CTU-Honeypot-Capture-7-1(somfy-01)	1.4	8276	139	2.094KB	Somfy Door Lock	dns(54), dhcp(15), ssl(1) et non reconnu par zeek(60)
2	CTU-Honeypot-Capture-4-1	24	21000	461	4.594KB	Philips HUE	http(54), dns(191), dhcp(2) et non reconnu (205)
3	CTU-Honeypot-Capture-5-1	5.4	398000	1383	381 MB	Amazon Echo	http(157), dns(521), dhcp(156), ssl(86) et non reconnu (454)

Le jeu de données contient également des étiquettes pour décrire la relation entre les flux liés à des activités malveillantes ou potentiellement malveillantes. Ces étiquettes ont été créées dans le laboratoire Stratosphère en tenant compte de l'analyse des captures de logiciels malveillants. 

Voici une brève explication sur les étiquettes utilisées pour la détection de flux malveillants basée sur l'analyse manuelle du réseau: 

Attaque : cette étiquette indique qu'il y a eu un certain type d'attaque du périphérique infecté vers un autre hôte. Nous qualifions ici d'attaque tout flux qui, en analysant sa charge utile et son comportement, tente de tirer parti d'un service vulnérable. Par exemple, une force brute sur une connexion telnet, une injection de commande dans l'en-tête d'une requête GET, etc.

Bénin: cette étiquette indique qu'aucune activité suspecte ou malveillante n'a été trouvée dans les connexions.

C&C: cette étiquette indique que le périphérique infecté était connecté à un serveur C&C. Cette activité a été détectée dans l'analyse de la capture de malware réseau car les connexions au serveur suspect sont périodiques ou l'appareil infecté télécharge des binaires à partir de celui-ci ou des commandes IRC similaires ou décodées vont et viennent.

DDoS: cette étiquette indique qu'une attaque de déni de service distribué est en cours d'exécution par le périphérique infecté. Ces flux de trafic sont détectés dans le cadre d'une attaque DDoS en raison de la quantité de flux dirigés vers la même adresse IP.

Mirai: cette étiquette indique que les connexions ont les caractéristiques d'un botnet Mirai. Cette étiquette est ajoutée lorsque les flux ont des modèles similaires à ceux des attaques Mirai connues les plus courantes. 

PartOfAHorizontalPortScan: cette étiquette indique que les connexions sont utilisées pour effectuer une analyse horizontale des ports afin de collecter des informations afin de mener d'autres attaques. Pour mettre ces étiquettes, nous nous appuyons sur le modèle dans lequel les connexions partageaient le même port, un nombre similaire d'octets transmis et plusieurs adresses IP de destination différentes.

Il y'a bien plus d'étiquettes dans le jeu de données qu'à mis à disposition le laboratoire mais celles-ci sont celles que nous avons retrouvées dans notre jeu de données.

En ce qui concerne le modèle sur l'identification des objets, un jeu de données a été obtenu en téléchargeant un projet IoT SENTINEL sur la plateforme github. Il s'agit d'un fichier contenant 27 tableaux Excel différents représentant le jeu de données d'un type d'objet différent. Tous ces objets sont simulés grâce à un système prototype dans un laboratoire IoT[16].

Ce jeu de données a été obtenu en implémentant le principe de l'empreinte digitale à partir d'une machine Linux exécutant Kali Linux. Celle-ci émule une interface Wifi sur un point d'accès, de même une interface Ethernet externe est connectée au laptop pour émuler des ports Ethernet typiquement présents dans les points d'accès. Le module de capture de paquets était implémenté en utilisant tcpdump sur les interfaces émulées.

Les paquets capturés et enregistrés étaient envoyés au module chargé des de l'empreinte digitale afin de collecter les attributs dont nous aurons besoin pour l'identification des objets.

Figure 23 : liste des objets connectés utilisés et de leurs technologies de communications correspondantes [16]

La figure ci-dessus présente les objets utilisés dans ce projet. Ainsi que les protocoles de communications utilisés. Nous pouvons voir que le wifi domine largement et que les autres technologies sont très peu utilisées.

Cependant nous avons aussi utilisé le jeu de données fourni par le laboratoire stratosphère car le jeu de données obtenu sur les objets de la figure 24 étaient déjà nettoyés.