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

De wiki-se.plil.fr
Aller à la navigation Aller à la recherche

Infrastructure Réseau 2025/2026

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.

Serveur Virtuel : 17/09

Création et configuration de la VM

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  : 

# 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
#

Vérification : 

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

Ajout de l'interface dans le VLAN408

Configuration de l'interface privé VLAN408 (eth1):

#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
#

Vérifications avec ip a :

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

Sur Capbreton: dans le fichier de configuration de ma VM : etc/xen/SE5-crhanim.cfg

#
#  Networking
#
dhcp        = 'dhcp'
vif         = [ 'mac=00:16:3E:D7:30:83,bridge=bridgeStudents',
                'mac=00:16:3E:D7:30:84,bridge=g5_crhanim' ]

Sur /etc/network/interfaces.d/g5_crhanim Configuration de l'interface Vlan408 et bridge: g5_crhanim

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

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

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.

Création et configuration du SSID au VLAN408

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

Pour vérifier : ap#sh dot11 bssid

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

Configuration du serveur DHCP

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.

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;
}

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

Implémentation du serveur DNS

Pour implémenter un serveur DNS, dans le fichier /etc/bind/named.conf.options : 

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; };
};

Mise en place de la mascarade sur le serveur virtuel 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: 

iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.16.8.0/24

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 iptables -t nat -L -v, qui affiche la règle de POSTROUTING active :

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

Cette configuration permet aux clients connectés au WiFi du VLAN 408 de naviguer sur Internet à travers le serveur virtuel.

Interception de flux:03/10

Redirection par DNS

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 :

//
// 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";

};

création de la zone db.github.com

$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

Redirection réseau

J'ai ajouté une règle iptables pour rediriger le trafic TCP vers un port local.

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

Serveur Apache sécurisé: 03/11

Commande utilisée pour générer le certificat auto-signé  :

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"

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.

<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>

Pour activer la configuration du site et recharger Apache : 

a2ensite site-github.conf
service apache2 reload

Vérification : 

:~#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))

Machine virtuelle Android : 03/11

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.

Tentative installation VM en utilisant QEMU

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 : 

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

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.

Configuration Wifi pour connecter la VM : 04/11

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.

>>ip link set bridge down

/etc/network/interfaces

iface wlan1 inet dhcp
  wpa-ssid SE5-crhanim
  wpa-key-mgmt WPA-PSK
  wpa-psk Chaymae08

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 : 

sudo apt install wpasupplicant

Problèmes rencontrés

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.

Tentative installation de Android x86_64 en utilisant les commandes du Dockerfile

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.

Création de VM en utilisant Android studio

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 : https://nedis-smartlife.en.aptoide.com/app .Cette fois ci l'application se lance correctement.

Ajout de certificat dans la VM

Première tentative

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

les commandes utilisées pour mettre le certificat sur la VM :

adb root
adb shell avbctl disable-verification
adb reboot
adb wait-for-device root
adb remount
adb push 9ab369ad.0 /system/etc/security/cacerts

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 :

emulator -avd <nom_avd> -writable-system -gpu swiftshader_indirect -no-snapshot -no-boot-anim &

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é.

Github redirigé.png
Récupérée de « http:///mediawiki/index.php?title=SE5_IdO_sécurité_des_objets_2025/2026_b5&oldid=10929 »