fwknop - Einzelpaket-Autorisierung (SPA)

Einleitung

fwknop implementiert ein Autorisierungsschema namens Single Packet Authorization (SPA) zur starken Dienstverbergung. SPA erfordert nur ein einzelnes Paket, das verschlüsselt, nicht wiederholbar und mittels eines HMAC authentifiziert ist, um den gewünschten Zugriff auf einen Dienst zu kommunizieren, der hinter einer Firewall in einer Standard-Drop-Filterhaltung verborgen ist. Die Hauptanwendung von SPA besteht darin, eine Firewall zu verwenden, um alle Verbindungsversuche zu Diensten wie SSH zu blockieren, um die Ausnutzung von Schwachstellen (sowohl 0-Day als auch nicht gepatchter Code) zu erschweren. Da keine offenen Ports vorhanden sind, kann jeder durch SPA verborgene Dienst selbstverständlich nicht mit Nmap gescannt werden. Das fwknop-Projekt unterstützt vier verschiedene Firewalls: iptables, firewalld, PF und ipfw unter Linux, OpenBSD, FreeBSD und Mac OS X. Es gibt auch Unterstützung für benutzerdefinierte Skripte, sodass fwknop für andere Infrastrukturen wie ipset oder nftables angepasst werden kann.

SPA ist im Wesentlichen die nächste Generation von Port Knocking (PK), löst jedoch viele der von PK gezeigten Einschränkungen, während seine Kernvorteile erhalten bleiben. Zu den Einschränkungen von PK gehören die allgemeine Schwierigkeit, sich vor Replay-Angriffen zu schützen, asynchrone Chiffren und HMAC-Schemata sind normalerweise nicht zuverlässig unterstützbar, und es ist trivial einfach, einen DoS-Angriff auf einen PK-Server durchzuführen, indem man ein zusätzliches Paket in eine PK-Sequenz einschleust, während diese das Netzwerk durchquert (wodurch der PK-Server davon überzeugt wird, dass der Client die richtige Sequenz nicht kennt). All diese Mängel werden von SPA gelöst. Gleichzeitig verbirgt SPA Dienste hinter einer standardmäßigen Drop-Firewall-Richtlinie, erfasst SPA-Daten passiv (normalerweise über libpcap oder andere Mittel) und implementiert Standard-Kryptografieoperationen für SPA-Paketauthentifizierung und Ver-/Entschlüsselung.

Von fwknop generierte SPA-Pakete nutzen HMAC für authentifizierte Verschlüsselung im Modus "Encrypt-then-Authenticate". Obwohl die Verwendung eines HMAC derzeit optional ist (aktiviert über die Befehlszeilenoption --use-hmac), wird sie aus drei Gründen dringend empfohlen:

1. Ohne HMAC ist eine kryptografisch starke Authentifizierung mit fwknop nicht möglich, es sei denn, GnuPG wird verwendet, aber selbst dann sollte ein HMAC angewendet werden.
2. Ein nach der Verschlüsselung angewendeter HMAC schützt vor kryptanalytischen CBC-Modus-Padding-Oracle-Angriffen wie dem Vaudenay-Angriff und ähnlichen Tricks (wie dem neueren "Lucky 13"-Angriff auf SSL).
3. Der Code, der vom fwknopd-Daemon zum Überprüfen eines HMAC erforderlich ist, ist wesentlich einfacher als der Code, der zum Entschlüsseln eines SPA-Pakets erforderlich ist. Ein SPA-Paket ohne korrekten HMAC wird daher gar nicht erst durch die Entschlüsselungsroutinen geschickt.

Der letzte Grund oben ist der Grund, warum ein HMAC auch dann verwendet werden sollte, wenn SPA-Pakete mit GnuPG verschlüsselt werden, da SPA-Daten nicht durch libgpgme-Funktionen gesendet werden, es sei denn, der HMAC wird zuerst überprüft. GnuPG und libgpgme sind relativ komplexe Codebasen, und daher hilft die Einschränkung der Fähigkeit eines potenziellen Angreifers, mit diesem Code über eine HMAC-Operation zu interagieren, eine stärkere Sicherheitshaltung aufrechtzuerhalten. Das Generieren eines HMAC für SPA-Kommunikation erfordert einen dedizierten Schlüssel zusätzlich zum normalen Verschlüsselungsschlüssel, und beide können mit der Option --key-gen erzeugt werden.

