Warum sollten Sie SSH und VPN in Kombination verwenden?


24

Mein Arbeitgeber fordert mich auf, mich zuerst bei einem VPN anzumelden, und erst dann kann ich SSH auf den Servern ausführen. Aber ist ein VPN-Overkill angesichts der Sicherheit von SSH?

Was nützt ein VPN aus Sicherheitsgründen, wenn ich bereits SSH verwende ?


2
Das VPN wird einen breiteren Anwendungsbereich haben - ohne es Sie wahrscheinlich keinen Zugang zum Inneren des Firmennetzwerk überhaupt .
user253751

2
Ich bin ein bisschen verwirrt, da ich keinen Grund anerkenne , SSH nicht zu verwenden, es sei denn, es ist aus irgendeinem wahnsinnigen Grund nicht verfügbar.
Shadur

1
@ Shadur: die Auswahlmöglichkeiten in der Q sind 1) VPN + SSH, 2) SSH allein, aber nicht 3) VPN allein. Die Entscheidungen, mit denen das OP konfrontiert ist, betreffen alle SSH.
RedGrittyBrick

Wenn ihr LAN IPSEC verwendet, dann könnten Siersh
Neil McGuigan

Antworten:


36

Die Begründung für Ihre aktuelle Konfiguration ist wahrscheinlich eine Kombination der folgenden drei Gründe.

Das VPN ist eine Sicherheitslösung für das Netzwerk Ihres Unternehmens (siehe Nr. 1 unten) . SSH ist möglicherweise eine zweite Sicherheitsebene außerhalb des Unternehmensnetzwerks. Der Hauptzweck besteht jedoch darin, den Datenverkehr innerhalb des Unternehmensnetzwerks zu schützen (siehe unten, Nr. 2) . VPN ist auch erforderlich, wenn das Gerät, in das Sie SSH ausführen möchten, eine private Adresse in Ihrem Unternehmensnetzwerk verwendet (siehe Nummer 3 unten) .

  1. VPN erstellt den Tunnel zu Ihrem Unternehmensnetzwerk, durch das Sie Daten übertragen. Somit kann niemand, der den Datenverkehr zwischen Ihnen und dem Netzwerk Ihres Unternehmens sieht, tatsächlich sehen, was Sie senden. Sie sehen nur den Tunnel. Auf diese Weise wird verhindert, dass Personen außerhalb des Unternehmensnetzwerks Ihren Datenverkehr auf nützliche Weise abfangen.

  2. SSH ist eine verschlüsselte Methode zum Herstellen einer Verbindung zu Geräten in Ihrem Netzwerk (im Gegensatz zu Telnet (Klartext)). Unternehmen benötigen aus Sicherheitsgründen häufig SSH-Verbindungen, auch in einem Unternehmensnetzwerk. Wenn ich Malware auf einem Netzwerkgerät installiert habe und Sie in dieses Gerät telneten (auch wenn Sie über einen VPN-Tunnel kommen - da der VPN-Tunnel normalerweise am Rand des Unternehmensnetzwerks endet), werden Ihr Benutzername und Ihr Kennwort angezeigt. Wenn Sie SSH verwenden, kann ich das nicht.

  3. Wenn Ihr Unternehmen eine private Adressierung für das interne Netzwerk verwendet, ist das Gerät, zu dem Sie eine Verbindung herstellen, möglicherweise nicht über das Internet routingfähig. Die Verbindung über einen VPN-Tunnel würde so aussehen, als wären Sie direkt im Büro verbunden. Daher würden Sie das interne Routing des Unternehmensnetzwerks verwenden, das außerhalb des Unternehmensnetzwerks nicht erreichbar wäre.


6
Wenn sich die Malware auf dem Zielgerät befindet, hilft SSH im Vergleich zu Telnet nicht wirklich. (Es würde helfen, wenn sich die Malware auf anderen Geräten im Netzwerk befindet.)
Paulo Ebermann

21

SSH ist ein äußerst beliebtes Ziel für Brute-Forcing-Versuche. Wenn Sie einen SSH-Server direkt im Internet haben, werden Sie innerhalb weniger Minuten Anmeldeversuche mit allen Arten von Benutzernamen (und Kennwörtern) sehen - oft Tausende pro Tag, sogar auf kleinen, unbedeutenden Servern.

