IMA4 2017/2018 P3 : Différence entre versions
(→Semaine 2) |
(→Semaine 2) |
||
Ligne 240 : | Ligne 240 : | ||
A l'aspect d'utilisation, la mode AT est souvent utilisé à la communication 'un point à un point', par contre, la mode API est souvent utilisé à la communication 'multiple point à multiple point', est les message de la mode API est plus facile à traité par l'ordinateur. Et maintenant, j'ai 4 arduinos, donc je chois la mode API à communiquer. | A l'aspect d'utilisation, la mode AT est souvent utilisé à la communication 'un point à un point', par contre, la mode API est souvent utilisé à la communication 'multiple point à multiple point', est les message de la mode API est plus facile à traité par l'ordinateur. Et maintenant, j'ai 4 arduinos, donc je chois la mode API à communiquer. | ||
− | <center><include iframe src="https:// | + | <center><include iframe src="https://www.youtube.com/embed/uhft9i8MHr8" width="320px" height="320px" frameborder="0" scrolling="yes"/></center> |
− | |||
==Semaine 3== | ==Semaine 3== |
Version du 8 mai 2018 à 01:39
Sommaire
- 1 Présentation générale
- 2 Analyse du projet
- 3 Préparation du projet
- 4 Réalisation du Projet
- 5 Documents Rendus
Présentation générale
Description
Mon projet est suivant:
Le développement de l'Internet des Objets amène de nouveaux problèmes en terme de sécurité. En effet, ces objets, en général petits, n'embarquent que très peu d'éléments de sécurisation. Par ailleurs, leur mise à jour est souvent très difficile voire impossible. Un défaut de sécurité sur ce type d'objets permet à des utilisateurs malveillants de réaliser des attaques de grande envergure, du fait du grand nombre d'objets (par exemple ici).
Comme il est difficile de sécuriser l'objet par lui même (coût élevé, performances des objets limitées, ...), il est nécessaire de trouver d'autres solutions. Pour cela, nous proposons de développer :
1.une plateforme d'écoute sur les bandes ISM 868 MHZ, 2,4 GHz essentiellement ;
2.un "modèle" normal correspondant à un trafic de données non malveillant ;
3. différents scénarios d'attaques et leurs signatures associées.
Objectifs
Le but du projet est donc de réaliser un système permettant de récupérer et analyser les messages sous le protocole zigbee. Et il peut donner des signaux et messages indiquant si le réseau est sous l'attaque et associer le scénario et l'attaque. Le projet a pour but de récupérer et analyser les messages du réseau d'objet, et après, donner une manière d'indiquer si le réseau subit l'attaque. J'ai choisi le zigbee comme protocole de réseau.
1. Construire la communication avec quelques arduino et Xbee par le protocole zigbee.
2. Faire communiquer les arduino et récupérer les messages, et après, selon les messages, chercher une définition de la commmunication normale.
3. Attaquer le réseau par 'DDos' , 'Replay'.
4. Analyser les messages, et chercher les caractères correspondant aux différentes attaques.
5. Selon les analyses, donner une solution à indiquer si le réseau subit l'attaque.
6. Associer les attaques et les scénarios
Definition des Attaques
Doss[1]
Une attaque par déni de service (abr. DoS attack pour Denial of Service attack en anglais) est une attaque informatique ayant pour but de rendre indisponible un service, d'empêcher les utilisateurs légitimes d'un service de l'utiliser. À l’heure actuelle la grande majorité de ces attaques se font à partir de plusieurs sources, on parle alors d'attaque par déni de service distribuée (abr.DDoS attack pour Distributed Denial of Service attack). Il peut s'agir de :
l’inondation d’un réseau afin d'empêcher son fonctionnement ; la perturbation des connexions entre deux machines, empêchant l'accès à un service particulier ; l'obstruction d'accès à un service pour une personne en particulier ; également le fait d'envoyer des milliards d'octets à une box internet. L'attaque par déni de service peut ainsi bloquer un serveur de fichiers, rendre impossible l'accès à un serveur web ou empêcher la distribution de courriel dans une entreprise.
L'attaquant n'a pas forcément besoin de matériel sophistiqué. Ainsi, certaines attaques DoS peuvent être exécutées avec des ressources limitées contre un réseau de taille plus importante et plus moderne. On appelle parfois ce type d'attaque « attaque asymétrique » en raison de la différence de ressources entre les protagonistes.
Les attaques en déni de service se sont modifiées au cours du temps (voir historique).
Tout d'abord, les premières n'étaient perpétrées que par un seul « attaquant » ; rapidement, des attaques plus évoluées sont apparues, impliquant une multitude de « soldats ». On parle alors de 'DDoS' (distributed denial of service attack). Certains pirates informatiques se sont spécialisés dans la « levée » d’armées de « zombies », qu’ils peuvent ensuite louer à d’autres personnes ou groupes malveillants pour attaquer une cible particulière. Avec la forte augmentation du nombre d’échanges commerciaux sur Internet, le nombre de chantages au déni de service a très fortement progressé.
Replay Attacks (Attaque par rejeu)[2]
Une attaque par rejeu (en anglais, replay attack ou playback attack) est une forme d'attaque réseau dans laquelle une transmission est malicieusement répétée par un attaquant qui a intercepté la transmission. Il s'agit d'un type d'usurpation d'identité.
Exemple d'attaque par rejeu:
L'exemple suivant présente une attaque par rejeu où Ève usurpe l'identité d'Alice en volant son mot de passe. Supposons qu'Alice veuille communiquer avec Bob. Pour être certain de communiquer avec Alice, Bob lui demande son mot de passe, qu'Alice lui envoie (possiblement après l'avoir chiffré avec une fonction de hachage cryptographique). Pendant ce temps, Ève écoute la conversation et enregistre le mot de passe (ou le résultat de l'application de la fonction de hachage sur le mot de passe, ce résultat est souvent appelé digest). Une fois l'échange terminé, Ève contacte Bob en prétendant qu'elle est Alice. Quand Bob lui demande son mot de passe pour vérifier son identité, Ève renvoie le mot de passe (ou son digest) qu'elle avait préalablement intercepté.
Les attaques par rejeu ne sont pas limitées au vol de mot de passe, ce genre d'attaque peut se faire dans d'autres situations. Une autre attaque permettant d'entrer dans un véhicule au moyen d'une attaque par rejeu est décrite plus bas dans cet article.
Analyse du projet
Positionnement par rapport à l'existant
L'idée du projet est de construire un système de IOT , et essayer d'attaquer le réseau avec 'Dos' et 'Replay Attack', et après, récupérer les messages de IOT, analyser si il est sur des attaques.Si oui, on associe les scénarios et les attaques.
Forescout et Bitdefender sont deux entreprises célèbre dans le domaine de sécurité de IOT, ils utilisent quelques astuces pour identifier rapidement l’utilisateur, le propriétaire, le système d’exploitation, la configuration de l’appareil, les logiciels, les services, l’état des patchs et la présence d’agents de sécurité. Leur produits peuvent savoir si la périphérie est dangereux selon leur base de donnée des caractères des attaques du IOT. Ils peuvent aussi offrir les service d'afficher tous les information de périphérie connectés au réseau pour aider leur client à observer et contrôler le réseau. Leur produit est bon, mais ils ne peuvent supporter que les protocoles: wifi , bluetooch, 4G, Ethernet, IP etc.
Par contre,rapport à mon projet, mon produit a pour le but de la sécurité de IOT dont protocol est Zigbee et il surveille le réseau de IOT en à deux aspects. Un est la surveillance du contenu de messages envoyé dans le réseau. L'autre est la surveillance de la caractère physique -- puissance du channel.
Analyse du premier concurrent
Forescout
ForeScout peut identifier les appareils Internet des objets (IoT), par example les ordinateurs,
les tablettes ou smartphones non gérés, les contrôler et organiser une réponse à l'échelle
du système.
Les spécialités principales sont:
1. Identifier les appareils et les détails indétectables par d'autres systèmes
2. Contrôler l'accès, refuser le chaos
3. Organiser la sécurité à l'échelle du système
Il a une grande base de donnée de sécurité qui lui aide à trouver les IOT vulnérable,
dangerous ou qui a des hautes risques. Son advantage principale est ce qu'il peut
détecter, identifier les IOT qui connecte au réseau et donner leur détails.
La façon de l'utiliser est suivant:
Analyse du second concurrent
Bitdefender BOX
BitDefender Box est une solution de protéger le IOT en l'autre manière,
Elle peut aussi detecter les apparails connectés au réseau, mais son acte
principal de protection est de dentifiez les failles de sécurité et les risques
sur le réseau, Lorsqu'elle détecte quelque chose, elle passe à l'action. BOX
fait correspondre les informations collectées à partir de vos appareils avec
des bases de données de vulnérabilités en ligne, avant de fournir un rapport
détaillé de l'opération. Elle fournit également des conseils sur la manière
de gérer et de sécuriser votre réseau, en fonction des vulnérabilités détectées.
Scénario d'usage du produit ou du concept envisagé
Mon produit est construit par un telsob. Il est utilisé à surveiller le IOT de Zigbee pour détecter les attaques de 'Dos' et 'Replay Attack'. Il peut récupère des trames du IOT et mesurer la puissance du channel. La utilisation est sample qu'on insère un telosb à pc ou l'autre appareil qui a le serial et peut lancer le scénario de python, après, lance mon scénario de python. Mon Produit offre des fonction: mesurer le nombre moyen de message dans un réseau et la puissance moyenne dans une channel, détecter l'attaque de Dos avec 2 manières: surveillance le nombre moyen de message, et la puissance moyenne dans une channel. Et il offre aussi la fonction pour détecter l'attaque de 'Replay Attack'.
L'idée des trois manière des surveillances est suivant:
Surveillance du nombre moyen de message
Quand le réseau est sur attaque de Dos, les appareils du IOT envoient plus de messages que quand il n'est pas sous attaque. Donc on peut d'abord mesurer le nombre moyen de message quand il n'est pas sous attaque, après, on entend les messages dans le réseau et les compte, si le nombre moyen de message que on compte est supérieur que le nombre moyen de message qu'on mesure d'abord, c'est à dire que le réseau est sous attaque de Dos.
Surveillance de la puissance du channel
L'idée de la manière est comme dont Surveillance du nombre moyen de message. Quand le réseau est sur attaque de Dos, les appareils du IOT envoient plus de messages que quand il n'est pas sous attaque, donc la puissance de channel va augmenter. Donc on peut d'abord mesurer la puissance du channel quand il n'est pas sous attaque, après, on mesure la puissance du channel, si la puissance du channel que on mesure est supérieur que le la puissance du channel qu'on mesure d'abord, c'est à dire que le réseau est sous attaque de Dos.
Détection l'attaque de 'Replay Attack
On suppose que chaque message dans le réseau apporte une identité spéciale qui change avec le temps, il n'est pas possible que il y a deux même message dans le réseau. donc mon produit offre une méthode à obtenir les message et les enregistrer, chaque fois il récupère un message, il va vérifier si le nouveau message est dans la liste de message enregistré, sinon, c'est à dire que le réseau n'est pas sous attaque, or, il est sur l'attaque de 'Replay Attaque'.
Réponse à la question difficile
Quel est le matériel ?
Je utilise 4 Arduino Uno, 4 Xbee Adapteur, 4 Arduino_xbee_shield, 4 Xbee, 1 telosb.
Quel est le protocole ?
Je utilise Zigbee comme le protocol de IOT.
L'acte d'analyser les donner?
Je utilise la surveillance du nombre moyen de message, la surveillance de la puissance du channel et la détection l'attaque de 'Replay Attack à analyser pour juger si le réseau est sous attaque.
Préparation du projet
Cahier des charges
Choix techniques : matériel et logiciel
4 Arduino Uno
1 Xbee Adapteur
4 Arduino_xbee_shield
4 Xbee
1 telosb
4 piles extérieurs
Logiciel:
Python, Goodfet.
Liste des tâches à effectuer
1. Construire un IOT avec 3 arduino sous le protocole zigbee.
2. Faire communiquer les arduino et récupérer les messages, et après, selons les messages, chercher une définition de 'commmunication normale'.
3. Attaquer le réseau par Dos, 'Replay Attack'.
4. Analyser les messages, et chercher les caractères correspondant à la façon d'attaque.
5. Selon les analyses, donner une solution à indiquer si le réseau subit l'attaque.
Calendrier prévisionnel
Réalisation du Projet
Feuille d'heures
Tâche | Prélude | Heures S1 | Heures S2 | Heures S3 | Heures S4 | Heures S5 | Heures S6 | Heures S7 | Heures S8 | Heures S9 | Heures S10 | Total |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Analyse du projet | 30 | 10 | 10 | 12 | 10 | 14 | 15 | 13 | 12 |
Prologue
Semaine 1
J'ai obtenu les matériaux et construit un IOT simple qui contenait 4 arduinos avec Xbee. J'étudie la Protocol de Xbee, et je comprends maintenant comment configurer les Xbee et utiliser Xbee à faire communication avec l'outil XCUT[3]. Xbee a deux mode de communication, API et AP. Je ne comprends pas très bien que quels est la différence entre les deux, et comment écrire le code à faire communiquer les Xbees. Après, je vais étudier l'utilisation des deux mode de communication et étudier comment les controler avec ma propre programmation.
Semaine 2
Je comprends la différence de la mode AT et API. Quand on utile Xbee en mode AT, on peut juste recevoir de l'autre Xbee dont Chanel, PIND, et l'adresse de réseau sont tous correspondant à lui, c'est à dire que une Xbee ne puet recevoir que le message d'une Xbee dont adresse de destination est même que son propre adresse.
Je comprends aussi que chaque Xbee a deux adresse, une est l'adresse de réseau, l'autre est l'adresse de MAC, on peut utiliser quelconque à faire une communication. L'adresse de réseau est 16bit, par contre, l'adresse de MAC est 64bit. L'adresse de réseau peut être changé, mais l'adresse de MAC est fixé.
A l'aspect d'utilisation, la mode AT est souvent utilisé à la communication 'un point à un point', par contre, la mode API est souvent utilisé à la communication 'multiple point à multiple point', est les message de la mode API est plus facile à traité par l'ordinateur. Et maintenant, j'ai 4 arduinos, donc je chois la mode API à communiquer.
Semaine 3
J'ai chercher les arts d'attaquer le IOT avec DDos, et je vais attaquer le IOT par 2 façon, le premier est d'utiliser un arduino à envoyer très fréquement les trames à un arduino de le IOT, et tester si le IOT se communique normalement, si non, de quelle fréquence, elle n'est pas fonctionne normalement. L'autre façon est d'envoyer les trame avec très grande de taille, et tester si le IOT se communique normalement, si non, à quel taille de trame, elle n'est pas fonctionne normalement.
Semaine 4
J'ai complété la communication de IOT. La communication est simple, mais practical: il y a 3 arduino(on va s'appleler A,B,C à la suite) avec xbee dans le réseau, dont 3 se communiquent, une est comme le coordinateur, les autres 2 sont comme end_point devices. Le fonctionnement est: 1. A envoie un message 'allumer B' à B, et reste allumé 3 seconds, après il éteint 3 seconds, et envoie un message 'allumer B' à B. 2. Quand B récupère 'allumer B' de A, il va allumer le Led, et après, envoyer 'allumer C à C. Quand B récupère 'éteindre B' de A, il va éteindre le Led, et après, envoyer 'éteindre C à C. 3. Quand c récupère 'allumer c' de B, il va allumer le Led. Quand c récupère 'éteindre c' de B, il va éteindre le Led, et après, envoyer 'éteindre C à C.
Média:Communication 3 arduino.mp4
source:
Arduino A: Fichier:Arduino A.zip
Arduino B: Fichier:Arduino B.zip
Arduino C: Fichier:Arduino C.zip
Semaine 5
J'ai trouvé un outil qui s'appelle Killerbee. Il est très utile à attaquer le réseau de Zigbee, et on peut aussi l'utiliser à surveiller le réseau, il offre la méthode de 'sniffer' pour récupérer tous les message dans un channel(par contre, xbee ne peut que récupérer les message spécialement à un address), mais si on veut l'utiliser, on dois utiliser les hardware spéciale: ApiMote v4beta (and v3), Texas Instruments CC2530/1 EMK, MoteIV Tmote Sky, TelosB mode ou Atmel RZ RAVEN USB Stick. Mais je n'ai pas des hardware, donc j'ai essayer à implémenter killerbee à Xbee, mais j'ai échoué, le plus grand problème est que xbee ne peut que récupérer les message spécialement à un address, donc il ne peut pas 'sniffer'. Et j'ai demandé à professeur un hardware qui peut implémenter killerbee.
Le github de killerbee: [4]
Semaine 6
J'ai pris un telosb de Professeur Vantroys. et j'ai écrit deux scénario de python à mesurer le RSSI et sniffer les message. la source est suivante:
- pour fonctionner on doit utiliser les packets de killerbee: GoodFETCCSPI.py, GoodFET.py et dev_telosb.py, mais j'ai changé quelque chose de dev_telosb.py pour faciliter à actualiser quelques fonction.
- Le protocol de message de telosb est different que dont xbee, et j'ai écrit un classe parser_trame pour l'analyse syntaxique.
dev_telosb.py: Fichier:Protecter.zip
Semaine 7
J'ai écrit les programmation à mesurer la puissance du channel et compter le nombre moyen de message, et les fonctions à détecter les attaque de Dos et 'Replay Attack'.
Source: Fichier:Protecter2.zip
Semaine 8
J'ai tester ma programmation et débugger, les fonctions de détection de Dos avec compter le nombre moyen de message et la détection de 'Replay Attaque' ont finctionné bien, mais la détection de Dos avec mesure de puissance du channel n'ai fonctionne pas bien, parce que je ne pouvais pas lire correctement les valeur de RSSI. Après je vais fixer le problème.