fwknop - Autorisation par paquet unique

Introduction

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 :

1. Sans HMAC, une authentification cryptographiquement forte n'est pas possible avec fwknop à moins d'utiliser GnuPG, mais même dans ce cas, un HMAC devrait toujours être appliqué.
2. Un HMAC appliqué après le chiffrement protège contre les attaques par oracle de padding en mode CBC, comme l'attaque de Vaudenay et autres artifices connexes (comme l'attaque plus récente "Lucky 13" contre SSL).
3. Le code nécessaire au démon fwknopd pour vérifier un HMAC est beaucoup plus simple que le code nécessaire pour déchiffrer un paquet SPA, donc un paquet SPA sans HMAC approprié n'est même pas envoyé dans les routines de déchiffrement.

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.

Cas d'utilisation

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"

Interface utilisateur

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.

Tutoriel

Un tutoriel complet sur fwknop se trouve ici :

http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html

Fonctionnalités

Voici une liste complète des fonctionnalités supportées par le projet fwknop :

• Implémente l'Autorisation par paquet unique autour des pare-feu iptables et firewalld sur Linux, ipfw sur *BSD et Mac OS X, et PF sur OpenBSD.
• Le client fwknop fonctionne sur Linux, Mac OS X, *BSD et Windows sous Cygwin. De plus, une application Android permet de générer des paquets SPA.
• Supporte à la fois les méthodes Rijndael et GnuPG pour le chiffrement/déchiffrement des paquets SPA.
• Supporte le chiffrement authentifié HMAC pour Rijndael et GnuPG. L'ordre de fonctionnement est chiffrer-puis-authentifier pour éviter divers problèmes cryptanalytiques.
• Les attaques par rejeu sont détectées et contrecarrées par comparaison de digest SHA-256 des paquets SPA entrants valides. D'autres algorithmes de digest sont également supportés, mais SHA-256 est le défaut.
• Les paquets SPA sont snifflés passivement sur le fil via libpcap. Le serveur fwknopd peut également acquérir les données de paquets à partir d'un fichier écrit par un renifleur Ethernet séparé (comme avec tcpdump -w <fichier>), à partir du rédacteur pcap iptables ULOG, ou directement via une socket UDP en mode --udp-server.
• Pour les pare-feu iptables, les règles ACCEPT ajoutées par fwknop sont ajoutées et supprimées (après un délai configurable) depuis des chaînes iptables personnalisées afin que fwknop n'interfère pas avec toute politique iptables existante déjà chargée sur le système.
• Supporte les connexions NAT entrantes pour les communications SPA authentifiées (pare-feu iptables uniquement pour l'instant). Cela signifie que fwknop peut être configuré pour créer des règles DNAT afin que vous puissiez atteindre un service (comme SSH) exécuté sur un système interne sur une adresse IP RFC 1918 depuis Internet ouvert. Les règles SNAT sont également supportées, ce qui transforme essentiellement fwknopd en une passerelle d'authentification SPA pour accéder à Internet depuis un réseau interne.
• Plusieurs utilisateurs sont supportés par le serveur fwknop, et chaque utilisateur peut se voir attribuer sa propre clé de chiffrement symétrique ou asymétrique via le fichier /etc/fwknop/access.conf.
• Résolution automatique de l'adresse IP externe via https://www.cipherdyne.org/cgi-bin/myip (ceci est utile lorsque le client fwknop est exécuté derrière un dispositif NAT). Parce que l'adresse IP externe est chiffrée dans chaque paquet SPA dans ce mode, les attaques Man-in-the-Middle (MITM) où un dispositif en ligne intercepte un paquet SPA et ne le transmet que depuis une IP différente dans le but d'obtenir l'accès sont contrecarrées.

Licence

Le projet fwknop est publié en tant que logiciel open source sous les termes de la GNU General Public License (GPL v2) ou (à votre option) toute version ultérieure. La dernière version peut être trouvée sur http://www.cipherdyne.org/fwknop/

État actuel

Ce fichier README décrit l'état actuel du projet fwknop tel que de la version 2.5 publiée en juillet 2013. Actuellement, nous avons une implémentation de la bibliothèque Firewall Knock Operator ; libfko, ainsi que les applications client et serveur fwknop. La bibliothèque fournit l'API et la fonctionnalité backend pour gérer les données d'Autorisation par paquet unique (SPA) que les autres composants fwknop emploient. Elle peut également être utilisée par d'autres programmes ayant besoin de fonctionnalités SPA (voir le répertoire perl pour le module FKO perl comme exemple, et il existe également des liaisons python dans le répertoire python).

Mise à niveau

Si vous mettez à niveau à partir d'une version plus ancienne de fwknop (et cela inclut l'implémentation perl d'origine aussi), alors vous voudrez lire le lien suivant pour assurer une transition en douceur vers fwknop-2.5 ou version ultérieure :

http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#backwards-compatibility

Divers

• Les questions ou commentaires sur fwknop seront traités sur la liste de diffusion fwknop.
• Pour l'analyse statique, fwknop utilise l'analyseur statique CLANG et également le puissant outil Coverity Scan :

Construction de fwknop

Cette distribution utilise GNU autoconf pour configurer la construction. Veuillez consulter le fichier INSTALL pour les bases générales sur l'utilisation d'autoconf.

Il existe certaines options "configure" spécifiques à fwknop. Elles sont (extrait de ./configure --help) :

  --disable-client        Ne pas construire le composant client fwknop. Le
                          défaut est de construire le client.
  --disable-server        Ne pas construire le composant serveur fwknop. Le
                          défaut est de construire le serveur.
  --with-gpgme            support pour le chiffrement gpg utilisant libgpgme
                          [default=check]
  --with-gpgme-prefix=PFX préfixe où GPGME est installé (optionnel)
  --with-gpg=/chemin/vers/gpg Spécifier le chemin vers l'exécutable gpg que gpgme utilisera
                          [default=check path]
  --with-firewalld=/chemin/vers/firewalld
                          Spécifier le chemin vers l'exécutable firewalld
                          [default=check path]
  --with-iptables=/chemin/vers/iptables
                          Spécifier le chemin vers l'exécutable iptables
                          [default=check path]
  --with-ipfw=/chemin/vers/ipfw
                          Spécifier le chemin vers l'exécutable ipfw [default=check
                          path]
  --with-pf=/chemin/vers/pfctl
                          Spécifier le chemin vers l'exécutable pf [default=check
                          path]
  --with-ipf=/chemin/vers/ipf
                          Spécifier le chemin vers l'exécutable ipf [default=check
                          path]