Jetzt ist es möglich, SSH-Server abzusichern (die drei Hauptmechanismen erfordern einen SSH-Schlüssel, verweigern den Root-Zugriff auf SSH und beschränken nach Möglichkeit die IP-Adressen, die überhaupt eine Verbindung herstellen dürfen). Der beste Weg, um einen SSH-Server abzusichern, besteht darin, ihn überhaupt nicht im Internet verfügbar zu machen.

Warum spielt es eine Rolle? SSH ist doch grundsätzlich sicher, oder? Ja, aber es ist nur so sicher, wie es die Benutzer schaffen - und Ihr Arbeitgeber ist möglicherweise besorgt, wenn Kennwörter und SSH-Schlüssel gestohlen werden.

Durch das Hinzufügen eines VPN wird eine zusätzliche Verteidigungsebene hinzugefügt, die auf Unternehmensebene gesteuert wird, anstatt wie bei SSH auf der Ebene einzelner Server.

Alles in allem möchte ich Ihren Arbeitgeber für die Umsetzung einiger guter Sicherheitspraktiken hier loben. Natürlich auf Kosten der Bequemlichkeit (Sicherheit geht in der Regel zu Lasten der Bequemlichkeit).


4
Mechanismus Nr. 4 heißt fail2ban, und ich empfehle dringend, ihn zu verwenden.
Shadur

Hervorragender Punkt. Ein weiteres ähnliches Tool ist Denyhosts. In einigen Versionen von fail2ban gibt es eine Sicherheitsanfälligkeit, die es einem Angreifer ermöglicht, beliebige Hosts zu blockieren. Im Grunde genommen können diese Versionen als Vektor für einen Denial-of-Service-Angriff verwendet werden.
Kevin Keane

7

Mit dem VPN können Sie eine Verbindung zum privaten Netzwerk Ihres Arbeitgebers herstellen und eine IP-Adresse dieses privaten Netzwerks abrufen. Sobald Sie mit dem VPN verbunden sind, verwenden Sie einen der Computer im Unternehmen - auch wenn Sie sich physisch auf der anderen Seite der Welt befinden.

Höchstwahrscheinlich verlangt Ihr Arbeitgeber, dass Sie zuerst eine VPN-Verbindung herstellen, da die Server nicht über das Internet erreichbar sind (dh sie haben keine öffentliche IP-Adresse). Dies ist eine gute Idee. Das VPN fügt eine weitere Sicherheitsebene hinzu, als ob die Server über SSH öffentlich zugänglich wären und für eine Reihe von Angriffen anfällig wären.


4

SSH ist ein Verschlüsselungsprotokoll, das für verschiedene Zwecke verwendet wird. Das Verschlüsseln des Datenverkehrs in einem VPN-Tunnel ist eine davon. Ihr Datenverkehr wird mit SSH verschlüsselt, muss dann jedoch in gültige IP-Pakete (Tunnel) eingeschlossen werden, um ein Netzwerk wie das Internet zu durchqueren. Dieser Tunnel ist das VPN.

Grundsätzlich blockiert Ihr Arbeitgeber aus Sicherheitsgründen den Datenverkehr außerhalb des Netzwerks, es sei denn, dieser Datenverkehr erfolgt über ein VPN, das der Arbeitgeber kontrolliert. Ein VPN kann den Inhalt des Tunnels verschlüsseln oder nicht. Durch die Verwendung von SSH wird der im VPN-Tunnel übertragene Datenverkehr verschlüsselt.


4
Kurz gesagt: VPN schützt das Netzwerk, SSH schützt einzelne Server.
Ricky Beam

4

Sie benötigen das VPN, um in das lokale Netzwerk zu gelangen.

Sie haben nicht dann müssen Sie Ihre Verbindung auf einzelne Server sichern, da sie bereits durch die VPN - Verbindung verschlüsselt werden.

Wie würden Sie sich sonst mit ihnen verbinden? SSH ist das De-facto- Konsolenzugriffsprotokoll für Remoteserver. Das Installieren und Konfigurieren eines unsicheren Netzwerks ist ein zusätzlicher Verwaltungsaufwand und verringert die Sicherheit im lokalen Netzwerk (was möglicherweise ein Problem darstellt oder nicht).

