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

De wiki-se.plil.fr
Révision datée du 2 décembre 2025 à 16:44 par Azongo (discussion | contributions) (→‎Projet Infrastructure Réseau 2025/2026)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à la navigation Aller à la recherche

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

É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.
Récupérée de « http:///mediawiki/index.php?title=SE5_IdO_sécurité_des_objets_2025/2026_b4&oldid=10914 »