Il y a 389 articles et 19 utilisateurs inscrits (ce bandeau est défini dans MediaWiki:Sitenotice)
Protection réseau du serveur Proxmox Beotos3
Sécurisation réseau et pare-feu du serveur Proxmox Beotos3
Objectif
Le serveur physique Beotos3 est directement connecté à Internet et possède sa propre adresse IPv4 publique.
Il héberge notamment des services Proxmox et fournit un stockage NFS utilisé par Saturne3.
Un contrôle du serveur a montré que plusieurs services système, notamment RPC/rpcbind, étaient directement accessibles depuis Internet et faisaient l'objet de très nombreuses connexions provenant d'adresses IP publiques inconnues.
L'objectif de cette configuration est donc :
- de conserver l'adresse IP publique de Beotos3 ;
- de conserver la possibilité d'utiliser Beotos3 comme serveur de secours d'Eole3 ;
- d'autoriser uniquement les flux entrants réellement nécessaires ;
- de bloquer RPC/rpcbind et les ports RPC dynamiques depuis Internet ;
- de conserver les accès d'administration SSH et Proxmox ;
- de conserver la supervision Centreon ;
- de conserver le montage NFS utilisé par Saturne3 ;
- de conserver les communications sortantes de Beotos3 sans restriction particulière.
Configuration réseau de Beotos3
Beotos3 possède deux interfaces réseau principales.
Réseau public
Interface physique : enp9s0f0np0
Bridge Proxmox : vmbr0
IPv4 publique : 51.210.192.214/32
Passerelle : 100.64.0.1
Cette interface doit être conservée.
Elle permet actuellement :
- l'administration de Beotos3 depuis Internet ;
- l'accès à l'interface Web Proxmox ;
- le NFS utilisé par Saturne3 ;
- la supervision Centreon.
Elle sera également nécessaire en cas de bascule des services publics d'Eole3 vers Beotos3.
Important : l'activation du pare-feu Proxmox ne supprime ni vmbr0, ni l'adresse 51.210.192.214, ni la route Internet.
Le pare-feu contrôle uniquement les connexions entrantes autorisées.
Réseau privé
Interface physique : enp9s0f1np1
Bridge Proxmox : vmbr1
IPv4 privée : 192.168.123.104/24
Le réseau privé utilisé entre les serveurs est :
192.168.123.0/24
Eole3 utilise notamment :
192.168.123.202
Pare-feu utilisé
Beotos3 fonctionne sous Proxmox VE 9.2.2.
Deux implémentations de pare-feu sont présentes sur le système :
pve-firewall
proxmox-firewall
La configuration actuellement retenue utilise le pare-feu Proxmox historique :
pve-firewall
Le moteur nftables « preview » de Proxmox VE 9 n'est pas utilisé.
Dans l'interface Proxmox :
Datacenter
└── Firewall
└── Options
└── Firewall = Yes
Sur le nœud :
beotos3
└── Firewall
└── Options
├── Firewall = Yes
└── nftables (preview) = No
La politique entrante est :
Input Policy : DROP
La politique sortante reste :
Output Policy : ACCEPT
Cela signifie que :
- toute nouvelle connexion entrante non explicitement autorisée est bloquée ;
- Beotos3 peut continuer à initier ses connexions sortantes ;
- les sauvegardes, rsync, mises à jour et connexions vers Eole3 ou PBS4 continuent donc à fonctionner normalement.
Emplacement de la configuration
Les règles spécifiques au nœud Beotos3 sont enregistrées par Proxmox dans :
/etc/pve/nodes/beotos3/host.fw
Attention : il ne faut pas créer manuellement un fichier :
/etc/pve/firewall/beotos3.fw
Ce n'est pas l'emplacement utilisé pour les règles firewall du nœud.
La configuration doit de préférence être réalisée depuis l'interface Proxmox afin que les règles soient enregistrées au bon endroit.
Règles entrantes autorisées
Les règles actuellement configurées dans :
/etc/pve/nodes/beotos3/host.fw
sont :
[RULES]
IN ACCEPT -source 109.190.129.96 -p tcp -dport 8006 -log nolog # Proxmox administration bureau
IN ACCEPT -source 51.83.117.105 -p udp -dport 161 -log nolog # SNMP Centreon public
IN ACCEPT -source 10.0.0.16 -p udp -dport 161 -log nolog # SNMP Centreon LAN
IN ACCEPT -source 141.95.206.118 -p tcp -dport 2049 -log nolog # NFS Saturne3
IN ACCEPT -source 192.168.123.0/24 -p tcp -dport 3128 -log nolog # SPICE réseau privé
IN ACCEPT -source 192.168.123.0/24 -p tcp -dport 8006 -log nolog # Proxmox réseau privé
IN ACCEPT -source 192.168.123.0/24 -p tcp -dport 22 -log nolog # SSH réseau privé
IN ACCEPT -source 109.190.129.96 -p tcp -dport 22 -log nolog # SSH administration AJLSM
Une règle ICMP entrante a également été ajoutée pour permettre le ping et notamment le monitoring OVH.
Tableau récapitulatif
| Source | Protocole | Port | Utilisation |
|---|---|---|---|
| 109.190.129.96 | TCP | 22 | Administration SSH AJLSM |
| 109.190.129.96 | TCP | 8006 | Interface Web Proxmox AJLSM |
| 192.168.123.0/24 | TCP | 22 | SSH depuis le réseau privé |
| 192.168.123.0/24 | TCP | 8006 | Interface Proxmox depuis le réseau privé |
| 192.168.123.0/24 | TCP | 3128 | SPICE depuis le réseau privé |
| 141.95.206.118 | TCP | 2049 | NFS Saturne3 |
| 51.83.117.105 | UDP | 161 | Supervision SNMP Centreon |
| 10.0.0.16 | UDP | 161 | Supervision SNMP Centreon LAN |
| Internet | ICMP | - | Ping et monitoring OVH |
Tout autre trafic entrant est bloqué par défaut.
Accès SSH
L'accès SSH root est conservé, mais l'authentification par mot de passe a été désactivée.
La configuration effective est :
PermitRootLogin yes
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
L'accès SSH public est en plus limité par le pare-feu à l'adresse d'administration :
109.190.129.96
La sécurité repose donc sur deux niveaux :
- filtrage de l'adresse IP source par le pare-feu ;
- authentification SSH par clé publique.
Après modification de SSH, une nouvelle connexion SSH a été testée avec succès.
Protection NFS et RPC
NFS Saturne3
Saturne3 monte le stockage de Beotos3 en NFSv4.2.
51.210.192.214:/data-backup/pbs/import-saturne3/vz/dump
La source autorisée est exclusivement :
141.95.206.118
sur :
TCP/2049
NFSv4.2 permet ce fonctionnement sans avoir besoin d'exposer rpcbind et les ports RPC dynamiques sur Internet.
Services RPC
Les services suivants peuvent continuer à écouter sur Beotos3 :
TCP/UDP 111 rpcbind
rpc.mountd
rpc.statd
nlockmgr
ports RPC dynamiques
Ils ne sont cependant plus accessibles librement depuis Internet.
Avant l'activation du pare-feu, environ 200 connexions TCP étaient simultanément établies depuis différentes adresses Internet vers :
51.210.192.214:111
Ces connexions concernaient rpcbind.
La politique INPUT DROP empêche désormais l'établissement de nouvelles connexions Internet vers TCP/111 et les autres ports RPC non explicitement autorisés.
Supervision Centreon
Deux sources sont autorisées à interroger SNMP sur Beotos3 :
51.83.117.105
10.0.0.16
sur :
UDP/161
Une capture réseau a permis de vérifier une interrogation réelle de Centreon :
51.83.117.105 -> 51.210.192.214:161/UDP
ainsi que la réponse de Beotos3 :
51.210.192.214:161 -> 51.83.117.105
La supervision SNMP fonctionne donc avec le pare-feu actif.
ICMP et monitoring OVH
Lors de la première activation de la politique INPUT DROP, OVH a signalé :
Le serveur 51.210.192.214 ne répond plus aux requêtes de ping.
Le serveur était pourtant toujours accessible en SSH, Proxmox, NFS et SNMP.
L'alerte provenait donc du blocage des requêtes ICMP utilisées par le monitoring OVH.
Une règle ICMP entrante a été ajoutée.
La compilation du pare-feu contient maintenant :
-A PVEFW-HOST-IN -p icmp -j RETURN
Le ping public est donc autorisé sans ouvrir de service TCP ou UDP supplémentaire.
Vérifications réalisées après activation
État du firewall
pve-firewall status
systemctl is-active pve-firewall
Résultat obtenu :
Status: enabled/running
active
Accès SSH
Une nouvelle connexion SSH a été ouverte après activation du pare-feu.
Le test a réussi.
Interface Proxmox
L'accès public à :
https://51.210.192.214:8006/
depuis l'adresse d'administration autorisée a été testé avec succès.
NFS Saturne3
Depuis Saturne3 :
touch /mnt/pve/beotos3-import-saturne3/.fw-test2 &&
rm /mnt/pve/beotos3-import-saturne3/.fw-test2 &&
echo "NFS TOUJOURS OK"
Résultat :
NFS TOUJOURS OK
Les connexions NFS restent établies :
51.210.192.214:2049 <-> 141.95.206.118
SNMP
Une requête SNMP Centreon et sa réponse ont été observées avec :
tcpdump -ni any 'udp port 161 and (host 51.83.117.105 or host 10.0.0.16)'
Vérification du filtrage Internet
Les compteurs du firewall ont été contrôlés avec :
iptables -L PVEFW-HOST-IN -n -v --line-numbers
En quelques secondes, le compteur de la règle DROP est notamment passé de :
362 paquets
à :
423 paquets
Les nouvelles tentatives Internet non autorisées sont donc effectivement bloquées.
Vérification de la configuration avant modification
Avant toute modification importante du firewall, vérifier ce que Proxmox va réellement générer.
pve-firewall compile
Pour contrôler les principales règles de Beotos3 :
pve-firewall compile | grep -E \
'109\.190\.129\.96|192\.168\.123\.0/24|141\.95\.206\.118|51\.83\.117\.105|10\.0\.0\.16'
Les règles attendues doivent apparaître avant la règle finale DROP.
On peut également contrôler ICMP :
pve-firewall compile | grep -E 'icmp|PVEFW-HOST-IN'
Procédure de sécurité lors d'une modification du firewall
Beotos3 étant un serveur physique distant, directement connecté à Internet, toute modification importante doit être effectuée avec précaution.
Avant modification
- conserver une session SSH déjà ouverte ;
- si possible, conserver l'accès IPMI/KVM OVH disponible ;
- vérifier les règles avec
pve-firewall compile; - ne jamais supposer qu'une règle présente dans un fichier est réellement compilée ;
- prévoir un rollback automatique pour toute modification susceptible de couper SSH.
Rollback automatique temporaire
Exemple de rollback à cinq minutes :
systemd-run --unit=firewall-rollback-beotos3 \
--on-active=5m \
/bin/bash -c 'pve-firewall stop; sed -i "s/^enable: 1/enable: 0/" /etc/pve/firewall/cluster.fw'
Vérifier sa programmation :
systemctl list-timers --all | grep firewall-rollback
Après activation
Contrôler immédiatement :
pve-firewall status
systemctl is-active pve-firewall
iptables -S PVEFW-HOST-IN
Puis tester :
- une nouvelle connexion SSH ;
- l'interface Web Proxmox ;
- NFS depuis Saturne3 ;
- SNMP/Centreon.
Suppression du rollback
Uniquement lorsque les tests sont concluants :
systemctl stop firewall-rollback-beotos3.timer
systemctl reset-failed firewall-rollback-beotos3.timer 2>/dev/null || true
systemctl list-timers --all | grep firewall-rollback || echo "Rollback désarmé"
Commandes de diagnostic
État du firewall
pve-firewall status
systemctl status pve-firewall
Règles effectivement chargées
iptables -S PVEFW-HOST-IN
Règles et compteurs
iptables -L PVEFW-HOST-IN -n -v --line-numbers
Connexions NFS Saturne3
ss -tn | grep '141\.95\.206\.118.*:2049\|:2049.*141\.95\.206\.118'
Connexions encore établies sur rpcbind
ss -nt state established '( sport = :111 )'
Pour compter les connexions :
ss -nt state established '( sport = :111 )' | tail -n +2 | wc -l
Capture SNMP Centreon
tcpdump -ni any 'udp port 161 and (host 51.83.117.105 or host 10.0.0.16)'
PRA : bascule publique d'Eole3 vers Beotos3
Principe
Beotos3 conserve volontairement son interface Internet :
vmbr0
51.210.192.214
Cette interface ne doit pas être supprimée même si, en fonctionnement normal, les services publics concernés sont fournis par Eole3.
Le firewall protège Beotos3 mais n'empêche pas une future publication de services.
Il suffira d'ajouter ou d'activer les règles correspondant aux services devant être accessibles publiquement.
Fonctionnement normal
Internet
│
│
▼
eole3.ajlsm.com
│
│ DNS
▼
51.178.110.230
│
▼
Eole3
Fonctionnement en PRA
En cas de panne d'Eole3 :
Internet
│
│
▼
eole3.ajlsm.com
│
│ modification DNS
▼
51.210.192.214
│
▼
Beotos3
Attention au firewall
Modifier uniquement le DNS ne suffira pas.
Actuellement, le firewall de Beotos3 bloque tous les services entrants qui ne figurent pas dans la liste des autorisations.
Par conséquent :
DNS eole3.ajlsm.com -> 51.210.192.214
ne signifie pas automatiquement
Services Eole3 accessibles sur Beotos3
Les ports nécessaires devront être autorisés dans le firewall.
Préparation recommandée avant une panne
Il est recommandé de préparer le PRA avant d'en avoir besoin.
Pour chaque service Eole3 susceptible d'être repris par Beotos3, déterminer :
- le nom DNS ;
- le protocole TCP ou UDP ;
- le port ;
- le service ou la VM qui répondra sur Beotos3 ;
- si l'accès doit être public ou limité à certaines adresses ;
- les éventuels certificats TLS nécessaires.
Créer ensuite dans :
Proxmox
└── beotos3
└── Firewall
└── Rules
les règles nécessaires au PRA.
Ces règles peuvent rester désactivées en fonctionnement normal.
Utiliser des commentaires explicites, par exemple :
PRA Eole3 - HTTPS
PRA Eole3 - SFTP
PRA Eole3 - service XXX
Ainsi, en cas de panne, il ne sera pas nécessaire d'inventer la configuration dans l'urgence.
Procédure de bascule Eole3 vers Beotos3
1. Constater l'indisponibilité d'Eole3
Vérifier qu'il s'agit bien d'une panne nécessitant le déclenchement du PRA.
2. Démarrer les services de secours
Sur Beotos3, démarrer les VM, conteneurs ou services prévus pour remplacer Eole3.
Vérifier leur fonctionnement localement ou depuis le réseau privé.
3. Activer les règles firewall PRA
Dans Proxmox :
beotos3
└── Firewall
└── Rules
activer uniquement les règles nécessaires.
Ne pas désactiver globalement le firewall.
Vérifier ensuite la compilation :
pve-firewall compile
Puis l'état :
pve-firewall status
Résultat attendu :
Status: enabled/running
4. Vérifier l'écoute des services
Avant de modifier le DNS :
ss -lntup
Vérifier que les ports nécessaires sont réellement en écoute.
5. Tester via l'adresse publique de Beotos3
L'adresse publique de secours est :
51.210.192.214
Tester autant que possible les services avant la modification DNS.
Pour HTTPS, il faudra tenir compte du fait que le certificat et le VirtualHost peuvent nécessiter le nom DNS pour répondre correctement.
6. Modifier le DNS
Faire pointer :
eole3.ajlsm.com
de :
51.178.110.230
vers :
51.210.192.214
On obtient alors :
eole3.ajlsm.com
│
▼
51.210.192.214
│
▼
Beotos3
7. Vérifier la propagation DNS
Par exemple :
dig +short eole3.ajlsm.com
Le résultat attendu après bascule est :
51.210.192.214
8. Tester les services depuis Internet
Tester chaque service via son nom DNS réel.
Par exemple, pour HTTPS :
curl -I https://eole3.ajlsm.com/
Vérifier également :
- les certificats TLS ;
- les éventuelles redirections ;
- les VirtualHosts ;
- les droits d'accès ;
- les journaux des services ;
- la supervision Centreon.
9. Ne pas ouvrir inutilement les services d'administration
Le déclenchement du PRA ne doit pas conduire à ouvrir publiquement :
SSH
Proxmox
RPC
NFS
SNMP
au monde entier.
Les règles actuelles d'administration et de supervision doivent rester limitées aux sources autorisées.
Retour d'Eole3 après PRA
Lorsque Eole3 est de nouveau opérationnel :
- vérifier complètement Eole3 ;
- remettre les données à jour si nécessaire ;
- tester les services Eole3 ;
- remettre le DNS vers l'adresse publique d'Eole3 ;
- attendre/vérifier la propagation DNS ;
- confirmer que les utilisateurs arrivent de nouveau sur Eole3 ;
- désactiver les règles firewall portant le commentaire
PRA Eole3; - arrêter les services de secours devenus inutiles sur Beotos3.
Le fonctionnement normal redevient :
eole3.ajlsm.com
│
▼
51.178.110.230
│
▼
Eole3
Point restant à préparer
La connectivité publique de Beotos3 est déjà conservée.
En revanche, avant de considérer le PRA Eole3 comme totalement opérationnel, il reste à établir précisément la liste des services d'Eole3 devant être repris.
Il faudra donc réaliser un inventaire :
Service
Nom DNS
Port
Protocole
Destination sur Beotos3
Certificat éventuel
Règle firewall PRA
À partir de cet inventaire, les règles PRA Eole3 pourront être préparées à l'avance et laissées désactivées.
Ainsi, une panne d'Eole3 ne nécessitera pas de modifier la politique générale du firewall de Beotos3 : il suffira de démarrer les services de secours, d'activer les règles PRA prévues et de basculer le DNS.