Vergessen Sie nicht, dass nicht jeder innerhalb des Unternehmens uneingeschränkten Zugriff auf jeden Server hat. Durch die Möglichkeit, auch innerhalb des lokalen Netzwerks eine schlüsselbasierte Verschlüsselung zu verwenden, kann Ihr Netzwerkadministrator auf einfache und sichere Weise sicherstellen, dass nur Personen, die scheinbar wissen, was sie sind tun, dürfen auch innerhalb des Unternehmens den Server berühren.


4

Sie können auch zusätzliche Sicherheitsebenen über das VPN steuern. Wie Gerätekriterienprüfungen, 2-Faktor-Authentifizierung usw.


2

Typische Überlegung ist, dass Sie die Exposition und mögliche Angriffsvektoren so weit wie möglich reduzieren möchten.

Wenn Sie davon ausgehen, dass sowohl SSH als auch VPN (für ihre eigenen Zwecke) erforderlich sind, bedeutet dies, dass Angreifer über zwei potenzielle Routen in Ihre Umgebung verfügen. Wenn Sie SSH nur lokal einrichten, wird der Sicherheit des Servers eine zusätzliche Ebene hinzugefügt. Stellen Sie sich die folgenden Szenarien vor:

  1. SSH + VPN extern. Angreifer müssen nur SSH gefährden, um den Server zu gefährden.

  2. SSH extern. Funktionell das gleiche wie im vorherigen Szenario.

  3. VPN extern (SSH intern). Verdoppelt die Sicherheit. Der Angreifer muss beide durchbrechen, bevor er etwas mit dem Server anstellen kann.

Bedenken Sie, dass neben der Tatsache, dass VPN für andere Funktionen erforderlich wäre und möglicherweise besser für den externen Zugriff konfiguriert ist, ein Kinderspiel ist.


0

Ich würde riskieren, dass die Antwort einfach darin besteht, dass NAT involviert ist und (wie viele andere angegeben haben) das Offenlegen des ultimativen Zielservers für die Welt einen weiteren Angriffspunkt einlädt. Wenn Sie keine umfangreichen Datenübertragungen mit großen Schlüsseln durchführen, wird SSH im Allgemeinen nicht behindert. Der Engpass wird fast immer das Netzwerk sein. (Fast! = Immer).

Wenn Sie das Glück haben, über IPv6 zu verfügen, ist dies wahrscheinlich kein so großes Problem, aber mit IPv4 und dem begrenzten verfügbaren Adressraum ist NAT (IMO) letztendlich das, was meiner Meinung nach hinter dieser "Richtlinie" mehr als jede andere steht "zufällige" oder "gezielte" Sicherheit.


0

Nach meinem derzeitigen Verständnis ist SSH - da es einfach einen TCP-Schlüsselaustausch verwendet, um zu überprüfen, ob ein Client-Benutzer über die richtigen Anmeldeinformationen für den Zugriff auf die Benutzer-ID im Server verfügt - anfällig für Man-in-the-Middle-Angriffe, bei denen ein ISP oder ein kompromittierter Router angreifen könnte Fangen Sie die Handshake-Anforderung ab und fungieren Sie als diejenige, die die Authentifizierung sendet, wodurch die Verbindung entführt wird. Auf diese Weise können Befehle in den Stream eingefügt und die Ausgabe herausgefiltert werden, bevor sie den ursprünglichen authentischen Client erreicht. Dadurch wird der Mann in der Mitte versteckt, der willkürliche Befehle in die ssh-Shell des Servers einfügt.

Allerdings lässt sich durch einen VPN-Tunnel etwas erreichen, was ssh nicht kann. Ein zusätzlicher vorab vereinbarter symmetrischer Verschlüsselungsschlüssel. Dies bedeutet, dass der Datenverkehr zwischen den beiden Computern für einen Mann in der Mitte nicht anfällig ist, da der Datenverkehr den VPN-Verschlüsselungsschlüssel nicht weiterleiten kann, wenn er im Namen des authentischen Clients abgefangen und weitergeleitet wird, um die SSL-Verschlüsselungsschicht zu steuern Anforderungen, weil der Dritte nicht in der Lage wäre, die VPN-Schlüssel auf die gleiche Weise zu fälschen, wie er eine Middle-Man-Weiterleitung der SSH-TCP-SSL-Verbindung steuern könnte.

Ssh ist also nicht gut genug, um man in der Mitte von einem ISP oder einem kompromittierten Router abzuhalten, den ein Client durchlaufen muss, um eine Verbindung zum Server herzustellen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.