Mathéo Analyse Analyse et caractéristiques – Onduleur APC 1) Présentation de l'onduleur L'onduleur APC Smart-UPS est un équipement d'alimentation sans interruption (ASI) de technologie Line-Interactive, conçu pour protéger les équipements informatiques sensibles contre les coupures de courant, les surtensions et les variations de tension. Dans le cadre du projet IRS-SI, cet onduleur est intégré dans la baie réseau du Bâtiment B. Il assure la continuité d'alimentation des équipements critiques de l'infrastructure. 2) Caractéristiques techniques Caractéristique Valeur Type APC Smart-UPS (Line-Interactive) Puissance 1000 VA / ~600 W Tension d'entrée 230 V / 220 V Format Rack 1U Protection surtension Oui — capacité d'absorption 600 J Technologie Line-Interactive avec régulateur AVR Interface locale Écran LCD en façade Communication réseau SNMP (via carte réseau optionnelle) Batterie Remplaçable à chaud — ref. APCRBC124 Gestion batterie Intelligente et automatique Fonctionnalités principales     • Maintien de l'alimentation en cas de coupure secteur     • Régulation automatique de tension (AVR) sans passage sur batterie     • Protection contre les surtensions et les microcoupures     • Supervision locale via écran LCD (état batterie, charge, tension)     • Supervision réseau via SNMP pour intégration dans Zabbix     • Batterie remplaçable à chaud sans arrêt des équipements     • Haute disponibilité adaptée aux applications critiques 3) Étude de capacité électrique Capacité disponible L'onduleur dispose d'une puissance de 1000 VA. En pratique, la puissance active utilisable est d'environ 600 W (facteur de puissance ~0,6 pour un onduleur Line-Interactive). Il est recommandé de ne pas dépasser 80 % de la charge maximale afin de garantir une autonomie suffisante et préserver la durée de vie de la batterie, soit une charge maximale recommandée de 480 W. Consommation estimée des équipements Équipement Modèle Conso. typ. (W) Conso. max. (W) Serveur Dell PowerEdge R440 R440 200 400 Routeur Cisco ISR (Gi0/0/0) 30 50 Switch Cisco PoE Catalyst / 2960 100 150 PDU ATEN PE7208G PE7208G 15 20 TOTAL 345 620 Analyse de la charge Charge typique estimée : 345 W soit 57 % de la capacité (600 W). Ce niveau est dans la plage recommandée. Charge maximale estimée : 620 W soit 103 % de la capacité. En pic de charge maximale simultanée, la limite peut être dépassée. Recommandation : en conditions normales d'exploitation, la charge reste inférieure à 80 % de la capacité. Le scénario de charge maximale simultanée est peu probable car le serveur Dell R440 atteint rarement sa consommation de pointe en production. L'onduleur 1 kVA est adapté pour cette configuration. Autonomie estimée Pour une charge de 345 W, l'APC Smart-UPS 1000 VA offre une autonomie d'environ 8 à 12 minutes. Cette durée est suffisante pour effectuer un arrêt propre des équipements ou attendre le retour du secteur pour une coupure brève. 4) Équipements à relier à l'onduleur Les équipements suivants doivent obligatoirement être reliés à l'onduleur car une coupure entraînerait une perte totale de service pour l'infrastructure IRS-SI : Équipement Priorité Justification Dell PowerEdge R440 Critique Héberge toutes les VMs (Asterisk, Zabbix, NoDogSplash). Arrêt = perte de tous les services. Routeur Cisco Critique Assure le routage inter-VLAN et l'accès internet. Arrêt = coupure totale du réseau. Switch Cisco PoE Critique Interconnecte tous les équipements. Alimente aussi les téléphones IP via PoE. PDU ATEN PE7208G Important Alimente d'autres équipements de la baie. Doit rester opérationnel pour maintenir l'alimentation. Équipements non prioritaires Les équipements suivants ne sont pas reliés à l'onduleur car leur coupure n'entraîne pas d'indisponibilité critique :     • Cisco WAP150 — réseau visiteurs uniquement, non critique pour l'exploitation     • Téléphones IP Yealink et Cisco — alimentés en PoE par le switch, donc couverts indirectement si le switch est sur l'onduleur 5) Suivi des informations de l'onduleur Communication SNMP L'APC Smart-UPS supporte le protocole SNMP via une carte réseau optionnelle (AP9630 ou AP9631) à insérer dans le slot de communication de l'onduleur. Cette carte attribue une adresse IP à l'onduleur et expose les données via SNMP. Intégration dans Zabbix Un template officiel APC est disponible nativement dans Zabbix. Il permet de superviser les paramètres suivants : Donnée supervisée Description État de la batterie Niveau de charge en % et état (OK / faible / critique) Statut alimentation On Line / On Battery / Bypass Tension d'entrée Tension secteur en volts Tension de sortie Tension fournie aux équipements Charge en % Pourcentage de la capacité utilisée Température interne Température de l'onduleur en °C Autonomie restante Durée estimée en minutes Alertes recommandées     • Alerte critique si passage sur batterie (coupure secteur)     • Alerte si niveau batterie inférieur à 30 %     • Alerte si charge dépasse 80 % de la capacité     • Alerte si température interne dépasse 40 °C 6) Conclusion L'onduleur APC Smart-UPS 1000 VA est adapté à la configuration de la baie réseau IRS-SI. Sa capacité couvre les équipements critiques dans des conditions normales d'exploitation, avec une marge de sécurité suffisante. L'intégration SNMP dans Zabbix permettra de superviser en temps réel l'état de l'alimentation et de déclencher des alertes en cas d'anomalie, garantissant ainsi la réactivité de l'équipe technique face à une coupure ou une dégradation de la batterie. Analyse et caractéristiques – PDU ATEN PE7208G 1) Présentation du PDU Le PDU ATEN PE7208G est une unité de distribution d'alimentation (PDU) en rack de type « Outlet-Metered eco PDU », conçue pour distribuer et mesurer la consommation électrique au niveau de chaque prise de sortie individuellement. Dans le cadre du projet IRS-SI, ce PDU est installé dans la baie réseau du Bâtiment B. Il assure la distribution de l'alimentation électrique aux équipements de la baie et permet une supervision fine de la consommation par prise via SNMP. 2) Caractéristiques techniques Caractéristique Valeur Modèle ATEN PE7208G Type Outlet-Metered eco PDU Format Rack 1U Nombre de prises 8 prises de sortie Courant maximal 20 A (NEMA) / 16 A (IEC) Tension d'entrée 100–240 V CA Interface réseau Port RJ-45 (LAN) intégré Communication réseau SNMP v1, v2c, v3 Interface web HTTP / HTTPS Protocoles supportés TCP/IP, UDP, HTTP, HTTPS, SSL, DHCP, SMTP, NTP, DNS, Telnet Sécurité Filtre IP/MAC, SSL 128 bits, RADIUS, comptes à deux niveaux Mesure Courant, tension, puissance active, énergie (kWh), par prise Supervision environnementale Capteurs externes température / humidité (option) Consommation propre ~15 W typ. / 20 W max. Fonctionnalités principales     • Distribution de l'alimentation vers 8 prises indépendantes     • Métrologie par prise : courant (A), tension (V), puissance (W), énergie consommée (kWh)     • Supervision réseau native via SNMP v1/v2c/v3 — pas de carte optionnelle nécessaire     • Interface web intégrée pour la configuration et la consultation     • Envoi d'alertes par email (SMTP) et traps SNMP en cas de dépassement de seuils     • Synchronisation horaire NTP pour l'horodatage des événements     • Contrôle on/off de chaque prise à distance (reboot d'équipements sans intervention physique) 3) Répartition des prises Prise Équipement connecté Priorité Justification 1 Dell PowerEdge R440 Critique Héberge toutes les VMs — arrêt = perte totale des services 2 Routeur Cisco ISR 4321 Critique Routage inter-VLAN et accès réseau global 3 Switch Cisco Catalyst (PoE) Critique Interconnexion + alimentation PoE des téléphones IP 4 APC Smart-UPS Important Alimentation ondulée — PDU en aval pour les équipements critiques 5–8 Réservé / équipements secondaires Variable À affecter selon évolution de la baie Asterisk 01 - Description 1) Architecture du projet Le projet IRS-SI déploie une infrastructure VoIP complète sur un réseau local segmenté en VLAN. Le serveur Asterisk est hébergé sur une machine virtuelle Debian 12 sur le serveur Proxmox, accessible depuis le VLAN 99 (LAN VMs) à l'adresse 192.168.10.69. Les deux téléphones IP sont connectés via le switch PoE du projet et s'enregistrent automatiquement sur le serveur Asterisk au démarrage. Les appels internes transitent entièrement par le réseau local sans passer par l'extérieur. Le schéma de communication est le suivant : lorsqu'un téléphone compose un numéro interne, il envoie une requête PJSIP au serveur Asterisk qui consulte son plan de numérotation (extensions.conf), identifie le poste destinataire et établit la communication. Le flux audio (RTP) circule ensuite directement entre les deux téléphones sans transiter par Asterisk. Les deux postes configurés sont les suivants : Extension Téléphone Protocole 1000 Yealink T31P PJSIP 1001 Yealink T41P PJSIP 2) Qu'est ce que Asterisk Asterisk est un logiciel open source de téléphonie IP développé par Digium (aujourd'hui Sangoma), disponible sous licence GPL. Il s'agit du serveur IPBX (IP Private Branch Exchange) le plus répandu dans le monde, utilisé aussi bien dans les PME que dans les grandes entreprises. Son rôle est de gérer les appels téléphoniques internes d'une infrastructure : il reçoit les demandes d'appel des téléphones IP, les route vers le bon destinataire et gère la signalisation entre les postes. Asterisk supporte plusieurs protocoles de téléphonie IP, dont PJSIP (le module recommandé depuis Asterisk 13), SIP (l'ancien module chan_sip) et IAX2. Il est compatible avec une très large gamme de téléphones IP physiques et de softphones. Dans le cadre du projet IRS-SI, Asterisk est déployé sur une machine virtuelle Debian 12 hébergée sur le serveur Proxmox. Il gère les communications entre les trois téléphones IP du site et constitue le cœur de l'infrastructure de téléphonie. Matériels utilisés Équipement Rôle Routeur Cisco ISR 4321 Routage, DHCP, gateway VLAN 20 Switch managé Segmentation VLAN Proxmox Hyperviseur hébergeant la VM Asterisk Debian 12 (VM) Système hôte du serveur Asterisk Asterisk 18 Serveur de téléphonie IP (PJSIP) Yealink T41P (poste 1000) Téléphone IP SIP Yealink T31P (poste 1001) Téléphone IP SIP Cisco CP-7811-3PCC (poste 1002) Téléphone IP SIP Zabbix Supervision réseau Réseau     • VLAN 20 dédié à la téléphonie : 192.168.10.64/26     • IP Asterisk (VM) : 192.168.99.9     • IP Yealink T41P (1000) : 192.168.10.66     • IP Yealink T31P (1001) : 192.168.10.67     • Port SIP Asterisk : 5160/UDP (PJSIP)     • DHCP assuré par le Cisco ISR avec réservations par adresse MAC 02 - Installation Serveur 01) Installation Tout d'abord, veillez à avoir une distribution à jour :  sudo apt update sudo apt upgrade Nous procédons ensuite à l'installation des dépendances : sudo apt-get install gcc make pkg-config build-essential wget libssl-dev libncurses5-dev libnewt-dev libxml2-dev linux-headers-$(uname -r) uuid-dev libsqlite3-dev libjansson-dev Parmi ces dépendances, nous retrouvons entre autre : Build-essential : contient le compilateur gcc, le compilateur g++, make, etc… La librairie SQL Lite La librairie SSL Une fois les dépendances installées, nous pouvons télécharger les sources d’Asterisk.                                                                              Commençons par créer un dossier pour les contenir. mkdir /usr/src/asterisk cd /usr/src/asterisk Dans le dossier  /usr/src/asterisk/ télécharger les sources d’Asterisk.                                                                                                                      Veillez à prendre la dernière version d’Asterisk en date (ici la version 18). cd /usr/src/asterisk/ sudo wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-18-current.tar.gz Puis décompresser les sources, et entrer dans le dossier nouvellement créé. sudo tar -xvzf asterisk-18-current.tar.gz cd asterisk-18.X.X Avant de compiler Asterisk, il faut s’assurer que le système dispose de toutes les dépendances. Pour cela, entrer la commande suivante dans le dossier contenant les sources : ./configure Si la vérification ne retourne pas de message d’erreur, vous pouvez alors continuer. Dans le cas où il vous manque des dépendances, identifiez les, et ajouter les à la main (avec un apt-get install ou en les téléchargent à la main avec un wget ). Il faut ensuite choisir les options de compilation. make menuselect Vous pouvez aussi ajouter les sons en français dans les sections Core Sound Package, et Extras Sound Package. Vous pouvez aussi ajouter les musiques d’attente en format aLAW. Lancer la compilation et l’installation. make make install Il convient ensuite de créer les fichiers d’exemple de configuration. make samples Créer les scripts de démarrage. make config Enfin, vous pouvez lancer Asterisk. /etc/init.d/asterisk start Il est possible d’entrer dans la console d’Asterisk avec la commande suivante : asterisk –r 03 - Configuration 1) Configuration PJSIP Le fichier de configuration principal à modifier est le /etc/asterisk/pjsip.conf. Transport UDP Points critiques :     • bind=0.0.0.0:5160 — écoute sur toutes les interfaces, port 5160 [transport-udp] type=transport protocol=udp bind=0.0.0.0:5160 Configuration des postes Chaque poste nécessite trois sections : endpoint, auth, aor. Toujours dans le fichier /etc/asterisk/pjsip.conf. Poste 1000 (Yealink T41P - Matheo) : [1000] type=endpoint context=interne disallow=all allow=alaw allow=ulaw aors=1000 auth=auth1000 callerid="Matheo" <1000> direct_media=no ; Empêche le bypass RTP direct entre téléphones [auth1000] type=auth auth_type=userpass username=1000 password=azerty [1000] type=aor max_contacts=2 qualify_frequency=30 Répéter la même structure pour les postes 1001 et 1002 en adaptant les valeurs. CRITIQUE : Sans qualify_frequency, les contacts restent en état 'NonQual' et les appels échouent avec 'provisoirement indisponible'. Asterisk ne sait pas si le téléphone est joignable. Paramètres critique expliqués Paramètre Pourquoi c'est important direct_media=no Sans ce paramètre, Asterisk tente un bypass RTP direct entre téléphones. Ça échoue sur réseau local segmenté → audio unidirectionnel ou absent. 2) Dial Plan (extensions.conf) Le dial plan est le cœur logique d'Asterisk : il définit comment chaque appel entrant est traité, routé et terminé. Il est structuré en contextes, extensions et priorités.  Structure du dial plan [contexte] exten => numéro, priorité, Application(paramètres) Élément Description Exemple Contexte Groupe logique d'extensions. Un endpoint ne peut accéder qu'à son contexte. [interne] Extension (exten) Numéro composé ou motif (_, X, Z, N...) 1000, _1XXX, s Priorité Ordre d'exécution. Commence à 1. n = next (priorité suivante). 1, 2, n Application Action à effectuer : Dial, Hangup, Playback, VoiceMail... Dial(PJSIP/1000,30) Configuration dans extension.conf Le Dial plan se configure dans ce fichier : /etc/asterisk/extension.conf [general] static=yes writeprotect=no clearglobalvars=no [interne] #Téléphone 1000 exten => 1000,1,Dial(PJSIP/1000,30) exten => 1000,2,Hangup() #Téléphone 1001 exten => 1001,1,Dial(PJSIP/1001,30) exten => 1001,2,Hangup() #Téléphone 1002 exten => 1002,1,Dial(PJSIP/1002,30) exten => 1002,2,Hangup() Le timeout de 30 secondes (paramètre Dial) déclenche le Hangup si personne ne répond. Après modification : sudo asterisk -rx "dialplan reload" Rechargement du  dial plan sudo asterisk -rx "dialplan reload" sudo asterisk -rx "dialplan show interne" ; Affiche le contexte interne 2) Configuration des téléphone IP Yealink T41P et T31P Accès à l'interface web : ouvrir un navigateur et saisir http://.  Naviguer vers Account → Account 1 et renseigner les champs suivants : Identifiants par défaut : admin / admin. Champ Valeur pour 1000 Valeur pour 1001 Description Label 1000 1001 Nom affiché sur le téléphone Display Name Service Comptabilité Service Informatique Identité appelant Register Name 1000 1001 Username SIP (doit correspondre à pjsip.conf) Username 1000 1001 Identifiant d'authentification Password azerty azerty Mot de passe SIP Server Host 192.168.10.69 192.168.10.69 IP du serveur Asterisk Port 5160 5160 Port SIP d'Asterisk (pas le défaut 5060 !) Transport UDP UDP Protocole de transport Server Expires 3600 3600 Durée d'enregistrement en secondes Le port 5160 est non standard. S'assurer que les téléphones pointent bien sur 5160 et non le port par défaut 5060, sinon l'enregistrement échoue silencieusement. Point de vigilance Toujours vérifier que le mode DND est désactivé (Features → Forward & DND → Etat NPD → "de"). Si activé, les appels entrants sont ignorés sans notification. DND (Ne Pas Déranger) Au décrochage, l'audio sort par défaut via le combiné. Appuyer sur le bouton haut-parleur pour basculer. Le bouton casque active la sortie jack. Mode audio Le message "Update Skipped" au redémarrage est normal si aucun serveur de provisioning n'est configuré. Il n'affecte pas le fonctionnement. Mise à jour firmware Après modification de la configuration, toujours redémarrer le téléphone via Settings → Upgrade → Reboot pour forcer le re-enregistrement SIP. Redémarrage 04 - Maintenance 1) Diagnostic et dépannage Commandes de diagnostic Asterisk Commande Usage asterisk -rx "pjsip show contacts" État des enregistrements : Avail/NonQual/Unreachable + RTT asterisk -rx "pjsip show endpoints" État global des endpoints configurés asterisk -rx "pjsip show endpoint 1000" Détail d'un endpoint spécifique asterisk -rx "core show channels" Appels actifs en cours asterisk -rx "dialplan show interne" Afficher le contexte du dial plan asterisk -rx "module reload res_pjsip.so" Recharger PJSIP à chaud asterisk -rx "dialplan reload" Recharger extensions.conf asterisk -rvvvv Console interactive avec niveau de verbosité 4 Activation des logs SIP et RTP  Depuis la console Asterisk (asterisk -rvvvv) : pjsip set logger on ; Active les logs SIP complets (INVITE, OPTIONS, 200 OK...) rtp set debug on ; Active les logs RTP (flux audio) pjsip set logger off ; Désactive (important en prod, très verbeux) rtp set debug off Vérification réseau # Vérifier qu'Asterisk écoute sur le bon port sudo ss -ulnp | grep 5160 # Tester la connectivité vers les téléphones ping -c 4 192.168.10.67 # Yealink T41P ping -c 4 192.168.10.66 # Yealink T31P # Vérifier les logs Asterisk sudo tail -f /var/log/asterisk/full sudo tail -f /var/log/asterisk/messages Problème fréquent Symptôme Cause probable Solution "Provisoirement indisponible" Contact en état NonQual — téléphone non qualifié Ajouter qualify_frequency=30 dans la section AOR. Vérifier DHCP/IP du téléphone. Pas de son (audio absent) external_signaling_address manquant → Asterisk annonce 127.0.0.1 Ajouter external_signaling_address et external_media_address dans le transport. Redémarrer Asterisk. Audio unidirectionnel direct_media=yes → bypass RTP échoue Ajouter direct_media=no dans chaque endpoint. Appel en absence sans sonnerie DND activé sur le téléphone destinataire Désactiver DND dans Features → Forward & DND → Etat NPD → "de". Téléphone non enregistré (croix rouge) Port SIP incorrect, mauvaise IP serveur, ou mot de passe erroné Vérifier la config du téléphone : IP Asterisk, port 5160, username/password. Contact Unavail après redémarrage VM Téléphone garde l'ancienne IP du serveur en cache Redémarrer le téléphone. Vérifier que la réservation DHCP d'Asterisk est correcte. Module reload sans effet sur le transport Le transport PJSIP ne se recharge pas à chaud sudo systemctl restart asterisk Appels impossibles, pas de connectivité VM VM attachée au mauvais bridge Proxmox Changer vmbr0 → vmbr1 dans les paramètres réseau de la VM Proxmox. 2) Sécurité de l'infrastructure VoIP Menaces courantes Menace Description Impact Scan SIP (SIPVicious) Robots qui scannent le port 5060 à la recherche de serveurs Asterisk Tentatives d'enregistrement non autorisé Brute force Attaque par dictionnaire sur les credentials SIP Accès non autorisé, frais téléphoniques Toll fraud Utilisation du serveur pour passer des appels internationaux payants Factures exorbitantes Écoute RTP Capture des flux audio RTP sur le réseau Violation de la confidentialité Déni de service (DoS) Flood de paquets SIP pour saturer le serveur Interruption de service Mesures de sécurité recommandées     •  (5060 → 5160 ou autre) pour réduire les scans automatisés.Changer le port SIP par défaut     •  Minimum 16 caractères, mélange de lettres, chiffres et symboles.Mots de passe complexes     •  Bloquer automatiquement les IPs effectuant trop de tentatives d'authentification.Fail2ban     •  Utiliser les listes de contrôle d'accès du Cisco ISR pour n'autoriser le trafic SIP qu'en provenance du VLAN 20.ACL réseau     •  Isoler les téléphones du reste du réseau — déjà en place dans ce projet.VLAN dédié     •  Chiffrer le flux audio RTP avec SRTP pour les environnements sensibles.SRTP     •  Modules Asterisk non utilisés (DAHDI, chan_skinny...) doivent être désactivés.Désactiver les services inutiles Installation de Fail2ban pour Asterisk Fail2ban est un outil qui surveille les fichiers de logs d'Asterisk et bloque automatiquement les adresses IP qui font trop de tentatives d'authentification SIP échouées (brute force sur les mots de passe des postes). sudo apt install -y fail2ban # Créer /etc/fail2ban/jail.local [asterisk] enabled = true port = 5160 filter = asterisk logpath = /var/log/asterisk/full maxretry = 5 bantime = 3600 sudo systemctl restart fail2ban sudo fail2ban-client status asterisk 3) Supervision avec Zabbix Éléments à superviser Élément Méthode Seuil d'alerte Service Asterisk Check process "asterisk" Alerte si arrêté > 1 min Nombre d'appels actifs AMI ou script Alerte si > seuil configuré Enregistrements SIP Script pjsip show contacts Alerte si endpoint Unreachable Connectivité téléphones ICMP ping Alerte si téléphone injoignable Logs d'erreurs Log monitoring Alerte sur ERROR/WARNING répétés 05 - Script 1) Script d'administration Bash Ce script centralise les opérations courantes d'administration de l'infrastructure VoIP. ############################################################## # Auteur : mkermorvant # # Date de modification : 20260511 # # # # Description : Management Asterisk # # # ############################################################## #! /bin/bash # # # ############################################################## # Variables : echo "" ASTERISK="192.168.99.9" TEL_1000="192.168.10.67" TEL_1001="192.168.10.66" #Code couleur ANSI pour l'affichage terminal VERT='\033[0;32m' ROUGE='\033[0;31m' JAUNE='\033[0;33m' NEUTRE='\033[0m' BLEU='\033[0;36m' PS3="Qu'elle action souhaiter vous exécuter : " OPTIONS=( "Statut Serveur Asterisk" "Ping" "Contacts" "Appels en cours" "Redémarrage Serveur Assterisk" "Rechargement Config" "Quitter" ) ############################################################## #Boucle principale : réaffiche le menu après chaque action while true; do clear echo -e "${BLEU}###############################################################" echo "# #" echo "# Admin Asterisk #" echo "# #" echo "###############################################################" echo "# #" echo "# Liste Options : #" echo "# #" echo "# 1) Statut Serveur #" echo "# 2) Ping Téléphones #" echo "# 3) Liste Contacts #" echo "# 4) Liste Appel #" echo "# 5) Redémarage Asterisk #" echo "# 6) Rechargement Config #" echo "# 7) Quitter #" echo "# #" echo -e "###############################################################${NEUTRE}" ############################################################## #Lecture du choix echo -ne " Votre choix : " read REPLY #Traitement du choix via case case $REPLY in 1) echo -e "${VERT}=== Statut du Serveur Asterisk ===${NEUTRE}" sudo systemctl status asterisk.service #Affiche l'état du service systemd echo "" ;; 2) echo -e "${VERT}=== Ping Asterisk vers Téléphones ===${NEUTRE}" # 3 paquets ICMP envoyés, résultat coloré selon le succès ou l'échec ping -c 3 $TEL_1000 && echo -e "${VERT}1000 OK${NEUTRE}" || echo -e "${VERT}1000 KO${NEUTRE}" echo "" ping -c 3 $TEL_1001 && echo -e "${VERT}1001 OK${NEUTRE}" || echo -e "${ROUGE}1001 KO${NEUTRE}" echo "" ;; 3) echo -e "${VERT}=== Liste contacts Asterisk ===${NEUTRE}" sudo asterisk -rx "pjsip show contacts" #Commande exécuté dans la CLI asterisk echo"" ;; 4) echo -e "${VERT}=== Liste d'appel en cours ===${NEUTRE}" sudo asterisk -rx "core show channels" #Liste les canaux actifs echo "" ;; 5) echo -e "${VERT}=== Redémarage du Serveur Asterisk ===${NEUTRE}" sudo systemctl restart asterisk.service #Redemmarre le service echo "" ;; 6) echo -e "${VERT}=== Rechargement de la Configuration ===${NEUTRE}" sudo asterisk -rx "module reload res_pjsip.so" #Recharge le module PJSIP sudo asterisk -rx "dialplan reload" #Recharge le plan de numérotation echo "" ;; 7) echo -e "${JAUNE}=== Quitter ===${NEUTRE}" break #Sort de la boucle While echo "" ;; *) #Toute saisie non reconnue echo -e "${ROUGE}=== Option invalide, veuillez réessayer ===${NEUTRE}" echo "" ;; esac #Pause avant de réafficher le menu echo -ne "Appuie sur Entrée..." read done Point Accès Wi-Fi 01 - Description 1) Architecture du projet Le projet IRS nécessite la mise en place d'un accès WiFi dédié aux visiteurs. Cet accès doit être totalement isolé du réseau interne de l'établissement afin de garantir la sécurité des équipements et des données. Le réseau visiteurs est diffusé par un point d'accès WiFi Cisco WAP150, configuré en mode autonome (sans contrôleur WLC). Il est segmenté via le VLAN 40, indépendant des autres VLANs du réseau. 2) Objectifs     • Fournir un accès WiFi fonctionnel aux visiteurs du projet IRS     • Isoler le trafic visiteurs du reste de l'infrastructure réseau     • Sécuriser l'accès par authentification WPA Personal     • Empêcher la communication entre les clients WiFi visiteurs (Channel Isolation) 2) Matériels utilisée Paramètre Valeur Équipement Cisco WAP150 Adresse IP de gestion 192.168.10.200 VLAN de gestion VLAN 40 Interface web https://192.168.10.200 Identifiant par défaut cisco 3) Plan d'adressage Équipement VLAN Adresse IP Rôle AP Cisco WAP150 10 192.168.10.200 Point d'accès WiFi Sous-interface routeur 40 192.168.40.x Passerelle VLAN 40 Clients visiteurs 40 192.168.40.x (DHCP) Accès Internet visiteurs 4) Architecture réseau Schéma d'ensemble Le schéma ci-dessous présente l'intégration du point d'accès dans l'infrastructure réseau du projet IRS. 02 - Installation 1) Prérequis Matériel nécessaire     • Point d'accès Cisco WAP150     • Switch compatible PoE (Power over Ethernet) ou injecteur PoE     • Câble RJ45 (Cat5e ou supérieur)     • PC avec navigateur web pour la configuration     • Câble console USB (optionnel, pour accès CLI) Prérequis réseau     • VLAN 40 créé et configuré sur le switch et le routeur     • Service DHCP actif pour le VLAN 40 sur le routeur     • Port switch dédié à l'AP configuré en access VLAN 40 Vérifier que le port switch est bien en mode access VLAN 40 avant de brancher l'AP. Un port en mode trunk ou sur le mauvais VLAN empêchera l'accès à l'interface web 2 ) Installation physique Branchement     1. Choisir un emplacement adapté pour couvrir la zone visiteurs     2. Brancher le câble RJ45 entre le port Ethernet de l'AP et le port 17 du switch     3. L'AP s'alimente via PoE — aucune alimentation électrique séparée nécessaire     4. Attendre environ 2 minutes le démarrage complet de l'AP     5. Vérifier que les LEDs de l'AP et du switch s'allument correctement Vérification du port switch Depuis la console du switch, vérifier la configuration du port 17 : show interfaces GigabitEthernet0/17 switchport Le résultat doit afficher :     • Administrative Mode : static access     • Access Mode VLAN : 40 Si le port n'est pas sur le VLAN 40, le configurer avec les commandes suivantes : configure terminal interface GigabitEthernet0/17 switchport mode access switchport access vlan 40 end write memory 3) Premier accès à l'interface web Accès via naviguateur     6. Ouvrir un navigateur web (Firefox ou Edge recommandé)     7. Saisir l'adresse : https://192.168.10.200     8. Accepter l'avertissement de certificat auto-signé     9. Se connecter avec les identifiants par défaut : Champ Valeur par défaut Nom d'utilisateur cisco Mot de passe cisco Le protocole HTTP simple (port 80) est désactivé par défaut sur le WAP150. Utiliser impérativement HTTPS. En cas de chargement infini, vérifier que l'URL commence bien par https://. 03 - Configuration 1) Topologie réseau Wi-Fi L'infrastructure Wi-Fi est isolée du réseau de production via le VLAN 40. Le tableau suivant récapitule l'adressage réseau utilisé : Élément VLAN Adresse IP Masque WAP150 (gestion) VLAN 40 192.168.10.198 /27 Réseau VLAN 40 VLAN 40 192.168.10.192 /27 Passerelle VLAN 40 VLAN 40 192.168.10.194 /27 Plage DHCP visiteurs VLAN 40 192.168.10.196 – .222 /27 Port switch Fa0/23 (trunk) — — Le port Fa0/23 du switch Cisco est configuré en mode trunk et autorise le VLAN 40 ainsi que le VLAN natif. Le DHCP snooping est activé sur ce port en mode trusted pour autoriser les réponses DHCP provenant du serveur. 2) Configuration du réseau sans fil (SSID) Paramètre Valeur configurée Nom du réseau (SSID) Visiteurs-IRS Diffusion du SSID Activée VLAN associé VLAN 40 Bande de fréquence 2,4 GHz Standard 802.11b/g/n Canal Auto (sélection automatique) Puissance d'émission 100 % (pleine puissance) Isolation clients Activée (clients isolés entre eux) Chiffrement WPA2 Personal  Le SSID Visiteurs-IRS est dédié aux accès des visiteurs et invités. L'isolation des clients est activée afin d'empêcher toute communication directe entre les postes connectés au Wi-Fi. Seul l'accès à travers le portail captif NoDogSplash est autorisé. Affectation VLAN sur l'interface réseau L'interface Ethernet du WAP150 est configurée en mode trunk pour transporter à la fois le VLAN de gestion (VLAN 99) et le VLAN visiteurs (VLAN 40). Configuration trunk côté switch (port Fa0/23) Switch(config)# interface FastEthernet0/23 Switch(config-if)# switchport mode trunk Switch(config-if)# switchport trunk allowed vlan 40,99 Switch(config-if)# ip dhcp snooping trust Switch(config-if)# spanning-tree portfast Configuration VLAN côté WAP150 Dans l'interface web du WAP150, les paramètres VLAN sont accessibles via le menu Advanced > VLAN & Radio Settings. Le SSID Visiteurs-IRS est associé au VLAN 40.   Intégration du portail captif NoDogSplash Le portail captif NoDogSplash est déployé sur une machine virtuelle Debian 12 hébergée sur Proxmox. Cette VM joue le rôle de passerelle pour le VLAN 40 et intercepte les requêtes HTTP des clients Wi-Fi pour les rediriger vers une page d'authentification. Élément Détail OS de la VM Debian 12 (Bookworm) Interface LAN (VLAN 99) ens18 — accès gestion / supervision Interface Wi-Fi (VLAN 40) ens19 — 192.168.10.194/27 Logiciel portail captif NoDogSplash (sources GitHub) Port d'écoute TCP 2050 Démarrage Service systemd (nodogsplash.service) Le flux d'un client visiteur se déroule comme suit : le poste obtient une adresse IP du DHCP du VLAN 40, puis toutes ses requêtes HTTP sont interceptées par NoDogSplash et redirigées vers le portail de connexion. Après validation sur la page d'accueil, l'accès au réseau est autorisé. 04 - Sécurité 1) Choix du protocole de chiffrement Wi-Fi L'un des premiers choix à effectuer pour sécuriser un réseau sans fil est le protocole de chiffrement. Contrairement aux réseaux filaires, les ondes radio se propagent au-delà des murs et peuvent être captées par tout équipement situé à portée. Sans chiffrement, toutes les données échangées seraient lisibles en clair par n'importe quel observateur passif. Quatre générations de protocoles existent. Le tableau suivant les compare afin de justifier le choix retenu pour le projet IRS-SI. Protocole Chiffrement Authentification Niveau sécurité Statut WEP (1999) RC4 – 40/104 bits Clé partagée Très faible Obsolète WPA-TKIP (2003) RC4 + TKIP PSK / 802.1X Faible Déprécié WPA2-AES (2004) AES-CCMP 128 bits PSK / 802.1X Bon Retenu ✔ WPA3-SAE (2018) AES-CCMP + SAE SAE / 802.1X Excellent Non supporté WEP — Wired Equivalent Privacy (1999) WEP est le premier protocole de sécurité Wi-Fi standardisé. Il utilise l'algorithme de chiffrement RC4 avec des clés de 40 ou 104 bits. Dès 2001, des chercheurs ont démontré que le vecteur d'initialisation (IV) de seulement 24 bits est réutilisé trop rapidement, ce qui permet à un attaquant de retrouver la clé en quelques minutes avec des outils comme aircrack-ng. WEP est formellement interdit dans tout réseau professionnel depuis 2004. Attention : WEP ne doit jamais être utilisé. Même un réseau sans données sensibles peut servir de point d'entrée vers l'infrastructure interne. WPA-TKIP — Wi-Fi Protected Access (2003) WPA avec TKIP a été conçu comme solution transitoire dans l'attente de WPA2. Il corrige les failles de WEP en ajoutant un compteur de séquence de trames et en renouvelant dynamiquement les clés. Cependant, des attaques de type TKIP MIC ont été publiées dès 2008, puis l'attaque Beck-Tews (2009) a permis de déchiffrer des paquets courts. WPA-TKIP est déprécié depuis 2012 par le standard 802.11. WPA2-AES-CCMP — Protocole retenu pour le projet WPA2 utilise le chiffrement AES (Advanced Encryption Standard) en mode CCMP (Counter Mode with CBC-MAC Protocol), avec des clés de 128 bits. AES est un algorithme symétrique standardisé par le NIST en 2001 et n'a à ce jour fait l'objet d'aucune attaque pratique sur des implémentations correctes. WPA2 est le standard de facto dans les environnements professionnels depuis 2006. Bonne pratique : WPA2-Personal avec AES-CCMP est retenu pour le SSID Visiteurs-IRS. Ce choix offre un niveau de sécurité adapté à un réseau invités tout en étant compatible avec l'ensemble des terminaux mobiles actuels.   WPA3-SAE — Évolution non déployée WPA3, introduit en 2018, remplace l'échange de clé PSK par le protocole SAE (Simultaneous Authentication of Equals), basé sur l'échange Diffie-Hellman. SAE élimine les attaques par dictionnaire hors ligne sur le mot de passe, car chaque tentative d'authentification nécessite une interaction réseau. WPA3 n'est pas supporté par le firmware 1.1.4.0 du Cisco WAP150 et ne peut donc pas être déployé dans le cadre actuel du projet. 2) Authentification et contrôle d'accès Le contrôle d'accès au réseau Wi-Fi repose sur deux mécanismes complémentaires : l'authentification au niveau du protocole Wi-Fi (WPA2-PSK) et le contrôle applicatif via le portail captif NoDogSplash, qui intervient après l'association au réseau. WPA2 Personal (PSK) - Premier niveau En mode WPA2-Personal, un mot de passe commun (Pre-Shared Key) est configuré sur le point d'accès. Tous les clients doivent le connaître pour s'associer au SSID. Cette méthode est adaptée à un réseau visiteurs où les terminaux sont variés et non gérés par l'entreprise. La clé PSK subit une dérivation cryptographique PBKDF2-HMAC-SHA1 avec 4096 itérations pour produire la PMK (Pairwise Master Key) de 256 bits. Cette PMK n'est jamais transmise sur le réseau. Politique appliquée au mot de passe Wi-Fi Critère Règle appliquée Longueur minimale 12 caractères Composition Majuscules + minuscules + chiffres Durée de validité Renouvellement mensuel recommandé Diffusion Via le portail captif après validation de l'identité Stockage Hash PBKDF2 côté WAP150, jamais en clair Portail captif NoDogSplash - Second niveau de contrôle Le portail captif constitue le deuxième niveau d'authentification. Même si un visiteur connaît le mot de passe WPA2, ses requêtes HTTP sont interceptées par la VM NoDogSplash jusqu'à ce qu'il accepte les conditions d'utilisation sur la page du portail. Flux d'authentification Le flux complet d'un client visiteur se déroule en cinq étapes :     1. Association Wi-Fi : le terminal se connecte au SSID Visiteurs-IRS avec le mot de passe WPA2.     2. Obtention d'une adresse IP : le serveur DHCP du VLAN 40 attribue une adresse dans la plage 192.168.10.196–222/27.     3. Interception HTTP : NoDogSplash redirige toute requête HTTP vers sa page d'accueil (port TCP 2050).     4. Validation : le visiteur accepte les conditions d'utilisation sur le portail.     5. Accès autorisé : NoDogSplash lève le blocage et laisse passer le trafic du client vers internet. 3) Isolation et segmentation réseau La segmentation réseau est le principe de défense qui consiste à diviser l'infrastructure en zones étanches. Même si un attaquant pénètre dans l'une d'elles, il ne peut pas accéder aux autres sans franchir des contrôles supplémentaires. Isolation des clients Wi-Fi L'isolation des clients interdit toute communication directe entre les terminaux connectés au même SSID. Sans cette mesure, deux visiteurs sur le même réseau pourraient s'attaquer mutuellement via des techniques comme l'ARP spoofing ou le scan de ports. Lorsque l'isolation est activée sur le WAP150, le point d'accès bloque au niveau de la couche 2 (Ethernet) tout échange de trames entre clients. Un client ne peut envoyer des trames qu'en direction de la passerelle par défaut (la VM NoDogSplash, 192.168.10.194). Les trames destinées à d'autres clients sont silencieusement supprimées par le WAP150. Segmentation par VLAN 40 Le réseau Wi-Fi visiteurs est entièrement isolé du réseau de production par l'utilisation du VLAN 40. Ce VLAN est dédié exclusivement aux clients sans fil et n'est pas routé vers les VLAN internes (VLAN 10 Gestion, VLAN 20 Administration, VLAN 30 Commercial, etc.). VLAN Usage Réseau Accès depuis VLAN 40 VLAN 10 Gestion 192.168.10.0/27 Interdit VLAN 20 Administration 192.168.10.32/27 Interdit VLAN 30 Commercial 192.168.10.64/27 Interdit VLAN 40 Wi-Fi visiteurs 192.168.10.192/27 Natif — DHCP 196-222 VLAN 99 LAN VMs / gestion 192.168.10.128/26 Interdit (sauf passerelle) Le routeur Cisco ISR 4321 est configuré pour bloquer tout routage inter-VLAN depuis le VLAN 40 vers les VLAN de production. Seul le trafic à destination d'internet (ou des ressources explicitement autorisées) est permis après validation sur le portail captif. Rôle de la VM  NoDogSplash comme point de contrôle unique La VM NoDogSplash (Debian 12) est le seul point de transit entre le VLAN 40 (Wi-Fi visiteurs) et le reste du réseau. Son architecture réseau est la suivante : Interface VM VLAN Adresse IP Rôle ens18 VLAN 99 Adresse DHCP Gestion / supervision Zabbix ens19 VLAN 40 192.168.10.194/27 Passerelle des clients Wi-Fi Les clients Wi-Fi utilisent 192.168.10.194 comme passerelle par défaut. Tout leur trafic transite obligatoirement par la VM, qui peut ainsi appliquer des règles iptables pour filtrer ou journaliser les connexions avant de les transmettre. 3) Supervision La supervision permet de détecter des comportements anormaux (saturation de la bande passante, nombre inhabituel de clients associés, perte de connectivité) et d'alerter l'administrateur avant qu'un incident ne se transforme en incident de sécurité majeur. Choix de SNMPv3 Le protocole SNMP (Simple Network Management Protocol) est le standard de supervision des équipements réseau. Trois versions coexistent, avec des niveaux de sécurité très différents : Version Authentification Chiffrement Recommandation SNMPv1 Community string en clair Aucun À proscrire SNMPv2c Community string en clair Aucun Déconseillé SNMPv3 noAuthNoPriv Utilisateur, sans auth Aucun Insuffisant SNMPv3 authNoPriv SHA-1 ou MD5 Aucun Acceptable SNMPv3 authPriv SHA-1 DES / AES Retenu ✔ SNMPv1 et v2c transmettent le nom de communauté (équivalent d'un mot de passe) en clair sur le réseau. Un simple sniffeur (Wireshark) suffit à l'intercepter et à prendre le contrôle de l'équipement. SNMPv3 en mode authPriv apporte une authentification forte par HMAC-SHA1 et un chiffrement du contenu des échanges par DES ou AES. Configuration SNMPv3 appliquée Paramètre Valeur configurée Utilisateur SNMP zabbix Niveau de sécurité authPriv (authentification + chiffrement) Protocole authentification SHA-1 (HMAC) Protocole chiffrement DES (Data Encryption Standard) Mot de passe auth Zabbix123 (à renforcer en production) Mot de passe chiffrement Zabbix123 (à renforcer en production) Version SNMP côté Zabbix SNMPv3 OID supervisés ifInOctets, ifOutOctets, ifOperStatus, sysUpTime 05 - NoDogSplash 1) Qu'est ce que NoDogSplash NoDogSplash est un logiciel open source de portail captif léger, conçu pour les systèmes Linux embarqués. Un portail captif est un mécanisme réseau qui intercepte le trafic HTTP d'un client nouvellement connecté à un réseau Wi-Fi et le redirige vers une page web de bienvenue, avant de lui accorder un accès complet à internet ou aux ressources autorisées. Ce type de système est fréquemment rencontré dans les hôtels, aéroports, restaurants ou tout établissement proposant un accès Wi-Fi public. Techniquement, NoDogSplash s'installe sur une machine Linux faisant office de passerelle (routeur) entre le réseau sans fil et le réseau en amont. Il exploite le pare-feu netfilter (iptables) du noyau Linux pour bloquer par défaut tout le trafic des clients non authentifiés, à l'exception des requêtes DNS et des connexions vers le portail lui-même. Lorsqu'un client tente d'accéder à n'importe quelle page web, NoDogSplash intercepte la requête et retourne une réponse de redirection HTTP 302 vers l'adresse de son interface web interne. Après que l'utilisateur a accepté les conditions d'utilisation sur la page du portail, NoDogSplash ajoute dynamiquement une règle iptables autorisant le trafic de ce client spécifique (identifié par son adresse MAC). L'accès reste ouvert jusqu'à expiration de la session ou déconnexion. 2) Obligation légal En France, toute personne physique ou morale proposant un accès à internet au public est soumise à des obligations légales définies par la loi n°2004-575 du 21 juin 2004 pour la Confiance dans l'Économie Numérique (LCEN), complétée par le décret n°2011-219 du 25 février 2011. Ces textes imposent à tout opérateur de réseau Wi-Fi ouvert de conserver pendant une durée d'un an les données de connexion de ses utilisateurs, notamment les adresses IP attribuées, les horodatages de connexion et de déconnexion, ainsi que les identifiants techniques permettant d'identifier le terminal utilisé. Cette obligation vise à permettre aux autorités judiciaires de remonter jusqu'à l'auteur d'une infraction commise via le réseau en cas de réquisition. Dans le cadre du projet IRS-SI, la mise en place du portail captif NoDogSplash répond directement à cette exigence. En interceptant chaque connexion et en enregistrant l'adresse MAC du terminal, l'adresse IP attribuée et l'horodatage de la session, la VM NoDogSplash permet à la PME fictive de disposer d'une traçabilité minimale conforme à la législation. Sans ce mécanisme, l'entreprise s'exposerait à des sanctions pénales en cas d'utilisation illicite de son réseau par un visiteur, faute de pouvoir fournir les éléments d'identification requis par les autorités. 3) Utilité dans le projet IRS-SI Dans le projet IRS-SI, le réseau Wi-Fi est dédié aux visiteurs et invités de la PME fictive. Ce réseau est isolé du réseau de production par le VLAN 40. NoDogSplash y joue trois rôles complémentaires :     • Contrôle d'accès applicatif : même si un visiteur connaît le mot de passe WPA2, il ne peut pas naviguer sans valider le portail. Cela ajoute un second niveau d'authentification indépendant du chiffrement Wi-Fi.     • Responsabilisation juridique : en affichant des conditions d'utilisation que le visiteur doit accepter explicitement, l'entreprise se protège légalement en cas d'utilisation abusive du réseau.     • Point de journalisation : NoDogSplash peut enregistrer les connexions (adresse MAC, horodatage, durée de session), ce qui permet une traçabilité minimale conforme aux obligations légales françaises pour les opérateurs de réseaux Wi-Fi ouverts. La VM NoDogSplash est déployée sur l'hyperviseur Proxmox avec deux interfaces réseau : ens18 connectée au VLAN 99 (LAN de gestion) et ens19 connectée au VLAN 40 (réseau Wi-Fi visiteurs) avec l'adresse 192.168.10.194/27. Elle constitue la passerelle par défaut de tous les clients Wi-Fi. Caractéristique Détail Logiciel NoDogSplash (sources GitHub — branche master) Licence GNU GPL v2 OS hôte Debian 12 (Bookworm) Hyperviseur Proxmox VE Interface VLAN 40 ens19 — 192.168.10.194/27 Interface VLAN 99 ens18 — adresse DHCP (gestion) Port d'écoute portail TCP 2050 Démarrage Service systemd (nodogsplash.service) Rôle réseau Passerelle par défaut des clients VLAN 40 4) Installation depuis les sources GitHub Clonage du dépôt NoDogSplash est disponible sur GitHub. La branche master contient la version stable la plus récente. Le clonage s'effectue dans le répertoire de l'utilisateur courant. cd /home/nodogsplash git clone https://github.com/nodogsplash/nodogsplash.git cd nodogsplash Compilation La compilation utilise les outils standards de build Linux. Aucune option particulière n'est nécessaire : NoDogSplash détecte automatiquement libmicrohttpd si le paquet de développement est installé. make # En cas d'erreur liée à libmicrohttpd : # Vérifier : dpkg -l | grep libmicrohttpd-dev Installation La commande make install copie le binaire dans /usr/bin/ et les fichiers de configuration par défaut dans /etc/nodogsplash/. make install # Vérifier les fichiers installés : ls /etc/nodogsplash/ which nodogsplash nodogsplash --version Fichier / Répertoire installé Contenu /usr/bin/nodogsplash Binaire principal /etc/nodogsplash/nodogsplash.conf Fichier de configuration principal /etc/nodogsplash/htdocs/ Pages HTML du portail (splash page) /etc/nodogsplash/htdocs/splash.html Page d'accueil affichée au visiteur /var/log/nodogsplash.log Fichier de log (créé au démarrage) 5) Configuration de NoDogSplash Le fichier de configuration principal se trouve dans /etc/nodogsplash/nodogsplash.conf. Il définit l'interface réseau sur laquelle NoDogSplash écoute, le port du portail, les règles de filtrage et les paramètres de session. Voici la configuration appliquée dans le projet IRS-SI : # # Nodogsplash Configuration File # # Parameter: GatewayInterface # Default: NONE # # GatewayInterface is not autodetected, has no default, and must be set here. # Set GatewayInterface to the interface on your router # that is to be managed by Nodogsplash. # Typically br-lan for the wired and wireless lan. # GatewayInterface ens19 # Parameter: WebRoot # Default: /etc/nodogsplash/htdocs # # The local path where the splash page content resides. # FirewallRuleSet: authenticated-users # # Control access for users after authentication. # These rules are inserted at the beginning of the # FORWARD chain of the router's filter table, and # apply to packets that have come in to the router # over the GatewayInterface from MAC addresses that # have authenticated with Nodogsplash, and that are # destined to be routed through the router. The rules are # considered in order, and the first rule that matches # a packet applies to it. # If there are any rules in this ruleset, an authenticated # packet that does not match any rule is rejected. # N.B.: This ruleset is completely independent of # the preauthenticated-users ruleset. # #TrustedMACList 70:f3:5a:27:95:30 FirewallRuleSet authenticated-users { # You may want to open access to a machine on a local # subnet that is otherwise blocked (for example, to # serve a redirect page; see RedirectURL). If so, # allow that explicitly here, e.g: # FirewallRule allow tcp port 80 to 192.168.254.254 # Your router may have several interfaces, and you # probably want to keep them private from the GatewayInterface. # If so, you should block the entire subnets on those interfaces, e.g.: # FirewallRule block to 192.168.0.0/16 # FirewallRule block to 10.0.0.0/8 # Typical ports you will probably want to open up include # 53 udp and tcp for DNS, # 80 for http, # 443 for https, # 22 for ssh: # FirewallRule allow tcp port 53 # FirewallRule allow udp port 53 # FirewallRule allow tcp port 80 # FirewallRule allow tcp port 443 # FirewallRule allow tcp port 22 # Or for happy customers allow all FirewallRule allow all # You might use ipset to easily allow/block range of ips, e.g.: # FirewallRule allow ipset WHITELISTED_IPS # FirewallRule allow tcp port 80 ipset WHITELISTED_IPS } # end FirewallRuleSet authenticated-users # FirewallRuleSet: preauthenticated-users # # Control access for users before authentication. # These rules are inserted in the PREROUTING chain # of the router's nat table, and in the # FORWARD chain of the router's filter table. # These rules apply to packets that have come in to the # router over the GatewayInterface from MAC addresses that # are not on the BlockedMACList or TrustedMACList, # are *not* authenticated with Nodogsplash. The rules are # considered in order, and the first rule that matches # a packet applies to it. A packet that does not match # any rule here is rejected. # N.B.: This ruleset is completely independent of # the authenticated-users and users-to-router rulesets. # #TrustedMACList 70:f3:5a:27:95:30 FirewallRuleSet preauthenticated-users { # For preauthenticated users to resolve IP addresses in their # initial request not using the router itself as a DNS server. # Leave commented to help prevent DNS tunnelling FirewallRule allow tcp port 53 FirewallRule allow udp port 53 FirewallRule allow to 192.168.99.0/28 # For splash page content not hosted on the router, you # will want to allow port 80 tcp to the remote host here. # Doing so circumvents the usual capture and redirect of # any port 80 request to this remote host. # Note that the remote host's numerical IP address must be known # and used here. # FirewallRule allow tcp port 80 to 123.321.123.321 } # end FirewallRuleSet preauthenticated-users # FirewallRuleSet: users-to-router # # Control access to the router itself from the GatewayInterface. # These rules are inserted at the beginning of the # INPUT chain of the router's filter table, and # apply to packets that have come in to the router # over the GatewayInterface from MAC addresses that # are not on the TrustedMACList, and are destined for # the router itself. The rules are # considered in order, and the first rule that matches # a packet applies to it. # If there are any rules in this ruleset, a # packet that does not match any rule is rejected. # #TrustedMACList 70:f3:5a:27:95:30 FirewallRuleSet users-to-router { # Nodogsplash automatically allows tcp to GatewayPort, # at GatewayAddress, to serve the splash page. # However you may want to open up other ports, e.g. # 53 for DNS and 67 for DHCP if the router itself is # providing these services. FirewallRule allow udp port 53 FirewallRule allow tcp port 53 FirewallRule allow udp port 67 # You may want to allow ssh, http, and https to the router # for administration from the GatewayInterface. If not, # comment these out. FirewallRule allow tcp port 22 FirewallRule allow tcp port 80 FirewallRule allow tcp port 443 FirewallRule allow to 192.168.99.0/28 } Page d'accueil du portail La page affichée aux visiteurs est définie dans /etc/nodogsplash/htdocs/splash.html. La page par défaut fournie par NoDogSplash suffit pour les besoins du projet. Elle contient un bouton permettant au visiteur d'accepter les conditions d'utilisation et de valider son accès. Portail de Connexion

Réseau Visiteurs IRS-SI

Portail de connexion invité

Bienvenue sur le réseau visiteurs du site IRS-SI. Ce réseau est réservé aux invités et visiteurs autorisés. L'accès est limité à un usage professionel et temporaire.

Conditions générales d'utilisation

Usage autorisé - Ce réseau est mis à disposition à titre gratuit pour un usage professionnel uniquement. Toute activité illicite, le téléchargement de contenus protégés ou l'utilisation excessive de la bande passante sont interdits.

Confidentialité - Les connexions sont susceptibles d'être journalisées à des fins de sécurité conformément à la législation en vigueur.

Responsabilité - L'établissement décline toute responsabilité quant aux dommages pouvant résulter de l'utilisation de ce réseau. L'utilisateur est seul responsable de l'usage qu'il fait de cette connexion.

Durée - L'accès est accordé pour la durée de votre visite. La session peut être interrompue à tout moment par l'administrateur réseau.

IRS-SI — Réseau sécurisé — Toute utilisation abusive sera signalée

Zabbix 00 - Comparatif Zabbic Vs Grafana Vs Centreon 1) Objectif des outils Zabbix — Solution de supervision complète Outil tout en un : collecte, stockage, alertes, découverte réseau, dashboards SNMP natif, agentless ou via agent Très adapté aux infrastructures réseau (switchs, routeur, UPS, firewalls, serveurs...) Pensé pour la supervision IT classique (CPU, RAM, interfaces...) Grafana — Plateforme de visualisation Outil centré sur les dashboards et la visualisation des données Ne collecte pas les données SNMP par lui-même (obligé de passer par Telegraf) Excellente ergonomie, très visuel Centreon — Supervision orientée entreprise Surcouche de Nagios/Naemon avec interface web moderne Support SNMP via plugins, configuration plus complexe Très complet mais orienté grandes infrastructures IT Nécessite une architecture dédiée (base de données, broker...) 2) Supervision SNMP — Comparaison détaillée Critère SNMP Zabbix Grafana Centreon Support SNMP natif Oui, complet (v1/v2c/v3) Non, nécessite Telegraf/Prometheus Via plugins Nagios Poller SNMP intégré Oui, polling interne (bulk requests, retry) Non, dépend de SNMP Exporter ou Telegraf Via Centreon Engine (plugins) SNMP Traps Support natif via snmptrapd Via Telegraf SNMP Trap plugin uniquement Via Centreon Trap, configuration manuelle Alertes basées sur SNMP Avancées (triggers, escalades) Limitées (Prometheus Alertmanager) Présentes mais complexes à configurer Performances SNMP Optimisé bulk requests à grande échelle Dépend totalement de Telegraf/Prometheus Dépend des plugins, moins optimisé 3) Installation & maintenance Zabbix Installation plus complexe Paramétrage parfois lourd mais complet Solution centralisée Grafana Installation simple Peut tourner en conteneur Docker en quelques lignes Nécessite d'installer la stack SNMP complète Centreon Installation complexe (dépendances Nagios, broker, base de données) Interface web moderne mais courbe d'apprentissage élevée Adapté aux équipes IT dédiées, surdimensionné pour un projet de taille réduite 4) Conclusion Zabbix a été retenu car il offre le meilleur compromis entre richesse fonctionnelle et simplicité de déploiement pour notre infrastructure. Grafana est écarté pour l'absence de collecte SNMP native. Centreon, bien que complet, est surdimensionné pour le besoin du projet. 01 - Description Matériels VM Proxmox OS : Debian 13 RAM : 4Go Processeur : 2 Stockage : 50Go Identifiants Proxmox IRS-admin ieufdL Debian-Zabbix root ieufdl real name (zabbix) Z@bB/* Asterisck Debian-Asterisck asterisck stjolorient 02 - Installation Zabbix Source : https://www.libra-linux.com/blog/15-supervision-avec-zabbix-7-0-lts-sur-debian-ubuntu 1) Installation du serveur Zabbix Prérequis OS : Debian 12 2 Go de RAM , 1 CPU Accès root / sudo Ajout du dépôt Zabbix Pour Debian 12 wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_7.0-1+debian12_all.deb sudo dpkg -i zabbix-release_7.0-1+debian12_all.deb sudo apt update Pour Ubuntu 22.04 wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-1+ubuntu22.04_all.deb sudo dpkg -i zabbix-release_7.0-1+ubuntu22.04_all.deb sudo apt update Installer le serveur Zabbix + frontend + BDD sudo apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf \ zabbix-sql-scripts zabbix-agent mariadb-server Configurer MariaDB sudo mysql_secure_installation Puis : CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER zabbix@localhost IDENTIFIED BY 'ieufdl'; GRANT ALL PRIVILEGES ON zabbix.* TO zabbix@localhost; FLUSH PRIVILEGES; Importer le schéma : zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix Configurer Zabbix Fichier /etc/zabbix/zabbix_server.conf : DBPassword=ieufdl Ne pas oubliez de démarrer le service :) sudo systemctl restart zabbix-server zabbix-agent apache2 sudo systemctl enable zabbix-server zabbix-agent apache2 Accéder à l’interface web Accéder à : http:///zabbix Identifiants initiaux :     Login : Admin     Mot de passe : zabbix 03 - Installation Client Zabbix 1) Installation du client Zabbix Installation de l'agent sur la machine Client wget https://repo.zabbix.com/zabbix/6.4/debian/pool/main/z/zabbix-release/zabbix-release_6.4-1+debian12_all.deb sudo dpkg -i zabbix-release_6.4-1+debian12_all.deb sudo apt update sudo apt install -y zabbix-agent2 Configuration de l'agent Afin de connecter votre machine au serveur Zabbix, il faut configurer celle-ci en indiquant l'adresse IP de votre serveur Zabbix. Server= ServerActive= Hostname=Debian-Asterisk Le fichier à modifier est le suivant : /etc/zabbix/zabbix_agent2.conf   Scripts de collecte Asterisk Voici un script vous permettant de collecter les données de votre machine pour les envoyer à votre serveur Zabbix. #!/bin/bash case "$1" in active_calls) sudo asterisk -rx "core show channels" | grep "active call" | awk '{print $1}' ;; registered_peers) sudo asterisk -rx "pjsip show contacts" | grep "Avail" | wc -l ;; unavail_peers) sudo asterisk -rx "pjsip show contacts" | grep "Unavail\|NonQual" | wc -l ;; service_status) systemctl is-active asterisk | grep -c "active" ;; esac Le fichier à modifier est le suivant : /etc/zabbix/zabbix_agent2.conf   N'oubliez pas de rendre le fichier exécutable avec la commande suivante :  sudo chmod +x /etc/zabbix/scripts/asterisk_stats.sh   Ajouter les UserParamèters Ajouter le contenu ci-dessous à la fin du fichier " /etc/zabbix/zabbix_agent2.conf " afin d'ajouter les UserParameters". UserParameter=asterisk.active_calls,/etc/zabbix/scripts/asterisk_stats.sh active_calls UserParameter=asterisk.registered_peers,/etc/zabbix/scripts/asterisk_stats.sh registered_peers UserParameter=asterisk.unavail_peers,/etc/zabbix/scripts/asterisk_stats.sh unavail_peers UserParameter=asterisk.service_status,/etc/zabbix/scripts/asterisk_stats.sh service_status Puis : Activer et relancer votre client Zabbix. sudo systemctl enable zabbix-agent2 sudo systemctl restart zabbix-agent2   Autoriser Zabbix à lancer Asterisk sudo visudo ``` Ajouter : ``` zabbix ALL=(ALL) NOPASSWD: /usr/sbin/asterisk 04 - Configuration 1) Configuration Langue Une fois sur l'interface web, la configuration de Zabbix commence. Vous commencerez par simplement choisir votre langue. Vérification des Prérequis A cette étape, vous n'aurez besoin que de vérifié que tous les prérequis sont bien "OK". Configuration de la connexion à la BDD A cette étapes, vous devrez remplir les différentes informations pour que la connexion entre Zabbix et la base de données se déroule correctement. Pensé a bien noté ces identifiant dans un gestionnaire de mot de passe !!! Paramétrage Ici vous n'aurez cas remplir le nom de votre serveur, son fuseau horaire par defaut (pourras être changé plus tard) et si vous le souhaitez un thème. Résumé Pour finir, vous aurez un résumé de pré-installation, n'hésitez pas à stocker les informations qui pourraient être utilisées plus tard. Connexion Une fois ces étapes réalisées, vous aurez accès à l'interface web de Zabbix. Identifiant par défaut :  Login : Admin Mdp : zabbix 05 - Dashboard 1) Tableau de bord - Supervision VoIP Ce tableau de bord supervise le serveur Asterisk 18 (VM 192.168.10.69) ainsi que les trois téléphones IP du projet. Les données sont collectées via SNMPv3 et complétées par des vérifications ICMP. Hôtes supervisés Équipement Adresse IP Protocole Template Zabbix Asterisk 18 (VM) 192.168.10.69 SNMP v3 + ICMP Linux by Zabbix agent Widget du tableau de bord Widget Métrique collectée Seuil / Alerte Statut ICMP Asterisk Ping vers 192.168.10.69 Alerte si indisponible Charge CPU serveur system.cpu.util (% utilisé) Alerte si > 80 % Mémoire RAM vm.memory.size[available] Alerte si < 100 Mo libres Uptime Asterisk sysUpTime (SNMP OID .1.3.6.1.2.1.1.3.0) Alerte si redémarrage Statut téléphones IP ICMP ping x3 postes Alerte si poste injoignable Appels actifs Asterisk AMI / SNMP MIB Informatif 2) Tableau de bord - Supervision Wi-Fi Ce tableau de bord supervise le point d'accès Cisco WAP150 (192.168.10.198) via SNMPv3 en mode authPriv (SHA-1 + DES). Le firmware a été mis à jour en version 1.1.4.0 pour corriger un bug qui empêchait la persistance des identifiants SNMPv3 SHA+DES. Hôtes supervisés Équipement Adresse IP Protocole Template Zabbix Cisco WAP150 192.168.10.198 SNMPv3 authPriv Network Generic Device by SNMP Paramètres SNMPv3 configurés dans Zabbix Paramètre Valeur Version SNMP SNMPv3 Utilisateur zabbix Niveau de sécurité authPriv Protocole d'authentification SHA-1 Protocole de chiffrement DES Widget du tableau de bord Widget Métrique collectée Seuil / Alerte Bande passante entrante ifInOctets (bits/s) Informatif Bande passante sortante ifOutOctets (bits/s) Informatif Statut ICMP Ping vers 192.168.10.198 Alerte si indisponible Latence réseau Temps de réponse ICMP (ms) Alerte si > 100 ms Uptime équipement sysUpTime (.1.3.6.1.2.1.1.3.0) Alerte si redémarrage Statut interface ifOperStatus (up/down) Alerte si interface down Le tableau de bord Zabbix ci-dessus illustre concrètement le problème de connectivité rencontré avec le point d'accès WAP150. On observe que le widget Statut WAP-WiFi affiche Down via ICMP ping, que le graphique Bande passante wlan0 ne remonte aucune donnée, et que le widget Alertes WAP-WiFi signale un PROBLÈME actif depuis le 01/06/2026 à 13h09, sans date de récupération. Ces indicateurs confirment que Zabbix ne parvient pas à joindre le WAP150 en ICMP. La cause identifiée est la suivante : lorsque le WAP150 est branché sur le switch Cisco, il provoque un crash de ce dernier, rendant l'ensemble du réseau du projet indisponible. Le switch redémarre alors automatiquement, ce qui coupe toute connectivité le temps du redémarrage. Le WAP150 est donc resté débranché du switch pour ne pas perturber les autres services du projet, ce qui explique l'absence totale de réponse ICMP et SNMP constatée dans Zabbix. Une alerte email a bien été reçue par Zabbix lors de l'apparition du problème, confirmant que le système de notification fonctionne correctement. Cette alerte indiquait l'indisponibilité de l'hôte WAP-WiFi et la perte de l'ICMP ping, ce qui valide le bon fonctionnement du mécanisme de supervision même en situation de panne. 3) Bilan Élément supervisé Statut Observations Serveur Asterisk 18 Operationnel SNMP v3 + ICMP — dashboard actif Téléphones IP (x2) Operationnel ICMP — statut en temps réel Cisco WAP150 Operationnel SNMPv3 authPriv — dashboard actif Alertes Zabbix (email) Operationnel Bloqué : pas d'accès internet sur VM Zabbix Supervision PDU ATEN PE7208G Non fait A réaliser Supervision APC Smart-UPS Non fait A réaliser Concernant le PDU ATEN PE7208G et l'onduleur APC Smart-UPS, la supervision via Zabbix n'a pas pu être réalisée dans les délais du projet. Ces deux équipements supportent le protocole SNMP et auraient pu être intégrés selon la même méthode que le WAP150, en créant un hôte Zabbix avec le template adapté et en configurant les OID correspondants (état des prises pour le PDU, niveau de batterie et statut d'alimentation pour l'onduleur). Le temps consacré à la résolution des problèmes techniques rencontrés sur d'autres parties du projet (recompilation NET-SNMP, problème de connectivité ARP du portail captif) n'a pas permis d'avancer sur ces deux éléments. Leur supervision reste une évolution prioritaire à mettre en place en fin de projet si le temps le permet. 06 - Idées Dashboards Asterisk / Téléphonie Nombre d'appels actifs en temps réel Nombre de postes enregistrés (Avail/Unavail) Durée moyenne des appels État du service Asterisk (up/down) CPU/RAM de la VM Debian PDU Consommation électrique globale (Watts) Consommation par prise Température interne Alertes de surcharge État de chaque prise (on/off) Onduleur (UPS) Niveau de batterie (%) Autonomie restante (minutes) Tension d'entrée/sortie État de charge (sur secteur / sur batterie) Température batterie Alertes : batterie faible, coupure secteur Point d'accès WiFi Nombre de clients connectés Signal moyen Bande passante utilisée (upload/download) État des SSIDs Température Dashboard global Un écran de synthèse avec : Carte du réseau avec statut vert/rouge de chaque équipement Graphes de consommation électrique sur 24h/7j Alertes actives en cours Disponibilité globale en % 07 - Messagerie 1) Installation de Postfix Dépendance Installation des dépendance de postfix. sudo apt update sudo apt install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules Configuration Pour configurer postfix, il faut compléter la configuration ci-dessous. relayhost = [smtp.gmail.com]:587 smtp_use_tls = yes smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt Les informations ci-dessus son à compléter dans le fichier suivant : /etc/postfix/main.cf Ajout identifiant Gmail Créer le fichier suivant : sudo nano /etc/postfix/sasl_passwd Il faut ajoute l'adresse email ainsi que le mot de passe : [smtp.gmail.com]:587 projet-irs@gmail.com:TON_MOT_DE_PASSE_APP Il faut bien utiliser son mot de passe d'application , pas son vrai mot de passe Sécurité sudo chmod 600 /etc/postfix/sasl_passwd sudo postmap /etc/postfix/sasl_passwd Test envoi La commande suivante permet de tester l'envoie d'un mail. echo "Test mail" | mail -s "Test Zabbix" projet-irs@gmail.com 2) Configuration de Zabbix Connexion Mail Dans l’interface web de  Zabbix : Va dans Alertes → Types de média Configure Email : SMTP server : localhost SMTP helo : ton hostname SMTP email : projet-irs@gmail.com Association Mail / utilisateur Afin que Zabbix sache à qui envoyé l'alerte, il faut configurer l'utilisateur avec l'adresse mail de destination. Dans l’interface web de  Zabbix : Va dans Utilisateurs → Utilisateurs Configure Média dans l'utilisateur Admin: Action Maintenant que tout est configuré, il faut maintenant créé une action. Dans l’interface web de  Zabbix : Va dans Alertes → Actions → Créé une actions Configure l'action : Nom : Alerte Problème Conditions : Le problème est supprimé : non Configure l'opération : Opérations : Envoyer au utilisateur : Admin 3) Résultat A partir de ce moment la, lorsqu'un problème est détecté une alerte est automatiquement envoyé au trois adresses configurés 4) Source https://www.zabbix.com/documentation/6.0/fr/manual/quickstart/notification https://www.zabbix.com/documentation/4.2/fr/manual/quickstart/notification#:~:text=La%20livraison%20des%20notifications%20est,marqu%C3%A9s%20d'un%20ast%C3%A9risque%20rouge. Vaultwarden 01 - Description Environnement de déploiement Parametre Valeur OS Debian 12 IP de la VM 192.168.99.6 Ressources VM 1 vCPU, 512 Mo RAM, 8 Go disque Hyperviseur Proxmox Moteur de conteneur Docker Engine 29.5.2 Port expose 8443 (HTTPS) Qu'est-ce que Vaultwarden ? Vaultwarden est une implementation open-source et allegee du serveur Bitwarden, ecrite en Rust. Il permet d'auto-heberger un gestionnaire de mots de passe complet sur sa propre infrastructure, sans dependance a des services cloud externes. Contrairement au serveur officiel Bitwarden qui necessite des ressources importantes, Vaultwarden est concu pour fonctionner sur des machines modestes tout en offrant les memes fonctionnalites essentielles : coffre-fort chiffre, organisation des secrets, partage entre utilisateurs et interface web accessible depuis un navigateur.   Utilite dans le projet IRS-SI Dans le cadre du projet IRS-SI, plusieurs services ont ete deployes sur des machines virtuelles distinctes : Asterisk, Zabbix, NoDogSplash, le NAS Synology, le WAP150, le PDU ATEN, etc. Chacun de ces equipements possede des identifiants d'administration qu'il est necessaire de stocker de maniere securisee et accessible a l'ensemble de l'equipe. Vaultwarden repond precisement a ce besoin en offrant :     • Un coffre-fort chiffre centralise pour tous les mots de passe du projet     • Un partage securise via l'organisation Projet-IRS entre les trois membres de l'equipe     • Une interface web accessible depuis n'importe quel poste du reseau local     • Un deploiement entierement en local, coherent avec la politique de securite du projet   02 - Installation Installation Docker Docker n'est pas inclus dans les depots Debian par defaut. La procedure suivante utilise le script d'installation officiel de Docker : sudo apt update && sudo apt install -y curl curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER Apres l'ajout au groupe docker, il est necessaire de se deconnecter puis de se reconnecter pour que le changement prenne effet. Generation du certificat SSL auto-signe Vaultwarden exige une connexion HTTPS pour fonctionner. En environnement local sans autorite de certification, un certificat auto-signe est genere avec OpenSSL : sudo mkdir /vw-ssl sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /vw-ssl/vaultwarden.key \ -out /vw-ssl/vaultwarden.crt \ -subj "/CN=192.168.99.6" Ce certificat est valable 10 ans et genere une cle RSA 2048 bits. Le navigateur affichera un avertissement de securite lors du premier acces, qu'il faudra accepter manuellement. Creation du script de demarrage Pour faciliter le demarrage du conteneur et eviter les problemes de saisie dans la console Proxmox, la commande Docker est enregistree dans un script bash : nano start.sh Contenu du fichier start.sh : #!/bin/bash sudo docker run -d --name vaultwarden --restart unless-stopped \ -e ADMIN_TOKEN=IRS-SI-Admin2026 \ -e ROCKET_TLS='{certs="/ssl/vaultwarden.crt",key="/ssl/vaultwarden.key"}' \ -v /vw-data:/data \ -v /vw-ssl:/ssl \ -p 8443:80 \ vaultwarden/server:latest Description des parametres :     • -d : execution en arriere-plan (mode detache)     • --name vaultwarden : nom du conteneur     • --restart unless-stopped : redemarrage automatique au boot     • -e ADMIN_TOKEN : token d'acces au panel d'administration     • -e ROCKET_TLS : chemin vers le certificat et la cle SSL     • -v /vw-data:/data : volume de donnees persistant     • -v /vw-ssl:/ssl : volume du certificat SSL     • -p 8443:80 : exposition du port 8443 en HTTPS Lancement du conteneur chmod +x start.sh ./start.sh Verification que le conteneur est bien en cours d'execution : sudo docker ps Le statut doit afficher 'Up' pour le conteneur vaultwarden. L'interface est ensuite accessible depuis un navigateur a l'adresse : https://192.168.99.6:8443 03 - Configuration Creation du compte administrateur Lors du premier acces a l'interface web, aucun compte n'existe. Il faut en creer un en cliquant sur 'Creez un compte' en bas de la page de connexion. Ce premier compte sera automatiquement proprietaire de l'instance. Champs a renseigner lors de la creation du compte :     • Adresse electronique : kermorvant.m@stjolorient.fr     • Nom : Matheo     • Mot de passe principal : mot de passe fort (min. 12 caracteres) Important : le mot de passe principal est le seul a devoir etre memorise. Il ne peut pas etre recupere en cas d'oubli car Vaultwarden utilise un chiffrement cote client (le serveur ne connait jamais le mot de passe en clair). Acces au panel d'administration Le panel d'administration Vaultwarden permet de gerer les utilisateurs, confirmer les comptes et superviser l'instance sans passer par un compte utilisateur. Il est accessible a l'adresse : https://192.168.99.6:8443/admin Le token d'acces est celui defini lors du lancement du conteneur : IRS-SI-Admin2026 Depuis ce panel, les actions disponibles sont :     • Consulter et gerer tous les utilisateurs enregistres     • Confirmer les inscriptions sans envoyer d'email     • Supprimer ou desactiver des comptes     • Consulter les organisations et collections     • Configurer les parametres SMTP si un serveur mail est disponible Creation de l'organisation partagee Une organisation dans Vaultwarden permet de partager des mots de passe entre plusieurs membres. Pour creer l'organisation du projet :     • Dans l'interface web, cliquer sur l'icone grille en haut a droite     • Cliquer sur 'Nouvelle organisation'     • Nom : Projet-IRS     • Plan : Gratuit     • Valider la creation L'organisation Projet-IRS apparait ensuite dans le menu lateral gauche sous 'Coffres'. Gestion des membres Pour inviter les autres membres du projet dans l'organisation :     • Aller dans Admin Console (menu bas gauche)     • Cliquer sur 'Membres' puis 'Inviter un membre'     • Saisir l'email du membre a inviter     • Le membre doit ensuite creer son compte sur https://192.168.99.6:8443     • Une fois le compte cree, aller dans l'onglet 'Confirmation necessaire' et confirmer Membres de l'organisation Projet-IRS : Membre Email Kermorvant Matheo kermorvant.m@stjolorient.fr Le Garrec Raphael legarrec.r@stjolorient.fr Le Galliot Ilian legalliot.i@stjolorient.fr Gestion des collections Les collections permettent de classer les mots de passe par categorie au sein de l'organisation. Une collection par defaut est creee automatiquement. Il est recommande de creer des collections thematiques pour le projet :     • Reseau : credentials des equipements reseau (switch, routeur, WAP150)     • Serveurs : acces Proxmox, VMs, services (Zabbix, Asterisk, NoDogSplash)     • Supervision : comptes Zabbix, SNMP credentials     • Infrastructure : PDU ATEN, onduleur APC, NAS Synology Pour creer une collection : Admin Console > Collections > bouton Nouveau. Ajout d'un mot de passe Pour ajouter un identifiant dans l'organisation :     • Aller dans Coffres > Projet-IRS     • Cliquer sur '+ Nouveau'     • Choisir le type : Identifiant     • Renseigner le nom, l'URL, le nom d'utilisateur et le mot de passe     • Selectionner le proprietaire : Projet-IRS (organisation)     • Selectionner la collection appropriee     • Enregistrer Les mots de passe ajoutes dans une collection de l'organisation sont visibles par tous les membres ayant acces a cette collection. Les mots de passe dans 'Mon coffre' restent prives. Recommandations de securite Dans le cadre du projet IRS-SI, les mesures de securite suivantes ont ete appliquees :     • Acces HTTPS exclusif via certificat TLS, le HTTP n'est pas expose     • Token ADMIN_TOKEN protege l'acces au panel d'administration     • Les donnees sont stockees dans /vw-data isole du conteneur     • Le conteneur est configure avec --restart unless-stopped pour la disponibilite     • L'acces est limite au reseau local du projet (192.168.99.0/24)     • Chaque membre dispose de son propre compte avec identifiants uniques Sécurité   Dans le cadre du projet IRS-SI, j'ai appliqué plusieurs recommandations de sécurité sur l'ensemble des services déployés. 1) Isolation réseau par VLAN Le réseau visiteurs est isolé sur le VLAN 40 (192.168.10.192/27), séparé du LAN interne. Un visiteur connecté au SSID Visiteurs-IRS ne peut pas accéder aux ressources internes de l'entreprise.   2) Sécurité Wi-Fi Le protocole WPA2 Personal a été retenu pour le réseau Wi-Fi visiteurs. Le protocole WEP, vulnérable aux attaques par dictionnaire, a été écarté. Le portail captif NoDogSplash ajoute une couche de contrôle supplémentaire en imposant une validation avant tout accès à internet. Son déploiement répond également à une obligation légale : en France, toute entreprise proposant un accès Wi-Fi visiteur doit conserver les logs de connexion pendant un an (LCEN).   3) Supervision sécurisée (SNMPv3) La supervision des équipements réseau utilise SNMPv3 avec authentification SHA1 et chiffrement DES. Les versions SNMPv1 et SNMPv2c, qui transmettent les données en clair, ont été écartées. SHA1 et DES sont imposés par les capacités du firmware 1.1.4.0 du WAP150, dans un contexte où le remplacement du matériel serait possible, SHA-256 et AES-128 seraient recommandés.   4) Sécurité VoIP L'accès au serveur Asterisk est restreint au VLAN 99 (LAN VMs). Chaque extension PJSIP est protégée par un mot de passe défini dans pjsip.conf . L'administration des VMs se fait exclusivement via SSH, évitant tout accès non chiffré.   5) Mises à jour Les systèmes Debian 12 des trois VMs ont été mis à jour lors de leur déploiement. Le firmware du WAP150 a été mis à jour vers la version 1.1.4.0 pour corriger un bug de persistance des credentials SNMPv3. Cahier de Tests Cahier de Tests - Projet IRS-SI Étudiant : Kermorvant Mathéo (E1) Présentation Ce cahier de tests recense l'ensemble des tests unitaires réalisés pour valider le bon fonctionnement des services déployés dans le cadre du projet IRS-SI. Pour chaque test, sont précisés : l'objectif, l'outil utilisé, la procédure, le résultat attendu et le résultat obtenu. 1. Infrastructure Wi-Fi 1.1 Connectivité WAP150 Champ Détail Objectif Vérifier la disponibilité réseau du point d'accès Prérequis VM Zabbix démarrée, WAP150 alimenté et connecté au switch Outil ping Commande ping 192.168.10.198 Résultat attendu Réponses ICMP reçues sans perte de paquets Résultat obtenu ✅ Fonctionnel — validé avant le problème ARP actuel Statut ⚠️ En cours de résolution (problème ARP entre VM NoDogSplash et WAP150) 1.2 Communication SNMPv3 vers le WAP150 Champ Détail Objectif Vérifier que Zabbix peut interroger le WAP150 en SNMPv3 Prérequis NET-SNMP recompilé avec --enable-des , SNMPv3 configuré sur le WAP150, firmware 1.1.4.0 Outil snmpwalk Commande snmpwalk -v3 -u zabbix -l authPriv -a SHA -A Zabbix123 -x DES -X Zabbix123 192.168.10.198 Résultat attendu Liste d'OIDs retournée par le WAP150 Résultat obtenu ✅ OIDs retournés correctement Statut ✅ Fonctionnel 1.3 Connexion au SSID Visiteurs-IRS Champ Détail Objectif Vérifier que le réseau Wi-Fi visiteurs est diffusé et accessible Prérequis WAP150 alimenté, SSID configuré sur VLAN 40, WPA2 activé Outil Poste client (PC ou smartphone) Procédure Se connecter au SSID Visiteurs-IRS avec le mot de passe WPA2 Résultat attendu Connexion Wi-Fi établie, adresse IP attribuée dans la plage 192.168.10.192/27 Résultat obtenu ✅ Connexion établie, adresse IP correcte Statut ✅ Fonctionnel 1.4 Affichage du portail captif NoDogSplash Champ Détail Objectif Vérifier la redirection vers la page de validation du portail Prérequis VM NoDogSplash démarrée, service nodogsplash actif, connecté au SSID Visiteurs-IRS Outil Navigateur web Procédure Ouvrir un navigateur et tenter d'accéder à une URL en HTTP (ex : http://example.com ) Résultat attendu Redirection automatique vers la page Réseau Visiteurs IRS-SI — Portail de connexion invité Résultat obtenu ⚠️ Page portail non affichée,  Statut ⚠️ Pas Focntionnel Remarque La page est servie en HTTP, comportement normal et inhérent au fonctionnement des portails captifs 1.5 Isolation VLAN 40 Champ Détail Objectif Vérifier qu'un client Wi-Fi visiteur ne peut pas accéder aux ressources internes Prérequis Connecté au SSID Visiteurs-IRS Outil ping depuis le poste client Commande ping 192.168.99.9 (VM Asterisk) Résultat attendu Aucune réponse — accès bloqué par l'isolation VLAN Résultat obtenu ✅ Ping sans réponse — isolation correcte Statut ✅ Fonctionnel 2. Téléphonie IP 2.1 Enregistrement des téléphones sur Asterisk Champ Détail Objectif Vérifier que les deux téléphones Yealink sont enregistrés sur le serveur Asterisk Prérequis VM Asterisk démarrée, téléphones alimentés via PoE et configurés avec l'IP du serveur Outil CLI Asterisk Commande asterisk -rx "pjsip show endpoints" Résultat attendu Extensions 1000 et 1001 avec statut Available Résultat obtenu ✅ Les deux téléphones enregistrés et disponibles Statut ✅ Fonctionnel 2.2 Appel interne entre les deux postes Champ Détail Objectif Vérifier qu'un appel interne peut être établi entre les deux postes Prérequis Les deux téléphones enregistrés (test 2.1 validé) Outil Téléphones Yealink T41P et T31P Procédure Composer le 1001 depuis le poste 1000 Résultat attendu Le poste 1001 sonne, la communication s'établit, l'audio fonctionne dans les deux sens Résultat obtenu ✅ Appel établi, sonnerie correcte, audio bidirectionnel fonctionnel Statut ✅ Fonctionnel 2.3 Vérification du flux RTP pendant un appel Champ Détail Objectif Vérifier qu'Asterisk gère uniquement la signalisation et que le flux audio est direct entre les téléphones Prérequis Un appel en cours entre 1000 et 1001 Outil CLI Asterisk Commande asterisk -rx "core show channels" Résultat attendu Canal actif affiché avec les deux extensions, flux RTP direct entre les postes Résultat obtenu ✅ Canal visible, Asterisk ne transporte pas l'audio Statut ✅ Fonctionnel 2.4 Test du script d'administration Asterisk Champ Détail Objectif Vérifier le bon fonctionnement du script Bash d'administration Prérequis Script déployé sur la VM Asterisk Outil Terminal SSH Procédure Lancer le script et tester chaque option du menu Résultat attendu Chaque fonction (statut, ping, endpoints, canaux, restart, reload) retourne un résultat correct Résultat obtenu ✅ Toutes les fonctions opérationnelles Statut ✅ Fonctionnel 3. Supervision Zabbix 3.1 Accès à l'interface web Zabbix Champ Détail Objectif Vérifier que l'interface web Zabbix est accessible Prérequis VM Zabbix démarrée, service zabbix-server et Apache actifs Outil Navigateur web Procédure Accéder à http://IP-VM-Zabbix/zabbix Résultat attendu Page de connexion Zabbix affichée Résultat obtenu ✅ Interface accessible Statut ✅ Fonctionnel 3.2 Statut des hôtes supervisés Champ Détail Objectif Vérifier que WAP150 et serveur Asterisk sont correctement supervisés Prérequis Hôtes configurés avec les paramètres SNMPv3, templates appliqués Outil Interface web Zabbix Procédure Accéder à Monitoring → Hosts Résultat attendu WAP150 (192.168.10.198) et Asterisk (192.168.99.9) avec statut Enabled et disponibilité verte Résultat obtenu ✅ Les deux hôtes supervisés et disponibles Statut ✅ Fonctionnel 3.3 Dashboard Supervision WiFi — IRS Champ Détail Objectif Vérifier que le dashboard Wi-Fi affiche les métriques en temps réel Prérequis Hôte WAP150 actif et supervisé Outil Interface web Zabbix Procédure Accéder au dashboard Supervision WiFi — IRS Résultat attendu Widgets bande passante, latence ICMP et statut hôte affichés avec données en temps réel Résultat obtenu ✅ Dashboard fonctionnel, métriques en temps réel Statut ✅ Fonctionnel 3.4 Dashboard Supervision VoIP — IRS Champ Détail Objectif Vérifier que le dashboard VoIP affiche l'état du serveur Asterisk Prérequis Hôte Asterisk actif et supervisé Outil Interface web Zabbix Procédure Accéder au dashboard Supervision VoIP — IRS Résultat attendu Statut service, CPU, RAM et nombre de processus actifs affichés Résultat obtenu ✅ Dashboard fonctionnel Statut ✅ Fonctionnel 3.5 Réception d'une alerte email Champ Détail Objectif Vérifier que Zabbix envoie bien un email en cas de défaillance Prérequis Alertes email configurées dans Zabbix Outil Boîte mail administrateur Procédure Simuler une indisponibilité en éteignant temporairement un équipement supervisé Résultat attendu Email d'alerte reçu dans la boîte mail de l'administrateur Résultat obtenu ✅ Les emails sont bien envoyé sur la boîte mail des administrateurs Statut ✅ Fonctionnel Synthèse # Service Test Statut 1.1 Wi-Fi Connectivité WAP150 ⚠️  1.2 Wi-Fi SNMPv3 WAP150 ✅ 1.3 Wi-Fi Connexion SSID ✅ 1.4 Wi-Fi Portail captif NoDogSplash ⚠️ 1.5 Wi-Fi Isolation VLAN 40 ✅ 2.1 Téléphonie Enregistrement PJSIP ✅ 2.2 Téléphonie Appel interne ✅ 2.3 Téléphonie Flux RTP ✅ 2.4 Téléphonie Script administration ✅ 3.1 Zabbix Interface web ✅ 3.2 Zabbix Statut hôtes ✅ 3.3 Zabbix Dashboard WiFi ✅ 3.4 Zabbix Dashboard VoIP ✅ 3.5 Zabbix Alerte email ✅