TeamViewer schreibt Log-Dateien mit, damit diese von TeamViewer Mitarbeitern zur Identifizierung vergangener Aktionen, zur technischen Fehlersuche und/oder zur Fehlersuche in TeamViewer genutzt werden können.
Dieser Artikel richtet sich an alle.
Im Allgemeinen sind diese Log-Dateien für die TeamViewer Mitarbeiter und nicht für den Endnutzer gedacht. Dennoch sind die Logdateien auch für die Endnutzer zugänglich.
Wenn Sie die Log-Dateien öffnen, werden Sie sie möglicherweise als überwältigend und verwirrend empfinden, da sie eine Menge Daten enthalten. Im Interesse der Transparenz und des Sicherheitsgefühls unserer Nutzer haben wir einen Leitfaden erstellt, der den Endnutzern helfen soll, die Log-Dateien soweit lesen zu können, um erfolgreiche und erfolglose Verbindungsversuche für eingehende Verbindungen zu identifizieren.
🚨 Haftungsausschluss
Die folgenden Beschreibungen und Angaben sind stark vereinfacht und können niemals wiedergeben, wie TeamViewer Sitzungen tatsächlich erstellt werden.
Dieser Artikel beabsichtigt, einige grundlegende und begrenzte Kenntnisse zu vermitteln. Um es so einfach und verständlich wie möglich zu halten, haben wir uns entschieden, ein Gleichnis als Beispiel zu verwenden.
Was im Folgenden beschrieben wird, geschieht innerhalb von Millisekunden und ist für den Anwender im Grunde nicht spürbar. Phase 3 ist eine stark vereinfachte Beschreibung, um das Beispiel verständlich zu halten und gibt nicht wieder, wie die TeamViewer Passwortüberprüfung funktioniert. TeamViewer sieht oder kennt das Passwort nicht und wird es auch nie sehen. Das Passwort wird lokal auf dem Client geprüft.
Denken Sie immer daran, dass Log-Dateien für die Fehlersuche gedacht sind. Aus diesem Grund ist die Zeitspanne, die von den Log-Dateien abgedeckt wird, begrenzt. Die Log-Datei ist standardmäßig 1MB groß. Wenn die maximale Größe erreicht wird, wird es zu logfile_old und ein eneues Log-Datei wird gestartet. (Jedes vorherige logfile_old wird in diesem Fall gelöscht).
Dieses Dokument kann nicht alle Fälle abdecken, in denen ein Fehler auftritt. Bitte beachten Sie, dass Sie diese Einträge in die Log-Datei nicht erwarten können, wenn etwas Unerwartetes passiert.
Identifizieren einer Verbindung
Da TeamViewer Verbindungen über unsere zentralen Server ausgehandelt werden, ist es wichtig zu wissen, dass es viele Verschlüsselungs- und Authentifizierungsvorgänge gibt, bevor ein eingehender Verbindungsversuch erfolgreich ist.
Weitere Informationen zu TeamViewer Sitzungen finden Sie in unserem Sicherheitshandbuch.
📌 Hinweis: Um die TeamViewer Log-Dateien vollständig lesen zu können, ist eine spezielle Schulung erforderlich, die nur TeamViewer Mitarbeiter in bestimmten Positionen erhalten.
Personen, die mit der Analyse von TeamViewer Log-Dateien nicht vertraut sind, kann es daher leicht passieren, dass sie beim Versuch, Log-Dateien zu lesen, denken, dass eine Sitzung aufgebaut wurde, obwohl es sich nur um einen Verbindungsversuch handelte.
Nach dem Lesen dieses Artikels werden Sie in der Lage sein, zwischen einem Verbindungsversuch und einer erfolgreichen Verbindung zu unterscheiden.
Erfolgreiche Verbindung vs. Verbindungsversuch
Eine erfolgreiche Verbindung ist das Ergebnis eines hochsicheren Verschlüsselungs- und Authentifizierungsprozesses, der tatsächlich dazu führt, dass eine Person das entfernte Gerät sehen kann. Abhängig von den Einstellungen auf den Geräten ist ein eingeschränkter oder vollständiger Fernzugriff möglich. Alle erfolgreichen Verbindungen werden im Protokoll Connections_incoming.txt aufgelistet, das Sie in Ihrem TeamViewer Ordner finden können.
Ein Verbindungsversuch kann, muss aber nicht zu einer erfolgreichen Verbindung führen. Es wird kein Zugriff auf das entfernte Gerät hergestellt und die Person, die versucht, eine Verbindung herzustellen, hat keinen Zugriff auf das entfernte Gerät.
Die 5 Phasen einer TeamViewer Verbindung
Um die fünf Stufen einer eingehenden TeamViewer Verbindung zu identifizieren und zu erklären, nehmen wir ein Beispiel, das uns hilft, eine TeamViewer Verbindung zu erklären und zu visualisieren. In unserem Beispiel versucht sich Bob mit Sallys Computer zu verbinden.
Als zweite Ebene dieses Beispiels verwenden wir ein Gleichnis eines Telefongesprächs, das mit Hilfe eines Telefonisten aufgebaut wird, wie es in der Mitte des 20 üblich war.
💡 Behalten Sie im Hinterkopf: Jede Phase der Verbindung muss erfolgreich abgeschlossen werden. Ein einziger Fehlschlag führt dazu, dass die Verbindung von TeamViewer verweigert wird.
Phase 1: Verbindungsversuch aufbauen
In der ersten Phase versucht Bob eine Verbindung zu Sally herzustellten. Diese Phase können Sie damit vergleichen, dass Bob Sallys Telefonnummer eintippt und ihr Telefon klingelt.
Wir drücken jetzt auf Pause und zoomen auf das, was passiert, damit Sallys Telefon überhaupt klingelt. Nehmen wir an, dass in der Mitte eine Telefonistin steht, der Bobs Anfrage entgegennimmt:
Bob ruft die Vermittlung an: "Hallo Vermittlung - hier ist Bob. Ich würde gerne mit Sally sprechen".
Telefonistin : "Ja - bitte warten".
Die Telefonistin ruft Sally an.
Sallys Telefon klingelt, während die Telefonistin sie anruft.
👉 Bob spricht in dieser Phase noch nicht direkt mit Sally. Somit handelt es sich hier um einen Verbindungsversuch. Im folgenden Beispiel, sehen Sie wie dieser Versuch in der Protokolldatei aussieht.
Hier können Sie auch sehen, welche Router für die Verbindungsversuche verwendet wurden. Der gewählte Router wird ausgewählt, um die bestmögliche Leistung zu gewährleisten und kann je nach Tageszeit ein anderer sein. Alle Router befinden sich in einer ISO 27001-zertifizierten Umgebung und alle Verbindungen sind immer Ende-zu-Ende-verschlüsselt.
Denken Sie dran: Zu diesem Zeitpunkt wurde noch keine Verbindung hergestellt:
CommandHandlerRouting[2]::CreatePassiveSession(): incoming session via AU-SYD-IBM-R008.teamviewer.com, protocol Tcp
Phase 2: Prüfen der Block und Allowliste
Sally nimmt den Hörer ab: "Hallo - hier ist Sally"
Telefonistin : "Hallo Sally - hier ist die Vermittlung. Ich habe Bob hier, der versucht, sich mit Ihnen zu verbinden. Möchten Sie das erlauben?"
Sally überprüft ihre Allowlisten und antwortet, nachdem sie Bob auf ihrer Allowliste gesehen hat: "Ja - Bob ist auf meiner Allowliste. Ich bin bereit, mit der nächsten Phase der Authentifizierung fortzufahren".
👉 Da Bob irgendwann in der Vergangenheit zu Sallys Allowliste hinzugefügt wurde, stimmt Sally zu, den Verbindungsversuchs fortzusetzen. Dennoch spricht Bob in dieser Phase noch nicht direkt mit Sally. Und damit haben wir immer noch nur einen Verbindungsversuch. Im fogenden Beispiel wurde noch keine Verbindung hergestellt
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::AuthenticateServer()
👉 Für den Fall, dass Bob nicht auf Sallys Allowliste oder sogar auf ihrer Blockliste stehen würde, würde Sally sich weigern, überhaupt mit Bob zu sprechen und der Verbindungsversuch wäre sofort abgebrochen worden. Eine solche Verweigerung würde in der Log-Datei so aussehen:
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::CheckIfConnectionIsAllowed: Partner 111111111 (Bob) not whitelisted CLoginServer::runServer: Connection is not allowed
Phase 3: Einfacher Zugriff und Passwortkontrolle
Die Telefonistin sagt zu Sally: "Bitte warten" und geht zurück zu Bob.
Telefonistin: "Hallo Bob - wie lautet das Passwort, um mit Sally zu sprechen?"
Bob: "Es ist 'Sesam öffne dich'".
Telefonistin: "Danke - bitte bleiben Sie dran"
Die Telefonistin sagt zu Sally: "Hallo Sally - Bob sagt, 'Sesam öffne dich' sei das Passwort"
🚨 Haftungsausschluss: So funktioniert das TeamViewer Passwortnicht. Dies hier ist eine sehr stark vereinfachte Beschreibung, zugunsten der Verständlicheit des Beispiels. TeamViewer sieht oder kennt das Passwort nicht und wird es auch nie sehen. Das Passwort wird lokal auf dem Client geprüft.
Für den Fall, dass Sally das Passwort bestätigt, verbindet die Telefonistin die beiden Leitungen miteinander und verlässt die Verbindung (=erfolgreicher Handshake). Damit kann die Telefonistin weder Bob noch Sally hören.
👉 In der Log-Datei sehen die (erfolgreichen) Prüfungen für den Einfachen Zugriff und das Passwort so aus :
Einfacher Zugriff V1
AuthenticationPublicKey_Passive::Verify: Success
Festes Passwort
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using fixed password was successful
Wenn Sally sagt, dass es sich um ein falsches Passwort handele, kehrt der Prozess zum Anfang von Phase 3 zurück. Bob erhält eine neue Chance, das richtige Passwort einzugeben. Nach zu vielen erfolglosen Versuchen verweigern Sally und der Betreiber die Verbindungsversuche und Bob wird für eine gewisse Zeit gesperrt.
👉 In der Log-Datei sehen die (erfolglose) Prüfungen für den Einfachen Zugriff und das Passwort so aus :
Einfacher Zugriff V2
LookupPublicKeyV2: Manager {~keyabcd1234} does not have EasyAccess right, reject Authentication
Dynamisches Passwort
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using dynamic password was denied
Phase 4: Erfolgreiche Verbindung startet
Nachdem sich Bob erfolgreich per Einfachem Zugriff oder Passwort authentifizieren konnte, startet die Verbindung.
Bob spricht nun direkt mit Sally. Und damit haben wir eine erfolgreiche Verbindung. Nachfolgend sehen Sie ein Beispiel, wie diese erfolgreiche Verbindung in der Protokolldatei aussieht:
CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Bob CPersistentParticipantManager::AddParticipant: [222222222,-987654321] type=6 name=Sally CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Bob
Phase 5: Verbindung endet
Zu jedem beliebigen Zeitpunkt können Sally oder Bob die Verbindung beenden. Sobald die Verbindung beendet ist können sich Bob und Sally nicht mehr gegenseitig hören. Wenn sie wieder miteinander sprechen wollen, müssen sie wieder bei Phase 1 beginnen.
👉 Nachfolgend sehen Sie ein Beispiel, wie das Sitzungsende einer erfolgreichen Verbindung in der Log-Datei aussieht:
SessionManagerDesktop::SessionTerminate: removing session with TVSessionID = -123456789
Für den Fall, dass sich Bob nicht erfolgreich per Einfachem Zugriff oder Passwort authentifizieren konnte, folgt ein kompletter Abbruch seines Verbindungsversuchs. Es hat nie eine Verbindung stattgefunden.
👉 Nachfolgend sehen Sie ein Beispiel dafür, wie das Sitzungsende einer missglückten Verbindung in der Log-Datei aussieht:
SessionManagerDesktop::SessionTerminate: no session with ID=123456789, aborting logins
💡 Tipp: Die in der Log-Datei angezeigten IDs für TVSessionID und ID sind nicht die TeamViewer IDs, sondern die ID für die einzelne Sitzung - diese können nicht zur Identifizierung von Personen oder Geräten oder zur Verbindung mit Personen verwendet werden.
Diese IDs wurden in diesem Beispiel verwendet
111111111 - Bobs TeamViewer (Classic) ID
222222222 Sallys TeamViewer (Classic) ID
123456789 - Sitzungs-ID 1 (= keine TeamViewer ID)
987654321 - Sitzungs-ID 2 (= keine TeamViewer ID)