126 lines
5.1 KiB
Markdown
126 lines
5.1 KiB
Markdown
# Politique de sécurité – Homelab Proxmox VE
|
||
|
||
## Objectif
|
||
|
||
Ce document décrit les choix de sécurité appliqués à l'infrastructure homelab. Il ne s'agit pas d'une liste de règles formelles mais d'une réflexion sur les principes retenus, les menaces considérées et les compromis effectués — dans le contexte d'un usage personnel et d'apprentissage.
|
||
|
||
---
|
||
|
||
## Modèle de menace
|
||
|
||
L'infrastructure est exposée à deux catégories de risques principaux :
|
||
|
||
**Risques externes**
|
||
- Scan automatisé de ports et tentatives d'exploitation de services exposés
|
||
- Compromission d'un compte d'accès (Guacamole, Proxmox)
|
||
- Attaque sur le service VPN
|
||
|
||
**Risques internes**
|
||
- Fuite d'un environnement de test vulnérable (VM CTF, malware) vers le réseau de production
|
||
- Mauvaise manipulation sur une VM qui affecterait d'autres services
|
||
- Compromission d'une VM TP accessible via Guacamole
|
||
|
||
---
|
||
|
||
## Principes appliqués
|
||
|
||
### 1. Exposition minimale
|
||
|
||
**Principe** : aucun service ne doit être accessible depuis internet s'il n'en a pas strictement besoin.
|
||
|
||
**Mise en œuvre** :
|
||
- Un seul port ouvert sur la Freebox : UDP 51820 (WireGuard)
|
||
- Tous les services web (Proxmox WebUI, Guacamole, TrueNAS) sont accessibles uniquement via VPN ou Cloudflare Tunnel
|
||
- Pas de redirection de port RDP, SSH ou HTTP/HTTPS directe
|
||
|
||
---
|
||
|
||
### 2. Administration exclusivement via VPN
|
||
|
||
**Principe** : la surface d'attaque de l'administration doit être nulle depuis internet.
|
||
|
||
**Mise en œuvre** :
|
||
- L'interface Proxmox (port 8006) n'est accessible que depuis le tunnel WireGuard
|
||
- Toute intervention de maintenance (SSH sur LXC, console VM) passe par le VPN
|
||
- WireGuard est préféré à OpenVPN pour sa simplicité de code (surface d'attaque réduite), ses performances et sa cryptographie moderne (Curve25519, ChaCha20)
|
||
|
||
---
|
||
|
||
### 3. Accès partagé cloisonné (Guacamole + Cloudflare Access)
|
||
|
||
**Principe** : les accès donnés à des tiers (étudiants, partenaires de TP) doivent être authentifiés, traçables et limités aux ressources concernées.
|
||
|
||
**Mise en œuvre** :
|
||
- Guacamole exposé via Cloudflare Tunnel (aucun port direct)
|
||
- Double couche d'authentification :
|
||
- **Cloudflare Access** : vérification par lien email avant d'atteindre Guacamole
|
||
- **Guacamole** : identifiants individuels par utilisateur
|
||
- Les VMs accessibles via Guacamole sont sur le réseau 10.1.1.x, isolées du réseau Freebox
|
||
- Ces VMs ont accès à internet (via NAT OPNsense) mais ne peuvent pas atteindre les services d'administration
|
||
|
||
**Pourquoi Cloudflare Tunnel plutôt qu'un VPN pour les TPs ?**
|
||
Un VPN par utilisateur impliquerait une gestion de clés, une distribution sécurisée et une configuration cliente. Cloudflare Access permet un accès web simple (lien + email) sans client à installer, adapté à des utilisateurs non techniques ou ponctuels.
|
||
|
||
---
|
||
|
||
### 4. Segmentation réseau
|
||
|
||
**Principe** : les environnements de confiance différente ne doivent pas pouvoir communiquer librement.
|
||
|
||
**Mise en œuvre** :
|
||
|
||
| Segment | Confiance | Communication autorisée |
|
||
|---------|-----------|------------------------|
|
||
| Réseau Freebox (192.168.1.x) | Haute | Services de production, accès VPN |
|
||
| Réseau interne OPNsense (10.1.1.x) | Moyenne | Internet sortant via NAT, pas de retour vers Freebox |
|
||
| VMs CTF / Malware | Nulle | Aucune interface réseau |
|
||
|
||
OPNsense applique les règles suivantes :
|
||
- NAT sortant pour les VMs 10.1.1.x → internet
|
||
- Blocage de tout trafic 10.1.1.x → 192.168.1.x
|
||
- Pas de règle entrante depuis Freebox vers 10.1.1.x (deny-all par défaut)
|
||
|
||
---
|
||
|
||
### 5. Isolation des environnements de test
|
||
|
||
**Principe** : une VM compromise ou délibérément vulnérable ne doit pas affecter l'infrastructure.
|
||
|
||
**Mise en œuvre** :
|
||
- VMs CTF et malware déployées sans interface réseau ou sur réseau host-only Proxmox
|
||
- Snapshots systématiques avant toute expérimentation
|
||
- Restauration rapide vers un état propre après chaque session
|
||
- Nommage clair des VMs pour distinguer production / test / éphémère
|
||
|
||
---
|
||
|
||
### 6. Journalisation
|
||
|
||
**Principe** : tout trafic réseau entre segments doit être visible.
|
||
|
||
**Mise en œuvre** :
|
||
- OPNsense journalise les flux inter-segments et les connexions bloquées
|
||
- Les logs WireGuard permettent de tracer les connexions VPN (date, IP source, handshake)
|
||
- Guacamole journalise les sessions utilisateurs (connexion, durée, ressource accédée)
|
||
|
||
---
|
||
|
||
## Limites assumées
|
||
|
||
Ce homelab est un environnement personnel et d'apprentissage. Certaines mesures ne sont pas implémentées par choix pragmatique :
|
||
|
||
| Mesure | Statut | Raison |
|
||
|--------|--------|--------|
|
||
| IDS/IPS (Suricata) | Non déployé | Overhead CPU, prévu comme évolution |
|
||
| Authentification MFA sur Proxmox | Non actif | Accès uniquement via VPN, risque résiduel accepté |
|
||
| SIEM / centralisation des logs | Non déployé | Hors scope actuel |
|
||
| Rotation automatique des clés WireGuard | Manuelle | Fréquence suffisante pour usage personnel |
|
||
|
||
---
|
||
|
||
## Évolutions prévues
|
||
|
||
- Déploiement de Suricata sur OPNsense pour détection d'intrusion
|
||
- Mise en place d'un VLAN dédié aux VMs de TP (isolation plus fine)
|
||
- Exploration d'un SIEM léger (Wazuh ou Graylog) pour centraliser les logs
|