Côté serveur — ce qui écoute

Les ports de service, à mettre en destination d'une règle « postes vers serveur ». Lancer PowerShell en administrateur, sinon les processus SYSTEM remontent sans nom.

Get-NetTCPConnection -State Listen |
  Where-Object LocalAddress -notmatch '^(127\.|::1)' |
  Select-Object LocalPort,
    @{n='Proc';e={(Get-Process -Id $_.OwningProcess -EA SilentlyContinue).ProcessName}} |
  Sort-Object LocalPort -Unique

Même chose en UDP :

Get-NetUDPEndpoint |
  Where-Object LocalAddress -notmatch '^(127\.|::1)' |
  Select-Object LocalPort,
    @{n='Proc';e={(Get-Process -Id $_.OwningProcess -EA SilentlyContinue).ProcessName}} |
  Sort-Object LocalPort -Unique

Côté serveur — ce qui est réellement utilisé

Get-NetTCPConnection -State Established |
  Where-Object { $_.RemoteAddress -notmatch '^(127\.|::)' } |
  Select-Object LocalPort, RemoteAddress, RemotePort,
    @{n='Proc';e={(Get-Process -Id $_.OwningProcess -EA SilentlyContinue).ProcessName}} |
  Sort-Object LocalPort | Format-Table -AutoSize

Pour un flux nocturne, une tâche planifiée qui échantillonne suffit :

1..120 | ForEach-Object {
  Get-NetTCPConnection -RemotePort <port> -EA SilentlyContinue |
    Select-Object @{n='t';e={Get-Date -f 'HH:mm:ss'}}, State, RemoteAddress,
      @{n='Proc';e={(Get-Process -Id $_.OwningProcess -EA SilentlyContinue).ProcessName}} |
    Export-Csv C:\temp\capture.csv -Append -NoTypeInformation
  Start-Sleep 5
}

Tester le flux une fois la règle posée

Depuis la machine source, vers le serveur et le port de la règle :

Test-NetConnection -ComputerName <serveur> -Port <port>

TcpTestSucceeded : True : la session TCP s'établit. False alors que le service écoute : chercher dans les logs du firewall la règle qui a répondu, puis une éventuelle alarme. Il n'existe pas d'équivalent fiable en UDP : seul le log du firewall tranche.

Source : Microsoft — Test-NetConnection

Côté firewall — lire les logs

Avant d'exporter, ajouter les colonnes destination et port destination en numérique. Sans elles, on ne sait pas quel hôte est visé, et le nom d'objet du port raconte n'importe quoi (§ 05).

Puis regrouper par port destination, jamais dérouler chronologiquement : un seul équipement bavard noie tout le reste. Un numéro inconnu se vérifie dans l'index des ports : nom officiel, groupes du socle qui le contiennent, faux amis.

Retirer une règle Any

1. Journaliser d'abord, plusieurs semaines. Ce qui apparaît dans ses logs est exactement la liste de ce que les règles spécifiques ne couvrent pas.
2. Créer les règles nommées correspondantes.
3. Passer la règle en off, pas la supprimer, et filtrer les logs du block all pendant 48 h.
4. Supprimer une fois la fenêtre passée sans incident.

Une journée d'observation ne couvre ni l'hebdomadaire ni le mensuel. Viser au minimum une semaine, idéalement une clôture de mois.

L'analyse des logs regroupe ce trafic par port destination et donne les groupes du socle qui le couvrent ; l'analyse d'un export vérifie ensuite la politique obtenue.

Basculer une règle en IPS

1. Vérifier que le niveau de journalisation a survécu au changement de profil.
2. Surveiller Monitoring → Alarmes dans les heures qui suivent.
3. Une alarme bloquante → profil dupliqué, alarme en « passer », appliquée à cette règle seule.
4. Ne pas basculer plusieurs règles à la fois : on ne saurait pas laquelle a cassé.