Ajouter une règle d'autorisation RDP ne réduit pas votre accès VPN

Le plan semble raisonnable : laissez l'autorisation existante pour le Bureau à distance telle quelle et ajoutez-en une petite pour l'unique client VPN qui devrait avoir accès. Le pare-feu Windows ne fonctionne pas ainsi. Les règles ne forment pas une liste ordonnée où l'entrée la plus précise l'emporte, et une autorisation étroite à côté d'une large ne change rien, car la large admet encore tous ceux qu'elle admettait déjà. Restreindre le service signifie modifier l'autorisation qui fait déjà le travail.

La règle que vous ajoutez n'est pas la règle qui compte

Le pare-feu Windows évalue toutes les règles d'entrée applicables dans les magasins de stratégies qui s'appliquent à la machine, puis décide si une autorisation correspond et si un blocage la supplante. Ajouter une règle ajoute une autorisation ; elle ne retire ni ne nuance les autorisations déjà présentes.

La question n'est donc jamais ce que vous avez ajouté. C'est ce que contient la stratégie effective après la fusion de la stratégie locale, de la stratégie de domaine et des valeurs par défaut du profil. Un poste de travail avec une seule règle locale est facile à raisonner ; un serveur joint à un domaine ne l'est pas.

C'est aussi pourquoi un administrateur peut faire une modification qui semble correcte, la tester depuis la mauvaise machine et conclure qu'elle a fonctionné. La source exclue n'a jamais été testée. Un test qui ne prouve que le succès prouve moins de la moitié de ce pour quoi la modification était faite.

Découvrez quelle adresse le serveur voit

Avant de délimiter quoi que ce soit, observez une session autorisée sur l'hôte Windows et notez l'adresse source que le serveur signale. Ce n'est pas toujours l'adresse que le client croit avoir.

Si la passerelle VPN conserve les adresses des clients, le serveur voit l'adresse de tunnel du client, et une règle limitée par adresse a un sens. Si la passerelle traduit, chaque client arrive avec l'adresse de la passerelle, et limiter à cette adresse donne accès à tous les clients derrière elle. La règle est alors précise sur la mauvaise chose.

Ces deux conceptions demandent des réponses différentes. La première peut s'exprimer dans une règle de pare-feu ; la seconde doit être appliquée là où l'identité existe encore, c'est-à-dire dans le VPN lui-même ou dans une passerelle authentifiée devant le service.

Un filtre de pare-feu ne peut pas récupérer une identité que la traduction réseau a écartée, aussi soigneusement l'adresse soit-elle saisie.

Changez le propriétaire de la règle effective

Inspectez la stratégie d'entrée effective et trouvez chaque règle qui admet actuellement le trafic RDP, y compris les règles dont le nom d'affichage ne mentionne jamais le port 3389. Les règles limitées par service et par application comptent aussi, tout comme le transport UDP que certains déploiements RDP activent.

Modifiez ensuite les règles existantes via le magasin qui les possède. Une modification locale d'une règle que la stratégie de domaine définit aussi peut être fusionnée, ignorée ou écrasée, et il vaut la peine de savoir laquelle de ces situations se produit avant de s'y fier.

Ces commandes trouvent les règles actives, affichent le filtre d'adresses associé à l'une d'elles et prévisualisent un changement de portée :

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

Les noms de règles ici sont des espaces réservés pour ce que la revue a trouvé, et l'indicateur d'aperçu existe pour qu'une faute de frappe dans une adresse ne vous enferme pas hors du serveur que vous modifiez.

Bloquer puis autoriser est un modèle différent

L'habitude d'autres pare-feu est d'écrire un blocage large puis une autorisation étroite au-dessus. Sous Windows, un blocage explicite l'emporte généralement sur une autorisation, si bien que cet ordre produit un service que personne ne peut atteindre plutôt qu'une exception pour un client. Le résultat est une panne qui ressemble à un service RDP cassé. C'est en réalité une erreur de priorité, et le correctif consiste à retirer le blocage plutôt qu'à ajouter une autre autorisation.

Conservez le comportement de blocage d'entrée par défaut sur les profils actifs et restreignez plutôt les autorisations précises. Cela laisse la machine avec une posture compréhensible au lieu de deux règles contradictoires dont l'interaction dépend de détails de priorité.

Prouvez-le avec une seconde source

Testez depuis le client autorisé et depuis une source qui devrait maintenant échouer. Une seule connexion réussie prouve uniquement que le chemin autorisé fonctionne ; elle ne dit rien de l'exclusion que vous venez de faire.

Répétez le test en IPv6 si le serveur l'a activé, car une intention limitée à IPv4 peut coexister avec une autorisation IPv6 large que personne n'a regardée.

Enfin, gardez l'authentification séparée de l'accessibilité. L'authentification au niveau du réseau, les droits du compte et les restrictions de connexion décident encore qui peut utiliser la session, et le pare-feu décide seulement qui peut demander. Retirer un appareil plus tard devrait retirer à la fois son enrôlement VPN et cette autorisation réseau, sinon l'adresse que vous avez délimitée appartiendra un jour à quelqu'un d'autre.