Port Knocking - Documentation Technique 1. Introduction Le port knocking est une technique de sécurisation des serveurs SSH née vers 2005-2006. Elle permet de masquer un service derrière un firewall en le rendant invisible aux yeux du monde extérieur, tout en offrant un mécanisme d'accès contrôlé basé sur une séquence d'actions réseau.
Contexte : En France, 680 000 serveurs SSH sont exposés publiquement, les exposant à des vulnérabilités, des scans de ports et du spam de logs.
- Fondamentaux Techniques 2.1 Protocole TCP Le protocole TCP repose sur quatre informations pour établir une communication :
L'adresse IP source
L'adresse IP destination
Le port source
Le port destination
À partir de ces quatre paramètres, un tunnel de communication est créé permettant le transit de multiples protocoles (HTTP, SFTP, SSH, etc.).
Poignée de main TCP : L'établissement d'une connexion TCP suit trois étapes (SYN, SYN-ACK, ACK). À l'issue de cette poignée de main, le canal est ouvert.
2.2 Firewall et Actions sur les Paquets Un firewall côté serveur filtre tous les paquets qui transitent sur le réseau selon des règles spécifiques. Trois actions sont possibles :
Accept Le firewall autorise le paquet à passer
Le serveur reçoit le paquet et répond
L'établissement de la connexion TCP se complète
Résultat : L'application est exposée, accessible et vulnérable
Reject Le firewall refuse le paquet
Il renvoie un paquet de type RST au client
Le client sait que le serveur est actif mais refuse la connexion
Résultat : Le client reçoit une confirmation que le port est fermé
Drop Le firewall supprime le paquet (mise à la poubelle)
Aucun retour n'est envoyé au client
Le client n'a aucune certitude : le paquet est-il perdu ? Le serveur est-il actif ?
Résultat : Aucun retour, aucune confirmation d'existence du service
2.3 Fondement du Port Knocking Le port knocking repose sur la subtilité entre drop et reject : faire croire qu'aucune application n'écoute sur un port donné, alors que le service existe réellement mais est temporairement masqué.
- Principe du Port Knocking 3.1 Concept Général Le port knocking consiste à envoyer discrètement une séquence précise de paquets vers des ports fermés pour déclencher l'ouverture temporaire d'un service autrement invisible (exemple : serveur SSH sur le port 22).
Analogie : Annoncer sa présence en frappant une porte avec une séquence rythmique particulière, mais avec le protocole TCP en frappant sur des ports bien définis dans un certain ordre.
3.2 Scénario de Fonctionnement État initial : Le firewall bloque le port 22 en droppant tous les paquets
Frappement : Le client envoie une séquence de paquets vers des ports spécifiques (exemple : 3000, 4000, 5000)
Reconnaissance : Si la séquence est correcte, le firewall révèle le port 22 en acceptant les connexions
Accès limité : L'ouverture est temporaire et limitée à une adresse IP spécifique
Fermeture : Après un délai défini (timeout), la règle est supprimée
3.3 Avantages Minimise l'exposition du serveur SSH
Réduit les attaques par scan de ports et spam de logs
Ouverture temporaire et limitée à une adresse IP
Les connexions établies persistent même après fermeture du port (grâce au keyword established)
- Implémentation Technique 4.1 Environnement Configuration testée :
VM sur Debian 12
Firewall : iptables
4.2 Configuration Serveur Éléments clés nécessaires :
Interface réseau : Doit écouter tous les paquets (acceptés, rejetés ou droppés)
Séquence : Les ports à frapper dans l'ordre
Timeout : Durée durant laquelle la séquence doit être complétée
Commande d'exécution : Ajoute une règle iptables pour accepter les connexions SSH
Commande de fermeture : Retire la règle après le timeout (par défaut 30 secondes)
Règle iptables générée :
Accepte les connexions TCP sur le port 22 pour une IP client donnée après validation de la séquence
S'exécute pendant un délai défini avant d'être supprimée
Configuration du firewall de base :
Policy : INPUT DROP
Les paquets entrants sont droppés par défaut, sauf si une règle écrite autorise explicitement
Exception : Les connexions établies (keyword established) restent toujours autorisées
4.3 Configuration Client Installation similaire au serveur, mais :
Le démon n'est pas lancé
Utilisation de la CLI uniquement
Fourniture de l'adresse IP et de la séquence des ports
- Démonstration Fonctionnelle 5.1 État Initial Port 22 : Filtré (iptables avec policy drop)
Nmap : Aucune réponse (ni acceptation, ni refus)
SSH : Timeout (accès coupé)
5.2 Après Frappement de la Séquence Les trois étapes de la séquence sont exécutées (un port par étape)
Logs du serveur : Reconnaissance et exécution de la commande
Configuration firewall : Nouvelle règle acceptant le port 22 pour l'IP client
Nmap : Le port affiche comme "ouvert"
SSH : Connexion fonctionnelle
5.3 Après Expiration du Timeout (30 secondes) Fermeture du port
Suppression de la règle iptables
Nmap revient à l'état "filtré"
SSH revient à "timeout"
- Limitations et Vulnérabilités 6.1 Attaque par Rejeu Vulnérabilité : Comme la séquence est fixe, un attaquant qui écoute le réseau peut la capturer et la rejouer pour ouvrir le port SSH à volonté.
Sévérité : Cette attaque est complexe à appliquer en conditions réelles, mais constitue une faille théorique significative.
6.2 Autres Limitations Pratique : Nécessite une action manuelle à chaque connexion SSH, ce qui peut devenir fastidieux avec des accès fréquents
Scalabilité : Complexe à mettre en place sur une grosse infrastructure, reste très manuel
Intégration : Difficile d'inclure dans de grandes machineries, bien que quelques projets existent pour l'automatisation
- Port Knocking avec TOTP 7.1 Principe Combiner le port knocking avec des codes TOTP (Time-based One-Time Password) pour rendre la séquence dynamique.
Au lieu d'une séquence fixe, générer une séquence qui change toutes les minutes, exactement comme un code TOTP classique.
7.2 Fonctionnement de TOTP Partage : Client et serveur partagent une clé secrète (seed)
Génération : La clé secrète est injectée dans la fonction TOTP, qui utilise également le temps
Résultat : Génération d'un code à six chiffres standardisé (RFC)
Transformation : Le code est transformé en une séquence de six nombres en multipliant par 100
Calcul indépendant : Client et serveur calculent la séquence de leur côté à tout moment, sans communication
7.3 Avantages Rend la séquence éphémère et jetable
Même si un attaquant capture la séquence, elle est obsolète la minute suivante
Élimine la vulnérabilité aux attaques par rejeu
7.4 Configuration Serveur avec TOTP Éléments nécessaires :
Clé secrète partagée (seed)
Paquet pour générer un TOTP
Script qui calcule la séquence à partir du TOTP
Cron job qui met à jour la configuration toutes les minutes
Complexité d'implémentation : Environ cinq lignes de Bash + un cron job
7.5 Configuration Client avec TOTP Fourniture uniquement de l'adresse IP du serveur
Calcul automatique de la bonne séquence basée sur la clé secrète partagée et le temps
Aucune entrée manuelle de séquence
- Alternatives et Évolutions 8.1 Single Packet Authorization (SPA) Concept : Version moderne du port knocking, plus récente et évolué.
Fonctionnement :
Le firewall droppe par défaut tous les paquets (similaire au port knocking)
Au lieu d'une séquence de ports, un seul paquet UDP contient l'instruction à exécuter
Le paquet est chiffré avec la clé publique du serveur avant envoi
Le serveur déchiffre avec sa clé privée et exécute l'instruction (exemple : ouvrir le port 22 SSH)
Avantages :
Approche plus moderne et efficace
Utilise un seul paquet au lieu d'une séquence
Chiffrement asymétrique pour sécurité renforcée
API invisible basée sur des concepts réseaux sécurisés
Outils connus :
fwknop (outil principal en CLI)
Implémentations en Rust offrant des interfaces plus élaborées
8.2 Choix d'UDP pour SPA Raison du choix : S'affranchir des contraintes réseau et pouvoir envoyer des paquets très facilement, avec la possibilité d'utiliser des entêtes différentes.
Note : Avec une politique de rejet (drop), le TCP devient fonctionnellement similaire à l'UDP, puisqu'il n'y a jamais de confirmation de réception du message.
- Cas d'Usage et Recommandations 9.1 Contextes Appropriés Serveurs isolés
Homelab et environnements de développement
Accès ponctuel SSH nécessaire mais non continu
Protection contre les scans automatisés et le spam de logs
9.2 Recommandations d'Implémentation Port Knocking classique :
Utile pour des cas simples
Acceptable pour accès occasionnels
Aspect TOTP recommandé si protection contre rejeu critique
SPA (Single Packet Authorization) :
À préférer pour des besoins plus robustes
Plus adapté aux implémentations modernes
Meilleure sécurité par chiffrement asymétrique
9.3 Déploiement en NAT Le port knocking fonctionne aussi avec du NAT, en redirigeant les ports via une box/routeur vers la machine cible.
- Considérations Pratiques Frais opérationnels : Une petite action supplémentaire est requise à chaque connexion
Fréquence d'utilisation : Peut devenir fastidieux avec des connexions SSH très fréquentes
Automatisation : Possible d'inclure dans des workflows, bien que reste largement manuel
Clients disponibles : Nombreux clients existants sur diverses plateformes, y compris natifs sur mobile