Mein Ziel besteht darin, einen VPN-Tunnel auf einem einzelnen Port der öffentlichen IP eines Servers zu haben und mit einer zusätzlichen VPN-Verschlüsselungsebene per SSH auf den Server zugreifen zu können.
DETAILS DER SERVERKONFIGURATION:
Ich verwende CentOS 7 sowohl auf dem Server als auch auf den Clients. Die Dokumente, die ich bisher gelesen habe, scheinen sich auf eine Konfiguration zu konzentrieren, die über den Browser läuft und den Internetverkehr weiterleitet. Ich brauche den Server nicht, um etwas weiterzuleiten. Kann ich über VPN auf den SSH-Port des Servers zugreifen und den Internetverkehr (80/443) allein auf dem Server und dem Client belassen? Der Server muss weiterhin in der Lage sein, 80/443 über Apache öffentlich bereitzustellen und der Client muss wie gewohnt auf das Internet zugreifen können.
Antwort1
Wenn ich darf, werde ich mir die Freiheit nehmen, Ihre Frage zu zerlegen, einen Schritt zurückzutreten und Ihnen zu helfen, den gesamten Lösungsdesignprozess zu durchlaufen, damit wir eine praktikable Lösung für Sie finden können. Ihre Frage enthält eine Reihe von Ungenauigkeiten zum SSH-Protokoll, zu VPNs und allgemein dazu, wie wir sichere Systeme entwerfen. Lassen Sie uns diese hier durchgehen.
Derzeit bitten Sie in Ihrer Frage um Anleitung zur Implementierung spezifischer Technologien. Ihre Problembeschreibung bewertet jedoch nicht die spezifische Bedrohung, der Sie ausgesetzt sind. Daher ist es verfrüht, eine Lösung zu entwerfen. In dieser Hinsicht haben SieXY problematischuns.
Jede Implementierung, die Sie vornehmen, wird das Problem entweder nicht lösen (weil das Problem tatsächlich woanders liegt) oder die Komplexität erhöhen, wo eine einfachere Lösung ausreichend ist. Darüber hinaus ist unnötige Komplexität unerwünscht, da sie eine Quelle weiterer Sicherheitslücken sein kann.
Definieren Sie Ihr Problem genau
Wir sollten seinzielorientiert,nicht lösungsorientiert. Wir sollten die Objekte unseres Problembereichs definieren, alle Faktoren ermitteln, die zu berücksichtigen sind, die Bedrohungen verstehen, denen wir ausgesetzt sind, und erst dann können wir beginnen zu bestimmen, welche Technologie- und Prozessentscheidungen getroffen werden können, um das vorliegende Problem zu lösen. Ein Prozess, dem wir folgen können:
- Identifizieren Sie das Problem– Welches spezielle Problem möchten wir lösen? Es sollte sich um ein objektives, messbares Problem handeln, dessen Existenz durch Beobachtungen im Feld belegt ist.
- Bestimmen Sie Annahmen und Einschränkungen– Gibt es bestimmte Elemente, von denen wir annehmen können, dass sie sich in einem bestimmten Zustand befinden, und sind der vorgeschlagenen Lösung andere Bedingungen auferlegt? Zu den wesentlichen Einschränkungen müssen die direkten Kosten für die Implementierung der Lösung (Kauf von Hardware, Software oder Beratungszeit) und die indirekten Kosten (Vornahme von Prozessänderungen, Schulung des Personals, Ausgleich verlorener Produktivität) gehören.
Bedrohungsakteure identifizieren(bei Sicherheitsproblemen) –kein System oder Prozess ist 100% sicher. Wir müssen die Art aller Angreifer, die wahrscheinlich einen Angriff starten, sorgfältig bestimmen, um zu ermitteln, ob unsere Lösung solche Angriffe ausreichend verhindert. Dies gilt für die Entwicklung realer physischer Sicherheitssysteme ebenso wie für die Entwicklung technischer Ergebnisse.
Bei Ihrer Beurteilung können Sie beispielsweise folgende Faktoren berücksichtigen:
- Fähigkeiten Ihres Gegners– Wie gut verfügen sie über das nötige Wissen, haben sie Zugriff auf bestimmte Ressourcen, um einen Angriff zu unterstützen usw.
- Ihre Position– Es besteht ein wesentlicher Unterschied zwischen einem Script-Kiddie auf der letzten Meile eines Internetdienstes für Privathaushalte und einem staatlichen Akteur mit Zugriff auf Positionen im Netzwerk, von denen aus Man-in-the-Middle-Angriffe möglich sind.
DeinRisiko und Risikothermostat– Was motiviert den Akteur, Sie oder Ihre Organisation gezielt anzugreifen? Speichert oder verarbeitet Ihr System beispielsweise sensible und/oder privilegierte Daten, die normalerweise geschützter Natur sind und für andere wertvoll sein können (persönliche Daten, Firmengeheimnisse usw.)? Hat es eine privilegierte Position in einem Netzwerk, von dem aus weitere Analysen oder Angriffe gestartet werden können (z. B. ein Core-Router in einem ISP, ein Border-Gateway am Rand eines sensiblen Netzwerks in einem großen Unternehmen)?
Dies hilft dabei zu erkennen, ob es sich um einen Advanced Persistent Threat (APT)-Akteur handelt, der gezieltDukonkret, oder ob wir Opportunisten verteidigen. Es ist viel einfacher, sich gegen einen vorbeikommenden Opportunisten zu verteidigen, wenn man über bescheidene Schutzmaßnahmen verfügt, die einen im Vergleich zur Konkurrenz sicher erscheinen lassen.
Darüber hinaus sollten Sie Ihre Risikobereitschaft (IhreRisikothermostat) trägt dazu bei, das Ergebnis zu optimieren, um die identifizierten Risiken angemessen abzudecken, ohne zu übertreiben.
- Umsetzungsbeschluss– mithilfe der in diesem Prozess gesammelten Informationen unter Berücksichtigung der beschriebenen Einschränkungen und unserer Einschätzung des Risikos geeignete Technologien identifizierenund ProzessÄnderungen zur Behebung des Problems,oder überarbeiten Sie die Einschränkungen oder das Risikoprofil, wenn keine Lösung gefunden werden kann.
Während des gesamten Prozesses erinnern wir unsSicherheit ist ein Prozess, kein Ziel. Sicherheit können wir nicht als Ware von der Stange „kaufen“, und jeder, der das behauptet, lügt oder hat Hintergedanken (wahrscheinlich finanzielle Bereicherung).
Ihr konkretes Problem
Ihre Frage ist unglaublich umfangreich, daher können wir unser Vorgehen anhand Ihrer spezifischen Probleme im Überblick darstellen:
Das Problem
Ich habe aufgrund einer Rkhunter-Analyse einen Serverkompromitt erlebt und möchte die Möglichkeit verringern, dass dies erneut passiert.
Bei dem konkreten Problem handelt es sich um eine frühere Beeinträchtigung des Computers, deren erneutes Auftreten Sie minimieren möchten.
Das Hauptziel, das ich aus Ihrer Frage erkenne, ist die Absicherung des Rechners gegen Remote-Kompromittierungsereignisse, die über ein öffentliches Netzwerk (wie das Internet) stattfinden können. Ein sekundäres Ziel ist die Gewährleistung der Vertraulichkeit und Integrität von Remote-Shell-Sitzungen mit dem Remote-Rechner.
Annahmen und Einschränkungen
Lassen Sie uns diese Punkte als Leitfaden für unsere Lösung dokumentieren:
- Die von der Maschine aus zugänglichen öffentlichen Website-Dienste sind sicher
- Die Arbeitsstationen, von denen Sie Remote-Verbindungen initiieren, sind keine Proxys für Angriffe auf den betreffenden Server. Sie werden beispielsweise selbst nicht infiltriert (und stellen daher keine Angriffsfläche für das Durchsickern oder Ändern von Schlüsseln oder für die Manipulation der Binärdateien dar, die zum Herstellen von Verbindungen verwendet werden). Möglicherweise möchten Sie die Sicherheitslücken aller Client-Computer separat untersuchen oder sie in einer einzigen Bewertung zusammenfassen.
- Der Servercomputer ist physisch sicher und eine Manipulation der Hardware- oder Softwarekonfiguration durch eine Person, die physisch vor Ort ist, ist unwahrscheinlich oder ausgeschlossen. (Ein Computer, auf den ein Angreifer physischen Zugriff hatte, ist wahrscheinlich nicht mehr Ihr Computer.)
- Es wird angenommen, dass das Netzwerk kompromittiert ist. Es könnte Akteure geben, die unsere Pakete abfangen oder umleiten können.
- Um die technischen Aspekte unserer Lösung umzusetzen, möchten wir frei verfügbare Software nutzen.
- Wir gehen davon aus, dass die Benutzer ausreichend geschult sind, sodass Angriffe auf die Wetware (menschliche Bediener) ausgeschlossen werden können (z. B. Social-Engineering-Bedrohungen). Auch hier gilt, dass diese Angriffe im Prinzip selten ausreichend abgeschwächt werden und für die meisten Organisationen eine Schwachstelle darstellen. Da es sich jedoch um einen Serverfehler handelt, werde ich die nichttechnischen Aspekte des Angriffsmodells außer einer beiläufigen Erwähnung außer Acht lassen.
- Es ist akzeptabel, wenn die Lösung eine Offline-Verteilung oder Überprüfung von Schlüsseln vor der ersten Verbindung erfordert.
- Bekannte kryptografische Grundelemente gelten als immun gegen Hintertürangriffe oder nicht öffentlich bekannt gegebene Angriffe.
Bedrohungsmodell
Ich kann Ihr Bedrohungsmodell nicht angemessen bestimmen, da ich weder Einblick in Ihre Organisation und Infrastruktur habe, noch einen Überblick über das von Ihnen verarbeitete Datenportfolio oder die privaten Netzwerke, mit denen Sie intern verbunden sein könnten. Aus den öffentlichen Informationen in Ihrem Profil erkenne ich, dass Sie möglicherweise an einem Ort arbeiten, an dem vertrauliches geistiges Eigentum im Auftrag anderer verarbeitet wird, was eine mittel- bis hochriskante Datensammlung für spezifische Angriffsbedrohungen darstellen würde. (Diese Bedrohung kann sich auch auf die von Ihnen betriebenen persönlichen Systeme erstrecken.)
Implementierung
Lassen Sie uns eine Lösung entwerfen, die unseren Zielen entspricht. Um die Maschine abzusichern, müssen wir öffentliche Angriffsrouten in Betracht ziehen. Sie legt zwei Dienste offen und wir sind davon ausgegangen, dass der Webdienst nicht anfällig ist. Daher müssen wir die Remote-Shell-Verbindung in Betracht ziehen.
Für diesen Zweck,SSH ist mehr als fähigIhre Anforderungen zu erfüllen, ohne den zusätzlichen Wrapper einer VPN-Sitzung. Fast jede Unix-Box kann einen SSH-Daemon ausführen, und eine beträchtliche Anzahl davon ist direkt oder indirekt feindlichen Netzwerken ausgesetzt, ohne dass sie infiltriert werden.
Wie passt SSH zu unseren Zielen?
Secure Shell (SSH) ist darauf ausgelegt, die Vertraulichkeit und Integrität von Remote-Shell-Sitzungen zu gewährleisten. Dies geschieht mithilfe kryptografischer Ansätze. Insbesondere werden Hosts ein oder mehrere Hostschlüssel zugewiesen, mit denen sich der Host für Client-Computer, die eine Verbindung herstellen, eindeutig identifizieren lässt.
Man-in-the-Middle-Angriffe auf SSH
Wie Sie richtig erkannt haben, ist SSH in einem bestimmten Szenario anfällig für einen Man-in-the-Middle-Angriff: Die meisten Benutzer überprüfen die Hostschlüssel, die der Computer bei der ersten Verbindung vorlegt, nicht. Sie verwenden einenVertrauen ab der ersten AnwendungRichtlinie. Wenn ein MitM an dieser Stelle alternative Hostschlüssel bereitstellen kann, ist ein Abfangen der SSH-Sitzung jetzt und bei zukünftigen Verbindungen ohne weitere Erkennung möglich. Eine Erkennung ohne Überprüfung des zwischengespeicherten Hostschlüssels würde erfordern, dass die MitM-Bedrohung neutralisiert wird oder eine Verbindung von einem nicht kompromittierten Netzwerk hergestellt wird, damit der wahre Hostschlüssel des Remote-Hosts präsentiert werden kann.
Da wir uns über MitM Sorgen machen, müssen wir eine Lösung entwickeln, um dies zu mildern. Zu den Ihnen zur Verfügung stehenden Optionen gehören (nicht abschließend):
- Nur Verbindungen über vertrauenswürdige Netzwerke. Dies ist nicht praktikabel, da es nicht unseren Zielen oder Annahmen in Bezug auf Verbindungen über öffentliche Netzwerke entspricht.
- Verteilung des Fingerabdrucks des Hostschlüssels (oder seines gesamten öffentlichen Schlüssels) vor der ersten Verbindung. Verwenden Sie den
ssh-keygenBefehl auf dem Server, um den Fingerabdruck abzurufen, verteilen Sie ihn an die Benutzer und lassen Sie sie den bei der ersten Verbindung angezeigten Fingerabdruck mit der Version auf dem Server vergleichen. Sie müssen sich nur anmelden, wenn der Fingerabdruck übereinstimmt. - Veröffentlichen Sie die Hostschlüssel im DNS und signieren Sie die Zone mit DNSSEC. Stellen Sie sicher, dass alle verbundenen Clients einen DNSSEC-validierenden Resolver verwenden und überprüfen Sie die DNS-basierten Hostschlüssel.Mehr Informationen hierDieser Ansatz vermeidet den Aufwand, den Host-Schlüssel verteilen und manuell überprüfen zu müssen, erfordert jedoch das Vorhandensein bestimmter technischer Komponenten, die in vielen Netzwerken noch nicht weit verbreitet sind.
Brute-Force-Passwortangriffe
Eine weitere Schwachstelle eines laufenden SSH-Daemons sind Brute-Force-Angriffe auf Passwörter. Angreifer testen häufig Ihre Box auf SSH-Dienste und versuchen, sich mithilfe einer gemeinsamen Liste von Benutzernamen und Passwörtern zu authentifizieren. Boxen mit Benutzernamen auf der öffentlichen Liste und schwachen Passwörtern sind wahrscheinlich gefährdet. Zu den Methoden, dies zu verhindern, gehören:
- Stellen Sie den SSH-Daemon so um, dass er eine schlüsselbasierte Authentifizierung verwendet, und deaktivieren Sie die Kennwortauthentifizierung aus dem öffentlichen Internet. Generieren Sie ein RSA-Schlüsselpaar für Ihr Benutzerkonto
ssh-keygenmit einer großen (z. B. >2048) Bitanzahl oder einer geeigneten Bitanzahl für ein mit einem anderen Kryptosystem signiertes Schlüsselpaar. - Verwenden Sie Software, um
fail2banIhre Protokolle zu überwachen und Firewall-Regeln hinzuzufügen, um weitere Verbindungsversuche von derselben Adresse zu blockieren, nachdem ein Schwellenwert für fehlgeschlagene Anmeldungen erreicht wurde.
Würde ein VPN helfen?
VPN-Lösungen können dasselbe Problem lösen, das Sie mit dem SSH-Tunnel lösen möchten. Sie verwenden möglicherweise einen anderen technischen Ansatz oder andere Kryptosysteme, aber beide sind ausreichend, um Ihren Sicherheitsanforderungen gerecht zu werden. Beide verursachen auch einen ähnlichen Aufwand (z. B. ist die Verpflichtung, die Schlüssel vorab an jede Partei zu verteilen oder zu überprüfen, identisch).
Die zusätzliche Funktionalität eines VPN scheint in diesem speziellen Fall unnötig zu sein, wenn Sie nur einen Remote-Shell-Server betreiben möchten. Der Betrieb eines VPN birgt wahrscheinlich zusätzliche Risiken, daein andererDaemon, der auf Ihrem Computer ausgeführt wird, und ein größerer Angriffsvektor.