Exemples :

./configure --disable-client --with-firewalld=/bin/firewall-cmd
./configure --disable-client --with-iptables=/sbin/iptables --with-firewalld=no

Notes

Migration depuis la version Perl de fwknop

Pour ceux d'entre vous qui utilisent actuellement la version Perl et prévoient de migrer vers cette version, il y a certaines choses à savoir :

• Toutes les fonctionnalités et caractéristiques du fwknop basé sur Perl n'ont pas été portées dans cette implémentation. Nous avons estimé qu'il était important de garder la version C aussi légère et minimaliste que possible. La plupart des fonctionnalités omises (comme les alertes par email) peuvent être accomplies par d'autres moyens (par exemple, utiliser un script externe pour surveiller les fichiers journaux et alerter en fonction des messages de journal appropriés).

• Il existe certaines différences dans les directives et les valeurs des fichiers de configuration et d'accès fwknop. Certaines sont assez subtiles. Vous devez prêter une attention particulière à la documentation et aux commentaires dans ces fichiers.

Pour les développeurs de fwknop

Si vous tirez cette distribution de git, vous devez exécuter le script autogen.sh pour générer les fichiers autoconf. Si vous obtenez des erreurs concernant des répertoires ou fichiers manquants, essayez de relancer autogen.sh. Après cela, vous pouvez exécuter autoreconf -i lorsque vous souhaitez régénérer la configuration. Si, pour une raison quelconque, autoreconf ne fonctionne pas pour vous, le script autogen.sh devrait suffire.

Les sources nroff des pages de manuel fwknop et fwknopd sont incluses dans leurs répertoires respectifs (client et serveur). Ces fichiers nroff sont dérivés des sources asciidoc dans le répertoire 'docs'. Voir le README dans docs pour plus de détails.