fwknop verschlüsselt SPA-Pakete entweder mit der Rijndael-Blockchiffre oder über GnuPG und die zugehörige asymmetrische Chiffre. Wenn die symmetrische Verschlüsselungsmethode gewählt wird, wird der Verschlüsselungsschlüssel wie üblich zwischen Client und Server gemeinsam genutzt (siehe die Datei /etc/fwknop/access.conf für Details). Der tatsächliche Verschlüsselungsschlüssel für die Rijndael-Verschlüsselung wird über den standardmäßigen PBKDF1-Schlüsselableitungsalgorithmus generiert, und der CBC-Modus wird eingestellt. Wenn die GnuPG-Methode gewählt wird, werden die Verschlüsselungsschlüssel aus GnuPG-Schlüsselbündeln abgeleitet.

Anwendungsfälle

Personen, die Single Packet Authorization (SPA) oder seinen sicherheitstechnisch herausgeforderten Cousin Port Knocking (PK) verwenden, greifen normalerweise auf SSHD zu, das auf demselben System läuft, auf dem die SPA/PK-Software bereitgestellt wird. Das heißt, eine auf einem Host laufende Firewall hat eine Standard-Drop-Richtlinie gegen alle eingehenden SSH-Verbindungen, sodass SSHD nicht gescannt werden kann, aber ein SPA-Daemon konfiguriert die Firewall neu, um einem passiv authentifizierten SPA-Client vorübergehend Zugriff zu gewähren:

"Grundlegende SPA-Nutzung für den Zugriff auf SSHD"

fwknop unterstützt das oben Genannte, geht aber noch viel weiter und nutzt NAT robust (für iptables/firewalld-Firewalls). Immerhin sind wichtige Firewalls normalerweise Gateways zwischen Netzwerken, im Gegensatz dazu, nur auf eigenständigen Hosts bereitgestellt zu werden. NAT wird üblicherweise auf solchen Firewalls (zumindest für IPv4-Kommunikation) verwendet, um internen Netzwerken, die sich im RFC-1918-Adressraum befinden, Internetzugang zu gewähren, und auch um externen Hosts Zugriff auf Dienste zu ermöglichen, die auf internen Systemen gehostet werden.

Da fwknop in NAT integriert ist, kann SPA genutzt werden, um auf interne Dienste durch die Firewall hindurch von Benutzern im externen Internet zuzugreifen. Obwohl dies viele Anwendungen in modernen traditionellen Netzwerken hat, ermöglicht es fwknop auch, Cloud-Computing-Umgebungen wie Amazon AWS zu unterstützen:

"SPA-Nutzung in Amazon AWS Cloud-Umgebungen"

Benutzeroberfläche

Die offizielle plattformübergreifende fwknop-Client-Benutzeroberfläche fwknop-gui (Download, Github) wird von Jonathan Bennett entwickelt. Die meisten clientseitigen SPA-Modi werden unterstützt, einschließlich NAT-Anfragen, HMAC- und Rijndael-Schlüssel (GnuPG wird noch nicht unterstützt), fwknoprc-Abschnittsspeicherung und mehr. Derzeit läuft fwknop-gui unter Linux, Mac OS X und Windows - hier ist ein Screenshot von OS X: "fwknop-gui unter Mac OS X" Ebenfalls verfügbar ist ein aktualisierter Android-Client, verfügbar ebenfalls.

Tutorial

Ein umfassendes Tutorial zu fwknop finden Sie hier:

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

Funktionen

Die folgende Liste enthält alle Funktionen, die vom fwknop-Projekt unterstützt werden:

