TeamViewer recoge archivos de registro para que el personal de TeamViewer pueda identificar las acciones históricas, soluciones de problemas técnicos y la búsqueda de errores en TeamViewer.
Este artículo se dirige a tod@s l@s usuari@s de TeamViewer.
En general, estos archivos de registro están destinados al personal de TeamViewer. Sin embargo, los usuarios finales también pueden acceder a estos archivos de registro.
Dada la cantidad de datos que se recogen en ellos, pueden resultar abrumadores y confusos. Pero para ofrecer transparencia y que los usuarios se sientan seguros, hemos dedicido escribir esta guía básica para ayudar a los usuarios finales a leer los archivos de registro a identificar los intentos de conexión exitosos y no exitosos para la conexión entrante.
🚨Descargo de responsabilidad
Las siguientes descripciones e informaciones están muy simplificadas y no reflejan cómo se crean realmente las sesiones de TeamViewer.
Este artículo pretende ofrecer unos conocimientos básicos y limitados que sean comprensibles para todos. Para que sea lo más sencillo y comprensible posible, hemos decidido utilizar una parábola como ejemplo.
Lo que se describe a continuación ocurre en milisegundos y básicamente no es perceptible para los usuarios. El pasaje de la etapa 3 es una descripción excesivamente simplificada para seguir la trama del ejemplo y no refleja cómo funciona la validación de la contraseña de TeamViewer. TeamViewer no ve ni conoce la contraseña y nunca la verá. La contraseña se comprueba localmente en el client.
Recuerda que los archivos de registro están diseñados para la resolución de problemas. Por ello, la cantidad de tiempo cubierta por los archivos de registro es limitada. El archivo de registro es de 1MB por defecto. Cuando se alcanza el tamaño máximo, se convierte en logfile_old y se inicia un nuevo logfile (cualquier archivo de registro anterior se borra cuando esto ocurre).
Este documento no puede cubrir todos los casos en los que se produce un error. Por favor, recuerda que en caso de que ocurra algo inesperado no esperes encontrarlo en estas entradas de registro.
Identificar una conexión
Como las conexiones de TeamViewer se realizan a través de nuestros servidores centrales, es importante tener en cuenta que hay mucho cifrado y autenticación que se produce antes de que un intento de conexión entrante tenga éxito.
Para más información sobre las sesiones de TeamViewer, consulta nuestro manual de seguridad.
📌Nota: Para poder leer completamente los archivos de registro de TeamViewer, se requiere una formación especial que solo reciben los miembros del personal de TeamViewer en determinados puestos.
Por lo tanto, para las personas que no están familiarizadas con el análisis de los archivos de registro de TeamViewer, es fácil pensar que se ha establecido una sesión aunque sólo haya sido un intento de conexión al intentar leer los archivos de registro.
El objetivo de este artículo es que después de leerlo seas capaz de diferenciar entre un intento de conexión y una conexión establecida correctamente.
Conexión exitosa frente a intento de conexión
Una conexión exitosa es el resultado de un proceso de encriptación y autenticación altamente seguro, en otras palabras una persona pueda ver el dispositivo remoto. Dependiendo de la configuración de los dispositivos, es posible un acceso remoto limitado o completo. Todas las conexiones exitosas se enumeran en el registro Connections_incoming.txt que puedes encontrar en tu carpeta de TeamViewer.
Un intento de conexión puede o no resultar en una conexión exitosa. No se establece ningún acceso al dispositivo remoto y la persona que intenta conectarse no tiene acceso al dispositivo remoto.
Las 5 etapas de una conexión de TeamViewer
Para identificar y explicar las cinco etapas de una conexión entrante de TeamViewer, tomamos un ejemplo que nos ayude a explicar y visualizar una conexión de TeamViewer. Este ejemplo es una configuración en la que Don Pepito intenta conectarse al ordenador de Doña Josefa.
Como ejemplo de visualización, utilizamos la parábola de una llamada telefónica que se está estableciendo con la ayuda de una telefonista (habitual del siglo XX).
💡Ten en cuenta: Cada etapa de la conexión debe tener éxito. Un solo fallo hace que la conexión sea denegada por TeamViewer.
Etapa 1: Establecimiento de un intento de conexión
La primera etapa en nuestro ejemplo de Don Pepito tratando de conectarse con Doña Josefa, es comparable con Don Pepito escribiendo el número de teléfono de Doña Josefa y su teléfono está sonando.
Ahora hacemos una pausa y nos acercamos a lo que ocurre para que el teléfono de Doña Josefa suene. Supongamos que hay una operadora telefónica en medio recibiendo la petición de Don Pepito:
Don Pepito llama a la operadora: "Hola operadora, soy Don Pepito. Me gustaría hablar con Doña Josefa".
Operadora: "Sí, espere por favor".
La operadora llama a Doña Josefa.
El teléfono de Doña Josefa suena mientras la operadora la llama.
👉Don Pepito no está hablando directamente con Doña Josefa en esta etapa. Y con esto, tenemos un intento de conexión. A continuación se muestra un ejemplo de cómo este intento se ve en el archivo de registro.
Aquí también puedes ver qué routers se han utilizado para los intentos de conexión. El router elegido se selecciona para garantizar el mejor rendimiento posible y puede variar según la hora del día. Todos los routers se encuentran en un entorno con certificación ISO 27001 y todas las conexiones están siempre encriptadas de extremo a extremo.
Recuerda que en este momento no se ha establecido ninguna conexión todavía:
CommandHandlerRouting[2]::CreatePassiveSession(): incoming session via AU-SYD-IBM-R008.teamviewer.com, protocol Tcp
Etapa 2: Comprobación de la lista de contactos permitidos y bloqueados
Doña Josefa coge el teléfono: "Hola - soy Doña Josefa"
Operadora: "Hola Doña Josefa- soy la operadora. Tengo a Don Pepito intentando conectarse contigo. ¿Quieres permitirlo?"
Doña Josefa comprueba su lista de permitidos y responde después de ver a Don Pepito en su lista de permitidos: "Sí, Don Pepito está en mi lista de permitidos. Estoy lista para pasar a la siguiente fase de autenticación".
👉 Como Don Pepito fue añadido en algún momento anterior a la lista de permitidos de Doña Josefa, Doña Josefa está de acuerdo en continuar el proceso de este intento de conexión. Aun así - Don Pepito no esta hablando directamente con Doña Josefa en esta etapa. Y con esto, de momento seguimos teniendo sólo un intento de conexión. A continuación se muestra un ejemplo de cómo se ve esta comprobación en el archivo de registro.
Recuerda que todavía no se ha establecido ninguna conexión en este punto:
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::AuthenticateServer()
👉En caso de que Don Pepito no estuviera en la lista de permitidos de Doña Josefa o incluso estuviera en su lista de bloqueados, Doña Josefa se negaría a hablar con Don Pepito en absoluto y el intento de conexión se detendría inmediatamente. A continuación se muestra un ejemplo de cómo se ve este rechazo en el archivo de registro:
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::CheckIfConnectionIsAllowed: Partner 111111111 (Don Pepito) not whitelisted CLoginServer::runServer: Connection is not allowed
Etapa 3: Acceso fácil y comprobación de la contraseña
La operadora le dice a Doña Josefa: "Por favor, espere" y vuelve con Don Pepito .
La operadora dice: "Hola Don Pepito - ¿Cuál es la contraseña para hablar con Doña Josefa?"
Don Pepito dice: "Ábrete Sésamo'"
La operadora dice: "Gracias - por favor espere"
La operadora le dice a Doña Josefa: "Hola Doña Josefa- Don Pepito dice que 'Ábrete Sésamo' es la contraseña"
⚠Descargo de responsabilidad: Esto no es cómo funciona la contraseña de TeamViewer. Es una descripción muy simplificada. TeamViewer no ve ni conoce la contraseña y nunca la verá. La contraseña se comprueba localmente en el client.
En caso de que Doña Josefa confirme la contraseña, el operador conecta las dos líneas y abandona la conexión (=successful handshake). Con esto, el operador no puede escuchar a Don Pepito o Doña Josefa.
👉En el archivo de registro las comprobaciones de Easy Access y la contraseña se ven así (con éxito):
Acceso fácil V1
AuthenticationPublicKey_Passive::Verify: Success
Contraseña fija
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using fixed password was successful
En caso de que Doña Josefa diga que la contraseña es incorrecta, el proceso vuelve al inicio de la etapa 3. Don Pepito tiene una nueva oportunidad para dar la contraseña correcta. Después de demasiados intentos fallidos, Doña Josefa y el operador rechazarán los intentos de conexión y Don Pepito quedará bloqueado durante un tiempo.
👉En el archivo de registro las comprobaciones de Acceso Fácil y la contraseña se ven así (sin éxito):
Acceso fácil V2
LookupPublicKeyV2: Manager {~keyabcd1234} does not have EasyAccess right, reject Authentication
Contraseña dinámica
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using dynamic password was denied
Etapa 4: Inicio de la conexión con éxito
Después de que Don Pepito haya podido autenticarse con éxito a través del Acceso Fácil (Easy Access) o de la contraseña, se inicia la conexión.
Don Pepito está ahora hablando directamente con Doña Josefa. Y con esto, tenemos una conexión establecida con éxito. A continuación se muestra un ejemplo de cómo se ve esta conexión exitosa en el archivo de registro:
CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Don Pepito CPersistentParticipantManager::AddParticipant: [222222222,-987654321] type=6 name=Doña Josefa CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Don Pepito
Etapa 5: Fin de la conexión
En cualquier momento, Doña Josefa o Don Pepito pueden terminar la conexión y cuando esta termina Don Pepito y Doña Josefa ya no pueden oírse. Si quieren volver a hablar, tienen que empezar de nuevo en la etapa 1.
👉A continuación se muestra un ejemplo de cómo se ve en el archivo de registro el Fin de Sesión de una conexión exitosa:
SessionManagerDesktop::SessionTerminate: removing session with TVSessionID = -123456789
En el caso de que Don Pepito no haya podido autenticarse con éxito a través del Acceso Fácil o de la contraseña, se rechaza por completo su intento de conexión. No ha habido ninguna conexión en absoluto.
👉A continuación se muestra un ejemplo de cómo se ve en el archivo de registro el Fin de Sesión de una conexión fallida :
SessionManagerDesktop::SessionTerminate: no session with ID=123456789, aborting logins
💡Sugerencia: Los IDs mostrados en el archivo de registro para TVSessionID e ID no son los IDs de TeamViewer sino el ID de la sesión individual - Estos no pueden ser usados para identificar a un contacto o dispositivo ni para conectarse con nadie.
Identificaciones utilizadas en este ejemplo
111111111 - ID de Don Pepito en TeamViewer
222222222 ID de Doña Josefa TeamViewer
123456789 - ID de sesión 1 (= sin ID de TeamViewer)
987654321 - ID de sesión 2 (= sin ID de TeamViewer)