Un utilisateur MikroTik VPN va trop loin : limitez à un hôte et un port

Le tunnel monte, la connexion réussit et tous les hôtes du réseau répondent. Ce n'est pas un VPN cassé ; c'est un VPN sans modèle d'autorisation. RouterOS authentifie le compte puis achemine ses paquets comme ceux de tout le monde, donc le pare-feu doit fournir la limite. Ajouter cette limite sans casser la connexion, c'est tout le travail.

L'authentification s'arrête là où commence l'autorisation

Une fois la session PPP établie, les paquets du client entrent dans la chaîne forward comme le trafic de n'importe quelle autre interface. Si la politique forward du routeur est permissive, le consultant hérite de cette permissivité à la connexion. Le compte n'a jamais porté de périmètre, il n'y a donc rien à changer sur le compte. Le jeu de règles a été écrit pour les employés et la nouvelle session l'a simplement rejoint.

Vérifiez à quel chemin se rapporte la demande avant d'écrire quoi que ce soit. Le trafic vers les hôtes derrière le routeur traverse forward, tandis que le trafic vers le routeur lui-même, y compris winbox et SSH, traverse input. Un périmètre qui ne couvre que forward laisse l'appareil ouvert au même client.

Les deux chaînes ont besoin d'une décision, même si la décision est de laisser input fermé. Ce choix appartient à la demande d'accès, pas à une réflexion après coup.

Rattachez la session à une liste nommée

Un profil PPP peut placer l'adresse qu'il remet dans une liste d'adresses nommée au démarrage de la session. Cela transforme une adresse de tunnel transitoire en quelque chose que le pare-feu peut faire correspondre par nom, et l'entrée disparaît à la fin de la session. Le compte hérite alors du périmètre de son profil plutôt que d'une règle qui code l'adresse en dur.

Créez d'abord le profil, puis liez-y le secret explicitement. Un secret qui pointe encore vers le profil par défaut reproduit le problème d'origine.

Nommez le profil et la liste pour que leurs rôles soient évidents, et commentez les deux avec la référence de la demande. Un profil peut servir plusieurs personnes avec le même périmètre, tandis que la liste identifie encore chaque session active. C'est moins coûteux à relire qu'une règle par personne.

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

Consignez le service autorisé dans une liste

Placez le serveur autorisé dans sa propre liste d'adresses au lieu d'intégrer l'adresse dans une règle de filtrage. La liste peut être auditée, étendue et commentée, et la règle qui la consomme ne change pas quand le serveur déménage. Une entrée unique semble excessive jusqu'à l'arrivée du second hôte, ce qui arrive généralement.

Faites correspondre une liste quand l'adresse est dynamique ou répartie, et faites correspondre l'adresse directement quand elle est réservée et stable. Les deux choix se lisent clairement si le commentaire nomme le service et le propriétaire.

Limitez le protocole et le port autant que l'hôte. Un accept pour un hôte sans restriction de port ouvre tous les services que cet hôte exécute, ce qui est plus large que ce que visent la plupart des demandes d'accès. Le port fait partie de l'autorisation, pas un détail à ajouter plus tard.

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

Placez le saut avant tout accept large

Une règle de saut envoie le trafic transféré depuis la liste restreinte dans une chaîne privée où toute la politique tient en trois lignes. La première règle accepte la destination et le port autorisés, et la dernière rejette tout le reste. Le saut doit se situer au-dessus de tout accept large dans forward, car un accept antérieur signifie que le saut ne s'exécute jamais. Gardez l'accept established et related avant le saut pour que le trafic de retour continue de circuler.

Vérifiez qu'aucune règle fasttrack ne peut faire passer ce trafic au-delà de la chaîne restreinte. Fasttrack contourne le reste du chemin de filtrage, et une session restreinte qui passe par fasttrack n'est pas restreinte du tout.

Répétez la décision pour la chaîne input si les services du routeur lui-même doivent être inaccessibles. Un périmètre qui bloque le trafic transféré et laisse winbox ouvert n'est qu'à moitié terminé.

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

Vérifiez avec les compteurs et l'appartenance à la liste

Depuis le client, testez le service autorisé et un autre qui doit échouer, puis lisez les statistiques de règles sur le routeur. Les compteurs accept et drop montrent quel chemin chaque paquet a pris, ce que le client ne peut pas voir. Confirmez aussi que l'adresse de la session active est apparue dans la liste restreinte.

Une liste vide signifie que le compte est sur un autre profil ou que le profil a perdu son réglage de liste d'adresses. Un compteur drop qui grimpe avec un service autorisé en échec signifie que la destination ou le port ne correspond pas à ce que le client envoie.

Testez le même service par nom et par adresse avant de conclure quoi que ce soit. Un échec de résolution de nom ressemble exactement à un port bloqué côté client. Consignez ensuite le profil, les deux listes et l'unique service autorisé dans la demande d'accès, afin que la prochaine revue compare au lieu de reconstruire.

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients