it-swarm.com.de

Wie sicher ist RDP?

Ich habe eine Art Konflikt mit dem Security Lead Engineer meines Unternehmens. Er sagt, dass Remote Desktop Protocol (RDP) nicht sicher genug ist und wir stattdessen TeamViewer verwenden sollten. Wir verwenden RDP nicht nur für den Zugriff auf lokale Ressourcen in unserem Unternehmensnetzwerk, sondern auch für den Zugriff auf Ressourcen (unter Windows 2012+) beim Cloud-Hosting.

Wie sicher ist es in beiden Szenarien, RDP zu verwenden?

85
prot

Ich glaube, dass Teamviewer ein Proxy-Dienst für getunnelte VNC-Verbindungen ist. Daher ist die erste Sicherheitsüberlegung in Bezug auf diesen Dienst, dass er vom Design her MITM'ed ist . Es gab Vorschläge, dass der Dienst vor ein paar Monaten kompromittiert wurde .

(Beachten Sie, dass VNC zwar Verschlüsselung verwendet, der gesamte Austausch jedoch standardmäßig nicht gekapselt ist. Es ist jedoch trivial, einen SSL/ssh/VPN-Tunnel einzurichten.).

Die nächste Überlegung ist, dass dies die Installation von Software von Drittanbietern auf Ihren Systemen bedeutet. Wenn Sie jedoch eine Microsoft-Plattform ausführen, führen Sie bereits Software von mehreren Anbietern aus, die wahrscheinlich nicht von Ihrer Patch-Management-Software abgedeckt wird. Die Aktualisierung der Software ist eines der effektivsten Mittel zum Schutz Ihrer Systeme.

Solange Ihre RDP-Verbindung SSL verwendet, sollte sie mindestens so sicher sein wie Teamviewer und meiner Meinung nach viel mehr.

90
symcbean

Bearbeiten: Den Kommentaren zufolge scheint es in der Enterprise Edition von TeamViewer eine Kombination von Konfigurationsoptionen zu geben, die meine Bedenken verringern könnten. Da ich diese noch nie benutzt habe, kann ich keine Einschätzung darüber abgeben und wie gut sie funktionieren. Laut den Kommentaren könnte es sich um eine fehlerhafte Lösung handeln.

Ich bin ein Serveradministrator (Windows und Linux) und würde jeden Versuch, TeamViewer auf den Servern zu installieren, aus folgenden Gründen blockieren:

  • alle Daten werden über einen vertrauenswürdigen (?) Server eines Drittanbieters übertragen. Dies erfolgt im Internet. Warum sollte ich ihnen vertrauen? Sind Sie sicher, dass es keine Sicherheitslücke gibt, durch die jemand auf dem Datenpfad die Systeme angreifen kann? Vertraue ich darauf, dass ihre Server nicht kompromittiert werden?
  • dies hängt vom Internet ab: Netzwerk-/Internetprobleme beeinträchtigen mit größerer Wahrscheinlichkeit die Möglichkeit, die Systeme remote zu verwalten
  • closed-Source-Software von Drittanbietern mit proprietärem (undokumentiertem?) Protokoll: Soll ich ihnen vertrauen und dass ihr Protokoll sicher ist?
  • Ich weiß nichts über die Benutzer-/Rechteverwaltung für TeamViewer, aber dies könnte auch ein Problem sein. Soweit ich weiß, zeigt TeamViewer den Bildschirm des aktuell angemeldeten Benutzers an, der Probleme mit Audits (welche Person hat eine bestimmte Aktion ausgeführt?) Und Benutzerrechten (die verbindende Person erhält die Rechte des zuvor verbundenen Benutzers) verursachen kann. Ich hoffe, jeder hat seinen eigenen Benutzer auf dem Server und verwendet nicht denselben (vielleicht sogar Administrator!) Benutzer.

Für mich gibt es zu viele rote Fahnen.

