Chaque serveur connecté à l'Internet public fait face à une activité permanente de reconnaissance automatisée. Des moteurs d'indexation comme Shodan ou Censys et des réseaux de machines zombies scannent sans relâche l'espace d'adressage IPv4 afin d'inventorier les sockets TCP et UDP en écoute. Lorsqu'une organisation expose des passerelles d'accès distant—qu'il s'agisse de démons OpenSSH, de services IPsec ou de passerelles de terminaison VPN—ces ports publics deviennent des cibles privilégiées pour les attaques par force brute, les tentatives de déclassement de protocoles et l'exploitation de vulnérabilités zero-day.

Les pare-feu de périmètre traditionnels doivent laisser certains ports ouverts en permanence pour accueillir des utilisateurs distants disposant d'adresses IP dynamiques. Le Single Packet Authorization (SPA) résout cette vulnérabilité structurelle en séparant l'étape d'authentification de l'établissement de la connexion réseau. Sous une architecture SPA, la passerelle ne présente aucun port ouvert aux outils de scan. Le pare-feu fonctionne selon une politique de rejet par défaut (default-drop), ignorant silencieusement les trames SYN et les sondes UDP sans renvoyer de paquet TCP RST ni de message ICMP unreachable. Le client n'obtient l'accès qu'en transmettant un datagramme d'autorisation unique, chiffré et authentifié, avant d'initier la poignée de main réelle.

+-------------------------------------------------------------------------+
|                  SCAN DE PÉRIMÈTRE : PARE-FEU STATIQUE VS SPA           |
+-------------------------------------------------------------------------+
|  Pare-feu statique classique :                                          |
|  [Attaquant] ---> Scan de ports (TCP 22, UDP 51820) ---> [Port répond]  |
|                                                                         |
|  Single Packet Authorization (SPA) :                                    |
|  [Attaquant] ---> Scan de ports ---> [Pare-feu DEFAULT DROP : Silence]  |
|  [Utilisateur] -> 1x Datagramme UDP SPA chiffré                         |
|                   │ (Capté via libpcap / eBPF sans socket ouvert)       |
|                   ▼                                                     |
|              [Règle nftables temporaire ouverte pendant 30 secondes]    |
+-------------------------------------------------------------------------+

Faiblesses critiques du Port Knocking traditionnel

Pour mesurer la rigueur du Single Packet Authorization, il convient d'analyser les défaillances de son ancêtre technique : le Port Knocking classique. Conçu en 2003 par Martin Krzywinski, ce procédé imposait au client l'émission d'une série de paquets TCP SYN ou UDP vers des ports fermés selon un ordre prédéterminé (par exemple frapper successivement les ports 7000, 8000 et 9000). Un démon surveillant les journaux du pare-feu détectait cette séquence et autorisait temporairement l'accès pour l'adresse IP source.

Malgré son caractère novateur à l'époque, le Port Knocking traditionnel souffre de limites majeures :

  1. Sensibilité au désordre des paquets : Les réseaux à commutation de paquets et le routage multi-chemins perturbent fréquemment l'ordre de distribution des datagrammes. Si les routeurs intermédiaires délivrent la séquence dans le désordre (par exemple 7000, 9000, 8000), le démon rejette la requête.
  2. Vulnérabilité au rejeu (Replay) : Les séquences de frappe ne contiennent aucune donnée cryptographique. Un espion situé sur le réseau local (comme un point d'accès Wi-Fi public) peut capturer la séquence de ports et la rejouer pour ouvrir l'accès à sa propre adresse IP.
  3. Interférence des scans aveugles : Les scanners automatisés qui parcourent des plages de ports déclenchent involontairement des séquences partielles, réinitialisant les machines à états du serveur et provoquant un déni de service pour les utilisateurs légitimes.
  4. Latence d'initialisation : L'envoi de plusieurs paquets séquentiels introduit un délai d'attente significatif avant même le début des échanges applicatifs.

Qu'est-ce que le Single Packet Authorization (SPA) ?

Le Single Packet Authorization a été conçu par Michael Rash (créateur du projet fwknop) pour éradiquer l'ensemble des défauts structurels du Port Knocking. Au lieu de manipuler une succession de numéros de ports, le protocole SPA encapsule l'identité, les privilèges d'accès et les contraintes de session au sein d'un unique datagramme UDP chiffré.

Dans une architecture SPA, le serveur ne réserve aucun socket d'écoute sur ses interfaces publiques. Les services finaux (tels qu'OpenSSH ou les serveurs VPN) sont strictement associés à localhost ou à des interfaces virtuelles internes, tandis que l'interface réseau externe applique une politique DROP absolue :

nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

Lorsqu'un hôte distant scanne le système, le noyau Linux élimine silencieusement les trames. Pour les outils de cartographie réseau et les robots malveillants, l'hôte réagit comme un espace d'adressage IP non alloué : totalement inerte et invisible.

Structure des données et anatomie du paquet SPA

La charge utile d'un paquet SPA regroupe des données d'authentification structurées, chiffrées au moyen d'algorithmes robustes (tels qu'AES-256-CBC ou des clés asymétriques GnuPG) et authentifiées par une empreinte HMAC-SHA256. Ce format garantit simultanément la confidentialité, l'intégrité et l'authenticité lors d'une transmission atomique.

+-------------------------------------------------------------------------+
|                        FORMAT DU PAQUET CHIFFRÉ SPA                     |
+-------------------------------------------------------------------------+
| [Sel aléatoire de 16 octets] : [Charge utile chiffrée en AES]           |
|                                                                         |
| Données en clair après déchiffrement :                                  |
| 1. Nombre aléatoire à usage unique Nonce (16 caractères)                |
| 2. Identifiant utilisateur client (Client Username)                     |
| 3. Horodatage Unix Epoch (contrôle de validité sur 32 bits)             |
| 4. Version du logiciel client fwknop                                    |
| 5. Indicateur de mode d'accès (Access Request)                          |
| 6. Service ciblé : protocole/port (ex. : udp/51820 ou tcp/22)           |
| 7. Définition de l'IP source (IP publique cliente ou marqueur dynamique)|
| 8. Empreinte SHA-256 calculée sur l'ensemble des champs précédents      |
+-------------------------------------------------------------------------+

Format standardisé de la charge utile SPA

La chaîne de données reconstituée après déchiffrement sépare les éléments par deux-points :

[nonce]:[user]:[timestamp]:[version]:[mode]:[proto/port]:[client_ip]:[sha256_hash]
  • Nonce aléatoire : Garantit la non-répétition du texte chiffré d'une session à l'autre, y compris lorsque les paramètres de connexion sont identiques.
  • Horodatage Unix : Permet au serveur d'imposer une fenêtre temporelle rigoureuse (rejetant systématiquement les paquets présentant un écart $|\Delta t| > 60$ secondes).
  • Spécification de l'IP source : Le client peut solliciter l'ouverture pour son IP observée ou demander au serveur d'extraire l'adresse source directement de l'en-tête IP (essentiel lors de la traversée de passerelles NAT).

Mécanisme de capture passive : libpcap et eBPF/XDP

Le point fort du Single Packet Authorization réside dans la capacité du serveur à analyser les autorisations sans mobiliser de socket d'écoute réseau conventionnel via les appels système bind() et listen().

Le démon SPA (fwknopd) inspecte les trames directement au niveau de la couche liaison de données en s'appuyant sur la bibliothèque libpcap ou sur des filtres eBPF/XDP dans le noyau :

  1. Crochet au niveau du pilote : Le dispositif intercepte les trames brutes dès leur réception par la carte d'interface réseau (NIC), avant l'évaluation par le pare-feu.
  2. Extraction de la charge utile : Dès qu'un paquet UDP vise le port configuré pour le SPA, fwknopd copie son contenu vers l'espace utilisateur.
  3. Vérification cryptographique : La signature HMAC est vérifiée en priorité. Si la signature s'avère non conforme, le paquet est immédiatement écarté sans solliciter le processeur pour un déchiffrement inutile. Si elle est valide, la charge utile est déchiffrée par clé AES ou GPG.
  4. Altération dynamique du pare-feu : Dès validation, le démon insère une règle temporaire dans la table nftables en mémoire noyau.

Prévention des attaques par rejeu (Replay Attacks)

Étant donné qu'un paquet SPA circule sur les réseaux publics sous forme de datagramme UDP autonome, un observateur passif pourrait intercepter la trame brute pour tenter de la rejouer ultérieurement.

