mrash/fwknopAutorisation par paquet unique > Port Knocking
fwknop implémente un schema d'autorisation connu sous le nom d'Autorisation par paquet unique (SPA) pour un masquage robuste des services. SPA ne nécessite qu'un seul paquet, qui est chiffré, non rejouable, et authentifié via un HMAC, afin de communiquer l'accès souhaité à un service caché derrière un pare-feu dans une posture de filtrage par défaut-rejet. La principale application de SPA est d'utiliser un pare-feu pour rejeter toutes les tentatives de connexion à des services tels que SSH, afin de rendre plus difficile l'exploitation de vulnérabilités (à la fois 0-day et code non patché). Comme il n'y a pas de ports ouverts, tout service masqué par SPA ne peut naturellement pas être scanné avec Nmap. Le projet fwknop supporte quatre pare-feu différents : iptables, firewalld, PF et ipfw sur Linux, OpenBSD, FreeBSD et Mac OS X. Il existe également un support pour des scripts personnalisés afin que fwknop puisse être adapté à d'autres infrastructures comme ipset ou nftables.
SPA est essentiellement la génération suivante du Port Knocking (PK), mais résout de nombreuses limitations du PK tout en conservant ses avantages fondamentaux. Les limitations du PK incluent une difficulté générale à se protéger contre les attaques par rejeu, les chiffrements asymétriques et les schémas HMAC ne sont généralement pas supportés de manière fiable, et il est trivial de lancer une attaque par déni de service contre un serveur PK simplement en usurpant un paquet supplémentaire dans une séquence PK lors de son transit sur le réseau (convainquant ainsi le serveur PK que le client ne connaît pas la séquence correcte). Toutes ces lacunes sont résolues par SPA. En même temps, SPA masque les services derrière une politique de pare-feu par défaut-rejet, acquiert les données SPA passivement (généralement via libpcap ou d'autres moyens), et implémente des opérations cryptographiques standard pour l'authentification et le chiffrement/déchiffrement des paquets SPA.
Les paquets SPA générés par fwknop exploitent HMAC pour un chiffrement authentifié dans le modèle chiffrer-puis-authentifier. Bien que l'utilisation d'un HMAC soit actuellement optionnelle (activée via l'option --use-hmac en ligne de commande), elle est fortement recommandée pour trois raisons :
La dernière raison ci-dessus explique pourquoi un HMAC devrait être utilisé même lorsque les paquets SPA sont chiffrés avec GnuPG, car les données SPA ne sont pas envoyées via les fonctions libgpgme tant que le HMAC n'est pas vérifié en premier. GnuPG et libgpgme sont des ensembles de code relativement complexes, et limiter ainsi la capacité d'un attaquant potentiel à interagir avec ce code via une opération HMAC aide à maintenir une posture de sécurité plus forte. La génération d'un HMAC pour les communications SPA nécessite une clé dédiée en plus de la clé de chiffrement normale, et les deux peuvent être générées avec l'option --key-gen.
fwknop chiffre les paquets SPA soit avec le chiffrement par blocs Rijndael, soit via GnuPG et le chiffrement asymétrique associé. Si la méthode de chiffrement symétrique est choisie, comme d'habitude, la clé de chiffrement est partagée entre le client et le serveur (voir le fichier /etc/fwknop/access.conf pour les détails). La clé de chiffrement réelle utilisée pour le chiffrement Rijndael est générée via l'algorithme standard de dérivation de clé PBKDF1, et le mode CBC est défini. Si la méthode GnuPG est choisie, les clés de chiffrement sont dérivées des trousseaux de clés GnuPG.
Les personnes qui utilisent l'Autorisation par paquet unique (SPA) ou son cousin moins sécurisé, le Port Knocking (PK), accèdent généralement à SSHD exécuté sur le même système que celui où le logiciel SPA/PK est déployé. C'est-à-dire qu'un pare-feu sur un hôte a une politique de rejet par défaut pour toutes les connexions SSH entrantes, de sorte que SSHD ne peut pas être scanné, mais un démon SPA reconfigure le pare-feu pour accorder temporairement l'accès à un client SPA passivement authentifié :
"Utilisation basique de SPA pour accéder à SSHD"
fwknop supporte ce qui précède, mais va également beaucoup plus loin et utilise robustement le NAT (pour les pare-feu iptables/firewalld). Après tout, les pare-feu importants sont généralement des passerelles entre réseaux, par opposition à être simplement déployés sur des hôtes autonomes. Le NAT est couramment utilisé sur ces pare-feu (du moins pour les communications IPv4) pour fournir un accès Internet aux réseaux internes qui sont sur l'espace d'adressage RFC 1918, et aussi pour permettre à des hôtes externes d'accéder à des services hébergés sur des systèmes internes.
Parce que fwknop s'intègre avec le NAT, SPA peut être utilisé pour accéder à des services internes à travers le pare-feu par des utilisateurs sur Internet externe. Bien que cela ait de nombreuses applications sur les réseaux traditionnels modernes, cela permet également à fwknop de supporter des environnements de cloud computing comme AWS d'Amazon :
"Utilisation de SPA sur les environnements cloud Amazon AWS"
L'interface utilisateur client fwknop officielle multiplateforme fwknop-gui
(téléchargement, github)
est développée par Jonathan Bennett. La plupart des modes SPA côté client sont supportés, y compris les requêtes NAT, les clés HMAC et Rijndael (GnuPG n'est pas encore supporté), la sauvegarde de strophes fwknoprc, et plus encore. Actuellement, fwknop-gui fonctionne sur Linux, Mac OS X et Windows - voici une capture d'écran sous OS X :
"fwknop-gui sur Mac OS X"
De même, un
client Android mis à jour est
disponible également.
Un tutoriel complet sur fwknop se trouve ici :
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html
Voici une liste complète des fonctionnalités supportées par le projet fwknop :
