Bloquer une sortie VPN bloque une adresse, pas une personne

Quelqu’un ajoute l’adresse de sortie d’un fournisseur VPN à une liste de refus, et l’abus cesse pendant un jour. Puis un client qui utilise justement le même fournisseur ouvre un ticket, et la règle se révèle plus large que ce que quiconque avait décrit. Le blocage a toujours été une décision sur une adresse ; le problème, c’est qu’on l’a vendu comme une décision sur une identité. Séparez les deux avant d’écrire la règle suivante.

La règle que vous pouvez appliquer porte sur une adresse source

Une règle de pare-feu correspond à un champ du paquet, et le champ auquel vous correspondez est l’adresse source. Cette règle peut refuser de manière fiable le trafic venant de cette adresse, ce qui est un effet réel et utile. Elle ne peut pas vous dire qui a envoyé le paquet, quel compte a été utilisé ni s’il s’agit de la même personne qui a causé le problème d’hier. Écrire la règle est facile ; décrire ce qu’elle prouve est là où les équipes se trompent.

Si l’objectif est d’arrêter un comportement précis, une règle d’adresse est un instrument grossier qui se trouve être disponible. Si l’objectif est d’identifier un utilisateur, l’adresse est la mauvaise preuve et l’authentification de l’application est la bonne. Décidez de votre objectif avant que la règle ne passe en production.

Ce qu’une recherche dans le registre vous dit réellement

Une recherche dans le registre renvoie l’allocation et les contacts enregistrés pour un réseau. Elle n’énumère pas les services exécutés sur chaque adresse et ne vous dit pas quel locataire a envoyé une requête. Même un petit bloc enregistré peut contenir des charges de travail sans rapport appartenant à des clients différents.

dig +short exit.example.net
whois 203.0.113.0 | head -40

Résoudre un nom d’hôte de sortie vous donne les adresses renvoyées à cet instant, ce qui est un instantané et non un inventaire. Étendre une réponse à tout le préfixe d’hébergement est une décision distincte à plus large rayon d’action, pas une version plus complète de la même preuve. Si vous utilisez un flux de classification maintenu, son étiquette est une supposition avec des erreurs connues dans les deux sens. Ce n’est pas de l’authentification, et ce n’est pas une liste de personnes.

Arrêtez-vous si la règle proposée n’est justifiée que par une recherche. Un instantané n’est pas une décision de portée.

Sorties partagées et dommages collatéraux

Une sortie partagée transporte de nombreux utilisateurs, et espace d’adressage partagé signifie qu’une adresse publique peut représenter tout un groupe d’abonnés. La bloquer les affecte tous, y compris ceux qui n’ont aucun lien avec l’abus. L’élargissement au préfixe environnant multiplie cet effet et augmente le risque qu’un service sans rapport soit pris au piège. Le dommage collatéral n’est pas un effet secondaire à noter plus tard ; il fait partie de la définition de la règle.

Les preuves issues des paquets ont leurs propres limites. Une adresse source dans un SYN isolé peut être falsifiée, donc le paquet n’établit pas qui a lancé quoi que ce soit. Un état de connexion à demi ouvert montre qu’une poignée de main a commencé, pas que la partie distante est coupable d’une attaque par réflexion. Une connexion terminée dit autre chose qu’un journal d’application, et une session authentifiée nomme un compte qu’aucun des deux ne nomme.

Choisissez la portée la plus étroite que la politique autorise, et notez qui risque d’être touché par erreur.

Les preuves à consigner, et un chemin de retour pour les utilisateurs

Chaque règle d’adresse devrait porter l’observation qui l’a justifiée, la date, la portée et un point de revue. C’est cet enregistrement qui permet à la personne suivante de réduire la règle au lieu de deviner pourquoi elle existe. Sans lui, un blocage temporaire devient une infrastructure permanente.

nft list ruleset | grep -n 203.0.113
ss -tn state syn-recv '( dport = :443 )'

Décidez comment un utilisateur légitime récupère l’accès avant de déployer le blocage, car une file d’attente de support n’est pas un plan de rétablissement. Un chemin de recours, une exception documentée ou une autre méthode d’accès fonctionnent ; dire aux gens d’arrêter d’utiliser leur VPN ne fonctionne pas. Associez la règle réseau à des contrôles adaptés au comportement : limites de débit, permissions de compte plus strictes ou application au sein du service lui-même. Un blocage de sortie VPN peut réduire le trafic indésirable sans prétendre être un annuaire d’utilisateurs.

Le symptôme à garder en vue est l’écart entre ce que fait la règle et ce que les gens croient qu’elle fait. Un blocage refuse une adresse. Un compte identifie un utilisateur. Gardez ces phrases séparées dans le ticket, et la règle suivante sera plus facile à défendre.