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

Projet Infrastructure Réseau 2025/2026

Partie 1 : Serveur virtuel (SE5-azongo)

Objectif

Créer un serveur virtuel sur l’hyperviseur capbreton, nommé SE5-azongo, et le configurer pour :

• être relié au commutateur virtuel bridgeStudents ;
• utiliser une IPv4 statique dans 172.26.145.0/24 avec comme passerelle 172.26.145.251 ;
• ajouter une seconde interface dans le VLAN privé 404 (réseau 172.16.4.0/24).

---

Étapes réalisées

1) Création de la VM sur capbreton

xen-create-image --hostname=SE5-azongo \
                 --dhcp \
                 --bridge=bridgeStudent \
                 --dir=/usr/local/xen \
                 --size=10GB \
                 --dist=daedalus \
                 --memory=1024M

Remarque : la commande de création a utilisé bridgeStudent. Plus bas, l’interface est référencée en bridgeStudents côté VM – adapter selon le nom exact sur l’hyperviseur.

---

2) Configuration réseau principale (eth0) dans la VM

Fichier /etc/network/interfaces :

# Boucle locale
auto lo
iface lo inet loopback

# Interface principale (bridgeStudents)
auto eth0
iface eth0 inet static
    address 172.26.145.104
    netmask 255.255.255.0
    gateway 172.26.145.251
    dns-nameservers 8.8.8.8 1.1.1.1

Vérifications :

# Affichage des interfaces
ip a

# Extrait attendu
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet 172.26.145.104/24 brd 172.26.145.255 scope global eth0

# Test de connectivité Internet
ping 8.8.8.8
# Résultat
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=5.53 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss

---

3) Préparation du VLAN 404 sur l’hyperviseur (capbreton)

Configuration réseau de l’hyperviseur (extrait) :

# VLAN 404 pour le binôme Azongo
auto Trunk.404
iface Trunk.404 inet manual
    vlan-raw-device Trunk
    up ip link set $IFACE up
    down ip link set $IFACE down

auto g5_azongo
iface g5_azongo inet manual
    bridge_ports Trunk.404
    up ip link set $IFACE up
    down ip link set $IFACE down

---

4) Ajout d’une 2e interface à la VM (pontée sur le VLAN 404)

Fichier de configuration Xen de la VM (extrait) :

# Networking
dhcp = 'dhcp'
vif  = [
    'mac=00:16:3E:A7:A6:FB,bridge=bridgeStudents',
    'mac=00:16:3E:A7:A6:FC,bridge=g5_azongo'
]

Redémarrage de la VM, puis configuration de eth1.

---

5) Configuration de l’interface VLAN (eth1) dans la VM

Fichier /etc/network/interfaces (ajout) :

# VLAN 404
auto eth1
iface eth1 inet static
    address 172.16.4.0
    netmask 255.255.255.0

Vérifications :

# Affichage des interfaces
ip a

# Extrait attendu
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet 172.16.4.0/24 brd 172.16.4.255 scope global eth1

# Test de connectivité interne (réseau VLAN)
ping 172.16.4.0
# Résultat
64 bytes from 172.16.4.0: icmp_seq=1 ttl=64 time=0.027 ms
--- 172.16.4.0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss

---

État actuel

Élément	Statut	Détails
Création de la VM	✅	VM SE5-azongo créée sur capbreton
Interface principale	✅	Pont bridgeStudents, IPv4 172.26.145.104/24
Accès Internet	✅	Ping 8.8.8.8 concluant (0% perte)
VLAN 404 (hyperviseur)	✅	Interfaces Trunk.404 et pont g5_azongo opérationnels
Interface eth1 (VM)	✅	IPv4 172.16.4.0/24 configurée
Connectivité VLAN	✅	Ping local concluant

Partie 2 : Sécurisation WiFi (WPA2-PSK)

Accès console du point d’accès Cisco

Connexion au point d’accès via la console série depuis la machine hôte (où l’AP est branché), en utilisant minicom. But : accéder au mode EXEC privilégié pour configurer le WiFi (SSID, chiffrement, VLAN).

Résumé opérationnel : ouverture de la session console, passage en mode configuration globale, puis configuration du SSID et des interfaces radio/802.1Q.

---

Création du SSID et association au VLAN 404

Configuration réalisée sur l’AP (console) :

