Un format fixe, à reproduire pour chaque nouvelle famille rencontrée.
Firewall Stormshield firewall
Le boîtier lui-même : administration, VPN, supervision.
Flux entrants
Depuis les interfaces protégées : Tcp_13443 administration (443 par défaut, déplacé sur le parc), Tcp_443 portail d'authentification, Tcp_22 SSH, Tcp_1300 serverd (Real-Time Monitor et outils). Depuis Internet : Udp_1194 puis Tcp_13444 pour le VPN SSL (443 par défaut, déplacé sur le parc), Tcp_443 pour le portail qui distribue sa configuration, Udp_500, Udp_4500 et Esp pour IPsec.
Flux initiés
Tcp_1754 vers Stormshield Management Center s'il est utilisé · DNS et NTP · syslog vers le collecteur (Groupe_Supervision). Sur le site qui héberge SMC, ce 1754 arrive par une publication restreinte aux boîtiers gérés : Groupe_SMC.
Pièges
Les règles implicites ouvrent l'administration, le VPN SSL et IKE/ESP avant le slot : une règle explicite qui restreint n'est jamais évaluée tant qu'elles sont actives.
Objet FQDN : jamais en groupe, un seul par règle, inopérant en NAT — sans avertissement.
L'analyseur DNS peut bloquer les réponses du propre résolveur du boîtier : objets FQDN instables.
Décision type
Qui administre le boîtier, et d'où ? Tant que la réponse n'est pas « ces postes-là », l'accès reste ouvert à toutes les interfaces protégées.
À vérifier
Postes d'administration autorisés renseignés · règles implicites passées en revue (ANSSI R30) · logs exportés hors du boîtier.
Stockage, partages SMB, souvent dépôt de sauvegarde.
Flux initiés
Tcp_443 QuickConnect, mises à jour, services cloud · Udp_123 + Udp_53 · vers un NAS distant nommé : Tcp_6281 Hyper Backup Vault, Tcp_5566 Snapshot Replication, Tcp_873 rsync (Groupe_NAS_Replication) · vers les hôtes Hyper-V, pour Active Backup for Business : Tcp_445 et Tcp_5985/5986
Flux entrants
Depuis le LAN : Tcp_445, Tcp_5001, et Tcp_5510 des agents Active Backup (Groupe_NAS). Depuis Internet : aucun — publier DSM est à proscrire.
Destination
Service web Synology s'il est disponible — il évite toute maintenance de liste. Sinon Internet + ports stricts.
Pièges
Un service web contraint le où, pas le quoi : sans groupe de ports associé, on autorise n'importe quel protocole vers ces plages.
Fermer Groupe_Infra en même temps coupe DNS et NTP, et la validation TLS échoue derrière.
QuickConnect contourne le firewall par conception. L'étude publique de 2023 a obtenu le numéro de série par la découverte Synology Assistant (UDP 9999), qui répondait sans authentification : elle n'a rien à faire entre VLAN.
Ports d'administration en clair — 5000 Synology, 8080 QNAP — à fermer, ne garder que la version TLS.
Décision type
Le NAS héberge-t-il les sauvegardes ? Si oui, QuickConnect y a-t-il sa place alors qu'un VPN SSL existe ?
À vérifier
Un dépôt de sauvegarde SMB accessible avec des identifiants du domaine est le scénario de perte totale sur rançongiciel. Poser la question de l'immuabilité et des comptes hors domaine.
Observé
09/2026 — dépôts Veeam en partage SMB sur deux NAS, aucun immuable.
Stockage, partages SMB, souvent dépôt de sauvegarde. Système QTS (ext4) ou QuTS hero (ZFS).
Flux initiés
Tcp_443 myQNAPcloud, mises à jour, services cloud · Udp_123 + Udp_53 · vers un NAS distant nommé : Tcp_873 rsync, Tcp_8899 RTRR (Groupe_NAS_Replication)
Flux entrants
Depuis le LAN : Tcp_445, Tcp_443 pour l'interface et Qsync (Groupe_NAS), Tcp_3260 depuis les serveurs pour les LUN iSCSI. Depuis Internet : aucun.
Pièges
L'interface répond en clair sur Tcp_8080 : à fermer, ne garder que Tcp_443.
QNAP demande de désactiver l'UPnP du NAS et toute redirection de port vers 8080 et 443 : le rançongiciel DeadBolt a chiffré des NAS joignables depuis Internet.
myQNAPcloud Link rend le NAS joignable par relais, sans règle au firewall : à décider explicitement, comme QuickConnect chez Synology.
Qsync passe par l'interface web : ouvrir la synchronisation, c'est ouvrir l'interface d'administration au même port.
Décision type
L'accès distant passe-t-il par le VPN SSL du firewall, ou par myQNAPcloud ? Les deux à la fois, c'est une porte de trop.
À vérifier
Comme pour Synology : dépôt de sauvegarde en SMB avec des identifiants du domaine, instantanés, immuabilité.
Tcp_12366 authentification P2P · Tcp/Udp_8800-8803 serveur P2P · Tcp_8900-8903 relais · Tcp_8180 GMS · Tcp_80Tcp_443 · UDP aléatoire pour le flux média, l'éditeur indique qu'aucune plage ne peut être définie
Flux entrants
aucun si le P2P fonctionne Le protocole propriétaire 37777/TCP et 37778/UDP est l'équivalent Dahua du 8000 Hikvision : ne jamais le publier.
Destination
Pas de service web en pratique. Domaines de courtage www.easy4ipcloud.com et www.easy4ip.com — mais ils ne couvrent que l'authentification. Donc Internet + ports Easy4ip + source restreinte à un groupe nommé caméras/enregistreurs.
Pièges
La sortie UDP large est inhérente au protocole. C'est acceptable uniquement en contrepartie de la suppression des publications entrantes.
Décision type
Qui consulte à distance, et avec quoi ? Si c'est l'application constructeur, les publications tombent.
Observé
09/2026 — trois enregistreurs et une vingtaine de caméras, 612 sessions P2P par quart d'heure, six publications entrantes devenues inutiles.
Quatre FQDN : dev.hik-connect.com, litedev.hik-connect.com, dev.eu.hik-connect.com, litedev.eu.hik-connect.com, dans un service web personnalisé — un objet FQDN ne se groupe pas. Pour EZVIZ, *.ezvizlife.com : joker refusé par un objet FQDN, accepté par un service web personnalisé (non encore testé sur le parc).
Pièges
La liste de ports est large : ce n'est acceptable que parce que la destination est restreinte aux FQDN. Vers Internet, c'est un trou béant.
Les quatre FQDN doivent être dans le service web, pas trois : un basculement vers celui qui manque donne un push intermittent, impossible à diagnostiquer.
Le 10101 est aussi le port de supervision des centrales d'alarme : ces plages peuvent mélanger deux équipements.
Un objet de protocole « Any » ouvre le port en TCP et UDP, soit deux fois la surface.
ONVIF passe par le port HTTP (80 par défaut) : pas de port ONVIF à ouvrir en plus.
Observé
09/2026 — un site où seuls trois des quatre FQDN étaient référencés.
Remontée vers un centre de télésurveillance, sur un port non standard.
Flux initiés
Port de supervision propre au télésurveilleur — Tcp_10101 fréquent · Tcp_443. Signature : un battement à intervalle strictement régulier, typiquement une fois par minute.
Flux entrants
à questionner Si le télésurveilleur doit configurer ou armer à distance, il faut ses ports exacts — jamais Any, et jamais sans restriction d'interface ni de source.
Pièges
Une centrale coupée de son superviseur ne lève plus d'alerte à distance, et rien ne le signale côté firewall. Ce flux est à retester après chaque resserrage. C'est celui dont la panne ne se voit que le jour où il aurait fallu qu'il fonctionne.
À vérifier
L'objet FQDN du superviseur existe-t-il et est-il référencé dans une règle ? Un objet créé mais inutilisé signifie que le flux passe par une règle fourre-tout, et tombera avec elle.
Observé
09/2026 — objet tcs.tcsalarm.com présent dans les objets, référencé nulle part.
Sauvegarde Veeam sauvegarde
Serveur VBR, proxies, dépôts, machines protégées.
VBR → serveurs gérés
Tcp_6160 Installer Service (repli Tcp_11731) · Tcp_6163 hôtes Hyper-V · Tcp_445 + Tcp_135 déploiement, sauf si le Veeam Deployment Kit est installé · Tcp_49152-65535 vers les hôtes Hyper-V quand le pare-feu Windows n'est pas celui par défaut
Transferts
v13 : Tcp_6162, la plage Tcp_2500-3300 seulement en repli. v12 : Tcp_6162 + un port de la plage par connexion. Entre proxy, dépôt et hôte ; le reste va de VBR vers l'hôte, jamais l'inverse : une règle retour symétrique est du copier-coller.
Console
v13 : Tcp_443 (et Tcp_9420 pour la mise à jour de la console). v12 : Tcp_9392 + Tcp_9420. Enterprise Manager → VBR : Tcp_9392.
Dépôt SMB
Le serveur passerelle monte le partage et écrit en Tcp_445. Avec « Gateway (auto) », Veeam choisit la passerelle tout seul et la source de la règle devient imprévisible — épingler la passerelle explicitement dans les propriétés du dépôt.
Ne jamais donner de sortie Internet générale au serveur de sauvegarde.
Le protocole du Data Mover est propriétaire : surveiller les alarmes à la première sauvegarde après un passage en IPS.
Tester avec un rescan de l'infrastructure, pas seulement un job incrémental — c'est le rescan qui exerce le 6160, le 445 et la plage RPC.
Résidus fréquents
Tcp_7680 Delivery Optimization, Tcp_2500 isolé dans des règles AD, et 2500-5000 sur une installation mise à jour depuis une version antérieure à la v10.
Partage pair-à-pair des mises à jour Windows, Store, Microsoft 365, Edge, Teams, Intune.
Flux initiés
Tcp_7680 entre postes · Udp_3544 (Teredo) en modes Groupe et Internet. Signature : retry toutes les 40 secondes environ, sur de nombreuses sources.
Piège de conf
Le mode « LAN » (1) définit les pairs comme les machines qui sortent par la même IP publique, pas le même sous-réseau : sur Windows 10, il n'empêche pas le trafic inter-VLAN. Windows 11 restreint déjà ce mode au sous-réseau ; un mode « Groupe » (2) poussé par GPO, lui, franchit les VLAN par conception.
Correctifs
DODownloadMode = 1etDORestrictPeerSelectionBy = 1 (masque de sous-réseau) — partage conservé dans chaque VLAN. DODownloadMode = 0 — aucun partage. Plus simple, et tout paquet 7680 restant devient une anomalie détectable.
Mise en œuvre
Registre : HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization. GPO : Composants Windows → Optimisation de la distribution.
gpupdate /force
Restart-Service DoSvc
Get-DeliveryOptimizationPerfSnap # BytesFromPeers doit tomber à 0
Impact
Plus de téléchargements depuis Internet le jour des mises à jour. Absorbé en fibre. À ne pas appliquer aux sites derrière un lien étroit.
Observé
09/2026 — 87 % du trafic inter-VLAN d'un site, dont 45 % généré par un seul poste.
Agent installé sur le parc, console hébergée chez l'éditeur.
Flux initiés
Tcp_443 vers les plateformes de l'éditeur.
Pièges
Certains agents déclenchent des alarmes SSL — « longueur invalide » — sur le format de leurs échanges. En IDS l'alarme est bénigne ; en IPS elle coupe la console de gestion, et le symptôme est un poste qui ne remonte plus. On cherche du côté de l'agent, pas du firewall.
Observé
09/2026 — alarme SSL majeure en Allow sur l'agent d'un antivirus d'entreprise.
Agent Datto RMM prise en main
Supervision et prise en main de tout le parc.
Flux initiés
Tcp_443 vers la plateforme (agent et interface) · pour Web Remote : Tcp/Udp_3478 et Tcp/Udp_49152-65535, vers tunnel.rmm.datto.com et webrtc.rmm.datto.com
Flux entrants
Udp_13300 entre agents d'un même réseau, pour la découverte ; rien depuis Internet.
Groupe de ports
Groupe_RMM
Destination
Les adresses de la plateforme Datto — liste propre à chaque plateforme, page « Allowlist » — plutôt qu'Internet, au moins pour la plage de tunnel.
Pièges
La plage 49152-65535 vers Internet, depuis chaque machine supervisée, ouvre toute la plage haute : à ne retenir que si Web Remote sert.
Du STUN sortant depuis un serveur est normal ici — identifier le processus quand même.
Le 4277-4278 relevé sur le terrain ne figure pas dans la documentation Datto.
Décision type
Web Remote est-il utilisé, ou seulement l'agent ? Sans prise en main, le 443 suffit.
