Ich glaube, dass Teamviewer ein Proxy-Dienst für getunnelte VNC-Verbindungen ist. Daher besteht die erste Sicherheitsüberlegung in Bezug auf diesen Dienst darin, dass er by design MITM'ed ist. Es gab Hinweise darauf, 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 - aber es ist Das Einrichten eines SSL / SSH / VPN-Tunnels ist trivial.

Die nächste Überlegung ist, dass Software von Drittanbietern auf Ihren Systemen installiert wird. Wenn Sie jedoch eine Microsoft-Plattform ausführen, wird bereits Software ausgeführt von mehreren Anbietern, die wahrscheinlich nicht von Ihrer Patch-Management-Software abgedeckt werden; 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 IMHO also.

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 deaktivieren eher die Möglichkeit, die Systeme remote zu verwalten.
• Dritt- Closed-Source-Software von Parteien 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 Tiefenverteidigungsansatz : 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, 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 anzugreifen, 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-Sicherheitsanfälligkeit vorliegt. Höchstwahrscheinlich würde nur ein Angreifer, der als fortgeschrittene dauerhafte Bedrohung ( APT) eingestuft ist, dh jemand, der ausgefeilte Techniken verwendet, um Ihr spezifisches System bei einem anhaltenden Angriff anzugreifen, einen 0-Tage-Exploit haben für RDP und es ist wahrscheinlicher, dass ein solcher Angreifer einfachere Methoden / Schwachstellen in anderer Software verwenden kann.

Zusätzlich zu den anderen großartigen 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 von vorbeigeht Eine remote verwaltete Sitzung kann sie beobachten und möglicherweise die Sitzung übernehmen, falls der Remotebenutzer nicht darauf achtet.

Hinweis: Nach der Installation eines Displays scheint es möglich zu sein, den Bildschirm auszublenden Dies muss jedoch für jede 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 dies sicher Sie fühlen sich damit wohl.

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, daher gibt es 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 Registrierungs-Tweaks 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, den der Server einschränken kann Verbindungen nur zu denen, 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 ohne Authentifizierung herzustellen.

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

• X.224 Exchange, unverschlüsselt, 1 Paket in jede Richtung, um festzustellen, ob Client und Server miteinander kommunizieren können NLA
• TLS-Handshake
• NLA-Austausch (wirklich [MS-CSSP]) zur Durchführung der Authentifizierung
• Normaler RDP-Protokollaustausch gemäß [MS-RDPBCGR]

Angenommen, Sie verwenden eine moderne Version von RDP und konfigurieren sie korrekt (z. B. NLA aktivieren, ordnungsgemäße Zertifikate sortieren), besteht das Hauptrisiko, sie direkt dem Internet zugänglich zu machen, in der Regel darin, eine Authentifizierung mit Benutzername / Kennwort bereitzustellen System zum Internet, dh Sie erlauben Angreifern, zu versuchen, Active Directory-Konten brutal zu erzwingen (vorausgesetzt, es handelt sich um eine AD-Umgebung und nicht um eine Reihe eigenständiger Server).

Dies ist nicht der Fall. 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). Wenn Sie also RDP verfügbar machen Direkt würde ich Benutzern, die über diesen Mechanismus Zugriff erhalten, eine Zwei-Faktor-Authentifizierung empfehlen.

Bei TeamViewer besteht kein Risiko eines direkten Zugriffs, aber Sie vertrauen ihnen als Organisation und wurde durch andere Antworten darauf hingewiesen, dass sie Sicherheitsbedenken hatten tly.

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.

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

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 Offenlassen eines Ports besteht darin, dass dies letztendlich der Fall ist gefunden, und Sie haben Brute-Force-Anmeldeversuche. 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 einen Benutzer ...)

Sie können 2 erkunden Faktorauthentifizierung mit Smartphone-Apps, Hardware-Token oder vorgedruckten Einmalkennwörtern.

Denken Sie daran, Sicherheit ist das Gegenteil von Komfort.

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.

Wenn Sie beispielsweise eine Zertifizierung für einen Vertrag benötigen und diese Zertifizierung Folgendes bewirkt:

Sie müssen sichere Remoteverwaltungsmethoden verwenden, unverschlüsselte Remoteverwaltung Methoden sind nicht erlaubt. 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 einfaches VNC.

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

Dann besteht das Risiko für das Unternehmen. 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.

Wie bereits erwähnt, sollten Sie nach Möglichkeit RDP + -Verschlüsselung verwenden. Ich habe jedoch keine Erwähnung grundlegender Sicherheitsmaßnahmen gegen Angriffe (brutal oder anderweitig) in den bereitgestellten Antworten gesehen.

JEDE Software / Ports, die für die Öffentlichkeit zugänglich sind, sind gescannt / gefunden werden. Zeitraum. RDP oder nicht. Verschlüsselung oder nicht. Wenn kein öffentlicher Zugriff erforderlich ist, warum sollte er dann zugelassen werden?

Das Erstellen und Verwalten einer auf IP-Blöcken basierenden Zulassungsliste kann zeitaufwändig und schmerzhaft sein (wenn viele Hosts darauf zugreifen), sollte es aber nicht sein übersehen. 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 Admin-Netzwerke 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.

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. Aus diesem Grund wird es nicht als sicher angesehen.

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

Was das Beste betrifft In diesem Fall sollten Sie Ihr eigenes zertifikatbasiertes VPN einrichten.