260901-reprise des règles du pare-feu de SASNEXTE

.....en profondeur !

Durcissement du NAS : de 28 ports exposés à 8

Constat de départ, mesuré depuis le VPS (hors LAN, hors VPN) : tous les ports en écoute du NAS répondaient depuis Internet, y compris NFS, SMB, FTP et le démon rsync.

La méthode qui a marché

Plutôt que de raisonner sur les règles du pare-feu, mesurer la surface réelle : lister les ports en écoute côté NAS, puis tester chacun depuis une machine extérieure. L'écart entre ce qu'on croit fermé et ce qui répond est la seule donnée qui compte.

Trois pièges rencontrés

1. L'ordre des règles. Le pare-feu Synology applique la première règle qui correspond, puis s'arrête. Une règle « Service terminal chiffré → Tous → Autoriser » placée en tête annulait complètement les règles « port 22 → Refuser » situées plus bas. Toute autorisation doit précéder le refus qu'elle contourne ; une règle placée après un refus qui la couvre est du décor.

2. Les libellés tronqués. « Interface de Gestion, File Station, Audio Statio… » masquait une longue liste d'applications — dont FTP et VPN Server. C'est ce qui expliquait qu'un port reste ouvert alors que la règle qui le concernait avait été supprimée. Toujours dérouler la liste complète derrière les points de suspension.

3. Éteindre un service est plus robuste que le filtrer. NFS a résisté à toutes les manipulations de règles ; il s'est fermé instantanément une fois le service désactivé. Un service éteint ne dépend d'aucune règle, d'aucun ordre, d'aucun profil actif.

Résultat

Fermés : SMB (445/139), NFS (2049, 111, 662, 892, 4045), FTP (21), rsync daemon (873), Note Station, File Station, WS-Discovery et une dizaine d'autres.

Restent : 22 (voulu — les deux VPS), 80/443/6690 (filtrés par pays), 5108/5109 (DSM), 5510 et 6281 (en cours d'identification).

Deux subtilités utiles

Le pare-feu Synology ne filtre que l'entrant. Le NAS va chercher les fichiers sur une seedbox en FTP : c'est une connexion sortante, soumise à aucune règle. Le port 21 du NAS n'y jouait aucun rôle et a pu être fermé sans rien casser. Bien distinguer « la machine se connecte » de « on se connecte à la machine » avant d'écrire une règle.

Le VPN rend la restriction indolore. En passant par le tunnel, le trafic arrive avec l'adresse source du VPN (10.8.0.0/24) et non l'IP publique du poste. Autoriser ce sous-réseau suffit, depuis n'importe où. Corollaire : le sous-réseau du VPN doit être explicitement autorisé sur le port 22 — il n'est couvert ni par 192.168.0.0/16 ni par 172.16.0.0/12. Sans cette règle, activer le pare-feu coupe l'accès SSH par le tunnel.

Point vérifié au passage : le VPN est OpenVPN (paquet VPNCenter, UDP 1194), et non WireGuard comme supposé. Testé par un vrai handshake — le serveur répond.

6. Erreurs commises pendant l'intervention

Consignées parce qu'elles sont instructives :

Une image supprimée à tort (page « Calcul Patterns Route Commune »), faute d'avoir compris que les pages pointent parfois sur l'URL scaled-. Restaurée depuis l'archive.
Diagnostic erroné : « vos suppressions de règles ne prennent pas effet ». La vraie cause était la règle englobante au libellé tronqué.
Test sur les mauvais ports : DSM déclaré « non exposé » après un test sur 5000/5001, alors qu'il écoute sur 5108/5109 — ports personnalisés.
Accès DSM supposé indisponible sans l'avoir vérifié. L'accès SMB au partage administrateur homes existait, et a permis de lire authorized_keys.

Les deux garde-fous qui ont évité des dégâts : l'archive systématique avant suppression, et la vérification après chaque action plutôt que la confiance dans l'effet attendu.

7. Ce qui reste ouvert

Sur la sauvegarde

Destination unique : si le NAS refuse, plus rien ne sort du VPS.
Aucune rétention sur le VPS (staging vidé après transfert).
Restauration jamais testée — une sauvegarde non restaurée n'est pas une sauvegarde.
Disque VPS à 87 % (9,3 Go libres).
HyperBackup non surveillé : toute la profondeur d'historique en dépend.

Sur le NAS

Identifier et fermer 5510 et 6281.
DSM (5108/5109) reste accessible depuis Internet — si maintenu, activer 2FA et le blocage automatique.
Inverser le sens du transfert : que le NAS tire depuis le VPS, ce qui permettrait de fermer SSH sur le NAS définitivement plutôt que provisoirement. Le compte synobackup existe déjà pour cela.

Sur les images : les 217 Mo de scaled- ne pourront être exclus qu'après avoir corrigé les 34 références dans les pages.