• Implementiert Single Packet Authorization für iptables- und firewalld-Firewalls unter Linux, ipfw-Firewalls unter *BSD und Mac OS X sowie PF unter OpenBSD.
• Der fwknop-Client läuft unter Linux, Mac OS X, *BSD und Windows unter Cygwin. Darüberhinaus gibt es eine Android-App zum Generieren von SPA-Paketen.
• Unterstützt sowohl Rijndael- als auch GnuPG-Methoden zur Ver-/Entschlüsselung von SPA-Paketen.
• Unterstützt HMAC-authentifizierte Verschlüsselung für sowohl Rijndael als auch GnuPG. Die Reihenfolge der Operationen ist "encrypt-then-authenticate", um verschiedene kryptanalytische Probleme zu vermeiden.
• Replay-Angriffe werden durch SHA-256-Digest-Vergleich von gültigen eingehenden SPA-Paketen erkannt und verhindert. Andere Digest-Algorithmen werden ebenfalls unterstützt, aber SHA-256 ist die Voreinstellung.
• SPA-Pakete werden passiv über libpcap aus der Leitung geschnüffelt. Der fwknopd-Server kann Paketdaten auch aus einer Datei beziehen, die von einem separaten Ethernet-Sniffer beschrieben wird (z.B. mit tcpdump -w <datei>), vom iptables ULOG pcap writer oder direkt über einen UDP-Socket im --udp-server-Modus.
• Für iptables-Firewalls werden von fwknop hinzugefügte ACCEPT-Regeln in benutzerdefinierten iptables-Chains hinzugefügt und (nach einer konfigurierbaren Zeitüberschreitung) gelöscht, sodass fwknop nicht mit einer bereits geladenen iptables-Richtlinie des Systems interferiert.
• Unterstützt eingehende NAT-Verbindungen für authentifizierte SPA-Kommunikation (derzeit nur iptables-Firewalls). Dies bedeutet, dass fwknop so konfiguriert werden kann, dass DNAT-Regeln erstellt werden, sodass Sie von offenen Internet aus einen Dienst (wie SSH) erreichen können, der auf einem internen System mit einer RFC-1918-IP-Adresse läuft. SNAT-Regeln werden ebenfalls unterstützt, was fwknopd im Wesentlichen in ein SPA-authentifizierendes Gateway für den Internetzugriff aus einem internen Netzwerk verwandelt.
• Der fwknop-Server unterstützt mehrere Benutzer, und jedem Benutzer kann ein eigener symmetrischer oder asymmetrischer Verschlüsselungsschlüssel über die Datei /etc/fwknop/access.conf zugewiesen werden.
• Automatische Auflösung der externen IP-Adresse über https://www.cipherdyne.org/cgi-bin/myip (dies ist nützlich, wenn der fwknop-Client hinter einem NAT-Gerät ausgeführt wird). Da die externe IP-Adresse in diesem Modus innerhalb jedes SPA-Pakets verschlüsselt ist, werden Man-in-the-Middle (MITM)-Angriffe verhindert, bei denen ein Inline-Gerät ein SPA-Paket abfängt und es nur von einer anderen IP weiterleitet, um Zugriff zu erlangen.

Lizenz

Das fwknop-Projekt wird als Open-Source-Software unter den Bedingungen der GNU General Public License (GPL v2) oder (nach Ihrer Wahl) einer späteren Version veröffentlicht. Die neueste Version finden Sie unter http://www.cipherdyne.org/fwknop/

Aktueller Stand

Diese README-Datei beschreibt den aktuellen Zustand des fwknop-Projekts mit dem 2.5-Release vom Juli 2013. Derzeit haben wir eine Implementierung der Firewall Knock Operator Bibliothek; libfko, sowie die fwknop-Client- und Serveranwendungen. Die Bibliothek stellt die API und Backend-Funktionalität für die Verwaltung der Single Packet Authorization (SPA)-Daten bereit, die die anderen fwknop-Komponenten verwenden. Sie kann auch von anderen Programmen verwendet werden, die SPA-Funktionalität benötigen (siehe das perl-Verzeichnis für das FKO-Perl-Modul als Beispiel, und es gibt auch Python-Bindungen im python-Verzeichnis).

Upgrade

