IMA4 2017/2018 P3 : Différence entre versions
(→Semaine 2) |
|||
(79 révisions intermédiaires par un autre utilisateur non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
+ | <include nopre noesc src="/home/pedago/pimasc/include/video-IOTSecurity-iframe.html" /> | ||
__TOC__ | __TOC__ | ||
<br style="clear: both;"/> | <br style="clear: both;"/> | ||
Ligne 18 : | Ligne 19 : | ||
==Objectifs== | ==Objectifs== | ||
− | Le but du projet est | + | Le but du projet est à réaliser un système permettant de récupérer et analyser les package sous le protocole zigbee. Après l’analyse, il peut indiquer si le réseau est sous l'attaque et associer le scénario et l'attaque. |
− | Le projet a pour but de | + | Le projet a pour but de construire un réseau d’objet’, attaquer le réseau et récupérer et surveiller le réseau. Je chois le zigbee comme le protocole de réseau à construir le réseau d'objet. |
− | 1. Construire la communication avec quelques arduino et Xbee par le protocole zigbee. | + | 1. Construire la communication avec quelques arduino et Xbee par le protocole zigbee. |
− | + | ||
− | 2. Faire communiquer les arduino et récupérer les messages | + | 2. Faire communiquer les arduino et récupérer les messages. |
− | + | ||
− | 3. Attaquer le réseau par 'DDos' , 'Replay'. | + | 3. Attaquer le réseau par les manière : 'DDos' , 'Replay'. |
− | + | ||
− | 4. Analyser les messages | + | 4. Analyser les messages et chercher les caractères de la communication sans attaque et la communication sous attaque. |
− | + | ||
− | 5. Selon les analyses, donner une solution à indiquer si le réseau subit l'attaque. | + | 5. Selon les analyses, donner une solution à indiquer si le réseau subit l'attaque. |
− | + | ||
6. Associer les attaques et les scénarios | 6. Associer les attaques et les scénarios | ||
− | + | ||
===Doss[https://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service]=== | ===Doss[https://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service]=== | ||
− | 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. | + | 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’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'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. | 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. | ||
+ | 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é. | ||
− | + | Au début Dos est juste pour les réseau de l’ordinateur, mais maintenant de plus en plus des attaques Dos sont utilisé contre le réseau d’objet. Une attaque célèbre est l’attaque de ‘Mirai’. | |
+ | [[Fichier:DoSAttacks.jpg]] | ||
− | |||
− | |||
===Replay Attacks (Attaque par rejeu)[https://fr.wikipedia.org/wiki/Attaque_par_rejeu]=== | ===Replay Attacks (Attaque par rejeu)[https://fr.wikipedia.org/wiki/Attaque_par_rejeu]=== | ||
Ligne 68 : | Ligne 65 : | ||
'''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. | '''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 protocole 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 chaîne. | |
− | Par contre,rapport à mon projet, mon produit a pour le but de la sécurité de IOT dont | + | ET il est facile à utiliser. Juste insérer le telosb à l’ordinateur ou rasperry et lancer un script de python. |
==Analyse du premier concurrent== | ==Analyse du premier concurrent== | ||
Ligne 109 : | Ligne 106 : | ||
BitDefender Box est une solution de protéger le IOT en l'autre manière, | BitDefender Box est une solution de protéger le IOT en l'autre manière, | ||
− | Elle peut aussi detecter les | + | Elle peut aussi detecter les appareils connectés au réseau, mais son acte |
principal de protection est de dentifiez les failles de sécurité et les risques | principal de protection est de dentifiez les failles de sécurité et les risques | ||
Ligne 125 : | Ligne 122 : | ||
==Scénario d'usage du produit ou du concept envisagé== | ==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 | + | 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 la distribution de 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'. |
Ligne 160 : | Ligne 157 : | ||
==Cahier des charges== | ==Cahier des charges== | ||
− | ==Choix techniques : | + | ==Choix techniques : matériaux et logiciel== |
4 Arduino Uno | 4 Arduino Uno | ||
Ligne 210 : | Ligne 207 : | ||
{| class="wikitable" | {| class="wikitable" | ||
− | !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 | + | !Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Heures S12 !! Heures S13 !! Total |
|- | |- | ||
− | | | + | | Choix du matériel |
− | | | + | | 8H |
− | | | + | | |
− | | | + | | |
− | | | + | | |
− | |||
| | | | ||
| | | | ||
| | | | ||
+ | | | ||
+ | | 3H | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | Analyse du projet + préparation oral | ||
+ | | 6H | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | Etudier le protocol Zigbee et Xbee | ||
+ | | | ||
+ | | 8H | ||
+ | | 9H | ||
+ | | 3H | ||
+ | | 2H | ||
+ | | | ||
+ | | | ||
+ | | 2H | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | Programmation sur arduino à construire une communication du réseau d'objet | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | 8H | ||
+ | | 8H | ||
+ | | 8H | ||
+ | | 6H | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | Etudier à attaquer le réseau d'objet | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | 6H | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | 3H | ||
+ | | 3H | ||
+ | | 1H | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | Etudier le telosb | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | 7H | ||
+ | | 5H | ||
+ | | 6H | ||
+ | | 2H | ||
+ | | 1H | ||
+ | | | ||
+ | |- | ||
+ | | Coder programmation à surveiller le réseau d'objet | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | 10H | ||
+ | | 10H | ||
+ | | 2H | ||
+ | | | ||
+ | |- | ||
+ | | Debugger et tester les programmation | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | 4H | ||
+ | | 2H | ||
+ | | 3H | ||
+ | | 2H | ||
+ | | 1H | ||
+ | | 1H | ||
+ | | 2H | ||
+ | | | ||
+ | |- | ||
+ | | Wiki | ||
+ | | | ||
+ | | 1H | ||
+ | | 4H | ||
+ | | 1H | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | 1H | ||
+ | | 1H | ||
+ | | | ||
+ | | | ||
+ | | 1H | ||
+ | | 10H | ||
+ | | | ||
|} | |} | ||
Ligne 230 : | Ligne 366 : | ||
==Semaine 1== | ==Semaine 1== | ||
− | J'ai obtenu les matériaux et construit un IOT simple qui contenait 4 arduinos avec Xbee. | + | 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[https://www.digi.com/products/xbee-rf-solutions/xctu-software/xctu]. 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. |
− | + | [[Fichier:XCTU.jpg]] | |
==Semaine 2== | ==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. | ||
− | + | <center><include iframe src="https://www.youtube.com/embed/uhft9i8MHr8" width="320px" height="320px" frameborder="0" scrolling="yes"/></center> | |
==Semaine 3== | ==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 | + | 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équemment 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. |
+ | |||
+ | Pour le réaliser, je trouve 2 manière. La première est à utiliser le logiciel XCTU qui nous donne le API à controler le trame, la destination, la frequence etc. Le deuxième manière est à utiliser le package de python de Xbee[http://xbplib.readthedocs.io/en/latest/getting_started_with_xbee_python_library.html]. On peut écrire la programation à controler les trame. | ||
+ | |||
+ | <center><include iframe src="https://www.youtube.com/embed/LZTDQbQ1uCc" width="320px" height="320px" frameborder="0" scrolling="yes"/></center> | ||
+ | |||
+ | Le code de Python à faire le Dos:[[Fichier:Dos avec python.zip]] | ||
+ | |||
+ | ==Semaine 4 - 5== | ||
+ | J'ai complété la communication de IOT. La communication est simple, mais practical: il y a 3 arduino(on va s'appeler 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. | ||
+ | |||
+ | <center><include iframe src="https://www.youtube.com/embed/xViIyk8oXuY" width="320px" height="320px" frameborder="0" scrolling="yes"/></center> | ||
+ | |||
+ | |||
+ | Pour coder la programmation, j'ai utilisé un package de Xbee[https://github.com/andrewrapp/xbee-arduino] | ||
+ | |||
+ | source: | ||
+ | |||
+ | Arduino A: | ||
+ | [[Fichier:Arduino_A.zip]] | ||
+ | |||
+ | Arduino B: | ||
+ | [[Fichier:Arduino_B.zip]] | ||
+ | |||
+ | Arduino C: | ||
+ | [[Fichier:Arduino_C.zip]] | ||
+ | |||
+ | ==Semaine 6 - 7== | ||
+ | En cette semaine, j'essayais à trouver une manière à 'sniffer' les trames de communication de IOT. Au début, je voulais utiliser Xbee comme le 'sniffeur', j'ai trouvé un package de Xbee qui est écrit de Python[http://xbplib.readthedocs.io/en/latest/index.html]. Il donne des fonctions, par exemple, avec lui, on peut configurer les paramètres de Xbee(adresse de réseau, PIND, Channel, mot de passe ect, le changement de mode API et AP, etc), afficher tous les appareils dans un réseau et obenir leur configuration, et envoyer et recevoir les message entre le réseau. Mais, quand je l'ai utilisé, j'ai trouver un problème que chaque Xbee peut recevoir seulement les trames dont destination est lui. Après, j'ai trouvé une solution que j'ai afficher tous les adresse de appareil du réseau, et j'ai changé continuellement l'adresse de source de mon Xbee aux adesse et récupérer les messages à l'adresse, et après, je peux sniffer le réseau. Mais, quand je l'ai fait, j'ai trouvé un problème que quand le Xbee a changé son propre adresse, il a pris près que 0.3 second qui a causé la perte de message. Donc ça n'a fonctionné pas. | ||
+ | Après, je vais chercher l'autre méthode à sniffer le réseau. | ||
+ | |||
+ | ==Semaine 8== | ||
+ | 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. | ||
+ | |||
+ | J'ai étudier la source de Killerber[https://github.com/riverloopsec/killerbee]. Il donné les fonctionne de 'sniffer', attaque de DDos, attaque de répète, et il peut obtenir voire le mot de passe du réseau. | ||
+ | |||
+ | Le github de killerbee: | ||
+ | [https://github.com/riverloopsec/killerbee] | ||
+ | |||
+ | ==Semaine 9== | ||
+ | J'ai pris un telosb de Professeur Vantroys. Selon la notice de Xbee, j'ai télechargé le firmware de xbee au telosb, mais, il a échoué: | ||
+ | [[Fichier:Telecharge error.jpeg]] | ||
+ | |||
+ | Après, j'ai cherché sur internet et j'ai trouvé que le problème était à cause de la version de goodfet. donc j'ai changé le fichier de goodfet et il a marché, quelques détail est sur la site suivante[https://github.com/riverloopsec/killerbee/issues/82] | ||
+ | |||
+ | Et j'ai essayé les packets d'outil de killerbee, par exemple, 'sniffer', 'Ddos' etc, mais, ça n'a fonctionné pas. En fait, le telosb n'a récupéré ou envoyé rien avec les l'outils donné. Je ne comprends pas pourquoi il n'a fonctionné pas, je vais le cheche à la semaine dernière. | ||
+ | |||
+ | ==Semaine 10 - 11== | ||
+ | Je n'ai trouvé pas encore pour quoi les utils de killerbee n'a fonctionné pas, mais, j'ai trouvé que avec le package 'goodfet', je peux sniffer le réseau. Donc j'ai écrit une programmation pour sniffer le réseau, et j'ai trouvé que le format du trame n'était pas identité que le format du trame de Xbee, donc je pense que le problème est à cause du format de trame différent. | ||
+ | |||
+ | Un exempledu format de trame de telosb est suivant: | ||
+ | |||
+ | 0x17 -> length (总字节数 - 1) | ||
+ | |||
+ | 0x61 -> la tête de trame(LOW) | ||
+ | |||
+ | 0x88 -> la tête de trame(HIGH) | ||
+ | |||
+ | 0xd -> frameID(不确定, 它随报文顺序,而增加) | ||
+ | |||
+ | 0x34 -> PIND(LOW) | ||
+ | |||
+ | 0x12 -> PIND(HIGH) | ||
+ | |||
+ | 0x3 -> Addr16 of sender (LOW) | ||
+ | |||
+ | 0x0 -> Addr16 of sender (HIGH) | ||
+ | |||
+ | 0x1 -> Addr16 of receiver (LOW) | ||
+ | |||
+ | 0x0 -> Addr16 of receiver (HIGH) | ||
+ | |||
+ | 0xeb -> numeno des trames envoyés(LOW) | ||
+ | |||
+ | 0x0 -> numeno des trames envoyés(LOW) | ||
+ | |||
+ | 0x68 |- | ||
+ | |||
+ | 0x65 |- | ||
+ | |||
+ | 0x6c |- | ||
+ | |||
+ | 0x6c |- | ||
+ | |||
+ | 0x6f |- -> data | ||
+ | |||
+ | 0x20 |- | ||
+ | |||
+ | 0x77 |- | ||
+ | |||
+ | 0x6f |- | ||
+ | |||
+ | 0x72 |- | ||
+ | |||
+ | 0x6c |- | ||
+ | |||
+ | 0xe7 -> checkSum(LOW) | ||
+ | |||
+ | 0xa9 -> checkSum(HIGH) | ||
+ | |||
+ | |||
+ | Pour obtenir les data correctement, j'ai écrit une classe 'parser_trame' à alalyser les trames et une classe 'Protecter' à analyser les datas et juger s'il y une attaque, dans cet parti, je vais utiliser 2 détection, un est contre Ddos, et l'autre est contre l'attaque 'répète'. Et j'ai écrit un démo, il a fonctionné pas mal. | ||
+ | |||
+ | J'ai deux algorithmes de la détection de l'attaque de Ddos. | ||
+ | Le premier est à compter le numéro moyen de trame dans une période, si la valeur est supérieur à la valeur moyen, c'est à dire qu'il y une attaque de Ddos. C'est logic, parce que en géneral, la charactère le plus marqué de l'attaque DDos est que le nombre du message une plus que le nombre du message en général. | ||
+ | |||
+ | Le deuxième est à mesurer la puissance du channel, je récupère la valeur de 'rssi'[https://fr.wikipedia.org/wiki/RSSI] du Xbee pour évaluer la puissance, la relation entre rssi et la puissance pour le telosb est environ: 'puissance = rssi -40'. Si la puissance obtenu est superieur à la puissance moyan sans attaque, c'est à dire qu'il y a une attaque. | ||
+ | |||
+ | Avant de mesurer, je vous donne aussi deux fonction pour évaluer la valeur du nombre de message et de la puissance moyen sans attaque. | ||
+ | |||
+ | La détection de l'attaque de 'répète' est basé en une hypothèse que pour tous mes trame, il y a une signe correspondante au temps, ainsi on tous les trames vont être diffirent même si quelsques trames ont les mème data. | ||
+ | |||
+ | Après, il récupère continuellement les trames dans le réseau, et les transforme au format de Hash[https://en.wikipedia.org/wiki/Hash_function] et les stocker. Après chaque fois qu'il récupère un trame, il va le transformer au format de Hash et vérifier s'il il y a un valeur dont hash est mème, si oui, c'est à dire qu'il y a une attaque de 'répète'. Mais, il y a un cas spécial que un appareil veut envoyer un message à l'autre appareil, mais, il est échoué, donc il répète une fois le même data(avec même signe), en fait, c'est pas l'attaque. Donc j'ai ajouté un délais, par exemple 5s, si il y a un message dont Hash est existé dans la base de donné mais l'intervalle entre le temps ou les 2 Hash sont récupéré est intérieur à 5s, il va penser qu'il n'y a pas d'attaque. | ||
+ | |||
+ | <center><include iframe src="https://www.youtube.com/embed/Yb_FpyFKsgo" width="320px" height="320px" frameborder="0" scrolling="yes"/></center> | ||
+ | |||
+ | dev_telosb.py: | ||
+ | [[Fichier:protecter.zip]] | ||
+ | |||
+ | |||
+ | Pour la partie de mesurer la puissance du channel, ça ne fonction pas bien, quand le telsob reçoit un trame, le rssi est environ -80, or la valeur est environ 120, et on ne peut pas juger s'il y a une attaque selon lui. Je ne comprends pas c'est pourquoi. | ||
+ | |||
+ | ==Semaine 12== | ||
+ | J'ai fait une démonstration à Professeur Redon et Professeur Vantroys, et Nous avons fait une communication sur le projet, Monsieur Vantroys m'a dit qu'il y a un problème à mon algorithme de la détection de Ddos par compter les numéro de message. Mon algorithme ne peut pas détection le Ddos si le nombre moyen est intérieur à la valeur de seuil, mais dans une petite durée, le nombre de message est beaucoup. En fait, c'est une attaque, mais avec mon algorithme précédant, on ne peut pas le détecter. Donc à ce semestre, je cherche une meilleure manière à détecter la Ddos. Après quelques jours de chercher, j'ai trouvé une manière de détecter Ddos qui est utiliser à détecter Ddos sur Internet. Cette manière utiliser un indicateur qui s'appelle 'Hurst exponent'[12]. L'indicateur est correspondant à auto-similarité. L'idée de l'algorithme est calculer continuellement l'indicateur, s'il y a pas d'attaque, l'indicateur va rester à un niveau et en général la valeur est entre 0.5 et 1. Mais, s'il y a une attaque, la auto-similarité va être influencé, la valeur d'indicateur va diminuer, donc on peut dire que quand l'indicateur de Hurst est intérieur à une valeur de seuil, il y a une attaque.aque. | ||
+ | |||
+ | L'algorithme à caluler l'indicateur de Hurst est suivant(copié de Wiki[https://en.wikipedia.org/wiki/Hurst_exponent]): | ||
+ | |||
+ | 1. Calculate the [[mean]]; | ||
+ | |||
+ | :<math>m=\frac{1}{n} \sum_{i=1}^{n} X_i \,.</math> | ||
+ | |||
+ | 2. Create a mean-adjusted series; | ||
+ | |||
+ | :<math>Y_t=X_{t}-m \quad \text{ for } t=1,2, \dots ,n \,. </math> | ||
+ | |||
+ | 3. Calculate the cumulative deviate series <math>Z</math>; | ||
+ | |||
+ | :<math>Z_t= \sum_{i=1}^{t} Y_{i} \quad \text{ for } t=1,2, \dots ,n \,. </math> | ||
+ | 4. Compute the range <math>R</math>; | ||
− | == | + | :<math> R(n) =\operatorname{max}\left (Z_1, Z_2, \dots, Z_n \right )- |
− | J'ai | + | \operatorname{min}\left (Z_1, Z_2, \dots, Z_n \right ). </math> |
+ | |||
+ | 5. Compute the [[standard deviation]] <math>S</math>; | ||
+ | |||
+ | :<math>S(n)= \sqrt{\frac{1}{n} \sum_{i=1}^{n}\left ( X_{i} - m \right )^{2}}. </math> | ||
+ | |||
+ | 6. Calculate the rescaled range <math>R(n)/S(n)</math> and average over all the partial time series of length <math>n.</math> | ||
+ | |||
+ | J'ai réaliser l'algorithme, et je l'ai implémenter à ma programmation, mais malheuresement ça n'a fonctionné pas. Parce que si on veut utiliser l'algorithme, c'est obiligatoire que les variance n'equale pas 0. Mais, pour mon data, il y a des situation ou la variance equale 0. Donc je ne peux pas l'utiliser. | ||
+ | |||
+ | Après, j'ai pensé une nouvelle idée que pour une liste de data, je peux les diviser à plusieur dessous-niveau, et pour chaque dessous-niveau, je mesurer leur valuer et l'utilise à juger s'il y a des attaque. | ||
+ | |||
+ | Par exemple, pour les data pendant 10s, je les diviser à 2 partie, la première partie est les data de première 5 secondes, la deuxième partie est les data de deuxième 5 secondes, et on peut le diviser encore. Après, on va avoir les nombres de message à chaque niveau et chaque segment. Après je récupère les data sans attaque, avec les data, j'utilise la loi normale évaluer la distribution du nombre de message à chaque niveau et chaque segment. Quand on fait la surveillance, ont calculer le nombre de message de chaque segment, si le nombre est supérieur à la valeur moyen du loi normale qui est correspondante à ce segment, on va calculer le quotient de la densité de probabilité à ce valeur et la densité de probabilité à la valeur moyen, après on fait la sommation tous les quotient à chaque segment dans une période(avant de la sommation, les quotient multiplie au poids qui est correspondant au niveau). A la fin, si le quotient est intérieur à un seuil, c'est à dire qu'il n'y a pas de attaque, or il y a des attaque. La semaine prochaine, je vail le réaliser. La procédure est suivant: | ||
+ | |||
+ | Préparation: | ||
+ | 0. Choisir la duré de la préparation t; | ||
+ | 1. Choisir un résolution r (par exemple 4); | ||
+ | 2. Récuperer les package du réseau dans une périod p (par exemple 10s); | ||
+ | 3. for i in 1 : résolution: | ||
+ | Deviser le période à (2 ** (résolution - 1) ) segment; | ||
+ | Calculer le nombre de package à chaque segment; | ||
+ | Les trier par l'ordre ascendant; | ||
+ | 4. Composer les data et les stocker | ||
+ | 5. if le temps de fonctionne tt > t: | ||
+ | go to 2; | ||
+ | else: | ||
+ | go to 6; | ||
+ | 6. calculer la valeur moyenne 'm' et la variance 's' des data à chaque segment à chaque résolution | ||
+ | |||
+ | [[Fichier:Algorithme1.jpg]] | ||
+ | |||
+ | surveiller: | ||
+ | 0. Obtenir les data de préparation: t, r, m, s, choisir un seuil k; | ||
+ | 1 Y = 0 | ||
+ | 2. for i in 1 : r: | ||
+ | Deviser le période à (2 ** (résolution - 1) ) segment; | ||
+ | Calculer le nombre de package à chaque segment comme x; | ||
+ | Les trier par l'ordre ascendant; | ||
+ | 3. calculer les indicateur :<math>yi = {1 \over si\sqrt{2\pi} }\,e^{- {{(x-mi)^2 \over 2si^2}}}/{1 \over si\sqrt{2\pi} }\,e^{- {{(mi-mi)^2 \over 2si^2}}} * {1 \over 2 * t}, </math> | ||
+ | if x > mi: | ||
+ | Y += yi; | ||
+ | 4. if Y > k : | ||
+ | print 'there is une attaque; | ||
+ | 5. if le temps de fonctionne tt > t: | ||
+ | go to 2; | ||
+ | else: | ||
+ | go to 6; | ||
+ | 6. print 'no attaque' | ||
+ | |||
+ | ==Semaine 13== | ||
+ | J'ai réaliser la programmation et j'ai tester ma programmation et débugger. Maintenant il fonctionne bien. Il peut détecter l’attaque de Dos au cas que l’assaillant envoie continuellement les packages avec la fréquence très haute, mais aussi au cas que l’assaillant envoie beaucoup de packages nuisibles à une durée courte, comme Ldos(Low rate Denial of Service). | ||
+ | |||
+ | Source: | ||
+ | |||
+ | <center><include iframe src="https://www.youtube.com/embed/Up-Wx8m6DAc" width="320px" height="320px" frameborder="0" scrolling="yes"/></center> | ||
+ | |||
+ | <center><include iframe src="https://www.youtube.com/embed/YT7m5j3xBcQ" frameborder="0" " width="320px" height="320px" frameborder="0" scrolling="yes"/></center> | ||
+ | |||
+ | |||
+ | [[Fichier:Protecteur.zip]] | ||
=Documents Rendus= | =Documents Rendus= | ||
+ | Le rapport:[[Fichier:Ji_Yang_Rapport.pdf]] | ||
+ | |||
+ | code d'arduino:[[Fichier:Arduino A.zip]],[[Fichier:Arduino B.zip]],[[Fichier:Arduino C.zip]] | ||
+ | |||
+ | code de l'ordinateur: [[Fichier:Protecteur.zip]] |
Version actuelle datée du 15 juin 2018 à 21:28
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 à réaliser un système permettant de récupérer et analyser les package sous le protocole zigbee. Après l’analyse, il peut indiquer si le réseau est sous l'attaque et associer le scénario et l'attaque. Le projet a pour but de construire un réseau d’objet’, attaquer le réseau et récupérer et surveiller le réseau. Je chois le zigbee comme le protocole de réseau à construir le réseau d'objet.
1. Construire la communication avec quelques arduino et Xbee par le protocole zigbee.
2. Faire communiquer les arduino et récupérer les messages.
3. Attaquer le réseau par les manière : 'DDos' , 'Replay'.
4. Analyser les messages et chercher les caractères de la communication sans attaque et la communication sous attaque.
5. Selon les analyses, donner une solution à indiquer si le réseau subit l'attaque.
6. Associer les attaques et les scénarios
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. 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é.
Au début Dos est juste pour les réseau de l’ordinateur, mais maintenant de plus en plus des attaques Dos sont utilisé contre le réseau d’objet. Une attaque célèbre est l’attaque de ‘Mirai’.
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 protocole 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 chaîne. ET il est facile à utiliser. Juste insérer le telosb à l’ordinateur ou rasperry et lancer un script de python.
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 appareils 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 la distribution de 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ériaux 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 | Heures S11 | Heures S12 | Heures S13 | Total |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Choix du matériel | 8H | 3H | |||||||||||||
Analyse du projet + préparation oral | 6H | ||||||||||||||
Etudier le protocol Zigbee et Xbee | 8H | 9H | 3H | 2H | 2H | ||||||||||
Programmation sur arduino à construire une communication du réseau d'objet | 8H | 8H | 8H | 6H | |||||||||||
Etudier à attaquer le réseau d'objet | 6H | 3H | 3H | 1H | |||||||||||
Etudier le telosb | 7H | 5H | 6H | 2H | 1H | ||||||||||
Coder programmation à surveiller le réseau d'objet | 10H | 10H | 2H | ||||||||||||
Debugger et tester les programmation | 4H | 2H | 3H | 2H | 1H | 1H | 2H | ||||||||
Wiki | 1H | 4H | 1H | 1H | 1H | 1H | 10H |
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équemment 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.
Pour le réaliser, je trouve 2 manière. La première est à utiliser le logiciel XCTU qui nous donne le API à controler le trame, la destination, la frequence etc. Le deuxième manière est à utiliser le package de python de Xbee[4]. On peut écrire la programation à controler les trame.
Le code de Python à faire le Dos:Fichier:Dos avec python.zip
Semaine 4 - 5
J'ai complété la communication de IOT. La communication est simple, mais practical: il y a 3 arduino(on va s'appeler 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.
Pour coder la programmation, j'ai utilisé un package de Xbee[5]
source:
Arduino A: Fichier:Arduino A.zip
Arduino B: Fichier:Arduino B.zip
Arduino C: Fichier:Arduino C.zip
Semaine 6 - 7
En cette semaine, j'essayais à trouver une manière à 'sniffer' les trames de communication de IOT. Au début, je voulais utiliser Xbee comme le 'sniffeur', j'ai trouvé un package de Xbee qui est écrit de Python[6]. Il donne des fonctions, par exemple, avec lui, on peut configurer les paramètres de Xbee(adresse de réseau, PIND, Channel, mot de passe ect, le changement de mode API et AP, etc), afficher tous les appareils dans un réseau et obenir leur configuration, et envoyer et recevoir les message entre le réseau. Mais, quand je l'ai utilisé, j'ai trouver un problème que chaque Xbee peut recevoir seulement les trames dont destination est lui. Après, j'ai trouvé une solution que j'ai afficher tous les adresse de appareil du réseau, et j'ai changé continuellement l'adresse de source de mon Xbee aux adesse et récupérer les messages à l'adresse, et après, je peux sniffer le réseau. Mais, quand je l'ai fait, j'ai trouvé un problème que quand le Xbee a changé son propre adresse, il a pris près que 0.3 second qui a causé la perte de message. Donc ça n'a fonctionné pas. Après, je vais chercher l'autre méthode à sniffer le réseau.
Semaine 8
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.
J'ai étudier la source de Killerber[7]. Il donné les fonctionne de 'sniffer', attaque de DDos, attaque de répète, et il peut obtenir voire le mot de passe du réseau.
Le github de killerbee: [8]
Semaine 9
J'ai pris un telosb de Professeur Vantroys. Selon la notice de Xbee, j'ai télechargé le firmware de xbee au telosb, mais, il a échoué:
Après, j'ai cherché sur internet et j'ai trouvé que le problème était à cause de la version de goodfet. donc j'ai changé le fichier de goodfet et il a marché, quelques détail est sur la site suivante[9]
Et j'ai essayé les packets d'outil de killerbee, par exemple, 'sniffer', 'Ddos' etc, mais, ça n'a fonctionné pas. En fait, le telosb n'a récupéré ou envoyé rien avec les l'outils donné. Je ne comprends pas pourquoi il n'a fonctionné pas, je vais le cheche à la semaine dernière.
Semaine 10 - 11
Je n'ai trouvé pas encore pour quoi les utils de killerbee n'a fonctionné pas, mais, j'ai trouvé que avec le package 'goodfet', je peux sniffer le réseau. Donc j'ai écrit une programmation pour sniffer le réseau, et j'ai trouvé que le format du trame n'était pas identité que le format du trame de Xbee, donc je pense que le problème est à cause du format de trame différent.
Un exempledu format de trame de telosb est suivant:
0x17 -> length (总字节数 - 1)
0x61 -> la tête de trame(LOW)
0x88 -> la tête de trame(HIGH)
0xd -> frameID(不确定, 它随报文顺序,而增加)
0x34 -> PIND(LOW)
0x12 -> PIND(HIGH)
0x3 -> Addr16 of sender (LOW)
0x0 -> Addr16 of sender (HIGH)
0x1 -> Addr16 of receiver (LOW)
0x0 -> Addr16 of receiver (HIGH)
0xeb -> numeno des trames envoyés(LOW)
0x0 -> numeno des trames envoyés(LOW)
0x68 |-
0x65 |-
0x6c |-
0x6c |-
0x6f |- -> data
0x20 |-
0x77 |-
0x6f |-
0x72 |-
0x6c |-
0xe7 -> checkSum(LOW)
0xa9 -> checkSum(HIGH)
Pour obtenir les data correctement, j'ai écrit une classe 'parser_trame' à alalyser les trames et une classe 'Protecter' à analyser les datas et juger s'il y une attaque, dans cet parti, je vais utiliser 2 détection, un est contre Ddos, et l'autre est contre l'attaque 'répète'. Et j'ai écrit un démo, il a fonctionné pas mal.
J'ai deux algorithmes de la détection de l'attaque de Ddos. Le premier est à compter le numéro moyen de trame dans une période, si la valeur est supérieur à la valeur moyen, c'est à dire qu'il y une attaque de Ddos. C'est logic, parce que en géneral, la charactère le plus marqué de l'attaque DDos est que le nombre du message une plus que le nombre du message en général.
Le deuxième est à mesurer la puissance du channel, je récupère la valeur de 'rssi'[10] du Xbee pour évaluer la puissance, la relation entre rssi et la puissance pour le telosb est environ: 'puissance = rssi -40'. Si la puissance obtenu est superieur à la puissance moyan sans attaque, c'est à dire qu'il y a une attaque.
Avant de mesurer, je vous donne aussi deux fonction pour évaluer la valeur du nombre de message et de la puissance moyen sans attaque.
La détection de l'attaque de 'répète' est basé en une hypothèse que pour tous mes trame, il y a une signe correspondante au temps, ainsi on tous les trames vont être diffirent même si quelsques trames ont les mème data.
Après, il récupère continuellement les trames dans le réseau, et les transforme au format de Hash[11] et les stocker. Après chaque fois qu'il récupère un trame, il va le transformer au format de Hash et vérifier s'il il y a un valeur dont hash est mème, si oui, c'est à dire qu'il y a une attaque de 'répète'. Mais, il y a un cas spécial que un appareil veut envoyer un message à l'autre appareil, mais, il est échoué, donc il répète une fois le même data(avec même signe), en fait, c'est pas l'attaque. Donc j'ai ajouté un délais, par exemple 5s, si il y a un message dont Hash est existé dans la base de donné mais l'intervalle entre le temps ou les 2 Hash sont récupéré est intérieur à 5s, il va penser qu'il n'y a pas d'attaque.
dev_telosb.py: Fichier:Protecter.zip
Pour la partie de mesurer la puissance du channel, ça ne fonction pas bien, quand le telsob reçoit un trame, le rssi est environ -80, or la valeur est environ 120, et on ne peut pas juger s'il y a une attaque selon lui. Je ne comprends pas c'est pourquoi.
Semaine 12
J'ai fait une démonstration à Professeur Redon et Professeur Vantroys, et Nous avons fait une communication sur le projet, Monsieur Vantroys m'a dit qu'il y a un problème à mon algorithme de la détection de Ddos par compter les numéro de message. Mon algorithme ne peut pas détection le Ddos si le nombre moyen est intérieur à la valeur de seuil, mais dans une petite durée, le nombre de message est beaucoup. En fait, c'est une attaque, mais avec mon algorithme précédant, on ne peut pas le détecter. Donc à ce semestre, je cherche une meilleure manière à détecter la Ddos. Après quelques jours de chercher, j'ai trouvé une manière de détecter Ddos qui est utiliser à détecter Ddos sur Internet. Cette manière utiliser un indicateur qui s'appelle 'Hurst exponent'[12]. L'indicateur est correspondant à auto-similarité. L'idée de l'algorithme est calculer continuellement l'indicateur, s'il y a pas d'attaque, l'indicateur va rester à un niveau et en général la valeur est entre 0.5 et 1. Mais, s'il y a une attaque, la auto-similarité va être influencé, la valeur d'indicateur va diminuer, donc on peut dire que quand l'indicateur de Hurst est intérieur à une valeur de seuil, il y a une attaque.aque.
L'algorithme à caluler l'indicateur de Hurst est suivant(copié de Wiki[12]):
1. Calculate the mean;
2. Create a mean-adjusted series;
3. Calculate the cumulative deviate series ;
4. Compute the range ;
5. Compute the standard deviation ;
6. Calculate the rescaled range and average over all the partial time series of length
J'ai réaliser l'algorithme, et je l'ai implémenter à ma programmation, mais malheuresement ça n'a fonctionné pas. Parce que si on veut utiliser l'algorithme, c'est obiligatoire que les variance n'equale pas 0. Mais, pour mon data, il y a des situation ou la variance equale 0. Donc je ne peux pas l'utiliser.
Après, j'ai pensé une nouvelle idée que pour une liste de data, je peux les diviser à plusieur dessous-niveau, et pour chaque dessous-niveau, je mesurer leur valuer et l'utilise à juger s'il y a des attaque.
Par exemple, pour les data pendant 10s, je les diviser à 2 partie, la première partie est les data de première 5 secondes, la deuxième partie est les data de deuxième 5 secondes, et on peut le diviser encore. Après, on va avoir les nombres de message à chaque niveau et chaque segment. Après je récupère les data sans attaque, avec les data, j'utilise la loi normale évaluer la distribution du nombre de message à chaque niveau et chaque segment. Quand on fait la surveillance, ont calculer le nombre de message de chaque segment, si le nombre est supérieur à la valeur moyen du loi normale qui est correspondante à ce segment, on va calculer le quotient de la densité de probabilité à ce valeur et la densité de probabilité à la valeur moyen, après on fait la sommation tous les quotient à chaque segment dans une période(avant de la sommation, les quotient multiplie au poids qui est correspondant au niveau). A la fin, si le quotient est intérieur à un seuil, c'est à dire qu'il n'y a pas de attaque, or il y a des attaque. La semaine prochaine, je vail le réaliser. La procédure est suivant:
Préparation:
0. Choisir la duré de la préparation t; 1. Choisir un résolution r (par exemple 4); 2. Récuperer les package du réseau dans une périod p (par exemple 10s); 3. for i in 1 : résolution: Deviser le période à (2 ** (résolution - 1) ) segment; Calculer le nombre de package à chaque segment; Les trier par l'ordre ascendant; 4. Composer les data et les stocker 5. if le temps de fonctionne tt > t: go to 2; else: go to 6; 6. calculer la valeur moyenne 'm' et la variance 's' des data à chaque segment à chaque résolution
surveiller:
0. Obtenir les data de préparation: t, r, m, s, choisir un seuil k; 1 Y = 0 2. for i in 1 : r: Deviser le période à (2 ** (résolution - 1) ) segment; Calculer le nombre de package à chaque segment comme x; Les trier par l'ordre ascendant; 3. calculer les indicateur : if x > mi: Y += yi; 4. if Y > k : print 'there is une attaque; 5. if le temps de fonctionne tt > t: go to 2; else: go to 6; 6. print 'no attaque'
Semaine 13
J'ai réaliser la programmation et j'ai tester ma programmation et débugger. Maintenant il fonctionne bien. Il peut détecter l’attaque de Dos au cas que l’assaillant envoie continuellement les packages avec la fréquence très haute, mais aussi au cas que l’assaillant envoie beaucoup de packages nuisibles à une durée courte, comme Ldos(Low rate Denial of Service).
Source:
Documents Rendus
Le rapport:Fichier:Ji Yang Rapport.pdf
code d'arduino:Fichier:Arduino A.zip,Fichier:Arduino B.zip,Fichier:Arduino C.zip
code de l'ordinateur: Fichier:Protecteur.zip