Unsere Server befinden sich in einem isolierten Subnetz, in dem die Firewall/der Switch nur vorkonfigurierte Ports zulässt und Benutzer mit ihrem Benutzernamen/Passwort eine VPN-Verbindung zu diesem Subnetz herstellen können. Wir verfolgen einen Tiefenverteidigung Ansatz: Nur bestimmte Gruppen erhalten die Berechtigung, mit ihrem Benutzer eine Verbindung zum VPN herzustellen. Innerhalb des VPN können sie RDP oder SSH verwenden. Sollte es eine Sicherheitslücke in RDP geben, müsste der Angreifer zuerst auf VPN oder LAN zugreifen. Dies würde bedeuten, dass sie entweder unsere IT-Mitarbeiter sind (denen ein Unternehmen bis zu einem gewissen Grad vertrauen muss), Zugriff auf VPN oder physischen Zugriff erhalten oder einen der Server hacken. Physischer Zugriff bedeutet, in das Rechenzentrum einzubrechen. In diesem Fall gibt es größere Sorgen. Gleiches gilt für jemanden des IT-Personals, der auf dem Postweg ist. Wenn sie einen der Server verletzen, benötigen sie auch eine Sicherheitsanfälligkeit bezüglich der Eskalation von Berechtigungen, um angreifen zu können, da sie gesperrte Konten sind. Für den VPN-Zugriff würde er eine Sicherheitslücke im VPN benötigen oder das Konto einer Person mit VPN-Berechtigungen erhalten.

Und das alles nur für den Fall, dass eine RDP-Sicherheitslücke besteht. Höchstwahrscheinlich nur ein Angreifer, der als fortgeschrittene dauerhafte Bedrohung eingestuft ist ( APT ), dh jemand, der ausgefeilte Techniken einsetzt, um Ihr spezifisches System bei einem anhaltenden Angriff anzugreifen. hätte einen -Tage-Exploit für RDP und es ist wahrscheinlicher, dass ein solcher Angreifer einfachere Methoden/Schwachstellen in anderer Software verwenden kann.

71
H. Idden

Zusätzlich zu den anderen guten Antworten bietet TeamViewer weniger physische Sicherheit, da der Bildschirm entsperrt werden muss, um eine Remote-Sitzung zu ermöglichen.

Das heißt, jeder, der an einer Tastatur und einem Monitor einer remote verwalteten Sitzung vorbeigeht, kann diese beobachten und möglicherweise die Sitzung übernehmen, falls der Remotebenutzer nicht darauf achtet.

Beachten Sie, dass der Bildschirm kann ausgeblendet werden nach der Installation eines Anzeigetreibers angezeigt wird. Dies muss jedoch bei jeder Verbindung erfolgen, wobei ein Zeitfenster verbleibt.

Außerdem vertrauen Sie jetzt eher auf die Sicherheit des Ausblendens des TeamViewer-Bildschirms als auf die Sicherheit des Windows-Sperrbildschirms. Stellen Sie sicher, dass Sie damit vertraut sind.

36
SilverlightFox

Zunächst weiß ich nichts über TeamViewer, daher werde ich nicht versuchen, dies zu kommentieren.

Historische RDP-Server verwendeten "RDP-Sicherheit", ein in der Tat fehlerhaftes Protokoll, das für MITM anfällig ist. Tu das nicht. Sogar 2003r2 kann TLS für RDP ausführen. Es gibt also keinen modernen Grund, warum Sie gezwungen sein sollten, RDP-Sicherheit zu verwenden.

Moderne Server unterstützen TLS, sodass die Sicherheit von RDP in direktem Zusammenhang mit der Sicherheit von TLS steht. Mit Registry-Optimierungen können Sie eine Teilmenge von TLS erzwingen, die Sie möchten - auf 1.2 erzwingen, auf bestimmte Cipher Suites beschränken, möglicherweise auf andere Dinge.

Außerdem gibt es hier einen RDP-spezifischen Winkel, da der Server Verbindungen nur auf diejenigen beschränken kann, die "Authentifizierung auf Netzwerkebene" unterstützen. NLA verwendet weiterhin TLS. Es handelt sich lediglich um eine Protokolländerung, um die Authentifizierung früher im Austausch durchzuführen. Ich glaube, dies soll vor einem Denial-of-Service-Angriff schützen, bei dem nicht authentifizierte Benutzer wiederholt versuchen, eine Verbindung herzustellen, ohne sich zu authentifizieren.

Wenn Sie eine RDP-TLS-Sitzung mit NLA entschlüsseln und verfolgen würden, wird Folgendes angezeigt:

  • X.224 Unverschlüsselt austauschen, 1 Paket in jede Richtung, um festzustellen, ob Client und Server NLA kommunizieren können
  • TLS Handshake
  • NLA-Austausch (wirklich [MS-CSSP]) zur Durchführung der Authentifizierung
  • Normaler RDP-Protokollaustausch per [MS-RDPBCGR]