Wenn Sie von einer älteren Version von fwknop upgraden (und dies schließt die ursprüngliche Perl-Implementierung mit ein), sollten Sie den folgenden Link lesen, um einen reibungslosen Übergang zu fwknop-2.5 oder später sicherzustellen:

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

Sonstiges

• Fragen oder Kommentare zu fwknop werden auf der fwknop-Mailingliste beantwortet.
• Für die statische Analyse verwendet fwknop den CLANG-Static-Analyzer und auch das leistungsstarke Coverity Scan Tool:

fwknop bauen

Diese Distribution verwendet GNU autoconf für die Einrichtung des Builds. Bitte lesen Sie die Datei INSTALL für die allgemeinen Grundlagen zur Verwendung von autoconf.

Es gibt einige "configure"-Optionen, die fwknop-spezifisch sind. Sie lauten (entnommen aus ./configure --help):

  --disable-client        Baut die fwknop-Client-Komponente nicht. Die
                          Voreinstellung ist, den Client zu bauen.
  --disable-server        Baut die fwknop-Server-Komponente nicht. Die
                          Voreinstellung ist, den Server zu bauen.
  --with-gpgme            Unterstützung für GPG-Verschlüsselung mit libgpgme
                          [default=check]
  --with-gpgme-prefix=PFX Präfix, wo GPGME installiert ist (optional)
  --with-gpg=/pfad/zu/gpg Geben Sie den Pfad zur gpg-Ausführbaren an, die gpgme verwenden wird
                          [default=check path]
  --with-firewalld=/pfad/zu/firewalld
                          Geben Sie den Pfad zur firewalld-Ausführbaren an
                          [default=check path]
  --with-iptables=/pfad/zu/iptables
                          Geben Sie den Pfad zur iptables-Ausführbaren an
                          [default=check path]
  --with-ipfw=/pfad/zu/ipfw
                          Geben Sie den Pfad zur ipfw-Ausführbaren an [default=check
                          path]
  --with-pf=/pfad/zu/pfctl
                          Geben Sie den Pfad zur pf-Ausführbaren an [default=check
                          path]
  --with-ipf=/pfad/zu/ipf Geben Sie den Pfad zur ipf-Ausführbaren an [default=check
                          path]

Beispiele:

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

Hinweise

Migration von der Perl-Version von fwknop

Für diejenigen unter Ihnen, die derzeit die Perl-Version verwenden und planen, zu dieser Version zu migrieren, gibt es einige Dinge, die zu beachten sind:

• Nicht alle Funktionen und Merkmale des Perl-basierten fwknop wurden in diese Implementierung übernommen. Wir hielten es für wichtig, die C-Version so schlank und leichtgewichtig wie möglich zu halten. Die meisten der ausgelassenen Funktionen/Funktionalitäten (wie E-Mail-Benachrichtigungen) können auf andere Weise erreicht werden (z.B. durch ein externes Skript zum Überwachen von Logdateien und zum Benachrichtigen basierend auf entsprechenden Logmeldungen).

• Es gibt einige Unterschiede in den Direktiven und Werten der fwknop-Konfigurations- und Zugriffsdateien. Einige davon sind recht subtil. Sie sollten die Dokumentation und die Kommentare in diesen Dateien sorgfältig beachten.

Für fwknop-Entwickler

Wenn Sie diese Distribution von git ziehen, sollten Sie das Skript autogen.sh ausführen, um die autoconf-Dateien zu generieren. Wenn Sie Fehler zu fehlenden Verzeichnissen oder Dateien erhalten, versuchen Sie, autogen.sh erneut auszuführen. Danach können Sie autoreconf -i ausführen, wenn Sie die Konfiguration neu generieren möchten. Wenn autoreconf aus irgendeinem Grund bei Ihnen nicht funktioniert, sollte das Skript autogen.sh ausreichen.

Die nroff-Quellen der Man-Pages von fwknop und fwknopd befinden sich in ihren jeweiligen Verzeichnissen (client und server). Diese nroff-Dateien werden von den asciidoc-Quellen im Verzeichnis 'docs' abgeleitet. Siehe README in docs für Details.