dot11 ssid SE5-azongo
  vlan 404
  authentication open
  authentication key-management wpa
  wpa-psk ascii 0 "VOTRE_CLE_PSK_ICI"
  mbssid guest-mode
exit

interface Dot11Radio1
  encryption vlan 404 mode ciphers aes-ccm
  ssid SE5-azongo
  mbssid
  no shutdown
exit

interface Dot11Radio1.404
  encapsulation dot1Q 404
  bridge-group 4
exit

interface GigabitEthernet0.404
  encapsulation dot1Q 404
  bridge-group 4
exit

---

Vérification sur l’AP

Commande exécutée : show dot11 bssid Sortie observée :

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

Interprétation : le SSID SE5-azongo est bien diffusé (MBSSID / guest-mode activé) sur l’interface Dot11Radio1 et associé au BSSID indiqué.

---

DNS (BIND9 forwarder)

Objectif

Mettre en place un serveur DNS local sur la VM (BIND9) qui **résout pour les clients du VLAN 404** en relayant (forward) les requêtes vers Internet. Réseau LAN : 172.16.4.0/24 — IP de la VM (LAN) : 172.16.4.1.

---

1) Installation de BIND9

apt-get update
apt-get install -y bind9 bind9utils

---

2) Configuration du forwarder (/etc/bind/named.conf.options)

options {
        directory "/var/cache/bind";

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

        forwarders {
                1.1.1.1;
                8.8.8.8;
        };

        dnssec-validation auto;

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

Validation et (re)démarrage :

named-checkconf
service bind9 restart || service named restart
service bind9 status  || service named status

---

3) DHCP → annoncer le DNS local (/etc/dhcp/dhcpd.conf)

Informer les clients Wi-Fi que le DNS est la VM (172.16.4.1) :

subnet 172.16.4.0 netmask 255.255.255.0 {
  range 172.16.4.100 172.16.4.200;
  option routers 172.16.4.1;
  option domain-name-servers 172.16.4.1;
}

Recharger le DHCP (SysV init) :

service isc-dhcp-server restart
service isc-dhcp-server status

Sur le téléphone/PC client : oublier le Wi-Fi puis se reconnecter (nouveau bail DHCP).

DHCP côté VM (VLAN 404)

Objectif : attribuer automatiquement des adresses aux clients WiFi du VLAN 404, avec routeur/DNS pointant vers la VM.

1) Installation du service :

apt install isc-dhcp-server

2) Déclarer l’interface à servir (eth1) dans /etc/default/isc-dhcp-server :

INTERFACESv4="eth1"

3) Activer le routage IPv4 sur la VM (fichier /etc/sysctl.conf) :

net.ipv4.ip_forward=1

4) Configuration DHCP (fichier /etc/dhcp/dhcpd.conf) :

subnet 172.16.4.0 netmask 255.255.255.0 {
  range 172.16.4.100 172.16.4.200;
  option routers 172.16.4.1;
  option domain-name-servers 172.16.4.1;
}

Partie 3 : Interception de flux (NAT + Redirection TCP)

Objectif

Intercepter le trafic HTTP (TCP/80) des clients Wi-Fi du VLAN 404 (réseau 172.16.4.0/24) et le rediriger vers un service local sur la VM (port 8080). Cette partie s’appuie sur : eth1 = 172.16.4.1/24, DHCP opérationnel, route par défaut de la VM via 172.26.145.251 sur eth0.

---

0) Routage IPv4 + NAT exécutés avant la redirection TCP

Activation du routage et mise en place de la mascarade ‘‘style TP’’ (deux règles listées), puis autorisation du forwarding :

# Activer immédiatement et rendre persistant l’IP forwarding
sysctl -w net.ipv4.ip_forward=1
sed -i 's/^#\?net\.ipv4\.ip_forward.*/net.ipv4.ip_forward=1/' /etc/sysctl.conf

# (Une fois, avant les redirections) table NAT propre
iptables -t nat -F

# NAT vers Internet depuis le VLAN 404 (deux règles « affichage TP »)
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.4.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.4.0/24 -j MASQUERADE
iptables -t nat -L -n -v

# Autoriser le forwarding (LAN -> WAN et retours établis)
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -L FORWARD -n -v

# Persistance des règles déjà posées
apt-get install -y iptables-persistent
netfilter-persistent save

