mrash/fwknopEinzelpaket-Autorisierung > Port-Klopfen
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:
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.
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"
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.
Ein umfassendes Tutorial zu fwknop finden Sie hier:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html
Die folgende Liste enthält alle Funktionen, die vom fwknop-Projekt unterstützt werden:
