Les alertes de connexion VPN ne sont pas des alertes d'intrusion : surveillez la session
Une connexion inhabituelle est un motif de révision, pas un verdict. Reliez l'enregistrement d'authentification à une session, puis à ce qu'elle a touché, avant de parler d'intrusion.
Une alerte VPN qui se déclenche pour un nouveau pays semble concluante, et elle ne l'est généralement pas. L'authentification dit qu'une tentative a été acceptée ; la session dit quelle connexion l'a portée ; les enregistrements de ressources disent ce qui s'est passé dans cette connexion. Chacun répond à une question différente. Une règle qui fusionne les trois produit trente tickets le lundi et manque le vrai cas le vendredi.
Une adresse étrangère est une question, pas une réponse
Les voyages, les opérateurs mobiles qui sortent dans un autre pays, un proxy web d'entreprise et un pool NAT d'opérateur réaffecté déplacent tous la source apparente sans déplacer l'attaquant. L'enregistrement de connexion reflète par où la connexion est entrée sur le réseau, pas qui tenait l'appareil.
L'échec inverse est pire parce qu'il est silencieux. Un mot de passe volé utilisé depuis la ville de l'utilisateur lui-même produit une connexion qui correspond à toutes les précédentes lors du contrôle géographique.
Traiter la géographie comme le verdict a un coût mesurable. Les portables qui voyagent génèrent un flux régulier de révisions, les relecteurs apprennent à les fermer sans les lire, et l'habitude survit jusqu'à ce qu'un vrai cas arrive dans la même file.
Trois types d'enregistrement répondent à trois questions différentes
Partez de ce que les produits déployés émettent réellement, pas de ce qu'une brochure suggère qu'ils pourraient émettre. La décision d'authentification nomme l'identité affirmée, la méthode et le résultat. Le cycle de vie de la session nomme la connexion, la passerelle et l'adresse attribuée, du début à l'arrêt.
| Record | Question it answers | What it cannot prove |
|---|---|---|
| Authentication decision | Which identity was accepted or rejected, by which method, at what time | That the person operating the device was the account owner |
| Session lifecycle | Which connection, gateway and assigned address were active, and for how long | What the session did with that access |
| Resource event | Which read, write or denied operation a service observed | Which human behind the session triggered it |
| Policy change | Whether an administrator altered the rule that governs the access | Whether the change was reviewed or intended |
Une cellule vide est un trou de collecte, pas un acquittement. Si les événements de ressources n'arrivent jamais, l'absence d'une lecture suspecte signifie que le pipeline n'a rien à signaler, et un tableau de bord silencieux décrit le pipeline plutôt que le réseau. Notez quels enregistrements le déploiement produit réellement avant de promettre une règle qui en dépend, et nommez le responsable de chaque flux manquant.
Le détail comptable est l'endroit où les sessions deviennent vérifiables. La comptabilité RADIUS décrite dans RFC 2866 transporte des mises à jour de début, d'arrêt et intermédiaires liées à un identifiant de session, si bien qu'une session avec un début et sans arrêt est un trou que vous pouvez nommer au lieu d'un mystère.
Joignez sur la session, pas sur le nom d'utilisateur
Un compte détient légitimement plusieurs sessions à la fois : un portable, un téléphone, une machine de laboratoire laissée connectée toute la nuit. Relier chaque événement de ce nom d'utilisateur fusionne trois appareils en une seule histoire, puis lit la combinaison comme une compromission. Les adresses attribuées sont aussi recyclées, donc une jointure qui continue de correspondre à une adresse après la fin de la session traîne l'appareil du mois dernier dans l'incident du jour. Conservez la clé de session à côté de l'adresse et bornez la correspondance à la fenêtre temporelle réellement couverte par la session.
Là où la traduction retire la source d'origine avant qu'un service la voie, utilisez l'identité qui survit à cette frontière, comme un sujet TLS mutuel ou une assertion d'authentification unique. Inventer une correspondance univoque entre une adresse et une personne est la même erreur avec des étapes en plus.
Une alerte sans responsable est un tableau de bord
Chaque règle a besoin d'une condition, des explications bénignes qui la produisent, des preuves à rassembler et de la personne qui agit. Une opération administrative refusée à répétition, une rafale de mots de passe échoués et un collecteur silencieux sont trois incidents différents avec trois horloges différentes.
La notification n'est pas le confinement, et une liste de diffusion ne restreint rien. Modifier une session active exige le composant qui peut le faire, que ce soit la passerelle qui coupe la connexion ou le fournisseur d'identité qui révoque la session. Les flux obsolètes et les enregistrements d'arrêt manquants appartiennent aussi au texte de la règle, car un collecteur qui n'a rien envoyé depuis un jour ressemble exactement à un réseau silencieux depuis le tableau de bord. La différence n'est visible que dans le pipeline lui-même.
Vérifiez le chemin de collecte avant de vous fier à une semaine calme
Prouvez le pipeline de bout en bout avant d'ajuster une seule règle. Les commandes ci-dessous confirment que les écouteurs d'authentification et de comptabilité sont actifs, qu'un identifiant de test est refusé pour la bonne raison et que les événements de session arrivent encore :
ss -uanp | grep -E ':(1812|1813)\b' radtest alice 'not-the-password' 127.0.0.1 0 testing123 journalctl -u openvpn-server@server --since '-30 min' | grep -c 'Peer Connection Initiated' timedatectl | grep -E 'System clock|synchronized'
Un Access-Reject issu du test prouve que la requête a atteint le serveur et que le secret partagé correspondait, et c'est la partie que les gens sautent. Un délai d'attente pointe plutôt vers le secret, l'écouteur ou un filtre devant lui, et chaque alerte en aval est invérifiable jusqu'à ce que ce soit corrigé.
L'état de l'horloge compte parce que les fenêtres de corrélation supposent un accord. Une passerelle décalée de quelques minutes rend une jointure de session par ailleurs propre impossible, et les relecteurs compensent en élargissant la fenêtre jusqu'à ce que la jointure cesse de discriminer. Vérifiez le décalage avant de modifier la règle.
Ensuite, éprouvez une règle lors d'un test inoffensif : générez une connexion depuis une adresse inattendue, vérifiez que l'alerte se déclenche, vérifiez que le répondant peut extraire la session et ses événements de ressources, et vérifiez que le ticket porte l'identifiant de session. Une règle qui produit une histoire cohérente passe. Une règle qui produit une pile de lignes de journal reste un tableau de bord. Consignez le résultat en regard de la règle pour que la prochaine révision parte de preuves et non d'intuition.