Obwohl ich es noch nicht bereitgestellt habe, kenne ich viele Leute, die es bereitgestellt haben. Jeder einzelne von ihnen hat eine signifikante Reduzierung des Bandbreitenverbrauchs von SSH-Brute-Force-Angriffen festgestellt.

Dies bedeutet jedoch nicht, dass es keine Nachteile gibt. AFAIK, es gibt keine kernelbasierten Port-Knocking-Implementierungen, was für mich der eigentliche Schlüssel zur Einführung wäre. Port-Knocking-Daemons basieren auf dem Lesen fehlgeschlagener (und gefilterter / verbotener) Protokolldateieinträge von einem Firewall-System. Das ist alles in Ordnung und gut, aber was passiert, wenn das Dateisystem voll wird? Was passiert, wenn der Dämon aufgrund eines außer Kontrolle geratenen Prozesses getötet wird, der den Arbeitsspeicher und den Austausch des Systems aufzehrt? Was passiert, wenn etwas anderes, von dem eines dieser beiden Dinge abhängt, einfach aufhört und nicht mehr funktioniert? Sie haben höchstwahrscheinlich einen Server, auf den Sie physisch zugreifen müssen. Dies könnte teurer sein als vernünftig, insbesondere wenn Sie mehr als ein paar zehn Meilen vom Server entfernt sind und niemanden haben, den Sie anrufen können, um schnell dorthin zu gelangen.

Eins Was ich sagen kann ist, dass es nicht "Sicherheit durch Dunkelheit" ist. Port Knocking ist eine Form der Authentifizierung und kann wie jedes Authentifizierungssystem so einfach oder komplex wie gewünscht gestaltet werden. Es kann etwas so Einfaches wie "Klopfen an Port 10.000 + realPortNumber" durchgeführt werden, was eine geringfügige Unterbrechung bedeuten würde, oder das Klopfen des Ports könnte selbst verwendet werden, um irgendeine Form der echten Authentifizierung zu übertragen (z. B. 1 Block von AES-codierten Daten, wenn a gegeben ist Schlüssel abgeleitet von einer anderen Methode). Es wäre jedoch nicht möglich, Port-Knocking zum Übertragen großer Datenmengen zu verwenden, da dies erheblich länger dauern würde als nur das Senden eines einzelnen Pakets. Wenn das Paket über TCP übertragen wird, kann zumindest festgestellt werden, ob es erfolgreich empfangen wurde oder auf irgendeine Form von Fehler gestoßen.

Eine interessante Frage, die sich daraus ergibt, ist jedoch, wie die Protokolldateien verwaltet werden. Für Userland-Implementierungen sind meistens die Protokolldateien erforderlich, um festzustellen, ob ein Klopfen erfolgreich gesendet wurde oder nicht, und was passiert, wenn diese Protokolle erstellt werden sind durchgesickert? Authentifizierungsdaten werden bekannt, und das ist offensichtlich keine sehr gute Sache.

Ich kann Ihnen nicht sagen, ob Sie Port Knocking in Ihrem Setup verwenden sollen oder nicht. Ich bin noch nicht und ich bin nicht 100% sicher, dass ich es jemals sein werde. Für mich ist es sinnvoller, starke Authentifizierungssysteme zu verwenden, die auf einer starken Kryptografie basieren (z. B. eine PKI-Infrastruktur), als Port-Knocking in die Quere zu bringen. Außerdem scheint es mir eine schlechte Idee zu sein, einen einzigen Fehlerpunkt für den Zugriff auf kritische Infrastrukturen hinzuzufügen, und es ist viel schwieriger, ihn mit irgendeiner Art von Garantie ordnungsgemäß zu unterstützen. Dies basiert jedoch wiederum auf der Vorstellung, dass die Port-Knocking-Software auf Kernel-Ebene des Betriebssystems nicht in die Firewall integriert ist. Sollte sich dies jemals ändern, kann ich auch meine Einstellung zur Verwendung ändern.

Port Knocking ist nicht nur ein weiteres Nur-Text-Passwort - zumindest nicht zum Schutz von Diensten, die einen TCP-Port wie SSH überwachen. Port-Knocking bedeutet, dass die Diensterkennung mit nmap aufgrund der Verwendung einer Standard-Drop-Firewall-Richtlinie nicht mehr möglich ist. SSHD hatte auch aus der Ferne ausnutzbare Sicherheitslücken, die nichts mit schwachen Passwörtern zu tun haben. Ich möchte nicht, dass jemand in der Lage ist, nmap zu starten und zu sehen, dass ich SSHD lausche.

Es gibt auch eine stärkere Variante des Port-Knockings namens "Single Packet Authorization", aber es ist auch eine Vollständig passives Authentifizierungsschema, sodass die Vorteile des Port-Knockings erhalten bleiben, aber die Einschränkungen behoben werden (Wiederholungsangriffe sind einfach, DoS-Angriffe sind einfach usw.).

Es ist leicht zu überprüfen, dass alle mit dem Internet verbundenen Dienste relativ häufig Sicherheitslücken aufweisen - Dienste wie SSH, OpenSSL usw. Angriffe auf diese werden im Internet massenhaft versucht und zielen auf alle Systeme ab, die über geeignete offene Ports verfügen.