Le protocole SPA neutralise ce risque par une double barrière défensive :

  • Fenêtre temporelle d'expiration : Le récepteur confronte l'horodatage interne à son horloge locale. Dès que l'écart dépasse le seuil configuré (généralement 60 secondes), le paquet est écarté. Les paquets enregistrés antérieurement deviennent inopérants.
  • Cache persistant des nonces : Pour parer au rejeu immédiat dans la fenêtre active des 60 secondes, le serveur stocke dans un cache mémoire et disque l'empreinte SHA-256 de chaque paquet traité. Si une empreinte réapparaît, elle est identifiée comme un rejeu frauduleux et rejetée sans modifier l'état du pare-feu.

Renforcement des passerelles VPN et des tunnels WireGuard

Les protocoles VPN de nouvelle génération comme WireGuard profitent d'une conception cryptographique remarquable et d'un silence natif : ils ne répondent à aucune tentative d'initialisation non authentifiée.

Toutefois, en environnement de production et au sein d'infrastructures cloud d'entreprise, ce silence algorithmique laisse subsister des vecteurs d'exposition :

  1. Sondage actif par clés compromises : Un attaquant ayant obtenu des clés clientes légitimes peut initier une session, confirmant ainsi la présence de la passerelle et cartographiant le réseau.
  2. Identification par analyse approfondie (DPI) : Les systèmes de filtrage repèrent les ports UDP statiques (comme 51820) et les tailles fixes des paquets d'initialisation WireGuard (148 octets) pour bloquer les flux.
  3. Exposition des interfaces de gestion : Les passerelles VPN comportent des accès d'administration—accès SSH, interfaces REST API, outils de métrologie. Laisser ces ports accessibles sur l'Internet public représente un danger critique.

L'association de WireGuard avec le SPA forme un bouclier hermétique : le port UDP de WireGuard ainsi que les services d'administration restent bloqués par nftables. Seul un client émettant un paquet SPA valide obtient une ouverture ciblée et éphémère.

RiceGuard et architecture furtive Zero-Port

L'infrastructure réseau de VPNRice s'appuie sur une résilience active du routage et sur le confinement cryptographique des accès. En couplant le protocole RiceGuard à une architecture Zero-Trust stricte, VPNRice préserve les flux utilisateurs contre la surveillance et la cartographie automatisée.

+-------------------------------------------------------------------------+
|                 ARCHITECTURE FURTIVE ZERO-PORT AVEC RICEGUARD           |
+-------------------------------------------------------------------------+
|  [ Poste Utilisateur ]                                                  |
|         │                                                               |
|         ├─ 1. Paquet SPA authentifié (Chiffrement + HMAC-SHA256)        |
|         │     ▼                                                         |
|  [ Nœud Anycast Edge ] ---> [ Pare-feu furtif (Rejet eBPF en noyau) ]   |
|                                     │ (Concordance cryptographique)     |
|                                     ▼                                   |
|                             [ Règle Ingress dynamique : 30 secondes ]   |
|                                     │                                   |
|         └─ 2. Poignée de main WireGuard (ChaCha20-Poly1305 / Noise_IK)  |
|               ▼                                                         |
|         [ Tunnel RiceGuard opérationnel et chiffré ]                    |
+-------------------------------------------------------------------------+

RiceGuard applique les principes de furtivité réseau suivants :

  • Absence totale de ports ouverts : Les passerelles publiques ne répondent à aucun robot d'exploration ni aux équipements de surveillance réseau.
  • Autorisation dynamique au cas par cas : Lors de l'initiation d'un tunnel, un signal chiffré autorise temporairement l'IP cliente dans le filtre de paquets pendant 30 secondes.
  • Mobilité sans rupture : Lors du passage du Wi-Fi aux données mobiles, les clés de session autorisent la nouvelle socket sans exposer le cœur de réseau.

Les utilisateurs recherchant un débit élevé associé à une architecture réseau furtive peuvent installer l'application sur la page de téléchargement VPN.

Déploiement pratique avec fwknop et nftables

La mise en œuvre du Single Packet Authorization sous Linux associe le démon fwknopd au sous-système de filtrage moderne nftables.

Configuration des fichiers fwknopd.conf et access.conf

Dans le fichier /etc/fwknop/fwknopd.conf, définissez les paramètres de capture et l'intégration du pare-feu :

# Capture des paquets entrants sur l'interface publique via libpcap
PCAP_INTF                   eth0;
ENABLE_NFTABLES             Y;
NFT_TABLE                   filter;
NFT_CHAIN                   input;
ENABLE_SPA_PACKET_AGING     Y;
MAX_SPA_PACKET_AGE          60;
ENABLE_DIGEST_CACHE         Y;

