Fichier:Videodemonstration.mov

2026-01-30T09:04:49Z

Crhanim :

video

2026-01-25T16:21:32Z

Crhanim : /* Utilisation de TinyTuya pour l’analyse de la communication ON/OFF */

== <big>'''Infrastructure Réseau 2025/2026'''</big> ==

L’objectif de cette partie est de mettre en place une '''infrastructure réseau''' intégrant un '''serveur virtuel''' sur Capbreton, connecté au réseau '''''bridgeStudents'''''. Ce serveur héberge les services '''DHCP''', '''DNS''' et une '''mascarade (NAT)''' afin d’assurer la connectivité et l’accès Internet des clients. Ajout d'une '''seconde interface réseau''' au serveur dans le '''VLAN 408''', appartenant au sous-réseau '''172.16.8.0/24.'''

La mise en place d'une '''sécurisation WiFi par WPA2-PSK''' pour garantir un accès protégé, et des tests ont été réalisés pour vérifier la visibilité du SSID, la connexion WiFi, la distribution d’adresses IP et l’accès à Internet.

=== ''<big>Serveur Virtuel : 17/09</big>'' ===

==== <big>Création et configuration de la VM</big> ====
Pour créer la VM : xen-create-image --hostname=SE5-crhanim --dhcp --dir=/usr/local/xen --size=20Gb --memory=2048mb --dist=daedalus --bridge=bridgeStudents

Configuration réseau de la VM : <syntaxhighlight>
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 172.26.145.108
netmask 255.255.255.0
gateway 172.26.145.251
dsn-nameservers 172.26.145.251
# post-up ethtool -K eth0 tx off

#
# The commented out line above will disable TCP checksumming which
# might resolve problems for some users. It is disabled by default
#
</syntaxhighlight>Vérification : <syntaxhighlight>
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=6.27 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 5.717/5.901/6.267/0.258 ms

</syntaxhighlight>

==== <big>Ajout de l'interface dans le VLAN408</big> ====
Configuration de l'interface privé VLAN408 (eth1):<syntaxhighlight>
#VLAN 408
auto eth1
iface eth1 inet static
address 172.16.8.1
netmask 255.255.255.0
#
# The commented out line above will disable TCP checksumming which
# might resolve problems for some users. It is disabled by default
#
</syntaxhighlight>Vérifications avec '''ip a :'''<syntaxhighlight>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:d7:30:83 brd ff:ff:ff:ff:ff:ff
inet 172.26.145.108/24 brd 172.26.145.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2001:660:4401:6050:216:3eff:fed7:3083/64 scope global dynamic mngtmpaddr
valid_lft 989sec preferred_lft 889sec
inet6 2a01:c916:2047:c850:216:3eff:fed7:3083/64 scope global dynamic mngtmpaddr
valid_lft 2591989sec preferred_lft 604789sec
inet6 fe80::216:3eff:fed7:3083/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:d7:30:84 brd ff:ff:ff:ff:ff:ff
inet 172.16.8.0/24 brd 172.16.8.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fed7:3084/64 scope link
valid_lft forever preferred_lft forever
</syntaxhighlight>

Sur Capbreton: dans le fichier de configuration de ma VM : '''etc/xen/SE5-crhanim.cfg'''<syntaxhighlight>
#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:D7:30:83,bridge=bridgeStudents',
'mac=00:16:3E:D7:30:84,bridge=g5_crhanim' ]
</syntaxhighlight>Sur /etc/network/interfaces.d/g5_crhanim

Configuration de l'interface Vlan408 et bridge: g5_crhanim<syntaxhighlight>
auto Trunk.408
iface Trunk.408 inet manual
vlan-raw-device Trunk
up ip link set $IFACE up
down ip link set $IFACE down

auto g5_crhanim
iface g5_crhanim inet manual
bridge_ports Trunk.408
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

=== '''''<big>Sécurisation WiFi par WPA2-PSK : 29/09</big>''''' ===
La connexion au point d’accès s’effectue via le '''port série''' depuis la '''machine hôte''' à l’aide de '''Minicom'''. L’objectif est de configurer les paramètres du WiFi : '''SSID''', '''chiffrement''' et '''VLAN'''.

==== <big>Création et configuration du SSID au VLAN408</big> ====
<syntaxhighlight>
dot11 ssid SE5-crhanim
vlan 408
authentication open
authentication key-management wpa
wpa-psk ascii 0 " "
mbssid guest-mode
exit
interface Dot11Radio1
encryption vlan 408 mode ciphers aes-ccm
ssid SE5-crhanim
mbssid
no shutdown
exit

interface Dot11Radio1.408
encapsulation dot1Q 408
bridge-group 8
exit

interface GigabitEthernet0.408
encapsulation dot1Q 408
bridge-group 8
exit
</syntaxhighlight>Pour vérifier : ap#'''sh dot11 bssid'''<syntaxhighlight>
ap#sh dot11 bssid
Interface BSSID Guest SSID
Dot11Radio1 04da.d2d1.4bf0 Yes SE5-azongo
Dot11Radio1 04da.d2d1.4bf1 Yes SE5-crhanim
Dot11Radio1 04da.d2d1.4bf2 Yes SE5-handrian
</syntaxhighlight>

==== <big>Configuration du serveur DHCP</big> ====
Dans la machine virtuelle, j'ai configuré le fichier : '''/etc/dhcp/dhcpd.conf''' pour définir le réseau du VLAN 408 (172.16.8.0/24). Le serveur attribue automatiquement des adresses IP comprises entre '''172.16.8.100''' et '''172.16.8.200''' aux clients WiFi.<syntaxhighlight>
subnet 172.16.8.0 netmask 255.255.255.0 {
range 172.16.8.100 172.16.8.200;
option routers 172.16.8.1;
#option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
option domain-name-servers 172.16.8.1;
}

</syntaxhighlight>dans /etc/sysctl.conf : j'ai décommenté la ligne : net.ipv4.ip_forward=1

'''sysctl -p /etc/sysctl.conf''' : pour recharger '''configuration sysctl.'''

sysctl net.ipv4.ip_forward : pour vérifier

==== <big>Implémentation du serveur DNS</big> ====

Pour implémenter un serveur DNS, dans le fichier <code>/etc/bind/named.conf.options :</code> <syntaxhighlight>
options {
directory "/var/cache/bind";

recursion yes;
allow-query {172.16.8.0/24; 127.0.0.1;};

forwarders {
8.8.8.8;
1.1.1.1;
};
dnssec-validation auto;

listen-on { 127.0.0.1; 172.16.8.1; };
listen-on-v6 { none; };
};

</syntaxhighlight>

==== <big>Mise en place de la mascarade sur le serveur virtuel</big> 03/10 ====
Pour permettre aux machines du '''VLAN 408 (172.16.8.0/24)''' d’accéder à Internet via le serveur virtuel, j'ai ajouté une '''règle de mascarade''' avec '''iptables:''' <syntaxhighlight>
iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.16.8.0/24
</syntaxhighlight>Cette règle remplace l’adresse source des paquets sortants par celle du serveur, assurant ainsi la traduction d’adresses (NAT).

L’état de la table NAT peut être vérifié avec la commande <code>iptables -t nat -L -v</code>, qui affiche la règle de '''POSTROUTING''' active :<syntaxhighlight>
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
122 51438 MASQUERADE 0 -- * * 172.16.8.0/24 0.0.0.0/0
</syntaxhighlight>Cette configuration permet aux clients connectés au WiFi du VLAN 408 de naviguer sur Internet à travers le serveur virtuel.

=== ''<big>'''Interception de flux:03/10'''</big>'' ===

==== <big>Redirection par DNS</big> ====
J'ai modifié la configuration de '''BIND''' sur le serveur virtuel. Dans le fichier '''/etc/bind/named.conf.local''', une nouvelle zone a été ajoutée pour le domaine '''github.com''' :<syntaxhighlight>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "github.com"{
type master;
file "/etc/bind/db.github.com";

};

</syntaxhighlight>création de la zone db.github.com<syntaxhighlight>
$TTL 604800
@ IN SOA ns.github.com. admin.github.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

;
@ IN NS ns.github.com.
ns IN A 172.16.8.1
@ IN A 172.16.8.1
www IN A 172.16.8.1

</syntaxhighlight>

==== <big>Redirection réseau</big> ====
J'ai ajouté une règle iptables pour rediriger le trafic TCP vers un port local.<syntaxhighlight>
iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REDIRECT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 8080

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
122 51438 MASQUERADE 0 -- * * 172.16.8.0/24 0.0.0.0/0
</syntaxhighlight>

=== '''''<big>Serveur Apache sécurisé: 03/11</big>''''' ===

Commande utilisée pour générer le certificat auto-signé :<syntaxhighlight>
openssl req -x509 -nodes -days 365 \
-newkey rsa:2048 \
-keyout /etc/ssl/apache/apache-selfsigned.key \
-out /etc/ssl/apache/apache-selfsigned.crt \
-subj "/C=FR/ST=Nord/L=Lille/O=Polytech/CN=github.com"
</syntaxhighlight>Configuration pour Apache :

j'ai mis la configuration dans le fichier '''etc/apache2/sites-available/site-github.conf'''

Mise en place d’un hôte virtuel HTTPS sur le port 443 avec le certificat auto-signé et redirection automatique du HTTP (port 80) vers le HTTPS.<syntaxhighlight>
<VirtualHost *:443>
ServerName github.com

DocumentRoot /var/www/html

SSLEngine on
SSLCertificateFile /etc/ssl/apache/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/apache/apache-selfsigned.key

ErrorLog ${APACHE_LOG_DIR}/github-error.log
CustomLog ${APACHE_LOG_DIR}/github-access.log combined

</VirtualHost>

<VirtualHost *:80>
ServerName github.com
Redirect permanent / https://github.com/
</VirtualHost>
</syntaxhighlight>Pour activer la configuration du site et recharger Apache : <syntaxhighlight>
a2ensite site-github.conf
service apache2 reload
</syntaxhighlight>Vérification : <syntaxhighlight>
:~#ss -tlnp | grep 443
LISTEN 0 128 *:443 *:* users:(("apache2",pid=1485,fd=6),("apache2",pid=1484,fd=6),("apache2",pid=1481,fd=6))
:~# ss -tlnp | grep 80
LISTEN 0 128 *:80 *:* users:(("apache2",pid=1485,fd=4),("apache2",pid=1484,fd=4),("apache2",pid=1481,fd=4))
</syntaxhighlight>

=== '''''<big>Machine virtuelle Android : 03/11</big>''''' ===
La redirection HTTPS est bloquée par les '''certificats X509'''. Comme il est difficile d’ajouter des certificats sur un téléphone moderne, une solution consiste à utiliser une '''machine virtuelle Android''' d'une ancienne version, sur laquelle il est possible d’ajouter les certificats nécessaires.

==== <big>''Tentative installation VM en utilisant QEMU''</big> ====
Pour l'installation de la VM sur PC en utilisant QEMU , j'ai suivi le tutoriel de ce site : https://help.clouding.io/hc/en-us/articles/4405454393756-How-to-virtualize-Android-with-QEMU-KVM. Pour la version, j'ai pris la version android 6.

Après installation j'ai lancé la VM en utilisant cette commande : <syntaxhighlight>
qemu-system-x86_64 -m 2048
-enable-kvm -drive file=~/VM_androidv6.img,format=qcow2
-cdrom ~/Downloads/android-x86_64-6.0-r1.iso
-boot d -net nic -net user -display sdl
</syntaxhighlight>La VM se connecte à Internet en utilisant la connexion du PC hôte, et elle ne détecte pas les WiFi disponible. Pour résoudre ce problème, nous avons modifié le fichier de configuration de la zabeth pour la connecter au wifi.

==== <big>''Configuration Wifi pour connecter la VM : 04/'''''11'''</big> ====
Pour cela, j'ai modifié le fichier /etc/network/interfaces. L'interface wlan1 est configurée en mode DHCP pour se connecter automatiquement au réseau WiFi avec le SSID “SE5-crhanim”, et une sécurité WPA2-PSK.<syntaxhighlight>
>>ip link set bridge down

/etc/network/interfaces

iface wlan1 inet dhcp
wpa-ssid SE5-crhanim
wpa-key-mgmt WPA-PSK
wpa-psk Chaymae08
</syntaxhighlight>Lors de cette configuration, la connexion échouait malgré une détection correcte du réseau. La cause était l’absence du paquet wpa_supplicant, nécessaire pour l’authentification sur les réseaux Wi-Fi sécurisés.

L’installation du paquet avec la commande suivante m'a permis de résoudre le problème : <syntaxhighlight>
sudo apt install wpasupplicant
</syntaxhighlight>

==== ''<big>Problèmes rencontrés</big>'' ====
L’installation de l’application Nedis Smart Life, utilisée pour gérer l’objet connecté, s’est déroulée avec succès. Cependant, une erreur est survenue lors de son lancement sur la machine android virtuelle.

==== ''<big>Tentative installation de Android x86_64 en utilisant les commandes du Dockerfile</big>'' ====
Les étapes réalisées (sur zabeth08 et sans Docker ) :

* Installation des dépendances nécessaires (OpenJDK, outils de compilation, librairies graphiques).
* Téléchargement des Android Command Line Tools.
* Configuration des variables d’environnement Android (ANDROID_HOME, ANDROID_SDK_ROOT).
* Installation des composants du SDK Android via sdkmanager (platform-tools, emulator, images système Android 30).
* Création d’un AVD avec avdmanager : '''avdmanager create avd -n test_avd -k "system-images;android-30;google_apis;x86_64"'''.
* Tentative de lancement de l’émulateur Android en ligne de commande.

L’objectif est de faire tourner un émulateur Android directement sur la VM pour pouvoir utiliser l’application associée à l’objet connecté. Toutefois, l’appareil virtuel lancé présentait de nombreux dysfonctionnements et manquait de stabilité, rendant impossible l’utilisation correcte du téléphone.

==== ''<big>Création de VM en utilisant Android studio</big>'' ====

===== Installation de Android studio =====
Pour le téléchargement d’Android Studio j'ai utilisé la dernière version depuis le site officiel. Une fois l’archive obtenue au format .tar.gz, je l’ai décompressée à l’aide de la commande '''tar -xvf android-studio-*.tar.gz''', ce qui a extrait l’environnement complet d’Android Studio. Comme il s’agit d’un logiciel installé manuellement, je l’ai ensuite déplacé dans le répertoire standard /'''opt'''.

Pour lancer l'application : '''/opt/android-studio/bin/studio.sh'''

Android Studio a téléchargé et installé les composants suivants : Android SDK Platform 30 et 36, Build-tools 36.1.0, Platform-tools, System Images, Sources Android.

Tout le SDK a été installé dans le répertoire : '''/home/crhanim/android/'''

===== Création d'un nouvel AVD. =====
Dans Android Studio : Ouverture du Device Manager : Tools → Device Manager

Création d’un nouvel appareil virtuel :

Category : Phone

Device choisi : Pixel 4

System Image : Android 10 (API 29)

Pour un premier essai, j’ai choisi une image ARM pour créer mon appareil virtuel. Cependant, un problème est survenu lors du lancement de l’AVD :

« AVD's CPU Architecture 'arm64' is not supported by the QEMU2 emulator on x86_64 host ».

'''Solution :''' J’ai finalement opté pour une image x86_64 (Google APIs x86_64), qui est pleinement prise en charge par l’émulateur.

Après ce changement, j’ai pu finaliser la configuration et créer correctement l’AVD.

===== '''APK utilisé pour Nedis smartLife ''' =====
Pour installer l'application de l'objet connecté, j'ai utilisé le lien suivant : <nowiki>https://nedis-smartlife.en.aptoide.com/app</nowiki> .Cette fois ci l'application se lance correctement.

==== ''<big>Ajout de certificat dans la VM</big>'' ====

===== Première tentative =====
Pour obtenir un accès root sur l’émulateur, j'ai installé l'outil Magisk, lien d'installation: <nowiki>https://gitlab.com/newbit/rootAVD</nowiki>.

les commandes utilisées pour mettre le certificat sur la VM :<syntaxhighlight>
adb root
adb shell avbctl disable-verification
adb reboot
adb wait-for-device root
adb remount
adb push 9ab369ad.0 /system/etc/security/cacerts
</syntaxhighlight>Cependant, la commande adb push échoue : Erreur d’accès : le répertoire est en lecture seule (Read-only file system).

Même après adb remount, la partition /system reste non modifiable.

Pour contourner ce problème, j’ai tenté de relancer l’émulateur en mode système modifiable avec la commande :<syntaxhighlight>
emulator -avd <nom_avd> -writable-system -gpu swiftshader_indirect -no-snapshot -no-boot-anim &
</syntaxhighlight>Ce lancement permet bien de modifier temporairement /system, mais il ne force pas un redémarrage propre de l’AVD. Donc le certificat est ajouté uniquement en mémoire, et disparaît dès que l’AVD est redémarré, et les modifications ne sont pas persistées sur l’image système.

===== Deuxième tentative =====
J'ai opté pour une méthode alternative : créer un module Magisk permettant d’injecter automatiquement le certificat dans le système au démarrage. Cette approche contourne la protection en lecture seule (dm-verity) puisqu’un module Magisk monte un overlay persistant au boot.

Utilisation de module magisk --> réussie. Le certificat est ajoutée avec succès et mon site github.com est bien redirigé.
[[Fichier:Github redirigé.png|néant|vignette]]

== '''<big>Objet : Interrupteur connecté</big>''' ==
L'objectif de cette partie du TP est d'analyser la communication réseau entre un smart wall switch et un téléphone (l'application nedis smartlife) afin de comprendre le trajet des paquets et les protocoles utilisés. Pour essayer de forger mon propre paquet qui permet d'allumer/éteindre l'interrupteur sans passer par l'application.

l'Interrupteur peut être commandé à distance par l'application mobile Nedis Smart Life pour l'éteindre ou allumer, j'ai fait les tests avec mon telephone et la VM android --> réussi.

=== <big>''Analyse du trafic en utilisant wireshark''</big> ===
J'ai identifié l'adresse IP et mac de l'interrupteur connecté :

IP : 172.16.8.105

MAC : d8:1f:12:98:93:58

Sur wireshark, j'ai procédé à plusieurs captures avec différents filtres pour comprendre la communication.

Filtre utilisé : '''ip.addr == 172.16.8.105.'''

J'ai observé du trafic UDP en broadcast vers 255.255.255.255 sur le port 6667. L'interrupteur envoie des annonces périodiques, toutes les ~5 secondes contenant la signature 000055aa et son état actuel chiffré.

le '''0055aa''' corrrespond à la signature Tuya: le header fixé par le protocole de communication qu'utilise Tuya.
[[Fichier:Trafic.png|centré|vignette|624x624px]]
Filtre : '''ip.addr == 172.16.8.105 && ip.addr == 172.16.8.104'''

Communication directe téléphone ↔ interrupteur

Aucun paquet capturé. Ce qui est normal ca indique qu'il n'existe aucune communication directe entre le téléphone et l'interrupteur sur le réseau local. Toutes les

commandes passent par les serveurs cloud Tuya.

Filtre utilisé : '''ip.addr == 172.16.8.104'''

'''172.16.8.104''' est l'adresse IP de la machine Android VM ou j'éxécute l'application Nedis Smart Life.
[[Fichier:Capture trames.png|centré|vignette|927x927px]]
Ce filtre permet de capturer l'ensemble de l'activité réseau du téléphone, notamment les connexions HTTPS/TLS établies vers les serveurs cloud Tuya, les paquets "Application Data" chiffrés contenant les commandes d'allumage et d'extinction, ainsi que les confirmations renvoyées par les serveurs. J'ai pu identifier que toutes les commandes transitent par des serveurs AWS localisés en Europe (3.78.92.3, 18.194.10.142, 193.48.57.31), communiquant sur le port 443 via le protocole HTTPS, révélant ainsi une architecture entièrement basée sur le cloud.

=== ''<big>Utilisation de TinyTuya pour l’analyse de la communication ON/OFF</big>'' ===
Dans cette partie, j'ai utilisé l’outil TinyTuya afin d’analyser la communication entre le Smart Wall Switch Tuya et le téléphone lors des commandes ON / OFF.

TinyTuya est une bibliothèque Python qui permet de communiquer localement avec des appareils Tuya (sans passer par le cloud), en utilisant le protocole Tuya LAN. Elle permet notamment de découvrir les appareils sur le réseau, de récupérer leurs informations et d’envoyer des commandes (ON/OFF).

Après avoir créé un environnement Python, j'ai installé les bibliothèques nécessaires :<syntaxhighlight>
python3 -m pip install pycryptodome
python3 -m pip install tinytuya
</syntaxhighlight>Ensuite, j'ai utilisé la commande python -m tinytuya scan : qui permet de scanner le réseau local afin de détecter les appareils Tuya présents.<syntaxhighlight>
root@zabeth08:~/penv# bin/python3 -m tinytuya scan
TinyTuya (Tuya device scanner) [1.17.4]

Scanning on UDP ports 6666 and 6667 and 7000 for devices for 18 seconds...

New Broadcast from App at 172.16.8.104 - {'from': 'app', 'ip': '172.16.8.104'}
Unknown v3.3 Device Product ID = key7axydcvmea3x9 [Valid Broadcast]:
Address = 172.16.8.105 Device ID = bf256839cbc866aa26yeyc (len:22) Local Key = Version = 3.3 Type = default, MAC =
No Stats for 172.16.8.105: DEVICE KEY required to poll for status
New Broadcast from App at 127.0.0.1 - {'from': 'app', 'ip': '10.0.2.16'}
Scan completed in 18.0288 seconds

Scan Complete! Found 1 devices.
Broadcasted: 1
Versions: 3.3: 1
Unknown Devices: 1

Saving device snapshot data to snapshot.json
</syntaxhighlight>Pour pouvoir communiquer correctement avec l’appareil, j'ai créé un compte développeur sur eu.platform.tuya.com et j'ai ajouté le Smart Wall Switch sur la plateforme en utilisant l’application SmartLife pour scanner le QR code et lier l’appareil au compte Tuya. Une fois l’appareil lié au compte Tuya, j'ai lancé :<syntaxhighlight>
python -m tinytuya wizard
</syntaxhighlight>Cette commande permet de scanner le réseau et elle récupère les informations depuis la plateforme Tuya pour générer automatiquement les fichiers de configuration.<syntaxhighlight>
Configuration Data Saved to tinytuya.json

{
"apiKey": "pwtm5xhprm393rxf8jsh",
"apiSecret": "aef15868be684109b0cb71a8d4681e2d",
"apiRegion": "eu",
"apiDeviceID": "bf256839cbc866aa26yeyc"
}

</syntaxhighlight>À la fin de cette étape, le fichier tinytuya.json est créé et il contient les clés d’API Tuya et les informations nécessaires pour récupérer automatiquement les paramètres du Smart Switch. Ces informations sont ensuite utilisées pour créer le fichier devices.json, indispensable à la communication locale avec l’appareil.

Pour vérifier et afficher les informations complètes du Smart Switch, on lance la commande : <syntaxhighlight>
python -m tinytuya devices
</syntaxhighlight>cette commande génére le fichier devices.json, qui contient l'identifiant et la clé de l'interrupteur, l’adresse IP, le modèle de l’interrupteur et la liste des Data Points (DP), utilisés par l’appareil. Les Data Points (DP) qui identifient les différentes fonctionnalités du switch.<syntaxhighlight>
root@zabeth08:~/penv# bin/python3 -m tinytuya devices

TinyTuya (Tuya device scanner) [1.17.4]

Loaded devices.json - 1 devices:

Device Listing

[
{
"name": "Interrupteur connect\u00e9",
"id": "bf256839cbc866aa26yeyc",
"key": "<UfC-OoB>RVu=@t>",
"mac": "d8:1f:12:98:93:58",
"uuid": "ec7b74129b6b536c",
"sn": "TXWDC05ME002D9",
"category": "kg",
"product_name": "Wall switch",
"product_id": "bkmg3ht7emkqwv91",
"biz_type": 18,
"model": "WIFIWS10WT",
"sub": false,
"icon": "https://images.tuyaeu.com/smart/icon/ay1513237774906SMBA3/456c398229a72ede67a148535fd2a5ab.png",
"mapping": {
"1": {
"code": "switch_1",
"type": "Boolean",
"values": {}
},
"7": {
"code": "countdown_1",
"type": "Integer",
"values": {
"unit": "s",
"min": 0,
"max": 86400,
"scale": 0,
"step": 1
}
},
"14": {
"code": "relay_status",
"type": "Enum",
"values": {
"range": [
"power_off",
"power_on",
"last"
]
}
},
"17": {
"code": "cycle_time",
"type": "String",
"values": "{}"
},
"18": {
"code": "random_time",
"type": "String",
"values": "{}"
},
"19": {
"code": "switch_inching",
"type": "String",
"values": "{}"
}
},
"ip": "172.16.8.105",
"version": "3.3"
}
]
</syntaxhighlight>À partir des informations contenues dans <code>devices.json</code>, j ’ai développé un script Python en utilisant la librairie '''TinyTuya''' afin de communiquer directement avec le Smart Wall Switch sur le réseau local. Ce script me permet de récupérer l’état actuel de l’interrupteur, d’envoyer une commande '''ON''', puis une commande '''OFF.''' L’activation du mode debug affiche les différentes étapes de la communication, notamment la construction des messages Tuya, leur chiffrement, leur envoi sur le réseau local ainsi que les réponses retournées par l’interrupteur.

Voici le code python utilisé : <syntaxhighlight lang="python">
import tinytuya
import time

DEVICE_ID = "bf256839cbc866aa26yeyc"
LOCAL_KEY = "<UfC-OoB>RVu=@t>"
DEVICE_IP = "172.16.8.105"
VERSION = 3.3

tinytuya.set_debug(True)

# Création du device
d = tinytuya.OutletDevice(
dev_id=DEVICE_ID,
address=DEVICE_IP,
local_key=LOCAL_KEY
)

d.set_version(VERSION)

print("État initial :")
print(d.status())

print("\n--- ON ---")
d.turn_on()
time.sleep(2)

print("\nÉtat après ON :")
print(d.status())

print("\n--- OFF ---")
d.turn_off()
time.sleep(2)

print("\nÉtat après OFF :")
print(d.status())
</syntaxhighlight>Grâce au script Python basé sur TinyTuya, j’ai pu contrôler avec succès le Smart Wall Switch '''uniquement via le réseau local''', sans passer par le cloud Tuya.

L’analyse des logs en mode debug montre que les commandes ON et OFF sont envoyées sous forme de '''trames Tuya chiffrées''', les messages sont '''chiffrés en AES''' (protocole Tuya v3.3). Chaque commande repose sur l’envoi d’un message contenant un champ <code>dps</code>, où le '''Data Point 1''' contrôle l’état de l’interrupteur (<code>true</code> pour ON, <code>false</code> pour OFF).<syntaxhighlight>
DEBUG:TinyTuya [1.17.4]

DEBUG:Python 3.11.2 (main, Nov 30 2024, 21:22:50) [GCC 12.2.0] on linux
DEBUG:Using pyca/cryptography 46.0.3 for crypto, GCM is supported
État initial :
DEBUG:status() entry (dev_type is default)
DEBUG:final payload_dict for 'bf256839cbc866aa26yeyc' ('v3.3'/'default'): {1: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 7: {'command': {'devId': '', 'uid': '', 't': ''}}, 8: {'command': {'gwId': '', 'devId': ''}}, 9: {'command': {'gwId': '', 'devId': ''}}, 10: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 13: {'command': {'devId': '', 'uid': '', 't': ''}}, 16: {'command': {'devId': '', 'uid': '', 't': ''}}, 18: {'command': {'dpId': [18, 19, 20]}}, 64: {'command': {'reqType': '', 'data': {}}}}
DEBUG:building command 10 payload=b'{"gwId":"bf256839cbc866aa26yeyc","devId":"bf256839cbc866aa26yeyc","uid":"bf256839cbc866aa26yeyc","t":"1768324046"}'
DEBUG:sending payload
DEBUG:payload encrypted=b'000055aa000000010000000a0000008818244f706e1005740059ceddf02f1829ed8b0833ddcb840a79ab3d00b5422a037737dfd0f905d7f80639a2608b830aeeed482913615be0cf5e62a732214bd02079928148c6ee178e35610640a3cf196aed8b0833ddcb840a79ab3d00b5422a0372733d68a3c7214f502ee01c4a2106ba8f3c59fd5d5731db7677bc1229c7a135649067940000aa55'
DEBUG:received data=b'000055aa000000010000000a0000004c0000000028ecbcc865e25c62b3d20e4d52cb91f6018cae5ba21fcd8ed5c0ce43dfe9c82eb62a4080c77fa007b1cae9e83cefef8142f977f994f1b0bdbc1bea641c4d38a740bf74f30000aa55'
DEBUG:received message=TuyaMessage(seqno=1, cmd=10, retcode=0, payload=b'(\xec\xbc\xc8e\xe2\\b\xb3\xd2\x0eMR\xcb\x91\xf6\x01\x8c\xae[\xa2\x1f\xcd\x8e\xd5\xc0\xceC\xdf\xe9\xc8.\xb6*@\x80\xc7\x7f\xa0\x07\xb1\xca\xe9\xe8<\xef\xef\x81B\xf9w\xf9\x94\xf1\xb0\xbd\xbc\x1b\xead\x1cM8\xa7', crc=1086289139, crc_good=True, prefix=21930, iv=None)
DEBUG:raw unpacked message = TuyaMessage(seqno=1, cmd=10, retcode=0, payload=b'(\xec\xbc\xc8e\xe2\\b\xb3\xd2\x0eMR\xcb\x91\xf6\x01\x8c\xae[\xa2\x1f\xcd\x8e\xd5\xc0\xceC\xdf\xe9\xc8.\xb6*@\x80\xc7\x7f\xa0\x07\xb1\xca\xe9\xe8<\xef\xef\x81B\xf9w\xf9\x94\xf1\xb0\xbd\xbc\x1b\xead\x1cM8\xa7', crc=1086289139, crc_good=True, prefix=21930, iv=None)
DEBUG:decode payload=b'(\xec\xbc\xc8e\xe2\\b\xb3\xd2\x0eMR\xcb\x91\xf6\x01\x8c\xae[\xa2\x1f\xcd\x8e\xd5\xc0\xceC\xdf\xe9\xc8.\xb6*@\x80\xc7\x7f\xa0\x07\xb1\xca\xe9\xe8<\xef\xef\x81B\xf9w\xf9\x94\xf1\xb0\xbd\xbc\x1b\xead\x1cM8\xa7'
DEBUG:decrypting=b'(\xec\xbc\xc8e\xe2\\b\xb3\xd2\x0eMR\xcb\x91\xf6\x01\x8c\xae[\xa2\x1f\xcd\x8e\xd5\xc0\xceC\xdf\xe9\xc8.\xb6*@\x80\xc7\x7f\xa0\x07\xb1\xca\xe9\xe8<\xef\xef\x81B\xf9w\xf9\x94\xf1\xb0\xbd\xbc\x1b\xead\x1cM8\xa7'
DEBUG:decrypted 3.x payload=b'{"dps":{"1":false,"7":0,"14":"memory","17":"","18":""}}'
DEBUG:payload type = <class 'bytes'>
DEBUG:decoded results='{"dps":{"1":false,"7":0,"14":"memory","17":"","18":""}}'
DEBUG:status() received data={'dps': {'1': False, '7': 0, '14': 'memory', '17': '', '18': ''}}
{'dps': {'1': False, '7': 0, '14': 'memory', '17': '', '18': ''}}

--- ON ---
DEBUG:building command 7 payload=b'{"devId":"bf256839cbc866aa26yeyc","uid":"bf256839cbc866aa26yeyc","t":"1768324047","dps":{"1":true}}'
DEBUG:sending payload
DEBUG:payload encrypted=b'000055aa000000020000000700000087332e3300000000000000000000000005ce79f17f973575c5f3b202529a10d2ed482913615be0cf5e62a732214bd02079928148c6ee178e35610640a3cf196aed8b0833ddcb840a79ab3d00b5422a035b1a69a9b681f527762a90c9d9768e7b6e503f335ebd5ef5e8b7a10a99ce938df56511b866449fccbf838c71e1f5adaa74845e6a0000aa55'
DEBUG:received data=b'000055aa00000000000000080000004b00000000332e330000000000002ecd00000001fb053bf4082a784d112a22a3d415707c2782e1bcb5a76e331ef111baac66f30cb27edc041220e6dabfed29faa91e838d65b884ea0000aa55'
DEBUG:received message=TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00.\xcd\x00\x00\x00\x01\xfb\x05;\xf4\x08*xM\x11*"\xa3\xd4\x15p|\'\x82\xe1\xbc\xb5\xa7n3\x1e\xf1\x11\xba\xacf\xf3\x0c\xb2~\xdc\x04\x12 \xe6\xda\xbf\xed)\xfa\xa9\x1e\x83\x8d', crc=1706591466, crc_good=True, prefix=21930, iv=None)
DEBUG:raw unpacked message = TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00.\xcd\x00\x00\x00\x01\xfb\x05;\xf4\x08*xM\x11*"\xa3\xd4\x15p|\'\x82\xe1\xbc\xb5\xa7n3\x1e\xf1\x11\xba\xacf\xf3\x0c\xb2~\xdc\x04\x12 \xe6\xda\xbf\xed)\xfa\xa9\x1e\x83\x8d', crc=1706591466, crc_good=True, prefix=21930, iv=None)
DEBUG:decode payload=b'3.3\x00\x00\x00\x00\x00\x00.\xcd\x00\x00\x00\x01\xfb\x05;\xf4\x08*xM\x11*"\xa3\xd4\x15p|\'\x82\xe1\xbc\xb5\xa7n3\x1e\xf1\x11\xba\xacf\xf3\x0c\xb2~\xdc\x04\x12 \xe6\xda\xbf\xed)\xfa\xa9\x1e\x83\x8d'
DEBUG:removing 3.x=b'\xfb\x05;\xf4\x08*xM\x11*"\xa3\xd4\x15p|\'\x82\xe1\xbc\xb5\xa7n3\x1e\xf1\x11\xba\xacf\xf3\x0c\xb2~\xdc\x04\x12 \xe6\xda\xbf\xed)\xfa\xa9\x1e\x83\x8d'
DEBUG:decrypting=b'\xfb\x05;\xf4\x08*xM\x11*"\xa3\xd4\x15p|\'\x82\xe1\xbc\xb5\xa7n3\x1e\xf1\x11\xba\xacf\xf3\x0c\xb2~\xdc\x04\x12 \xe6\xda\xbf\xed)\xfa\xa9\x1e\x83\x8d'
DEBUG:decrypted 3.x payload=b'{"dps":{"1":true},"t":1768324046}'
DEBUG:payload type = <class 'bytes'>
DEBUG:decoded results='{"dps":{"1":true},"t":1768324046}'
DEBUG:set_status received data={'dps': {'1': True}, 't': 1768324046}

État après ON :
DEBUG:.................DEBUG:status() received data={'dps': {'1': True, '7': 0, '14': 'memory', '17': '', '18': ''}}
{'dps': {'1': True, '7': 0, '14': 'memory', '17': '', '18': ''}}
--- OFF ---
DEBUG:building command 7 payload=b'{"devId":"bf256839cbc866aa26yeyc","uid":"bf256839cbc866aa26yeyc","t":"1768324050","dps":{"1":false}}'
DEBUG:sending payload
DEBUG:payload encrypted=b'000055aa000000040000000700000087332e3300000000000000000000000005ce79f17f973575c5f3b202529a10d2ed482913615be0cf5e62a732214bd02079928148c6ee178e35610640a3cf196aed8b0833ddcb840a79ab3d00b5422a032c023980a15c42049143fff860acf21d1a7f60ac058279fbd401f003b4d79044000fb3f9a415dc32b5b503abca466df5cb62aa460000aa55'
DEBUG:received data=b'000055aa00000000000000080000004b00000000332e330000000000002ece0000000128ecbcc865e25c62b3d20e4d52cb91f69bb1f0f3d320ab01586ea0bb05cb8607266c12fccccf93cbedeced4b00ee0cc0e4e4882e0000aa55'
DEBUG:received message=TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00.\xce\x00\x00\x00\x01(\xec\xbc\xc8e\xe2\\b\xb3\xd2\x0eMR\xcb\x91\xf6\x9b\xb1\xf0\xf3\xd3 \xab\x01Xn\xa0\xbb\x05\xcb\x86\x07&l\x12\xfc\xcc\xcf\x93\xcb\xed\xec\xedK\x00\xee\x0c\xc0', crc=3840182318, crc_good=True, prefix=21930, iv=None)
DEBUG:raw unpacked message = TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00.\xce\x00\x00\x00\x01(\xec\xbc\xc8e\xe2\\b\xb3\xd2\x0eMR\xcb\x91\xf6\x9b\xb1\xf0\xf3\xd3 \xab\x01Xn\xa0\xbb\x05\xcb\x86\x07&l\x12\xfc\xcc\xcf\x93\xcb\xed\xec\xedK\x00\xee\x0c\xc0', crc=3840182318, crc_good=True, prefix=21930, iv=None)
DEBUG:decode payload=b'3.3\x00\x00\x00\x00\x00\x00.\xce\x00\x00\x00\x01(\xec\xbc\xc8e\xe2\\b\xb3\xd2\x0eMR\xcb\x91\xf6\x9b\xb1\xf0\xf3\xd3 \xab\x01Xn\xa0\xbb\x05\xcb\x86\x07&l\x12\xfc\xcc\xcf\x93\xcb\xed\xec\xedK\x00\xee\x0c\xc0'
DEBUG:removing 3.x=b'(\xec\xbc\xc8e\xe2\\b\xb3\xd2\x0eMR\xcb\x91\xf6\x9b\xb1\xf0\xf3\xd3 \xab\x01Xn\xa0\xbb\x05\xcb\x86\x07&l\x12\xfc\xcc\xcf\x93\xcb\xed\xec\xedK\x00\xee\x0c\xc0'
DEBUG:decrypting=b'(\xec\xbc\xc8e\xe2\\b\xb3\xd2\x0eMR\xcb\x91\xf6\x9b\xb1\xf0\xf3\xd3 \xab\x01Xn\xa0\xbb\x05\xcb\x86\x07&l\x12\xfc\xcc\xcf\x93\xcb\xed\xec\xedK\x00\xee\x0c\xc0'
DEBUG:decrypted 3.x payload=b'{"dps":{"1":false},"t":1768324049}'
DEBUG:payload type = <class 'bytes'>
DEBUG:decoded results='{"dps":{"1":false},"t":1768324049}'
DEBUG:set_status received data={'dps': {'1': False}, 't': 1768324049}

État après OFF :
DEBUG:status()..............DEBUG:status() received data={'dps': {'1': False, '7': 0, '14': 'memory', '17': '', '18': ''}}
{'dps': {'1': False, '7': 0, '14': 'memory', '17': '', '18': ''}}
</syntaxhighlight>Cette observation permet d’envisager une méthode alternative pour contrôler le switch sans passer par TinyTuya, en reproduisant la trame nécessaire.

SE5 IdO sécurité des objets 2025/2026 b5

2026-01-25T15:16:34Z

Crhanim : /* Utilisation de TinyTuya pour l’analyse de la communication ON/OFF */

== <big>'''Infrastructure Réseau 2025/2026'''</big> ==

L’objectif de cette partie est de mettre en place une '''infrastructure réseau''' intégrant un '''serveur virtuel''' sur Capbreton, connecté au réseau '''''bridgeStudents'''''. Ce serveur héberge les services '''DHCP''', '''DNS''' et une '''mascarade (NAT)''' afin d’assurer la connectivité et l’accès Internet des clients. Ajout d'une '''seconde interface réseau''' au serveur dans le '''VLAN 408''', appartenant au sous-réseau '''172.16.8.0/24.'''

La mise en place d'une '''sécurisation WiFi par WPA2-PSK''' pour garantir un accès protégé, et des tests ont été réalisés pour vérifier la visibilité du SSID, la connexion WiFi, la distribution d’adresses IP et l’accès à Internet.

=== ''<big>Serveur Virtuel : 17/09</big>'' ===

==== <big>Création et configuration de la VM</big> ====
Pour créer la VM : xen-create-image --hostname=SE5-crhanim --dhcp --dir=/usr/local/xen --size=20Gb --memory=2048mb --dist=daedalus --bridge=bridgeStudents

Configuration réseau de la VM : <syntaxhighlight>
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 172.26.145.108
netmask 255.255.255.0
gateway 172.26.145.251
dsn-nameservers 172.26.145.251
# post-up ethtool -K eth0 tx off

#
# The commented out line above will disable TCP checksumming which
# might resolve problems for some users. It is disabled by default
#
</syntaxhighlight>Vérification : <syntaxhighlight>
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=6.27 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 5.717/5.901/6.267/0.258 ms

</syntaxhighlight>

==== <big>Ajout de l'interface dans le VLAN408</big> ====
Configuration de l'interface privé VLAN408 (eth1):<syntaxhighlight>
#VLAN 408
auto eth1
iface eth1 inet static
address 172.16.8.1
netmask 255.255.255.0
#
# The commented out line above will disable TCP checksumming which
# might resolve problems for some users. It is disabled by default
#
</syntaxhighlight>Vérifications avec '''ip a :'''<syntaxhighlight>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:d7:30:83 brd ff:ff:ff:ff:ff:ff
inet 172.26.145.108/24 brd 172.26.145.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2001:660:4401:6050:216:3eff:fed7:3083/64 scope global dynamic mngtmpaddr
valid_lft 989sec preferred_lft 889sec
inet6 2a01:c916:2047:c850:216:3eff:fed7:3083/64 scope global dynamic mngtmpaddr
valid_lft 2591989sec preferred_lft 604789sec
inet6 fe80::216:3eff:fed7:3083/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:d7:30:84 brd ff:ff:ff:ff:ff:ff
inet 172.16.8.0/24 brd 172.16.8.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fed7:3084/64 scope link
valid_lft forever preferred_lft forever
</syntaxhighlight>

Sur Capbreton: dans le fichier de configuration de ma VM : '''etc/xen/SE5-crhanim.cfg'''<syntaxhighlight>
#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:D7:30:83,bridge=bridgeStudents',
'mac=00:16:3E:D7:30:84,bridge=g5_crhanim' ]
</syntaxhighlight>Sur /etc/network/interfaces.d/g5_crhanim

Configuration de l'interface Vlan408 et bridge: g5_crhanim<syntaxhighlight>
auto Trunk.408
iface Trunk.408 inet manual
vlan-raw-device Trunk
up ip link set $IFACE up
down ip link set $IFACE down

auto g5_crhanim
iface g5_crhanim inet manual
bridge_ports Trunk.408
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

=== '''''<big>Sécurisation WiFi par WPA2-PSK : 29/09</big>''''' ===
La connexion au point d’accès s’effectue via le '''port série''' depuis la '''machine hôte''' à l’aide de '''Minicom'''. L’objectif est de configurer les paramètres du WiFi : '''SSID''', '''chiffrement''' et '''VLAN'''.

==== <big>Création et configuration du SSID au VLAN408</big> ====
<syntaxhighlight>
dot11 ssid SE5-crhanim
vlan 408
authentication open
authentication key-management wpa
wpa-psk ascii 0 " "
mbssid guest-mode
exit
interface Dot11Radio1
encryption vlan 408 mode ciphers aes-ccm
ssid SE5-crhanim
mbssid
no shutdown
exit

interface Dot11Radio1.408
encapsulation dot1Q 408
bridge-group 8
exit

interface GigabitEthernet0.408
encapsulation dot1Q 408
bridge-group 8
exit
</syntaxhighlight>Pour vérifier : ap#'''sh dot11 bssid'''<syntaxhighlight>
ap#sh dot11 bssid
Interface BSSID Guest SSID
Dot11Radio1 04da.d2d1.4bf0 Yes SE5-azongo
Dot11Radio1 04da.d2d1.4bf1 Yes SE5-crhanim
Dot11Radio1 04da.d2d1.4bf2 Yes SE5-handrian
</syntaxhighlight>

==== <big>Configuration du serveur DHCP</big> ====
Dans la machine virtuelle, j'ai configuré le fichier : '''/etc/dhcp/dhcpd.conf''' pour définir le réseau du VLAN 408 (172.16.8.0/24). Le serveur attribue automatiquement des adresses IP comprises entre '''172.16.8.100''' et '''172.16.8.200''' aux clients WiFi.<syntaxhighlight>
subnet 172.16.8.0 netmask 255.255.255.0 {
range 172.16.8.100 172.16.8.200;
option routers 172.16.8.1;
#option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
option domain-name-servers 172.16.8.1;
}

</syntaxhighlight>dans /etc/sysctl.conf : j'ai décommenté la ligne : net.ipv4.ip_forward=1

'''sysctl -p /etc/sysctl.conf''' : pour recharger '''configuration sysctl.'''

sysctl net.ipv4.ip_forward : pour vérifier

==== <big>Implémentation du serveur DNS</big> ====

Pour implémenter un serveur DNS, dans le fichier <code>/etc/bind/named.conf.options :</code> <syntaxhighlight>
options {
directory "/var/cache/bind";

recursion yes;
allow-query {172.16.8.0/24; 127.0.0.1;};

forwarders {
8.8.8.8;
1.1.1.1;
};
dnssec-validation auto;

listen-on { 127.0.0.1; 172.16.8.1; };
listen-on-v6 { none; };
};

</syntaxhighlight>

==== <big>Mise en place de la mascarade sur le serveur virtuel</big> 03/10 ====
Pour permettre aux machines du '''VLAN 408 (172.16.8.0/24)''' d’accéder à Internet via le serveur virtuel, j'ai ajouté une '''règle de mascarade''' avec '''iptables:''' <syntaxhighlight>
iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.16.8.0/24
</syntaxhighlight>Cette règle remplace l’adresse source des paquets sortants par celle du serveur, assurant ainsi la traduction d’adresses (NAT).

L’état de la table NAT peut être vérifié avec la commande <code>iptables -t nat -L -v</code>, qui affiche la règle de '''POSTROUTING''' active :<syntaxhighlight>
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
122 51438 MASQUERADE 0 -- * * 172.16.8.0/24 0.0.0.0/0
</syntaxhighlight>Cette configuration permet aux clients connectés au WiFi du VLAN 408 de naviguer sur Internet à travers le serveur virtuel.

=== ''<big>'''Interception de flux:03/10'''</big>'' ===

==== <big>Redirection par DNS</big> ====
J'ai modifié la configuration de '''BIND''' sur le serveur virtuel. Dans le fichier '''/etc/bind/named.conf.local''', une nouvelle zone a été ajoutée pour le domaine '''github.com''' :<syntaxhighlight>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "github.com"{
type master;
file "/etc/bind/db.github.com";

};

</syntaxhighlight>création de la zone db.github.com<syntaxhighlight>
$TTL 604800
@ IN SOA ns.github.com. admin.github.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

;
@ IN NS ns.github.com.
ns IN A 172.16.8.1
@ IN A 172.16.8.1
www IN A 172.16.8.1

</syntaxhighlight>

==== <big>Redirection réseau</big> ====
J'ai ajouté une règle iptables pour rediriger le trafic TCP vers un port local.<syntaxhighlight>
iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REDIRECT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 8080

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
122 51438 MASQUERADE 0 -- * * 172.16.8.0/24 0.0.0.0/0
</syntaxhighlight>

=== '''''<big>Serveur Apache sécurisé: 03/11</big>''''' ===

Commande utilisée pour générer le certificat auto-signé :<syntaxhighlight>
openssl req -x509 -nodes -days 365 \
-newkey rsa:2048 \
-keyout /etc/ssl/apache/apache-selfsigned.key \
-out /etc/ssl/apache/apache-selfsigned.crt \
-subj "/C=FR/ST=Nord/L=Lille/O=Polytech/CN=github.com"
</syntaxhighlight>Configuration pour Apache :

j'ai mis la configuration dans le fichier '''etc/apache2/sites-available/site-github.conf'''

Mise en place d’un hôte virtuel HTTPS sur le port 443 avec le certificat auto-signé et redirection automatique du HTTP (port 80) vers le HTTPS.<syntaxhighlight>
<VirtualHost *:443>
ServerName github.com

DocumentRoot /var/www/html

SSLEngine on
SSLCertificateFile /etc/ssl/apache/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/apache/apache-selfsigned.key

ErrorLog ${APACHE_LOG_DIR}/github-error.log
CustomLog ${APACHE_LOG_DIR}/github-access.log combined

</VirtualHost>

<VirtualHost *:80>
ServerName github.com
Redirect permanent / https://github.com/
</VirtualHost>
</syntaxhighlight>Pour activer la configuration du site et recharger Apache : <syntaxhighlight>
a2ensite site-github.conf
service apache2 reload
</syntaxhighlight>Vérification : <syntaxhighlight>
:~#ss -tlnp | grep 443
LISTEN 0 128 *:443 *:* users:(("apache2",pid=1485,fd=6),("apache2",pid=1484,fd=6),("apache2",pid=1481,fd=6))
:~# ss -tlnp | grep 80
LISTEN 0 128 *:80 *:* users:(("apache2",pid=1485,fd=4),("apache2",pid=1484,fd=4),("apache2",pid=1481,fd=4))
</syntaxhighlight>

=== '''''<big>Machine virtuelle Android : 03/11</big>''''' ===
La redirection HTTPS est bloquée par les '''certificats X509'''. Comme il est difficile d’ajouter des certificats sur un téléphone moderne, une solution consiste à utiliser une '''machine virtuelle Android''' d'une ancienne version, sur laquelle il est possible d’ajouter les certificats nécessaires.

==== <big>''Tentative installation VM en utilisant QEMU''</big> ====
Pour l'installation de la VM sur PC en utilisant QEMU , j'ai suivi le tutoriel de ce site : https://help.clouding.io/hc/en-us/articles/4405454393756-How-to-virtualize-Android-with-QEMU-KVM. Pour la version, j'ai pris la version android 6.

Après installation j'ai lancé la VM en utilisant cette commande : <syntaxhighlight>
qemu-system-x86_64 -m 2048
-enable-kvm -drive file=~/VM_androidv6.img,format=qcow2
-cdrom ~/Downloads/android-x86_64-6.0-r1.iso
-boot d -net nic -net user -display sdl
</syntaxhighlight>La VM se connecte à Internet en utilisant la connexion du PC hôte, et elle ne détecte pas les WiFi disponible. Pour résoudre ce problème, nous avons modifié le fichier de configuration de la zabeth pour la connecter au wifi.

==== <big>''Configuration Wifi pour connecter la VM : 04/'''''11'''</big> ====
Pour cela, j'ai modifié le fichier /etc/network/interfaces. L'interface wlan1 est configurée en mode DHCP pour se connecter automatiquement au réseau WiFi avec le SSID “SE5-crhanim”, et une sécurité WPA2-PSK.<syntaxhighlight>
>>ip link set bridge down

/etc/network/interfaces

iface wlan1 inet dhcp
wpa-ssid SE5-crhanim
wpa-key-mgmt WPA-PSK
wpa-psk Chaymae08
</syntaxhighlight>Lors de cette configuration, la connexion échouait malgré une détection correcte du réseau. La cause était l’absence du paquet wpa_supplicant, nécessaire pour l’authentification sur les réseaux Wi-Fi sécurisés.

L’installation du paquet avec la commande suivante m'a permis de résoudre le problème : <syntaxhighlight>
sudo apt install wpasupplicant
</syntaxhighlight>

==== ''<big>Problèmes rencontrés</big>'' ====
L’installation de l’application Nedis Smart Life, utilisée pour gérer l’objet connecté, s’est déroulée avec succès. Cependant, une erreur est survenue lors de son lancement sur la machine android virtuelle.

==== ''<big>Tentative installation de Android x86_64 en utilisant les commandes du Dockerfile</big>'' ====
Les étapes réalisées (sur zabeth08 et sans Docker ) :

* Installation des dépendances nécessaires (OpenJDK, outils de compilation, librairies graphiques).
* Téléchargement des Android Command Line Tools.
* Configuration des variables d’environnement Android (ANDROID_HOME, ANDROID_SDK_ROOT).
* Installation des composants du SDK Android via sdkmanager (platform-tools, emulator, images système Android 30).
* Création d’un AVD avec avdmanager : '''avdmanager create avd -n test_avd -k "system-images;android-30;google_apis;x86_64"'''.
* Tentative de lancement de l’émulateur Android en ligne de commande.

L’objectif est de faire tourner un émulateur Android directement sur la VM pour pouvoir utiliser l’application associée à l’objet connecté. Toutefois, l’appareil virtuel lancé présentait de nombreux dysfonctionnements et manquait de stabilité, rendant impossible l’utilisation correcte du téléphone.

==== ''<big>Création de VM en utilisant Android studio</big>'' ====

===== Installation de Android studio =====
Pour le téléchargement d’Android Studio j'ai utilisé la dernière version depuis le site officiel. Une fois l’archive obtenue au format .tar.gz, je l’ai décompressée à l’aide de la commande '''tar -xvf android-studio-*.tar.gz''', ce qui a extrait l’environnement complet d’Android Studio. Comme il s’agit d’un logiciel installé manuellement, je l’ai ensuite déplacé dans le répertoire standard /'''opt'''.

Pour lancer l'application : '''/opt/android-studio/bin/studio.sh'''

Android Studio a téléchargé et installé les composants suivants : Android SDK Platform 30 et 36, Build-tools 36.1.0, Platform-tools, System Images, Sources Android.

Tout le SDK a été installé dans le répertoire : '''/home/crhanim/android/'''

===== Création d'un nouvel AVD. =====
Dans Android Studio : Ouverture du Device Manager : Tools → Device Manager

Création d’un nouvel appareil virtuel :

Category : Phone

Device choisi : Pixel 4

System Image : Android 10 (API 29)

Pour un premier essai, j’ai choisi une image ARM pour créer mon appareil virtuel. Cependant, un problème est survenu lors du lancement de l’AVD :

« AVD's CPU Architecture 'arm64' is not supported by the QEMU2 emulator on x86_64 host ».

'''Solution :''' J’ai finalement opté pour une image x86_64 (Google APIs x86_64), qui est pleinement prise en charge par l’émulateur.

Après ce changement, j’ai pu finaliser la configuration et créer correctement l’AVD.

===== '''APK utilisé pour Nedis smartLife ''' =====
Pour installer l'application de l'objet connecté, j'ai utilisé le lien suivant : <nowiki>https://nedis-smartlife.en.aptoide.com/app</nowiki> .Cette fois ci l'application se lance correctement.

==== ''<big>Ajout de certificat dans la VM</big>'' ====

===== Première tentative =====
Pour obtenir un accès root sur l’émulateur, j'ai installé l'outil Magisk, lien d'installation: <nowiki>https://gitlab.com/newbit/rootAVD</nowiki>.

les commandes utilisées pour mettre le certificat sur la VM :<syntaxhighlight>
adb root
adb shell avbctl disable-verification
adb reboot
adb wait-for-device root
adb remount
adb push 9ab369ad.0 /system/etc/security/cacerts
</syntaxhighlight>Cependant, la commande adb push échoue : Erreur d’accès : le répertoire est en lecture seule (Read-only file system).

Même après adb remount, la partition /system reste non modifiable.

Pour contourner ce problème, j’ai tenté de relancer l’émulateur en mode système modifiable avec la commande :<syntaxhighlight>
emulator -avd <nom_avd> -writable-system -gpu swiftshader_indirect -no-snapshot -no-boot-anim &
</syntaxhighlight>Ce lancement permet bien de modifier temporairement /system, mais il ne force pas un redémarrage propre de l’AVD. Donc le certificat est ajouté uniquement en mémoire, et disparaît dès que l’AVD est redémarré, et les modifications ne sont pas persistées sur l’image système.

===== Deuxième tentative =====
J'ai opté pour une méthode alternative : créer un module Magisk permettant d’injecter automatiquement le certificat dans le système au démarrage. Cette approche contourne la protection en lecture seule (dm-verity) puisqu’un module Magisk monte un overlay persistant au boot.

Utilisation de module magisk --> réussie. Le certificat est ajoutée avec succès et mon site github.com est bien redirigé.
[[Fichier:Github redirigé.png|néant|vignette]]

== '''<big>Objet : Interrupteur connecté</big>''' ==
L'objectif de cette partie du TP est d'analyser la communication réseau entre un smart wall switch et un téléphone (l'application nedis smartlife) afin de comprendre le trajet des paquets et les protocoles utilisés. Pour essayer de forger mon propre paquet qui permet d'allumer/éteindre l'interrupteur sans passer par l'application.

l'Interrupteur peut être commandé à distance par l'application mobile Nedis Smart Life pour l'éteindre ou allumer, j'ai fait les tests avec mon telephone et la VM android --> réussi.

=== <big>''Analyse du trafic en utilisant wireshark''</big> ===
J'ai identifié l'adresse IP et mac de l'interrupteur connecté :

IP : 172.16.8.105

MAC : d8:1f:12:98:93:58

Sur wireshark, j'ai procédé à plusieurs captures avec différents filtres pour comprendre la communication.

Filtre utilisé : '''ip.addr == 172.16.8.105.'''

J'ai observé du trafic UDP en broadcast vers 255.255.255.255 sur le port 6667. L'interrupteur envoie des annonces périodiques, toutes les ~5 secondes contenant la signature 000055aa et son état actuel chiffré.

le '''0055aa''' corrrespond à la signature Tuya: le header fixé par le protocole de communication qu'utilise Tuya.
[[Fichier:Trafic.png|centré|vignette|624x624px]]
Filtre : '''ip.addr == 172.16.8.105 && ip.addr == 172.16.8.104'''

Communication directe téléphone ↔ interrupteur

Aucun paquet capturé. Ce qui est normal ca indique qu'il n'existe aucune communication directe entre le téléphone et l'interrupteur sur le réseau local. Toutes les

commandes passent par les serveurs cloud Tuya.

Filtre utilisé : '''ip.addr == 172.16.8.104'''

'''172.16.8.104''' est l'adresse IP de la machine Android VM ou j'éxécute l'application Nedis Smart Life.
[[Fichier:Capture trames.png|centré|vignette|927x927px]]
Ce filtre permet de capturer l'ensemble de l'activité réseau du téléphone, notamment les connexions HTTPS/TLS établies vers les serveurs cloud Tuya, les paquets "Application Data" chiffrés contenant les commandes d'allumage et d'extinction, ainsi que les confirmations renvoyées par les serveurs. J'ai pu identifier que toutes les commandes transitent par des serveurs AWS localisés en Europe (3.78.92.3, 18.194.10.142, 193.48.57.31), communiquant sur le port 443 via le protocole HTTPS, révélant ainsi une architecture entièrement basée sur le cloud.

=== ''<big>Utilisation de TinyTuya pour l’analyse de la communication ON/OFF</big>'' ===
Dans cette partie, j'ai utilisé l’outil TinyTuya afin d’analyser la communication entre le Smart Wall Switch Tuya et le téléphone lors des commandes ON / OFF.

TinyTuya est une bibliothèque Python qui permet de communiquer localement avec des appareils Tuya (sans passer par le cloud), en utilisant le protocole Tuya LAN. Elle permet notamment de découvrir les appareils sur le réseau, de récupérer leurs informations et d’envoyer des commandes (ON/OFF).

Après avoir créé un environnement Python, j'ai installé les bibliothèques nécessaires :<syntaxhighlight>
python3 -m pip install pycryptodome
python3 -m pip install tinytuya
</syntaxhighlight>Ensuite, j'ai utilisé la commande python -m tinytuya scan : qui permet de scanner le réseau local afin de détecter les appareils Tuya présents.<syntaxhighlight>
root@zabeth08:~/penv# bin/python3 -m tinytuya scan
TinyTuya (Tuya device scanner) [1.17.4]

Scanning on UDP ports 6666 and 6667 and 7000 for devices for 18 seconds...

New Broadcast from App at 172.16.8.104 - {'from': 'app', 'ip': '172.16.8.104'}
Unknown v3.3 Device Product ID = key7axydcvmea3x9 [Valid Broadcast]:
Address = 172.16.8.105 Device ID = bf256839cbc866aa26yeyc (len:22) Local Key = Version = 3.3 Type = default, MAC =
No Stats for 172.16.8.105: DEVICE KEY required to poll for status
New Broadcast from App at 127.0.0.1 - {'from': 'app', 'ip': '10.0.2.16'}
Scan completed in 18.0288 seconds

Scan Complete! Found 1 devices.
Broadcasted: 1
Versions: 3.3: 1
Unknown Devices: 1

Saving device snapshot data to snapshot.json
</syntaxhighlight>Pour pouvoir communiquer correctement avec l’appareil, j'ai créé un compte développeur sur eu.platform.tuya.com et j'ai ajouté le Smart Wall Switch sur la plateforme en utilisant l’application SmartLife pour scanner le QR code et lier l’appareil au compte Tuya. Une fois l’appareil lié au compte Tuya, j'ai lancé :<syntaxhighlight>
python -m tinytuya wizard
</syntaxhighlight>Cette commande permet de scanner le réseau et elle récupère les informations depuis la plateforme Tuya pour générer automatiquement les fichiers de configuration.<syntaxhighlight>
Configuration Data Saved to tinytuya.json

{
"apiKey": "pwtm5xhprm393rxf8jsh",
"apiSecret": "aef15868be684109b0cb71a8d4681e2d",
"apiRegion": "eu",
"apiDeviceID": "bf256839cbc866aa26yeyc"
}

</syntaxhighlight>À la fin de cette étape, le fichier tinytuya.json est créé et il contient les clés d’API Tuya et les informations nécessaires pour récupérer automatiquement les paramètres du Smart Switch. Ces informations sont ensuite utilisées pour créer le fichier devices.json, indispensable à la communication locale avec l’appareil.

Pour vérifier et afficher les informations complètes du Smart Switch, on lance la commande : <syntaxhighlight>
python -m tinytuya devices
</syntaxhighlight>cette commande génére le fichier devices.json, qui contient l'identifiant et la clé de l'interrupteur, l’adresse IP, le modèle de l’interrupteur et la liste des Data Points (DP), utilisés par l’appareil. Les Data Points (DP) identifient les différentes fonctionnalités du switch.<syntaxhighlight>
root@zabeth08:~/penv# bin/python3 -m tinytuya devices

TinyTuya (Tuya device scanner) [1.17.4]

Loaded devices.json - 1 devices:

Device Listing

[
{
"name": "Interrupteur connect\u00e9",
"id": "bf256839cbc866aa26yeyc",
"key": "<UfC-OoB>RVu=@t>",
"mac": "d8:1f:12:98:93:58",
"uuid": "ec7b74129b6b536c",
"sn": "TXWDC05ME002D9",
"category": "kg",
"product_name": "Wall switch",
"product_id": "bkmg3ht7emkqwv91",
"biz_type": 18,
"model": "WIFIWS10WT",
"sub": false,
"icon": "https://images.tuyaeu.com/smart/icon/ay1513237774906SMBA3/456c398229a72ede67a148535fd2a5ab.png",
"mapping": {
"1": {
"code": "switch_1",
"type": "Boolean",
"values": {}
},
"7": {
"code": "countdown_1",
"type": "Integer",
"values": {
"unit": "s",
"min": 0,
"max": 86400,
"scale": 0,
"step": 1
}
},
"14": {
"code": "relay_status",
"type": "Enum",
"values": {
"range": [
"power_off",
"power_on",
"last"
]
}
},
"17": {
"code": "cycle_time",
"type": "String",
"values": "{}"
},
"18": {
"code": "random_time",
"type": "String",
"values": "{}"
},
"19": {
"code": "switch_inching",
"type": "String",
"values": "{}"
}
},
"ip": "172.16.8.105",
"version": "3.3"
}
]
</syntaxhighlight>À partir des informations contenues dans <code>devices.json</code>, j ’ai développé un script Python en utilisant la librairie '''TinyTuya''' afin de communiquer directement avec le Smart Wall Switch sur le réseau local. Ce script me permet de récupérer l’état actuel de l’interrupteur, d’envoyer une commande '''ON''', puis une commande '''OFF.''' L’activation du mode debug affiche les différentes étapes de la communication, notamment la construction des messages Tuya, leur chiffrement, leur envoi sur le réseau local ainsi que les réponses retournées par l’interrupteur.

Voici le code python utilisé : <syntaxhighlight lang="python">
import tinytuya
import time

DEVICE_ID = "bf256839cbc866aa26yeyc"
LOCAL_KEY = "<UfC-OoB>RVu=@t>"
DEVICE_IP = "172.16.8.105"
VERSION = 3.3

tinytuya.set_debug(True)

# Création du device
d = tinytuya.OutletDevice(
dev_id=DEVICE_ID,
address=DEVICE_IP,
local_key=LOCAL_KEY
)

d.set_version(VERSION)

print("État initial :")
print(d.status())

print("\n--- ON ---")
d.turn_on()
time.sleep(2)

print("\nÉtat après ON :")
print(d.status())

print("\n--- OFF ---")
d.turn_off()
time.sleep(2)

print("\nÉtat après OFF :")
print(d.status())
</syntaxhighlight>

SE5 IdO sécurité des objets 2025/2026 b5

2026-01-25T14:45:41Z

Crhanim : /* Utilisation de TinyTuya pour l’analyse de la communication ON/OFF */

SE5 IdO sécurité des objets 2025/2026 b5

2026-01-25T09:02:38Z

Crhanim : /* Analyse du trafic en utilisant wireshark */

SE5 IdO sécurité des objets 2025/2026 b5

2026-01-25T09:00:36Z

Crhanim : /* Deuxième tentative */

Fichier:Capture trames.png

2026-01-25T08:57:51Z

Crhanim :

activ reseau

Fichier:Trafic.png

2026-01-25T08:53:23Z

Crhanim :

UDP_broadcast

SE5 IdO sécurité des objets 2025/2026 b5

2025-12-13T10:11:33Z

Crhanim : /* APK utilisé pour Nedis smartLife : */

Fichier:Github redirigé.png

2025-12-13T10:09:16Z

Crhanim :

mon site github.com est bien redirigé

SE5 IdO sécurité des objets 2025/2026 b5

2025-12-13T09:58:18Z

Crhanim : Installation android studio et certificat

SE5 IdO sécurité des objets 2025/2026 b5

2025-12-13T09:40:40Z

Crhanim : /* Machine virtuelle Android : 03/11 */

SE5 IdO sécurité des objets 2025/2026 b5

2025-11-07T21:31:33Z

Crhanim : /* Sécurisation WiFi par WPA2-PSK : 29/09 */

SE5 IdO sécurité des objets 2025/2026 b5

2025-11-06T19:16:44Z

Crhanim : /* Serveur Apache sécurisé: 03/11 */

SE5 IdO sécurité des objets 2025/2026 b5

2025-11-06T18:30:43Z

Crhanim : /* Création et configuration de la VM */

SE5 IdO sécurité des objets 2025/2026 b5

2025-11-06T18:28:26Z

Crhanim : /* Serveur Virtuel : */ organisation en sous titres

SE5 IdO sécurité des objets 2025/2026 b5

2025-11-03T14:18:22Z

Crhanim : /* Redirection réseau */

== Serveur Virtuel : ==
Pour créer la VM : xen-create-image --hostname=SE5-crhanim --dhcp --dir=/usr/local/xen --size=20Gb --memory=2048mb --dist=daedalus --bridge=bridgeStudents

Configuration réseau de la VM : <syntaxhighlight>
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 172.26.145.108
netmask 255.255.255.0
gateway 172.26.145.251
dsn-nameservers 172.26.145.251
# post-up ethtool -K eth0 tx off

#
# The commented out line above will disable TCP checksumming which
# might resolve problems for some users. It is disabled by default
#
</syntaxhighlight>Vérification : <syntaxhighlight>
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=6.27 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 5.717/5.901/6.267/0.258 ms

</syntaxhighlight>Ajout d'une interface dans le VLAN 408 :<syntaxhighlight>
#VLAN 408
auto eth1
iface eth1 inet static
address 172.16.8.1
netmask 255.255.255.0
#
# The commented out line above will disable TCP checksumming which
# might resolve problems for some users. It is disabled by default
#
</syntaxhighlight>ip a<syntaxhighlight>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:d7:30:83 brd ff:ff:ff:ff:ff:ff
inet 172.26.145.108/24 brd 172.26.145.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2001:660:4401:6050:216:3eff:fed7:3083/64 scope global dynamic mngtmpaddr
valid_lft 989sec preferred_lft 889sec
inet6 2a01:c916:2047:c850:216:3eff:fed7:3083/64 scope global dynamic mngtmpaddr
valid_lft 2591989sec preferred_lft 604789sec
inet6 fe80::216:3eff:fed7:3083/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:d7:30:84 brd ff:ff:ff:ff:ff:ff
inet 172.16.8.0/24 brd 172.16.8.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fed7:3084/64 scope link
valid_lft forever preferred_lft forever
</syntaxhighlight>

Sur Capbreton: etc/xen/SE5-crhanim.cfg<syntaxhighlight>
#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:D7:30:83,bridge=bridgeStudents',
'mac=00:16:3E:D7:30:84,bridge=g5_crhanim' ]
</syntaxhighlight>Sur /etc/network/interfaces.d/g5_crhanim

Configuration de l'interface Vlan408 et bridge: g5_crhanim<syntaxhighlight>
auto Trunk.408
iface Trunk.408 inet manual
vlan-raw-device Trunk
up ip link set $IFACE up
down ip link set $IFACE down

auto g5_crhanim
iface g5_crhanim inet manual
bridge_ports Trunk.408
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

== Sécurisation WiFi par WPA2-PSK ==
<syntaxhighlight>
dot11 ssid SE5-crhanim
vlan 408
authentication open
authentication key-management wpa
wpa-psk ascii 0 " "
mbssid guest-mode
exit
interface Dot11Radio1
encryption vlan 408 mode ciphers aes-ccm
ssid SE5-crhanim
mbssid
no shutdown
exit

interface Dot11Radio1.408
encapsulation dot1Q 408
bridge-group 8
exit

interface GigabitEthernet0.408
encapsulation dot1Q 408
bridge-group 8
exit
</syntaxhighlight>Pour vérifier : ap#sh dot11 bssid<syntaxhighlight>
ap#sh dot11 bssid
Interface BSSID Guest SSID
Dot11Radio1 04da.d2d1.4bf0 Yes SE5-azongo
Dot11Radio1 04da.d2d1.4bf1 Yes SE5-crhanim
Dot11Radio1 04da.d2d1.4bf2 Yes SE5-handrian
</syntaxhighlight>dans la VM : /etc/dhcp/dhcpd.conf<syntaxhighlight>
subnet 172.16.8.0 netmask 255.255.255.0 {
range 172.16.8.100 172.16.8.200;
option routers 172.16.8.1;
#option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
option domain-name-servers 172.16.8.1;
}

</syntaxhighlight>dans /etc/sysctl.conf : j'ai décommenté la ligne : net.ipv4.ip_forward=1

sysctl -p /etc/sysctl.conf : pour recharger '''configuration sysctl.'''

sysctl net.ipv4.ip_forward : pour vérifier

Pour implémenter un serveur DNS, dans le fichier <code>/etc/bind/named.conf.options :</code> <syntaxhighlight>
options {
directory "/var/cache/bind";

recursion yes;
allow-query {172.16.8.0/24; 127.0.0.1;};

forwarders {
8.8.8.8;
1.1.1.1;
};
dnssec-validation auto;

listen-on { 127.0.0.1; 172.16.8.1; };
listen-on-v6 { none; };
};

</syntaxhighlight>Pour implémenter une mascarade sur le serveur virtuel : <syntaxhighlight>
iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.16.8.0/24
</syntaxhighlight><syntaxhighlight>
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
122 51438 MASQUERADE 0 -- * * 172.16.8.0/24 0.0.0.0/0
</syntaxhighlight>

== Interception de flux ==

=== Redirection par DNS ===

Modification de /etc/bind/named.conf.local<syntaxhighlight>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "github.com"{
type master;
file "/etc/bind/db.github.com";

};

</syntaxhighlight>création de la zone db.github.com<syntaxhighlight>
$TTL 604800
@ IN SOA ns.github.com. admin.github.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

;
@ IN NS ns.github.com.
ns IN A 172.16.8.1
@ IN A 172.16.8.1
www IN A 172.16.8.1

</syntaxhighlight>

=== Redirection réseau ===
<syntaxhighlight>
iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REDIRECT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 8080

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
122 51438 MASQUERADE 0 -- * * 172.16.8.0/24 0.0.0.0/0
</syntaxhighlight>

== Serveur Apache sécurisé ==
Pour générer le certificat auto-signé :<syntaxhighlight>
openssl req -x509 -nodes -days 365 \
-newkey rsa:2048 \
-keyout /etc/ssl/apache/apache-selfsigned.key \
-out /etc/ssl/apache/apache-selfsigned.crt \
-subj "/C=FR/ST=Nord/L=Lille/O=Polytech/CN=github.com"
</syntaxhighlight>Configuration HTTPs pour Apache :

j'ai mis la configuration dans le fichier etc/apache2/sites-available/site-github.conf<syntaxhighlight>
<VirtualHost *:443>
ServerName github.com

DocumentRoot /var/www/html

SSLEngine on
SSLCertificateFile /etc/ssl/apache/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/apache/apache-selfsigned.key

ErrorLog ${APACHE_LOG_DIR}/github-error.log
CustomLog ${APACHE_LOG_DIR}/github-access.log combined

</VirtualHost>

<VirtualHost *:80>
ServerName github.com
Redirect permanent / https://github.com/
</VirtualHost>
</syntaxhighlight><syntaxhighlight>
a2ensite site-github.conf
service apache2 reload
</syntaxhighlight>Vérification : <syntaxhighlight>
:~#ss -tlnp | grep 443
LISTEN 0 128 *:443 *:* users:(("apache2",pid=1485,fd=6),("apache2",pid=1484,fd=6),("apache2",pid=1481,fd=6))
:~# ss -tlnp | grep 80
LISTEN 0 128 *:80 *:* users:(("apache2",pid=1485,fd=4),("apache2",pid=1484,fd=4),("apache2",pid=1481,fd=4))
</syntaxhighlight>

SE5 IdO sécurité des objets 2025/2026

2025-11-03T13:24:08Z

Crhanim : /* Répartition des binômes pour le module de sécurité des objets */

= Infrastructure réseau pour 2025/2026 =

== Serveur virtuel ==

Créez un serveur virtuel sur <code>capbreton</code> par binôme. Préfixez le nom du serveur par <code>SE5-</code>. Le serveur doit avoir une unique interface dans le commutateur virtuel <code>bridgeStudents</code>.

Prenez une adresse IPv4 à partir de <code>172.26.145.100</code> et utilisez, comme routeur, l'adresse IPv4 <code>172.26.145.251</code>. Le routeur à cette adresse est configuré pour faire passer vos machines par un dispositif de type mascarade.

Par la suite ajoutez à votre serveur une interface dans le VLAN <code>400+X</code> numérotée dans le sous-réseau IPv4 <code>172.16.X.0/24</code>. Bien entendu <code>X</code> est différent d'un binôme à l'autre (et <code>X</code>>1).

== Point d'accès WiFi ==

Installez un ou plusieurs point d'accès WiFi Cisco sur un port de commutateur en mode trunk. Tentez d'associer une adresse d'administration à ce point d'accès dans le VLAN 50 (adresse d'administration en <code>172.26.145.Y</code>).

== Sécurisation WiFi par WPA2-PSK ==

Créez un SSID associé à votre VLAN et configuré pour une identification par WPA2-PSK.

De plus implantez les services suivant sur votre serveur virtuel :
* configuration par DHCP pour les clients WiFi, utilisez les adresses d'octet de poids faible <code>100</code> à <code>200</code> du réseau IPv4 de votre VLAN privé. Donner l'adresse de votre machine mandataire comme routeur par défaut et comme serveur DNS ;
* Implanter un serveur DNS minimal sur votre serveur virtuel (DNS transitaire ou DNS forwarder en patoi) ;
* Implanter une mascarade sur votre serveur virtuel entre votre VLAN privé et le routeur du réseau des salles de projets.

Vous pouvez tester la visibilité de votre SSID, l'identification WiFi, le serveur DHCP et enfin l'accès à Internet en utilisant votre téléphone portable ou la carte WiFi des zabeth.

= Interception de flux =

L'étude d'applications mobiles peut passer par la redirection de flux TCP pour de la rétro-ingénierie. Deux voies sont possibles, une redirection par DNS ou une redirection de flux TCP vers un port local.

== Redirection par DNS ==

Ajoutez une zone primaire à votre serveur DNS avec le nom Internet que vous souhaitez rediriger vers votre machine locale.

== Redirection réseau ==

Ajoutez des règles <code>iptables</code>/<code>nftables</code> pour rediriger un flux TCP vers un port local.

== Serveur apache sécurisé ==

En régle générale, c'est un flux HTTPS que vous souhaitez rediriger, vous avez donc besoin d'un serveur Web local en mode sécurisé (HTTPS).

= Machine virtuelle <code>android</code> =

La redirection de flux HTTPS est problématique à cause de la protection par certificat X509. Pour contourner cette protection, une solution consiste à ajouter des autorités de certification sur l'appareil où l'application mobile est installée. Pour ce faire il est probable qu'il faille un contrôle important sur l'OS de l'appareil. Comme vous pouvez rechigner à rooter votre mobile, une machine virtuelle <code>android</code> semble adaptée.

Il vous est proposé de tester de créer une machine virtuelle <code>android</code> soit par émulation d'un ARM en utilisant <code>QEMU</code> sur un PC ordinaire soit en utilisant <code>KVM</code> sur une Raspberry Pi.

= Répartition des binômes pour le module de sécurité des objets =

Donnez les élèves dans chaque binôme.

{| class="wikitable"
! Binôme !! Elèves !! Nom du serveur virtuel !! N° du VLAN
|-
| [[SE5 IdO sécurité des objets 2025/2026 b1 | Cahier b1]] || Victorien Détrez || SE5-serveur || n°410
|-
| [[SE5 IdO sécurité des objets 2025/2026 b2 | Cahier b2]] || Kaoutar El Bachiri || SE5-kelbachi || n°409
|-
| [[SE5 IdO sécurité des objets 2025/2026 b3 | Cahier b3]] || Heriniaina Raissa Andrianirintsoa || SE5-serveur || n°
|-
| [[SE5 IdO sécurité des objets 2025/2026 b4 | Cahier b4]] || Abdel Zongo || SE5-serveur || n°
|-
| [[SE5 IdO sécurité des objets 2025/2026 b5 | Cahier b5]] || Chaymae Rhanim || SE5-serveur || n°408
|-
|}

SE5 IdO sécurité des objets 2025/2026 b5

2025-10-03T10:43:42Z

Crhanim : /* Redirection réseau */

SE5 IdO sécurité des objets 2025/2026 b5

2025-10-03T10:36:38Z

Crhanim : /* Redirection par DNS */

SE5 IdO sécurité des objets 2025/2026 b5

2025-10-03T10:34:57Z

Crhanim : /* Redirection par DNS */

== Serveur Virtuel : ==
Pour créer la VM : xen-create-image --hostname=SE5-crhanim --dhcp --dir=/usr/local/xen --size=20Gb --memory=2048mb --dist=daedalus --bridge=bridgeStudents

Configuration réseau de la VM : <syntaxhighlight>
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 172.26.145.108
netmask 255.255.255.0
gateway 172.26.145.251
dsn-nameservers 172.26.145.251
# post-up ethtool -K eth0 tx off

#
# The commented out line above will disable TCP checksumming which
# might resolve problems for some users. It is disabled by default
#
</syntaxhighlight>Vérification : <syntaxhighlight>
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=6.27 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 5.717/5.901/6.267/0.258 ms

</syntaxhighlight>Ajout d'une interface dans le VLAN 408 :<syntaxhighlight>
#VLAN 408
auto eth1
iface eth1 inet static
address 172.16.8.1
netmask 255.255.255.0
#
# The commented out line above will disable TCP checksumming which
# might resolve problems for some users. It is disabled by default
#
</syntaxhighlight>ip a<syntaxhighlight>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:d7:30:83 brd ff:ff:ff:ff:ff:ff
inet 172.26.145.108/24 brd 172.26.145.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2001:660:4401:6050:216:3eff:fed7:3083/64 scope global dynamic mngtmpaddr
valid_lft 989sec preferred_lft 889sec
inet6 2a01:c916:2047:c850:216:3eff:fed7:3083/64 scope global dynamic mngtmpaddr
valid_lft 2591989sec preferred_lft 604789sec
inet6 fe80::216:3eff:fed7:3083/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:d7:30:84 brd ff:ff:ff:ff:ff:ff
inet 172.16.8.0/24 brd 172.16.8.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fed7:3084/64 scope link
valid_lft forever preferred_lft forever
</syntaxhighlight>

Sur Capbreton: etc/xen/SE5-crhanim.cfg<syntaxhighlight>
#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:D7:30:83,bridge=bridgeStudents',
'mac=00:16:3E:D7:30:84,bridge=g5_crhanim' ]
</syntaxhighlight>Sur /etc/network/interfaces.d/g5_crhanim

Configuration de l'interface Vlan408 et bridge: g5_crhanim<syntaxhighlight>
auto Trunk.408
iface Trunk.408 inet manual
vlan-raw-device Trunk
up ip link set $IFACE up
down ip link set $IFACE down

auto g5_crhanim
iface g5_crhanim inet manual
bridge_ports Trunk.408
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

== Sécurisation WiFi par WPA2-PSK ==
<syntaxhighlight>
dot11 ssid SE5-crhanim
vlan 408
authentication open
authentication key-management wpa
wpa-psk ascii 0 " "
mbssid guest-mode
exit
interface Dot11Radio1
encryption vlan 408 mode ciphers aes-ccm
ssid SE5-crhanim
mbssid
no shutdown
exit

interface Dot11Radio1.408
encapsulation dot1Q 408
bridge-group 8
exit

interface GigabitEthernet0.408
encapsulation dot1Q 408
bridge-group 8
exit
</syntaxhighlight>Pour vérifier : ap#sh dot11 bssid<syntaxhighlight>
ap#sh dot11 bssid
Interface BSSID Guest SSID
Dot11Radio1 04da.d2d1.4bf0 Yes SE5-azongo
Dot11Radio1 04da.d2d1.4bf1 Yes SE5-crhanim
Dot11Radio1 04da.d2d1.4bf2 Yes SE5-handrian
</syntaxhighlight>dans la VM : /etc/dhcp/dhcpd.conf<syntaxhighlight>
subnet 172.16.8.0 netmask 255.255.255.0 {
range 172.16.8.100 172.16.8.200;
option routers 172.16.8.1;
#option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
option domain-name-servers 172.16.8.1;
}

</syntaxhighlight>dans /etc/sysctl.conf : j'ai décommenté la ligne : net.ipv4.ip_forward=1

sysctl -p /etc/sysctl.conf : pour recharger '''configuration sysctl.'''

sysctl net.ipv4.ip_forward : pour vérifier

Pour implémenter un serveur DNS, dans le fichier <code>/etc/bind/named.conf.options :</code> <syntaxhighlight>
options {
directory "/var/cache/bind";

recursion yes;
allow-query {172.16.8.0/24; 127.0.0.1;};

forwarders {
8.8.8.8;
1.1.1.1;
};
dnssec-validation auto;

listen-on { 127.0.0.1; 172.16.8.1; };
listen-on-v6 { none; };
};

</syntaxhighlight>Pour implémenter une mascarade sur le serveur virtuel : <syntaxhighlight>
iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.16.8.0/24
</syntaxhighlight><syntaxhighlight>
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
122 51438 MASQUERADE 0 -- * * 172.16.8.0/24 0.0.0.0/0
</syntaxhighlight>

== Redirection par DNS ==
Modification de /etc/bind/named.conf.local<syntaxhighlight>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "github.com"{
type master;
file "/etc/bind/db.github.com";

};

</syntaxhighlight>création de la zone db.github.com<syntaxhighlight>
$TTL 604800
@ IN SOA ns.github.com. admin.github.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

;
@ IN NS ns.github.com.
ns IN A 172.16.8.1
@ IN A 172.16.8.1
www IN A 172.16.8.1

</syntaxhighlight>

SE5 IdO sécurité des objets 2025/2026 b5

2025-10-03T10:30:44Z

Crhanim :

SE5 IdO sécurité des objets 2025/2026 b5

2025-10-03T09:47:07Z

Crhanim :

SE5 IdO sécurité des objets 2025/2026 b5

2025-09-29T11:00:46Z

Crhanim :

SE5 IdO sécurité des objets 2025/2026 b5

2025-09-29T10:45:19Z

Crhanim :

SE5 IdO sécurité des objets 2025/2026 b5

2025-09-29T10:18:07Z

Crhanim :