26
Daniel Bungert

Unter der Annahme, dass Sie eine moderne Version von RDP verwenden und diese korrekt konfigurieren (z. B. NLA aktivieren, ordnungsgemäße Zertifikate sortieren), besteht das Hauptrisiko, sie direkt dem Internet zugänglich zu machen, in der Regel darin, ein Authentifizierungssystem für Benutzernamen und Kennwörter für das Internet verfügbar zu machen Internet, dh Sie erlauben Angreifern, Active Directory-Konten zu erzwingen (vorausgesetzt, es handelt sich um eine AD-Umgebung und nicht um eine Reihe eigenständiger Server).

Dies ist nicht besonders gut, da Sie entweder ein DoS-Risiko mit festgelegter Kontosperrung oder das Risiko eines nicht autorisierten Zugriffs ohne festgelegte Kontosperrung haben (jemand wählt immer ein schwaches Kennwort oder verwendet ein Kennwort, das an anderer Stelle verletzt wird) RDP direkt verfügbar machen Ich würde Benutzern, die über diesen Mechanismus Zugriff erhalten, die Zwei-Faktor-Authentifizierung empfehlen.

Was TeamViewer betrifft, besteht kein Risiko eines direkten Zugriffs, aber Sie vertrauen ihnen als Organisation und wurden durch andere Antworten darauf hingewiesen, dass sie in letzter Zeit Sicherheitsbedenken hatten.

16
Rory McCune

Ich werde auf Daniel Bungerts Erklärung der beteiligten Protokolle und warum sie zusammenarbeiten, eingehen. Nachdem ich einen MitM-Proxy für RDP geschrieben habe, bin ich mit dem Innenleben der meisten beteiligten Protokolle sehr vertraut. (Mehr als ich gerne wäre ...)

Sie können es so konfigurieren, dass es nur über TLS funktioniert. Dies bietet eine große Sicherheit für sich. Jede Nachricht ist mit TLS-Verschlüsselung versehen. Sie können Gruppenrichtlinien verwalten, mit denen die zulässigen TLS-Verschlüsselungsprotokolle festgelegt werden. Sie können dies verwenden, um nur diejenigen mit Schlüssellängen oder Algorithmen anzugeben, die Sie für geeignet halten. Dies sind allgemeine Windows-Einstellungen und nicht rdp-spezifisch. Ihre einzige Sorge wären Benutzer, die schlechte Zertifikate akzeptieren. In diesem Fall ist ein MitM-Angriff möglich.

Sie können es jedoch weiter konfigurieren, um nur mit NLA-Authentifizierung zu arbeiten. Insbesondere wird CredSSP mit NTLM verwendet. Dies verhindert MitM, da das in der TLS-Schicht verwendete Zertifikat (zusammen mit anderen Dingen) zum Verschlüsseln des Kennworts verwendet wird. Sie können das verschlüsselte Kennwort dann nicht mehr nur weiterleiten, da der Ziel-RDP-Dienst keinen Hash authentifiziert, der mit einem anderen als dem eigenen Zertifikat generiert wurde. Der Grund, warum mein Mitm funktioniert, ist, dass wir die Passwörter kennen, die für die Verbindung zum Proxy verwendet werden, und damit Informationen extrahieren und einen neuen Hash für den Ziel-RDP-Dienst generieren können. Ein böswilliger RDP-Proxy hat diesen Vorteil nicht.

Da sowohl TLS als auch NLA konfiguriert sind, ist rdp vor Benutzern sicher, die möglicherweise fehlerhafte Zertifikate akzeptieren. Dies wirkt Overminds Bedenken hinsichtlich Mitm-Angriffen entgegen.

10

Ich würde mit einer Art VPN vom Remotecomputer des Benutzers zu einer Firewall bei der Arbeit gehen und dann RDP über diese verschlüsselte Verbindung ausführen.

Das Problem beim Öffnen eines Ports besteht darin, dass er schließlich gefunden wird und Sie Brute-Force-Anmeldeversuche durchführen müssen. Entweder verlangsamt dies nur Ihre Umgebung, oder es führt dazu, dass Konten gesperrt werden, oder sie finden einen Benutzernamen mit einem schwachen Passwort (es gibt immer diesen einen Benutzer ...)

