Alerte entrante sur un serveur VPN : lisez le point d'observation

Un serveur derrière un VPN conserve ses entrées de service publiques, et les gens continuent de les trouver. Ce qui arrive dans la file d'alertes n'est pas une découverte mais trois possibles, et elles signifient des choses différentes. Le premier travail consiste à séparer un service exposé d'un identifiant exposé.

Parcourez les points d'observation dans l'ordre. Arrêtez-vous lorsque les preuves changent de catégorie, car l'étape suivante répond à une autre question.

Première étape : ce que la capture a réellement vu

Une capture de paquets enregistre ce qui était visible à son propre point sur le chemin. Ce point peut se trouver avant une décision de filtrage ultérieure. Un paquet capturé prouve que le trafic y est arrivé. Il ne prouve rien sur ce qui s'est passé ensuite.

Notez aussi l'interface. Une capture sur l'adaptateur public et une capture à l'intérieur du tunnel décrivent des points d'arrivée différents, et une alerte qui cite le mauvais mène à la mauvaise conclusion.

Windows filtre aussi à plusieurs couches de la pile, si bien que le modèle bien rangé où l'outil de capture siège à la couche deux et le pare-feu à la couche trois ne survit pas au contact d'un produit réel. La présentation de Windows Filtering Platform décrit le filtrage à travers les couches de la pile, et c'est pourquoi l'ordre d'observation doit être établi plutôt que supposé.

Deuxième étape : ce que l'enregistrement de rejet établit

Un enregistrement de rejet dit qu'une frontière de stratégie a rejeté ce paquet. C'est une preuve solide. C'est aussi une preuve étroite, car elle couvre une décision à une frontière. Rien d'autre dans la pile n'est décrit par elle.

Corrélez sur le tuple et l'horodatage. Même source, même destination, même port, dans la même seconde. Sans cette correspondance, un événement d'apparence similaire dans un autre journal n'est qu'un autre événement, et les apparier produit une histoire que personne ne peut défendre.

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

Un port fermé et un paquet rejeté semblent identiques de l'extérieur et complètement différents dans ces deux sorties. Cette différence est toute la raison de lire l'enregistrement local.

Troisième étape : ce que l'événement d'authentification prouve

Un événement d'authentification dit qu'un composant a traité la demande assez loin pour enregistrer un résultat. C'est la seule des trois étapes qui parle d'identité, et elle ne dit rien du nombre de paquets arrivés avant.

Lisez le contexte réel de l'événement. Un échec de connexion pour un compte qui n'existe pas est du bruit de balayage. Un échec de connexion pour un compte réel depuis une source plausible est une autre priorité. Une session réussie est une catégorie d'incident entièrement différente.

Surveillez aussi les noms de protocoles. RPC et RDP sont des services distincts avec des ports distincts. Un détecteur qui surveille l'un ne couvre pas l'autre. Les outils qui résument l'activité réseau n'indiquent pas toujours lequel des deux a produit l'événement.

Un échantillon corrélé vaut mieux qu'un tableau de bord

Choisissez un test autorisé, exécutez-le exprès et suivez-le de bout en bout : adresse de destination et interface, adresse source réelle, port du service, profil et règle de pare-feu effectifs, et le résultat de service correspondant. Incluez dans cette chaîne toute correspondance en amont ou pare-feu cloud, car une règle permissive y est peut-être prioritaire sur une règle locale bien rangée.

Séparez ensuite les deux obligations. Si l'administration doit passer uniquement par le VPN, imposez-le à la fois sur le chemin public et sur celui du tunnel tout en conservant une voie de récupération approuvée. Surveiller une tentative rejetée n'est pas la même tâche que décider ce que le serveur doit accepter.

Une règle géographique ou un protocole sans rapport bloqué ne remplacent pas la recherche de l'entrée observée et de la décision qu'elle a reçue. Un VPN non plus : acheminer le trafic sortant par un tunnel ne documente rien sur l'autorisation entrante.