Pourquoi la masquerade ? Les clients Wi-Fi sont en adresses privées (172.16.4.0/24). Le NAT traduit leurs paquets pour sortir avec l’IP de la VM côté salles (via 172.26.145.251). Sans NAT, pas d’Internet pour le VLAN.

---

1) Service HTTP local de test (port 8080)

mkdir -p /var/log/se5
mkdir -p /srv/se5/www
echo "OK from $(hostname) at $(date)" > /srv/se5/www/index.html

# Lancer le serveur de test et loguer la sortie
nohup python3 -m http.server 8080 --directory /srv/se5/www >/var/log/se5/http8080.log 2>&1 &
ss -lntp | grep :8080    # ecoute sur 0.0.0.0:8080

---

2) Redirection TCP (PREROUTING → port local 8080)

Intercepter l’HTTP venant du VLAN 404 (eth1) et le rediriger vers le service local :

iptables -t nat -A PREROUTING -i eth1 -s 172.16.4.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -L -n -v | grep REDIRECT

Important : ne pas exécuter iptables -t nat -F après avoir ajouté cette règle, sinon elle sera effacée.

Persister **après** avoir posé la PREROUTING :

netfilter-persistent save

Partie 5 : Serveur Web sécurisé (Apache HTTPS)

Objectif

Fournir un service Web local en HTTPS sur la VM pour les clients du VLAN 404 (172.16.4.0/24). Adresse de la VM côté LAN : 172.16.4.1.

---

1) Installation & modules

apt-get update
apt-get install -y apache2 openssl
a2enmod ssl headers rewrite

---

2) Certificat auto-signé (TP)

mkdir -p /etc/ssl/{private,certs}
openssl req -x509 -nodes -newkey rsa:2048 -days 365 \
  -keyout /etc/ssl/private/se5.key \
  -out /etc/ssl/certs/se5.crt \
  -subj "/CN=se5-azongo"
chmod 600 /etc/ssl/private/se5.key

Remarque : un certificat auto-signé provoque un avertissement sur le téléphone. C’est attendu pour le TP.

---

3) VirtualHost HTTPS (/etc/apache2/sites-available/se5-https.conf)

<VirtualHost *:443>
    ServerName se5-azongo

    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/se5.crt
    SSLCertificateKeyFile /etc/ssl/private/se5.key

    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-XSS-Protection "1; mode=block"

    <Directory /var/www/html>
        Options -Indexes +FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/se5-https-error.log
    CustomLog ${APACHE_LOG_DIR}/se5-https-access.log combined
</VirtualHost>

Activer le site :

a2ensite se5-https

---

4) (Option) Redirection HTTP → HTTPS

Fichier /etc/apache2/sites-available/se5-redirect.conf :

<VirtualHost *:80>
    ServerName se5-azongo
    RewriteEngine On
    RewriteRule ^/(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
    ErrorLog ${APACHE_LOG_DIR}/se5-redirect-error.log
    CustomLog ${APACHE_LOG_DIR}/se5-redirect-access.log combined
</VirtualHost>

Activation :

a2ensite se5-redirect
a2dissite 000-default
service apache2 restart

---

Depuis un client Wi-Fi (VLAN 404) :

• Naviguer vers https://172.16.4.1/ → page personalisée ("Site SE5").
• Si redirection activée : http://172.16.4.1/ → redirection vers HTTPS.

---

État actuel (Apache HTTPS)

Élément	Statut	Détails
Apache2 + SSL	✅	Modules ssl, headers, rewrite activés
Certificat	✅	Auto-signé (/etc/ssl/private/se5.key, /etc/ssl/certs/se5.crt)
VHost 443	✅	se5-https.conf actif, DocumentRoot = /srv/se5/www
Redirection HTTP→HTTPS	⛭ Optionnel	se5-redirect.conf
Tests client	✅	Accès à https://172.16.4.1/ (avertissement attendu)

Partie 2 : Objet connecté

Objectif général

Avoir un Android fonctionnel pour tester la redirection/DNS/NAT et afficher un faux site HTTPS (ex. amazon.fr) sans alerte TLS, en environnement labo (zabeth04 + VM réseau).

---

1) Tentative Android ARM via Docker – Échec

Idée

Installer le SDK Android via Docker, créer un AVD ARM64 (android-30) et lancer l’émulateur pour exécuter des APK ARM-only.

Résultat

Lancement impossible sur hôte x86_64 :

