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 :

1. filtrage de l'adresse IP source par le pare-feu ;
2. 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

1. conserver une session SSH déjà ouverte ;
2. si possible, conserver l'accès IPMI/KVM OVH disponible ;
3. vérifier les règles avec pve-firewall compile ;
4. ne jamais supposer qu'une règle présente dans un fichier est réellement compilée ;
5. 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 :

1. une nouvelle connexion SSH ;
2. l'interface Web Proxmox ;
3. NFS depuis Saturne3 ;
4. 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 :

1. vérifier complètement Eole3 ;
2. remettre les données à jour si nécessaire ;
3. tester les services Eole3 ;
4. remettre le DNS vers l'adresse publique d'Eole3 ;
5. attendre/vérifier la propagation DNS ;
6. confirmer que les utilisateurs arrivent de nouveau sur Eole3 ;
7. désactiver les règles firewall portant le commentaire PRA Eole3 ;
8. 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.