Port Knocking hat meiner Meinung nach den Zweck, diese zufälligen Angreifer vom Internet fernzuhalten, die nach generischen Schwachstellen suchen. Das heißt, es soll keinen dedizierten Angreifer fernhalten oder einen Teil der tatsächlichen Sicherheit der Dienste ausmachen. Der Vorteil des Port-Klopfens sollte darin bestehen, dass es wirklich so einfach ist, dass es wahrscheinlich nie ausnutzbare Fehler enthält.

Diese Verwendung bedeutet, dass das Port-Klopfen so sein kann lax wie möglich, solange es die Mehrheit der Angreifer fernhält. Es kann nur Sicherheit durch Dunkelheit sein, aber ein besserer Weg ist es, es als schwache Form der "Passwort" -Authentifizierung zu haben.

Der "beste" Port-Knocking-Dienst wäre also Eine, gegen die man sich keine Angriffe vorstellen kann, die jedoch für jeden legitimen Benutzer trivial genug ist, um sie von jedem Client-Computer aus zu verwenden.

Laut meinen Kommentaren an anderer Stelle kann es zwar viele Implementierungen geben, die alle möglichen speziellen Tricks verwenden, um auf das Klopfen zu reagieren, es kann jedoch nur mit iptables auf einem Linux-System implementiert werden. d.h. dies ist effektiv eine kernelbasierte Port-Knocking-Implementierung

Da das Klopfen im Netzwerk sichtbar ist, bietet die Verwendung von Sequenzen mit mehr als 3 Klopfen wenig Nutzen. Ich würde die Verwendung von TCP empfehlen - obwohl es langsamer sein wird, haben Sie eine bessere Garantie dafür, dass das Klopfen geliefert wurde.

Obwohl es auf Userspace-Programmen basiert, bevorzuge ich fail2ban Da für die Verbindung keine zusätzlichen Schritte / Software erforderlich sind, die zuverlässig ausgeführt werden und ein Ausfall fehlschlägt, kann ich nicht auf die Server zugreifen.

Es überrascht mich, dass es so wenig gibt Übernahme der verschlüsselten Identität - obwohl RFC1413 lediglich einen möglichen Ansatz unter Verwendung des Protokolls erwähnt, anstatt zu definieren, wie es funktionieren soll.

Aber natürlich sollten Sie sicherstellen, dass Sie den Zugriff unabhängig davon so weit wie möglich eingeschränkt haben (dh keine Root-Anmeldung, beschränken Sie den Zugriff auf die nominierte Gruppe, wenn dies praktikabel ist, und benötigen Sie Schlüsselpaare). SSH ist auf Sicherheit ausgelegt - und in der Vergangenheit gab es relativ wenige Sicherheitslücken in den Hauptstromimplementierungen. Der Grund für den Erfolg von Angriffen liegt normalerweise in einer Kombination aus erratenen Benutzernamen, einfachen Passwörtern und Brute-Force-Angriffen oder Social Engineering. Beachten Sie, dass ich nicht befürworte, dass Sie eine komplexe Passphrasenvalidierung (außer der Mindestlänge) erzwingen oder dass Benutzer ihre Passwörter ständig ändern müssen. Es gibt bessere Ansätze (z. B. Zwei-Faktor), aber leider nur sehr wenige Implementierungen. P. >

Portklopfen ist keine Sicherheit durch Dunkelheit. Es ist Verteidigung in der Tiefe. Es ist, als würde man sein Auto neben einem stehlbareren Auto parken - es wird nicht viel dazu beitragen, einen gezielten Angriff zu verhindern, aber es könnte Opportunisten dazu bringen, in die andere Richtung zu schauen.

Ich habe seit einigen Jahren kein Port-Knocking mehr implementiert, vermute jedoch, dass es sich im Prinzip nicht wesentlich geändert hat. Andere Kommentare enthalten viele gültige Punkte, und ich werde sie hier nicht einfach wiederholen.

Ein Aspekt des Port-Knockings, den ich immer als selbstverständlich implementiert habe, besteht darin, die Klopfsequenz auf einem Pseudozufall, aber wiederholbar zu basieren Wert, wie das aktuelle Datum und die aktuelle Uhrzeit. Diese Strategie schließt die Gefahr eines Wiederholungsangriffs nicht im großen Stil aus, begrenzt jedoch die Exposition einer bestimmten Klopfsequenz. Damit dies erfolgreich ist, wäre natürlich eine synchronisierte Zeit, in meinem Beispiel, eine Quelle für die Konsistenz erforderlich.

Port Knocking ist nur ein weiteres Klartext-Passwort. Es kann wie jedes andere Klartext-Passwort brutal erzwungen, entdeckt, erfasst und wiedergegeben werden. Warum Telnet-Logins neu erfinden?

Sie müssen etwas vertrauen. Nehmen wir also an, Sie vertrauen Ihrem Betriebssystem-Netzwerkstapel und Sie vertrauen sshd, wenn Sie mit verzögerter Komprimierung und Berechtigungstrennung arbeiten und nur eine vernünftige Form der Zwei-Faktor-Authentifizierung (z. B. schlüsselbasiert) zulassen.

Sie können verwenden "einfache" Dienste wie sshd, die authpf aufrufen, um Ihre komplexeren, anfälligen Dienste zu schützen.

Mit authpf können Sie Ihre Firewalls-Regelsätze basierend darauf ändern, wer sich erfolgreich bei sshd authentifiziert, also nur IP-Adressen, bei denen die Anmeldung möglich ist Ihre SSH-Gateways dürfen eine Verbindung zu Ihrer Compile- / Compute- / Datenbankfarm herstellen.