Sie können die 2-Faktor-Authentifizierung mit Smartphone-Apps, Hardware-Token oder vorgedruckten Einmalkennwörtern untersuchen.

Denken Sie daran, Sicherheit ist das Gegenteil von Bequemlichkeit.

7
Criggie

Dies begann als Kommentar.

Es ist wichtig, auf die Frage "Wer ist schuld" hinzuweisen. Wenn Sie einen Dienst eines Drittanbieters verwenden und dieser nicht bereitstellt, wird er nicht bereitgestellt. Wenn Sie etwas im Haus verwenden und es fehlschlägt, ist es jetzt die Schuld des Hauses. Solche Unterscheidungen haben viel Gewicht. Es bedeutet vielleicht nichts für die tatsächliche Sicherheit, aber das kann manchmal an die Seitenlinie gehen.

Zum Beispiel, wenn Sie eine Zertifizierung für einen Vertrag benötigen und diese Zertifizierung Folgendes aussagt:

Sie müssen sichere Remoteverwaltungsmethoden verwenden. Unverschlüsselte Remoteverwaltungsmethoden sind nicht zulässig. Verträge mit Dritten zur Erbringung von Dienstleistungen sind zulässig. Die Verschlüsselung muss den Anforderungen an Stärke und Balken entsprechen. Allgemeine Dienste, die diese Anforderungen erfüllen, sind LogMeIn und TeamViewer. Allgemeine Dienste, die diese Anforderungen nicht erfüllen, sind GoToMyPC und Plain VNC.

Dann könnte die Entscheidung getroffen werden, Team Viewer zu verwenden.

Dann besteht das Risiko für das Geschäft. Es könnte argumentiert werden, dass Teamviewer ein geringeres Risiko darstellt, da Sie einen Dienst in gutem Glauben nutzen, der sicher sein soll. Gleichzeitig kann RDP ein größeres Risiko darstellen, da Sie jetzt das Wissen Ihres Teams gegen das Verständnis zufälliger Personen stellen.

Obwohl dies keine wirkliche Verbindung zur wirklichen Sicherheit hat, ist es wichtig zu bedenken, dass Unternehmen keine Sicherheit betreiben, weil sie damit (normalerweise) Geld verdienen. Sie tun dies als Risikominderung und weil sie weiterhin Geld verdienen müssen. Durch die Verwendung eines Drittanbieter-Dienstes kann ein Teil des Risikos für das Unternehmen beseitigt werden.

6
coteyr

Wie bereits erwähnt, sollten Sie nach Möglichkeit RDP + -Verschlüsselung verwenden. In den Antworten wurden jedoch keine grundlegenden Sicherheitsmaßnahmen gegen Angriffe (brutal oder anderweitig) erwähnt.

ALLE Software/Ports, die für die Öffentlichkeit zugänglich sind, werden gescannt/gefunden. Zeitraum. RDP oder nicht. Verschlüsselung oder nicht. Wenn kein öffentlicher Zugang erforderlich ist, warum zulassen?

Das Erstellen und Verwalten einer Zulassungsliste basierend auf IP-Blöcken kann zeitaufwändig und mühsam sein (wenn viele Hosts darauf zugreifen), sollte jedoch nicht übersehen werden. Sei es 1 IP oder Hunderte von separaten Netzwerk-IPs.

Sie haben einen Cloud-basierten Server erwähnt. So sollte beispielsweise unter AWS/ec2 eine EC2-Sicherheitsgruppe verwendet werden, um einige IPs oder Administratornetzwerke zuzulassen und den Rest zu verweigern. Die meisten Anbieter haben ähnliche Methoden.

Punkt ist (und zusätzlich zu den Antworten): RDP wäre meine Wahl, aber nichts ist perfekt. Es wird noch unvollkommener, wenn Sie keine unerwünschten Netzwerke blockieren.

4
bshea

Auf RDP können Sie einen MiTM-Angriff ausführen. Anschließend wird der gesamte Datenverkehr vom RDP-Server zum RDP-Client und zurück über unser MiTM-System geleitet. Deshalb gilt es nicht als sicher.

Was Teamviewer betrifft, müssen Sie einem Drittanbieter vertrauen, was nicht die Option ist, für die sich viele entscheiden würden.

Im besten Fall sollten Sie Ihr eigenes zertifikatbasiertes VPN einrichten.

3
Overmind