Cet article s'applique à tous les utilisateurs de TeamViewer.
Général
TeamViewer créer des fichiers journaux pour le support technique de TeamViewer afin d'identifier l'historique des actions, offrir un support technique et rechercher des dans TeamViewer.
En général, ces fichiers journaux sont destinés au personnel de TeamViewer et non aux utilisateurs finaux. Cependant, les fichiers journaux sont disponibles pour tous.
Lorsque vous ouvrez les fichiers journaux, vous pouvez les trouver accablants et déroutants car de nombreuses données sont incluses. Dans l'intérêt de la transparence et des personnes se sentant en sécurité, nous avons établi un guide pour aider les utilisateurs finaux à lire les fichiers journaux à un niveau de base pour identifier les tentatives de connexion réussies et infructueuses concernant les connexions entrantes.
Avertissement
Les descriptions et informations suivantes sont considérablement simplifiées et ne peuvent jamais refléter la manière dont les sessions TeamViewer sont réellement créées.
Cet article vise à fournir des connaissances de base et limitées compréhensibles pour tout le monde. Pour que cela reste aussi simple et compréhensible que possible, nous avons décidé d'utiliser un exemple.
Ce qui est décrit ci-dessous se produit en quelques millisecondes et n'est fondamentalement pas perceptible pour les utilisateurs. Le passage à l'étape 3 est une description très simplifiée pour suivre l'intrigue de l'exemple et ne reflète pas le fonctionnement de la validation du mot de passe TeamViewer. TeamViewer ne voit pas ou ne connaît pas le mot de passe et ne le verra jamais. Le mot de passe est vérifié localement sur le client.
Rappelez-vous toujours que les fichiers journaux sont conçus pour le dépannage. De ce fait, la durée couverte par les fichiers journaux est limitée. Le fichier journal fait 1 Mo par défaut. Lorsque celui-ci atteint sa taille maximale, il devient logfile_old et un nouveau fichier journal est lancé. (tout logfile_old précédent est effacé lorsque cela se produit).
Ce document ne peut pas couvrir tous les cas où une erreur se produit. Sachez qu'en cas d'imprévu, vous ne pouvez pas vous attendre à voir ces entrées de journal.
Identifier une connexion
Comme les connexions TeamViewer sont négociées via nos masters, il est important de noter qu'il y a beaucoup de cryptage et d'authentification qui se produisent avant qu'une tentative de connexion entrante ne réussisse.
Pour plus d'informations sur les sessions TeamViewer, veuillez vous référer à notre manuel de sécurité.
📌 Note : Pour pouvoir lire complètement les fichiers journaux de TeamViewer, une formation spéciale est requise que seuls les membres du personnel de TeamViewer à certains postes reçoivent.
Par conséquent, pour les personnes qui ne sont pas habituées à analyser les fichiers journaux de TeamViewer, il est facile de penser qu'une session a été établie même s'il ne s'agissait que d'une tentative de connexion lors de la lecture des fichiers journaux.
Après avoir lu cet article, vous serez en mesure de faire la différence entre une tentative de connexion et une connexion réussie.
Connexion réussie vs tentative de connexion
Une connexion réussie est le résultat d'un processus de cryptage et d'authentification hautement sécurisé qui permet à une personne de voir l'appareil distant. Selon les paramètres des appareils, un accès à distance limité ou complet est possible. Toutes les connexions réussies sont répertoriées dans le journal Connections_incoming.txt que vous pouvez trouver dans votre dossier TeamViewer.
Une tentative de connexion peut ou non aboutir à une connexion réussie. Aucun accès à l'appareil distant n'est établi et la personne essayant de se connecter n'a pas accès à l'appareil distant.
Les 5 étapes d'une connexion TeamViewer
Pour identifier et expliquer les cinq étapes d'une connexion TeamViewer entrante , nous prenons un exemple qui nous aide à expliquer et visualiser une connexion TeamViewer. Cet exemple est une configuration dans laquelle Bob essaie de se connecter à l'ordinateur de Sally.
Comme deuxième couche de cet exemple, nous utilisons l'exemple d'un appel téléphonique en cours d'établissement avec l'aide d'un opérateur téléphonique qui était habituel au milieu du 20e siècle.
💡 Gardez à l'esprit : Chaque étape de la connexion doit réussir. Un seul échec entraîne le refus de la connexion par TeamViewer.
Etape 1 : Etablissement d'une tentative de connexion
La première étape de notre exemple de Bob essayant de se connecter à Sally est comparable à Bob tapant le numéro de téléphone de Sally et son téléphone sonne.
Nous appuyons maintenant sur pause et zoomons sur ce qui se passe pour faire sonner le téléphone de Sally. Supposons qu'il y ait un opérateur téléphonique au milieu recevant la demande de Bob :
Bob appelle l'opérateur : « Bonjour opérateur - c'est Bob. J'aimerais parler à Sally ».
Opérateur : « Oui - veuillez patienter ».
L'opérateur appelle Sally.
Le téléphone de Sally sonne alors que l'opérateur l'appelle.
Bob ne parle pas directement avec Sally à ce stade. Et avec cela, nous avons une tentative de connexion. Vous trouverez ci-dessous un exemple de ce à quoi ressemble cette tentative dans le fichier journal.
Ici, vous pouvez également voir quels routeurs ont été utilisés pour les tentatives de connexion. Le routeur choisi est sélectionné pour garantir les meilleures performances possibles et peut différer selon l'heure de la journée. Tous les routeurs sont dans un environnement certifié ISO 27001 et toutes les connexions sont toujours chiffrées de bout en bout.
Gardez à l'esprit : aucune connexion n'a été établie à ce stade :
CommandHandlerRouting[2]::CreatePassiveSession(): incoming session via AU-SYD-IBM-R008.teamviewer.com, protocol Tcp
Étape 2 : vérification des blocages et des listes d'autorisation
Sally décroche le téléphone : « Bonjour, c'est Sally »
Opérateur : « Bonjour Sally - c'est l'opérateur. J'ai Bob qui essaie de se connecter avec vous. Êtes vous d'accord ? »
Sally vérifie ses listes d'autorisation et répond après avoir vu Bob sur sa liste d'autorisation : "Oui - Bob est sur ma liste d'autorisation. Je suis prêt à passer à l'étape suivante d'authentification".
👉 Comme Bob a été ajouté à la liste d'autorisation de Sally dans le passé, Sally accepte de poursuivre le processus de cette tentative de connexion. Pourtant - Bob ne parle pas directement avec Sally à ce stade. Et avec cela, nous n'avons encore qu'une tentative de connexion. Vous trouverez ci-dessous un exemple de ce à quoi ressemble cette vérification dans le fichier journal. Gardez à l'esprit : aucune connexion n'a été établie à ce stade :
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::AuthenticateServer()
Dans le cas où Bob ne serait pas sur la liste d'autorisation de Sally ou serait même sur sa liste de blocage, Sally refuserait de parler à Bob et la tentative de connexion s'arrêterait immédiatement. Vous trouverez ci-dessous un exemple de ce à quoi ressemble ce refus dans le fichier journal :
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::CheckIfConnectionIsAllowed: Partner 111111111 (Bob) not whitelisted CLoginServer::runServer: Connection is not allowed
Étape 3 : Accès facile et vérification du mot de passe
L'opérateur dit à Sally : « Veuillez patienter » et retourne à Bob.
L'opérateur dit : « Salut Bob - quel est le mot de passe pour parler à Sally ? »
Bob dit : "C'est "Sésame, ouvres-toi"'"
L'opérateur dit : « Merci, veuillez patienter »
L'opérateur dit à Sally : "Salut Sally - Bob dit que "Sésame, ouvres-toi" est le mot de passe"
AVIS DE NON-RESPONSABILITÉ : Ce n'est pas ainsi que fonctionne le mot de passe TeamViewer. C'est une description vulgarisée pour suivre l'intrigue de l'exemple. TeamViewer ne voit pas ou ne connaît pas le mot de passe et ne le verra jamais. Le mot de passe est vérifié localement sur le client.
Dans le cas où Sally confirme le mot de passe, l'opérateur connecte les deux lignes ensemble et quitte la connexion (= 🤝 hand-shake réussi). Avec cela, l'opérateur ne peut pas entendre Bob ou Sally.
👉 Dans le fichier journal, la vérification de l'accès facile et le mot de passe ressemble à ceci (réussi) :
Accès facile V1
AuthenticationPublicKey_Passive::Verify: Success
Mot de passe fixe
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using fixed password was successful
Si Sally dit que le mot de passe est incorrect, le processus revient au début de l'étape 3. Bob a une nouvelle chance de donner le bon mot de passe. Après trop de tentatives infructueuses, Sally et l'opérateur refuseront les tentatives de connexion et Bob sera bloqué pendant un certain temps.
👉 Dans le fichier journal, les vérifications d'Eacy Access et le mot de passe ressemblent à ceci (sans succès) :
Accès facile V2
LookupPublicKeyV2: Manager {~keyabcd1234} does not have EasyAccess right, reject Authentication
Mot de passe dynamique
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using dynamic password was denied
Étape 4 : La connexion réussie démarre
Une fois que Bob a réussi à s'authentifier via Easy Access ou un mot de passe, la connexion démarre.
Bob parle maintenant directement avec Sally. Et avec cela, nous avons une connexion réussie. Vous trouverez ci-dessous un exemple de ce à quoi ressemble cette connexion réussie dans le fichier journal :
CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Bob CPersistentParticipantManager::AddParticipant: [222222222,-987654321] type=6 name=Sally CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Bob
Étape 5 : La connexion se termine
À tout moment, Sally ou Bob peuvent mettre fin à la connexion et la connexion est terminée et Bob et Sally ne peuvent plus s'entendre. S'ils veulent reparler, ils doivent recommencer à l'étape 1.
👉 Vous trouverez ci-dessous un exemple de la fin de session d'une connexion réussie dans le fichier journal :
SessionManagerDesktop::SessionTerminate: removing session with TVSessionID = -123456789
Dans le cas où Bob n'a jamais pu s'authentifier avec succès via Easy Access ou un mot de passe, un refus complet de sa tentative de connexion s'ensuit. Il n'y a eu aucun lien du tout.
👉 Vous trouverez ci-dessous un exemple de la fin de session d'une connexion infructueuse dans le fichier journal :
SessionManagerDesktop::SessionTerminate: no session with ID=123456789, aborting logins
💡 Astuce : Les ID indiqués dans le fichier journal pour TVSessionID et ID ne sont pas les ID, mais l'ID TeamViewer pour la session individuelle - Ceux - ci ne peuvent pas être utilisés pour identifier toute personne ou de tout appareil , ni de se connecter à tout le monde.
IDs utilisés dans cet exemple
111111111 - Identifiant TeamViewer de Bob
22222222 Identifiant TeamViewer de Sallys
123456789 - ID de session 1 (= pas d'ID TeamViewer)
987654321 - ID de session 2 (= pas d'ID TeamViewer)