Règles d’entrée SSH et VPN : ce que la liste d’autorisation contrôle vraiment

Suivez une connexion du client à l’hôte : quel hook elle traverse, pourquoi un blocage et un refus signifient des règles différentes et pourquoi rejeter n’est jamais une politique.

Connectez-vous une fois avant de modifier une règle et notez si le client se bloque ou s’il est refusé immédiatement. Cette seule différence vous dit quelle décision a écarté le paquet et vous épargne une heure de lecture de fichiers de politique. Le reste du parcours est court : le paquet traverse un hook, correspond à une règle et atteint un écouteur ou non. Une liste d’autorisation n’est que de la comptabilité autour de ces trois faits.

Suivez une tentative SSH jusqu’au hook d’entrée

Un client envoie un SYN à l’adresse de l’hôte sur le port 22, et le noyau décide si ce paquet est destiné à un service local. Si oui, le chemin d’entrée s’exécute et le jeu de règles accepte le paquet ou le rejette. Le silence signifie que le SYN est mort avant que l’écouteur ne le voie, tandis qu’un refus rapide signifie que quelque chose a répondu par une réinitialisation. Ce sont des verdicts différents de règles différentes, et les deux sont des issues légitimes.

Confirmez ensuite l’écouteur, car aucune règle ne sauve un service absent. Lancez ss -ltnp et vérifiez que quelque chose est lié au port et à la famille d’adresses que vous attendez, puis lisez ssh -v côté client pour voir où il s’arrête.

Le transfert est une décision à part

Sur un serveur VPN, le hook le plus intéressant est forward, car le trafic du client est routé à travers la machine au lieu de lui être livré. Un hôte qui n’exécute que son propre client VPN a besoin d’un jeu de règles bien plus petit que celui qui relaie les paquets d’autres personnes. Mélanger les deux conceptions sur une seule machine produit des règles qui semblent correctes et ne laissent rien passer.

Écrivez la politique interne comme une question à part : quelles adresses client peuvent atteindre quelles destinations à travers le tunnel. Gardez le chemin administratif, comme SSH, sur le chemin d’entrée avec sa propre restriction de source. Une règle forward permissive ajoutée pendant un test est le défaut classique qui survit au test, alors relisez tout le jeu de règles après un changement et non la ligne que vous avez modifiée. Ouvrir l’écouteur du tunnel n’est pas une autorisation pour chaque client connecté d’administrer l’hôte.

Rejeter et refuser sont des actions, pas des politiques

La politique d’une chaîne de base accepte ou rejette, et c’est toute la liste des choix, comme l’indique la référence nftables. Le refus existe comme action de règle avec une réponse choisie, et c’est pourquoi l’écrire comme politique échoue à la fois sur nftables et sur iptables. En pratique, un drop ne donne au client aucune information, tandis qu’un reject lui donne une erreur sur laquelle il peut agir.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Lisez ce croquis comme la forme d’une décision et non comme un fichier à coller, car les plages d’adresses sont des exemples. Un reject explicite sur le port SSH fait échouer un client non autorisé en une seconde au lieu d’attendre un délai d’expiration, ce qui raccourcit votre propre débogage. Le silence dissuade l’analyse occasionnelle et ne dit absolument rien à un utilisateur autorisé. Choisissez par service et notez pourquoi, sinon la personne suivante le remettra en place.

Conservez le trafic de contrôle dont vous avez vraiment besoin

Bloquer tout l’ICMP est un réglage par défaut populaire qui casse la découverte du MTU du chemin, et le symptôme est une connexion qui s’établit puis se bloque sur les paquets plus gros. La découverte de voisins en IPv6 dépend de ses propres types ICMPv6, et les supprimer casse le lien avant qu’une quelconque règle TCP ne soit consultée. Les deux relèvent de la liste d’autorisation comme dépendances nommées et non comme autorisations générales. Une politique qui casse silencieusement la découverte est pire qu’une qui admet un peu de trafic de diagnostic.

Autorisez les états established et related pour les connexions que vous avez initiées, et laissez le moteur à états gérer les réponses. Confirmez ensuite que le chemin de réponse n’est pas bloqué plus loin, car une restriction uniquement sortante en amont produit le même délai d’expiration que vous alliez imputer à l’hôte.

Prouvez la reprise avant de retirer l’ancien chemin

Gardez une session console ouverte, appliquez le changement et ouvrez une connexion d’administration entièrement nouvelle depuis un autre terminal. Une session existante ne prouve rien, car elle peut survivre à une règle qui bloque chaque nouvelle connexion, ce qui en fait le faux positif le plus convaincant du travail sur pare-feu. Si un système de supervision vérifie l’hôte, ajoutez son adresse source avant le changement et non après la première alerte. Testez ensuite un gros paquet et un petit pour prouver que la découverte fonctionne toujours.

Pour un service VPN, répétez depuis un client qui ne s’est jamais connecté, car une session reprise peut réutiliser un état qu’une session neuve doit négocier. Notez le jeu de règles exact qui a passé, avec une somme de contrôle ou une copie, afin qu’une modification ultérieure soit comparée plutôt que devinée. Coordonnez-vous avec le propriétaire de l’ordre des règles, car une règle antérieure gagne silencieusement sur celle que vous avez ajoutée.

Articles similaires