https://teknolabs.net/courses/python/programmation-reseaux/module-5/index.html DevSecOps appliqué au réseau Définition Intégrer la sécurité à chaque étape du cycle DevOps, plutôt qu’en contrôle final avant mise en production. Shift-left Déplacer les contrôles de sécurité le plus tôt possible dans le pipeline (dès le commit), pour détecter un problème avant le déploiement plutôt qu’après. Étapes типiques d’un pipeline CI/CD sécurisé Commit --> Lint --> Validation --> Tests --> Déploiement --> Monitoring Les contrôles de sécurité (lint, validation, tests) sont poussés le plus tôt possible dans le pipeline. Hugo en-us https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp15-environnement/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp15-environnement/index.html Ce TP réutilise exactement la même VM FortiGate que le TP 6 (voir tp6-environnement.md) : aucune nouvelle VM à créer. Il ajoute un runner CI auto-hébergé sur le poste hôte. 1. Prérequis la VM FortiGate du TP 6 démarrée et accessible en API REST, un compte GitHub et le dépôt du TP 6 (ou un nouveau dépôt dédié), Git installé sur le poste hôte. 2. Pourquoi un runner auto-hébergé ? Les runners GitHub Actions hébergés dans le cloud ne peuvent pas atteindre la VM FortiGate, isolée sur un réseau privé (host-only) accessible uniquement depuis le poste hôte. Un runner self-hosted, installé sur ce même poste, résout le problème. https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp15-cicd-firewall-as-code/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp15-cicd-firewall-as-code/index.html Module : 5 – NetSecDevOps et Sécurité Automatisée Durée indicative : 2h30 Prérequis : Modules 1 et 2 (Git, FortiGate REST API), un dépôt GitHub, un runner CI accessible Objectifs Décrire des règles de pare-feu FortiGate sous forme de fichiers versionnés. Construire un pipeline CI/CD : lint, tests de non-régression, déploiement. Appliquer le principe de shift-left à la gestion d’un pare-feu. Contexte Toute nouvelle règle de pare-feu passe désormais par une Pull Request (Module 1), validée automatiquement par un pipeline avant d’être appliquée au FortiGate du TP 6. https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp16-environnement/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp16-environnement/index.html Hyperviseur recommandé : VirtualBox (fonctionne également avec VMware Workstation ou Hyper-V) Ce TP nécessite deux petites VM Linux (peer-web, peer-admin) servant de pairs NetBird — aucun composant NetBird côté serveur à installer (utilisation de NetBird Cloud, gratuit). 1. Prérequis 512 Mo de RAM et 1 vCPU par VM suffisent, un accès Internet depuis les deux VM (mode NAT), pour joindre NetBird Cloud, un compte NetBird gratuit (https://app.netbird.io). 2. Téléchargement de l’image Utilisez une image Linux légère, par exemple Debian 12 netinst (https://www.debian.org/download) ou Ubuntu Server 22.04/24.04 LTS. https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp16-ztna-netbird/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp16-ztna-netbird/index.html Module : 5 – NetSecDevOps et Sécurité Automatisée Durée indicative : 2h Prérequis : un compte NetBird (Cloud, offre gratuite), deux pairs Linux accessibles (voir fichier d’environnement), Python 3, pip install requests Objectifs Comprendre le déploiement d’un réseau overlay WireGuard managé (NetBird). Provisionner des pairs et des politiques d’accès via l’API REST NetBird. Illustrer concrètement la différence ZTNA / VPN classique du Module 5. Contexte Deux machines (peer-web, peer-admin) doivent communiquer uniquement sur le port applicatif nécessaire, sans être exposées l’une à l’autre sur l’ensemble de leur sous-réseau — contrairement à un VPN classique qui les placerait sur le même LAN virtuel complet. https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp17-environnement/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp17-environnement/index.html Ce TP réutilise exactement la même VM OPNsense que le TP 7 (voir tp7-environnement.md) : aucune nouvelle VM à créer. Le « collecteur SOAR » est un simple script Python exécuté sur le poste hôte. 1. Prérequis la VM OPNsense du TP 7 démarrée et accessible en API, Python 3 avec pip install fastapi uvicorn requests pydantic python-dotenv sur le poste hôte. 2. Préparation côté OPNsense Firewall → Aliases → + : créez un alias vide de type Host(s), nommé soar_blocklist. Firewall → Rules → LAN (ou WAN selon le scénario) : créez une règle Block en première position, source = alias soar_blocklist, appliquez. Vérifiez que la clé/secret API du TP 7 sont toujours valides (.env). 3. Vérification de l’accès à l’alias via l’API curl -k -u "$OPNSENSE_KEY:$OPNSENSE_SECRET" https://192.168.1.1/api/firewall/alias/getAliasUUID/soar_blocklist 4. Lancement du serveur d’écoute Aucune VM supplémentaire n’est nécessaire : soar_listener.py tourne directement sur le poste hôte, sur le même réseau que celui utilisé pour joindre OPNsense (adaptateur host-only du TP 7). https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp17-soar-opnsense/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp17-soar-opnsense/index.html Module : 5 – NetSecDevOps et Sécurité Automatisée Durée indicative : 2h Prérequis : le OPNsense du TP 7 accessible, Python 3, pip install fastapi uvicorn requests pydantic python-dotenv Objectifs Construire un mini-outil SOAR : réception d’alertes, décision, action. Automatiser le blocage d’une adresse IP compromise via l’API REST d’OPNsense. Mettre en œuvre les garde-fous vus en théorie (portée et durée limitées, journalisation). Contexte Un IDS/IPS enverrait normalement une alerte via un webhook lors de la détection d’un comportement suspect. Vous simulez cette alerte pour déclencher automatiquement un blocage temporaire sur le pare-feu. https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp18-environnement/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp18-environnement/index.html Hyperviseur recommandé : VirtualBox (une seule VM), ou installation directe sur le poste hôte si Docker Desktop y est déjà disponible. 1. Prérequis matériels 4 Go de RAM, 2 vCPU, 20 Go de disque (VM dédiée recommandée pour isoler l’environnement), un accès Internet (téléchargement des images de conteneurs). 2. Création de la VM (si environnement isolé souhaité) Nouvelle machine → Type Linux → Ubuntu (64-bit). RAM : 4 Go, disque : 20 Go. Téléchargez Ubuntu Server 24.04 LTS (https://ubuntu.com/download/server), installez-le normalement. Réseau : Adaptateur en NAT (accès Internet) ; un second adaptateur host-only est optionnel si vous voulez exposer kubectl depuis le poste hôte. 3. Installation de Docker curl -fsSL https://get.docker.com | sudo sh sudo usermod -aG docker $USER newgrp docker 4. Installation de kind et kubectl curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64 chmod +x ./kind && sudo mv ./kind /usr/local/bin/kind curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" chmod +x kubectl && sudo mv kubectl /usr/local/bin/ 5. Création du cluster sans le CNI par défaut Le CNI par défaut de kind (kindnet) n’applique pas les NetworkPolicy. Créez le cluster en le désactivant : https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp18-kubernetes-networkpolicy/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp18-kubernetes-networkpolicy/index.html Module : 5 – NetSecDevOps et Sécurité Automatisée Durée indicative : 2h Prérequis : un cluster Kubernetes local avec CNI supportant les NetworkPolicy (voir fichier d’environnement), kubectl, Python 3, pip install kubernetes Objectifs Déployer des microservices de test dans des espaces de noms dédiés. Appliquer une politique default deny puis des autorisations ciblées. Générer des NetworkPolicy par programmation avec le client Python Kubernetes. Contexte Vous sécurisez une petite architecture de microservices (frontend, backend, database) en n’autorisant que les flux strictement nécessaires entre eux. https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp19-environnement/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp19-environnement/index.html Ce TP réutilise exactement les VM MikroTik (TP 5) et Cisco IOS-XE (TP 9) : aucune nouvelle VM à créer. 1. Prérequis les VM des TP 5 et TP 9 démarrées et accessibles (API REST pour MikroTik, SSH pour Cisco), Python 3 avec pip install requests netmiko pyyaml sur le poste hôte, si vous réutilisez inventory/hosts.yaml du TP 14, celui-ci doit toujours pointer vers des adresses valides. 2. Introduction volontaire d’une non-conformité (pour tester le scanner) Sur MikroTik, activez temporairement Telnet (normalement désactivé) : https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp19-compliance-as-code/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/python/programmation-reseaux/module-5/tp19-compliance-as-code/index.html Module : 5 – NetSecDevOps et Sécurité Automatisée Durée indicative : 2h Prérequis : les VM MikroTik (TP 5) et Cisco IOS-XE (TP 9) accessibles, Python 3, pip install requests netmiko pyyaml Objectifs Définir un référentiel de contrôles de sécurité au format déclaratif. Développer un scanner d’audit interrogeant plusieurs équipements. Générer un rapport de conformité automatisé et exploitable. Contexte Plutôt qu’un audit manuel ponctuel, vous construisez un contrôle continu qui vérifie régulièrement que les équipements du parc respectent des règles de sécurité minimales.