P32 Apprentissage automatique pour la détection d’attaques par déni de services : Différence entre versions

De Wiki de Projets IMA
(PING)
(RSSI)
Ligne 165 : Ligne 165 :
  
 
=== RSSI ===
 
=== RSSI ===
 +
 +
Pour le RSSI, j'ai opté pour une mesure du delta entre deux trames. C'est à dire que si la puissance du signal reçu varie trop fortement, alors une attaque est peut-être en cours. Comment est-ce possible ? Si un émetteur est réglé sur une puissance d'envoi de 14 dBm, un autre émetteur paramétré sur un envoi de 20 dBm pourrait l'usurpé ou perturber le trafic.
 +
Lors de mes essais réalisé avec deux émetteurs (14 et 20 dBm d'envoi), j'ai noté une attaque par DoS visible lorsque l'émetteur le plus puissant est proche du récepteur.

Version du 20 janvier 2018 à 10:59

Description du projet

L'objectif de ce projet est d'automatiser la détection d'attaques par déni de services sur un réseau LoRa composé d'un émetteur, d'un récepteur ainsi que d'un capteur. Les données qui transitent dans les trames sont des températures. Une attaque peut par exemple correspondre à une variation brutale du ping, au détournement de la source et autres. Pour cela, il faut analyser les trames en transit et détecter si oui ou non elles représentent une menace. Un programme, développé en Python, sera capable d'avertir les personnes concernées sur une éventuelle attaque par déni de services. Dans un premier temps, il sera nécessaire de recenser un maximum d'angles d'attaque pour être capable de prévoir ces phénomènes. Une fois ces attaques analysées, il faudra générer un DATASET de trames avec trafic normal et avec attaques. Ce dataset sera ensuite utilisé par un réseau de neurones pour qu 'il puisse l'apprendre et être capable de classer une trame normale d'une trame à risque. En parallèle à cela, un programme séquentiel viendra renforcer la détection avec une étude du ping et de renvoi automatique des trames. Pour réaliser ce projet, je dispose de deux mois à temps plein.

Matériel emprunté

Titre
Matériel Quantité
Modules LoRa SX1276 3
STM32 3
Câbles mini-USB/USB 3

Environnement de développement

Spyder (Python IDE) : https://anaconda.org/anaconda/spyder

Mbed Compiler (Modules LoRa) : https://os.mbed.com/compiler/#nav:/;

Ubuntu

Archives GitLab : https://archives.plil.fr/rcavalie/PFE

Planning prévisionnel

Titre
Tâche Temps (jours)
état de l'art 3
prise en main des modules LoRa / IDE Mbed 2
communication / interception du trafic 3
types d'attaque 7
création du dataset 7
architecture du réseau de neurones 7
tests sur réseau 4
développement d'une application facile d'usage 3

État de l'art

Les attaques par déni de service consistent à rendre indisponible un service en augmentant la fréquence d'envoi de trames sur un récepteur. Il est également possible d'utiliser le rejet afin de renvoyer de manière continue une seule et même trame et tenter de saturer la BP d'un service. Un émetteur pirate pourrait par exemple usurper l'identité d'un émetteur du réseau et ainsi perturber les mesures de température.

Les DoS sont des attaques très répandues notamment dans le domaine de l'IoT ou de plus en plus d'objets connectés font leur apparition. Nous pouvons citer pour exemple la vulnérabilité de certains drones quant à ce type d'attaques.

Ici les paramètres à surveiller seront :

- L'identifiant de l'émetteur 
- Le ping
- La puissance d'émission 
- Le contenu de la trame qui doit toujours indiquer une température 
- Le rejet de trame

Concernant le réseau LongRange, la communication se fait par modulation des ondes radios. A partir de la board SX1276, nous allons être capable d'envoyer des paquets et de les recevoir. Ainsi, il sera possible de générer un DATASET correspondant à la classe d'un trafic normal.

Proposition de résolution

Schematic.JPG

I - Première semaine

Au cours de cette première semaine, j'ai pu obtenir plus de précisions sur le projet. Une fois le matériel récupéré à l'IRCICA, je suis passé par quelques exemples de code notamment l'exemple du Ping-Pong entre deux modules LoRa.

lien : https://github.com/Lora-net/LoRaMac-node

documentation sur la librairie SX1276 par Mbed (C++) : https://os.mbed.com/users/GregCr/code/SX1276Lib/docs/tip/classRadio.html#a5a96290956c521510d1bd5a7c1ac21b9

En étudiant la valeur des registres et les paramètres d'émission et de réception, je suis parvenu à créer un code capable d'émettre une trame de la forme suivante :

Trame format.JPG

Un identifiant est associé à chaque émetteur et à chaque récepteur pour renforcer une certaine sécurité lors de la réception. Je souhaiterais ajouter un bit de parité dans la trame afin de vérifier si le message a été correctement reçu ou non.

Une fois les paramètres définis et la radio configurée, j'ai été capable d'émettre mes trames toutes les 10 secondes (en émission continue) à partir de la fonction Send :

Send function.JPG

Pour la partie réception, les paramètres restent identiques. Je vérifie le contenu du buffer chaque seconde. Si celui-ci est plein alors je compare le contenu de son entête à savoir les 11 premières cases du tableau pour savoir si le récepteur souhaite lire les trames de l'émetteur (sécurité).

La lecture radio en continue se fait par la fonction Rx :

Recept function.JPG

Si tel est le cas, alors la trame est lue toutes les 1 seconde.

26829710 555808894769008 128433563 o.png

Il y a donc un fichier emetteur.cpp et recepteur.cpp pour la réception et l'émission. Chaque fichier est compilé avec la librairie SX1276 via le Mbed Compiler. Un fichier binaire permet ensuite de flasher le microcontrôleur.

Pour la température, je vais générer des valeurs aléatoires afin de simuler au mieux le comportement d'un capteur utilisé en industrie. L'objectif va être d’enregistrer ces trames dans un fichier .csv ou .txt pour les utiliser lors d'un apprentissage profond.

Le code est assez générique et vous permettra d'adapter les trames selon votre application. Il sera juste nécessaire de modifier les constantes en ce qui concerne la taille du Buffer : BUFFER_SIZE.

II - Seconde semaine

Au cours de cette semaine, j'ai travaillé sur la création des datasets lors des séances mais également sur l'interface graphique python permettant d'afficher les données utiles à la surveillance du trafic.

J'ai donc créé un fichier python appelé recorder.py qui permet d'enregistrer :

- les trames normales 
- le ping en trafic normal
- le ping en attaque
- le rssi en temps normal
- le rssi en attaque

Pour cela, j'écoute en boucle le port série de COM4 de ma machine Windows et enregistre 3000 individus pour chaque dataset. La trame correspond à la première ligne lue avec le serial python. La puissance de réception de la trame arrive en seconde ligne.

Lecture port.JPG

Le dataset des trames est un simple enregistrement de la première ligne reçue. La trame est écrite dans un fichier trame_norm.csv. Les trames en elles-mêmes ne permettent pas de réaliser une classification entre un trafic normal et une attaque DoS. Je me suis donc plus penché sur le ping et sur le rssi.

Chaque élément est enregistré avec son numéro de classe : 0 pour normal, 1 pour attaque. L'utilité de cette démarche sera expliquée lors de la phase d'apprentissage du réseau de neurones.

PING

Pour procéder à l'enregistrement du ping normal, j'ai travaillé avec un envoi toutes les 1000 ms et une réception toutes les 300 ms. Jusque là, rien d'anormal. En descendant petit à petit la temporisation dans ma fonction d'envoi, j'ai noté des mauvaises réception de trames et une perturbation importante du trafic en dessous de 100 ms. J'ai donc réalisé toutes mes mesures de ping_attaque.csv avec un envoi de 50 ms et une réception de 300 ms.

Pour mesurer le ping j'ai utilisé la librairie time et ai fait la soustraction entre le temps d'arrivé d'un première trame et de la seconde.

L'enregistrement se fait de la même manière que pour les trames.

Voici la représentation de la population du dataset après enregistrement.

Dataset ping.png

Il est possible de distinguer clairement deux classe. La classe 0 avec un ping normal et la classe 1 avec un ping fortement élevé par rapport au trafic que nous jugeons "normal" pour notre application. Cette représentation est très importante car elle permet de comprendre comment le réseau fera la distinction entre nos deux classes (normale et d'attaque). Il est réellement important de fournir un dataset de qualité avec des valeurs qui soient les plus uniformes possible dans leurs classes respectives.

RSSI

Pour le RSSI, j'ai opté pour une mesure du delta entre deux trames. C'est à dire que si la puissance du signal reçu varie trop fortement, alors une attaque est peut-être en cours. Comment est-ce possible ? Si un émetteur est réglé sur une puissance d'envoi de 14 dBm, un autre émetteur paramétré sur un envoi de 20 dBm pourrait l'usurpé ou perturber le trafic. Lors de mes essais réalisé avec deux émetteurs (14 et 20 dBm d'envoi), j'ai noté une attaque par DoS visible lorsque l'émetteur le plus puissant est proche du récepteur.