Dans le fichier /etc/fwknop/access.conf, configurez les autorisations d'accès et les secrets cryptographiques :

# Bloc d'accès pour poste d'administration autorisé
SOURCE                      ANY;
OPEN_PORTS                  udp/51820, tcp/22;
KEY_BASE64                  +n8kZ3fV9g5wJkL8x7Qp1vYw2z4mR6tP8s0uA2bC4dE=;
HMAC_KEY_BASE64             k9P2wL4mR6tP8s0uA2bC4dE+n8kZ3fV9g5wJkL8x7Q=;
FW_ACCESS_TIMEOUT           30;
REQUIRE_SOURCE_ADDRESS      N;

Lorsque le client exécute fwknop -A udp/51820 -D 198.51.100.1 -R, le démon valide la charge utile, ajoute une règle temporaire dans nftables pendant exactement 30 secondes et laisse s'établir la négociation. Une fois le tunnel actif, le suivi de connexion (ct state established,related accept) assure la persistance des flux tandis que le port redevient invisible pour le reste de l'Internet.

Comparatif architectural : Port Knocking, SPA et Zero Trust (mTLS)

Propriété technique Port Knocking classique Single Packet Authorization (SPA) Zero Trust / Mutual TLS (mTLS)
Visibilité des ports Fermés (analyse des logs) Invisibles (Rejet Default Drop) Requiert un port d'écoute TCP
Robustesse cryptographique Nulle (numéros en clair) Élevée (AES-256 / GPG + HMAC) Élevée (Certificats PKI)
Protection anti-rejeu Vulnérable Complète (Horodatage + Nonce) Complète (Nonces TLS)
Tolérance au désordre Rupture lors du désordre Totale (Datagramme unique autonome) Totale (Gérée par la couche TCP)
Résistance aux scans Perturbé par les scanners Silence absolu et indétectable Les scanners identifient le port TLS
Charge de traitement Très faible Négligeable (HMAC avant déchiffrement) Moyenne (Négociation complète TLS)

Optimisation des performances et résistance aux attaques DoS

En production sous fort trafic, l'administration d'un service SPA nécessite des ajustements au niveau du noyau pour empêcher la perte de paquets lors d'attaques volumétriques :

  1. Pré-filtrage par clé HMAC : Configurez systématiquement une clé HMAC indépendante de la clé de chiffrement AES. fwknopd valide l'intégrité du HMAC avant toute tentative de déchiffrement, évitant l'épuisement des ressources CPU par des paquets falsifiés.
  2. Dimensionnement des tampons de réception : Augmentez la capacité des tampons réseau (SO_RCVBUFFORCE) dans la configuration de capture pour éliminer les pertes de trames dans l'anneau libpcap lors des pics de débit.
  3. Délestage en noyau via eBPF/XDP : Pour les infrastructures traitant des millions de paquets par seconde, insérez des filtres eBPF/XDP pour vérifier la longueur et les motifs d'octets dès la carte réseau avant de transmettre les données au démon en espace utilisateur.

Liste de contrôle de sécurité pour pare-feu furtif

Les administrateurs d'infrastructure mettant en œuvre le Single Packet Authorization doivent valider les points opérationnels suivants :

  1. Politique Default-Drop stricte : Vérifiez que nftables rejette silencieusement les paquets non sollicités sans générer de réponse ICMP.
  2. Confinement des ports d'administration : Assurez-vous que les démons OpenSSH et les interfaces d'API n'écoutent que sur l'adresse locale 127.0.0.1.
  3. Séparation des clés cryptographiques : Utilisez deux clés Base64 indépendantes pour le chiffrement symétrique et pour la signature HMAC.
  4. Synchronisation rigoureuse de l'horloge : Mettez en place un protocole NTP ou NTS authentifié afin de maintenir l'écart temporel entre client et serveur sous les 60 secondes.
  5. Réduction de la fenêtre d'ouverture : Fixez FW_ACCESS_TIMEOUT entre 15 et 30 secondes, ce qui suffit amplement pour finaliser la négociation tout en limitant l'exposition.

Fermer l'ensemble des ports publics transforme radicalement la sécurité des accès distants. En associant l'authentification cryptographique à un filtrage passif, le Single Packet Authorization garantit que vos passerelles VPN critiques restent invisibles aux sondes hostiles sur l'Internet mondial.