FATAL | Avd's CPU Architecture 'arm64' is not supported by the QEMU2 emulator on x86_64 host.
System image must match the host architecture.

Conclusion

Sur hôte x86_64, l’émulateur (version utilisée) ne lance pas d’images ARM64 → bascule vers une image x86_64.

---

2) Installation Android x86_64 (solution retenue)

Étapes (sans Docker, sur zabeth04)

1. Installer JDK + command line tools + dépendances graphiques.
2. Définir ANDROID_HOME / ANDROID_SDK_ROOT et compléter le PATH.
3. Installer via sdkmanager : platform-tools, emulator, system-images;android-30;google_apis;x86_64.
4. Créer l’AVD : avdmanager create avd -n test_avd -k "…x86_64".
5. Démarrer : emulator -avd test_avd -writable-system -gpu swiftshader_indirect -no-snapshot & puis attendre sys.boot_completed.

Vérification

adb shell getprop ro.product.cpu.abi → x86_64.

---

3) APK qui « keeps stopping » sur Android-x86

Cause principale

APK ARM-only (armeabi-v7a/arm64-v8a) → crash sur x86/x86_64 sans traduction ARM.

Vérification

unzip -l monapp.apk | grep -E 'lib/(x86|x86_64|armeabi-v7a|arm64-v8a)/'.

Correction

Installer une build x86/x86_64/universal → l’appli s’installe et tourne sur l’AVD x86_64.

---

4) Réseau & Faux site HTTPS (DNS/NAT/REDIRECT)

Contexte

VLAN 404 (172.16.4.0/24), VM routeur (172.16.4.1) avec DHCP, NAT vers Internet, BIND (DNS), redirection TCP.

Objectif

Afficher https://amazon.fr (faux site) sans alerte TLS.

Principe TLS propre

Installer dans Android (niveau SYSTÈME) une **CA de confiance** (/system/etc/security/cacerts/<subject_hash_old>.0, droits 0644, reboot), et servir le site avec un **cert serveur** signé par cette CA (SAN = DNS:amazon.fr).

---

5) Résolution du problème Read-Only (RO) avec ADB → /system en RW

Symptôme

adb push … /system/etc/security/cacerts/ → Read-only file system.

Cause

dm-verity/AVB + system-as-root : la racine / est montée RO ; un simple adb remount n’active pas toujours l’écriture.

Procédure robuste (émulateur déjà lancé)

# (1) Désactiver la vérification + redémarrer
adb root || true
adb shell avbctl disable-verification || true
adb shell avbctl disable-verity || true
adb reboot
# Attendre le boot :
until adb shell getprop sys.boot_completed 2>/dev/null | grep -q 1; do sleep 1; done

# (2) Remonter en écriture
adb root || true
adb remount   # active overlayfs si nécessaire

# (3) Vérifier les montages
adb shell 'cat /proc/mounts | grep -E " /( |system )"'
# Exemple OK :
# /dev/block/dm-0 / ext4 ro,...
# overlay /system overlay rw,...  <-- /system est en overlay RW => écriture possible

Remarques

Si l’émulateur était lancé sans -writable-system, le redémarrer avec cette option.

---

6) Installation de ma CA se5.crt dans le magasin SYSTÈME Android

Préparation (sur zabeth04, dossier avec se5.crt)

cd ~/Desktop
HASH=$(openssl x509 -inform PEM -subject_hash_old -in se5.crt | head -1)
cp -f se5.crt ${HASH}.0    # ex. 48db4bf5.0

Push + droits + reboot (après RW confirmé)

adb root || true
adb remount
adb push ${HASH}.0 /system/etc/security/cacerts/
adb shell chown root:root /system/etc/security/cacerts/${HASH}.0
adb shell chmod 644       /system/etc/security/cacerts/${HASH}.0
adb shell ls -l /system/etc/security/cacerts | grep ${HASH}
adb reboot

État atteint

Le fichier /system/etc/security/cacerts/<hash>.0 est bien présent (-rw-r--r--), la CA est prise en compte après reboot.

---

7) Vérifications & tests

DNS Android

adb shell toybox nslookup amazon.fr || adb shell nslookup amazon.fr → renvoie l’IP de la VM (faux site).

Navigateur Android

Ouvrir https://amazon.fr → pas d’alerte TLS si le cert serveur a un SAN DNS:amazon.fr et est signé par se5.crt.

---