LogMeIn_SecurityWhitepaper

LogMeIn Security: An In-Depth Look

Seguridad LogMeIn:Una mirada en profundidad

Seguridad LogMeIn: Una mirada en profundidad

Copyright © 2003-2013 LogMeIn, Inc. Todos los derechos reservados. 1

Índice

Axiomas de acceso remoto ....................................................................................................3

Arquitectura de LogMeIn ...................................................................................................... 5

Mecanismos de seguridad de LogMeIn ................................................................................... 7

Detección de intrusión ........................................................................................................ 15

Reenvío de datos ................................................................................................................ 21

NAT transversal de UDP ....................................................................................................... 22

Actualizaciones de software y seguridad de la puerta de enlace ............................................. 24

Conclusión ......................................................................................................................... 25



Autor Márton Anka, Jefe técnico ejecutivo, LogMeIn, Inc.

Resumen Este documento proporciona una mirada en profundidad de las

características de seguridad del producto de acceso remoto de

LogMeIn.com, LogMeIn. En LogMeIn pensamos que la seguridad

no tiene porqué ser un campo secreto, ni esperamos que nuestros

clientes acepten con los ojos cerrados nuestros puntos de vista

relacionados con características de seguridad importantes, como el

cifrado de extremo a extremo. Mediante la publicación de los

detalles sobre cómo funcionan los mecanismos de seguridad y la

forma en la que operan entre nuestros distintos productos, también

estamos invitando al público a que examine nuestros esfuerzos.

Público Este documento tiene un contenido técnico y está dirigido a

ingenieros o diseñadores de redes. La lectura de este documento

puede ayudarle a realizar los análisis de amenazas necesarios

antes de desplegar nuestro producto.

Terminología En la arquitectura de LogMeIn, existen tres entidades que

participan en cada sesión de acceso remoto. El “cliente” o

“usuario” es la persona o el software que accede a un recurso

remoto. El “host” o “servidor” es el ordenador al que se está

accediendo o el software del host de LogMeIn de dicho ordenador.

La “puerta de enlace” es el servicio de LogMeIn que actúa como

intermediario del tráfico entre el cliente y el host.

Conceptos

fundamentales de

diseño

LogMeIn se ha diseñado para permitir un acceso remoto seguro a

recursos importantes a través de una red que no es de confianza.

Durante el desarrollo del software, las consideraciones de

seguridad siempre prevalecieron sobre las consideraciones de

utilización.



Axiomas de acceso remoto

Todo puede ser un objetivo

Debido al aumento de las conexiones por banda ancha de Internet, cada día más ordenadores

están conectados de manera ininterrumpida. La mayoría de estos ordenadores los utilizan

usuarios que se conectan desde casa y que tienen vacíos de seguridad, como las

vulnerabilidades sin parches y la falta de contraseñas adecuadas.

Sin embargo, la mayor debilidad son los usuarios en sí. La penetración extremadamente rápida

de los denominados virus de correo electrónico ilustra la total falta de conciencia en los

referente a la seguridad y la ingenuidad de la mayoría de los usuarios de Internet. Los virus de

correo electrónico son archivos adjuntos al mensaje, más conocidos como caballos de Troya. Se

propagan tan rápido porque los usuarios, sorprendentemente, están dispuestos a violar una de

las reglas principales del manejo de contenido que no es de confianza. Si los propios usuarios

son responsables de la infección de sus ordenadores con troyanos, ¿cómo podemos fiarnos de

ellos para proteger adecuadamente sus sistemas contra ataques directos?

Incluso los administradores de red competentes pueden despistarse y olvidar instalar uno o dos

parches, lo cual supondría, en el peor de los casos, permitir que los piratas informáticos

ejecuten código arbitrario en los sistemas afectados. No hay nada que demuestre mejor este

hecho que la rápida propagación de los gusanos de Microsoft SQL Server en 2003. MSBlaster y

Slammer infectaron un gran número de ordenadores, generando un excesivo tráfico de red con

la ayuda de un número exponencial creciente de hosts infectados que los usuarios podían

percibir mediante un descenso en la velocidad de acceso a Internet, incluso en redes que no

estaban en peligro.

Los gusanos como MSBlaster o Slammer no eran muy complejos. Su velocidad de propagación

estaba muy lejos de ser perfecta y, por lo tanto, no causaron ningún tipo de pérdida o robo de

datos importante. Sus creadores explotaron una vulnerabilidad ampliamente conocida de

Microsoft SQL Server, cuya solución estuvo disponible unas cuantas semanas después del primer

ataque de gusano. Esto quiere decir que se pueden calificar como una broma de muy mal gusto,



que sin duda causó innumerables problemas, pero cuyo efecto no fue ni mucho menos tan

desastroso como podría haber sido. Sólo nos queda imaginarnos lo que pueden hacer piratas

informáticos expertos con malas intenciones cuando tienen un objetivo lucrativo.

Acceso remoto y seguridad

Es fácil observar que la mayoría de los ordenadores conectados a Internet son extremadamente

vulnerables, incluso sin la instalación de un producto de acceso remoto. Los productos de

acceso remoto se perciben como factores de alto riesgo, pero principalmente por motivos

psicológicos. Cuando un usuario observa una solución de acceso remoto en acción, su primera

reacción negativa está relacionada normalmente con las implicaciones de seguridad. Esto es

completamente normal y, de hecho, es lo ideal. El verdadero problema es que los usuarios no

observan inmediatamente la amenaza inherente en otras aplicaciones de red como un cliente de

correo electrónico, un servidor web o el sistema operativo en sí.

Todos los sistemas operativos modernos incluyen de forma predeterminada algún tipo de

solución de acceso remoto. Windows, por ejemplo, incluyen Escritorio remoto de Microsoft como

una sencilla interfaz de administración remota. Incluso OpenBSD, la variante de Unix, que

normalmente está considerado como el sistema operativo más seguro que existe, incluye SSH,

que, una vez más, es una aplicación sencilla y segura que permite un acceso de línea de

comandos al ordenador remoto.

Básicamente, una solución de acceso remoto bien configurada y correctamente elegida no

conlleva ningún riesgo adicional. Si un administrador de red puede mantener una red segura

utilizando un paquete de software de acceso remoto fiable como LogMeIn, se aumenta la

productividad y se reducen los costes sin que esto tenga ningún efecto negativo en la seguridad

de la red.



Arquitectura de LogMeIn Antes de explicar los mecanismos de seguridad exactos que se utilizan en LogMeIn, es necesario

proporcionar una breve introducción a la arquitectura de soluciones.

Existen tres componentes clave en cualquier sesión de acceso remoto. Los roles del cliente y del

host deben ser sencillos; el tercer componente es la puerta de enlace de LogMeIn.

Figura 1. Arquitectura de LogMeIn

El host de LogMeIn que aparece en la figura 1 mantiene una conexión continua protegida por

SSL con uno de los servidores de puerta de enlace de LogMeIn en uno de nuestros centros de

datos físicamente protegido. El vínculo se inicia a través del host y el firewall lo considera una

conexión saliente, como tráfico de exploración web protegido.



El navegador del cliente establece una conexión a LogMeIn y se autentica. En función de la

identidad del cliente. se le autoriza el intercambio de datos con uno o más host (los host

correspondientes a la cuenta del usuario). A continuación, la puerta de enlace reenvía el

siguiente tráfico cifrado entre el cliente y el host. Hay que destacar que el cliente tendrá que

autenticarse también en el host; la puerta de enlace es el intermediario del tráfico entre las dos

entidades, pero no necesita que el host confíe en el cliente de forma implícita. Una vez que el

host ha verificado la identidad del cliente y autorizado el acceso al ordenador, se inicia la

verdadera sesión de acceso remoto.

La ventaja de utilizar la puerta de enlace, en lugar de establecer un vínculo directo entre el

cliente y el host, es que uno de estos dos, o ambos, pueden tener configurado un firewall. La

puerta de enlace de LogMeIn garantiza que el usuario no necesite configurar ningún firewall.



Mecanismos de seguridad de LogMeIn Cuando los usuarios piensan en la seguridad de los datos de Internet, normalmente se

preocupan sobre el cifrado de datos, hasta el punto en el que la seguridad se calcula sobre la

longitud de la clave de cifrado utilizada. Sin embargo, el cifrado y descifrado, aunque son muy

importantes, son tareas un tanto triviales en comparación con los otros retos a los que se

enfrentan los diseñadores de sistemas seguros. Como podrá observar, el cifrado de datos es sólo

uno de los objetivos principales establecidos por los diseñadores de LogMeIn.

Autenticación de la puerta de enlace en el cliente

En primer lugar, cuando un usuario se conecta a una instalación de LogMeIn a través de una

puerta de enlace (el “servidor”), debe estar completamente seguro de que el ordenador con el

que va a realizar el intercambio de datos es realmente el equipo al que desea conectarse.

Supongamos que un pirata informático imita el servidor ante el usuario e imita al usuario ante

el servidor. El pirata informático, en este caso, puede situarse entre las dos partes mientras

consulta o, posiblemente, modifica los datos que se están transmitiendo. Esto se conoce como

“intrusión” o ataque MITM, del cual es muy difícil protegerse.

LogMeIn utiliza certificados SSL/TLS para verificar las identidades del servidor y, por lo tanto,

proporcionar protección ante los ataques MITM. Cuando se realiza una conexión, se verifica el

certificado del servidor. Si el certificado no ha sido emitido por una autoridad de certificación en

la que confía el usuario, aparecerá una advertencia. Si el certificado ha sido emitido por una

autoridad de certificación de confianza, pero el nombre del host en la dirección URL no coincide

con el nombre del host incluido en el certificado, aparecerá una advertencia diferente.

Si el servidor acepta estas verificaciones, el navegador del usuario genera una “clave maestra” o

PMS, la cifra en la clave pública del servidor incluida en su certificado y la envía al servidor.

Asegurada por la criptografía de claves públicas, sólo el servidor que incluya esa clave privada

correspondiente podrá descifrar la clave PMS. El usuario y el servidor utilizarán la clave PMS



para derivar la clave secreta, que a su vez, se utilizará para derivar los vectores de inicialización

y las claves de sesión para la duración de la sesión segura.

En poco tiempo, todo lo anterior asegurará que el usuario está estableciendo una conexión con

el servidor y no con una tercera entidad. Si se intenta un ataque MITM, se disparará una de las

advertencias de seguridad o la clave PMS será desconocida para el ataque MITM, haciendo el

ataque imposible.

(Lectura recomendada: SSL and TLS: Designing and Building Secure Systems (SSL y TLS: Diseño y

creación de sistemas seguros) por Eric A. Rescorla)

Autenticación de usuarios en la puerta de enlace

Los usuarios de LogMeIn se deben autenticar en la puerta de enlace y en el host. Cuando un

usuario se conecta al sitio web de LogMeIn, se realiza una verificación de dirección de correo

electrónico y contraseña. A los usuarios también se les recomienda activar una o varias

funciones de seguridad adicionales de LogMeIn para reforzar este paso de autenticación.



Figura 2. Autenticación entre los usuarios y la puerta de enlace



Códigos de seguridad impresos

Una de las funciones de seguridad adicionales en una hoja de códigos de seguridad impresos.

Cuando el usuario activa esta función, se le solicitará que imprima una lista de las contraseñas

de nueve caracteres aleatorios generadas por la puerta de enlace. Cada vez que un usuario de

LogMeIn inicie sesión en su cuenta en www.LogMeIn.com se le pedirá que introduzca uno de los

códigos de seguridad de la lista antes de poder acceder a su cuenta. Cada código podrá

utilizarse una sola vez. Antes de que el usuario agote todos los códigos de seguridad impresos,

se le solicitará que imprima otra página. Esto invalida los códigos de seguridad anteriores que

no habían sido utilizados.

Cómo habilitar los códigos de seguridad impresos

1 Inicie sesión en su cuenta de LogMeIn.

2 Haga clic en Cuenta en la esquina superior derecha.

3 En la ficha Seguridad, seleccione la opción Código de seguridad impreso.

4 Genere e imprima una lista de códigos de seguridad.

5 Haga clic en Guardar.

Códigos de seguridad enviados por correo electrónico

Otra forma de proteger su cuenta de LogMeIn es utilizar la función Código de seguridad enviado

por e-mail. Cada vez que inicie sesión en su cuenta en LogMeIn.com se le enviará un correo

electrónico con un código de seguridad que debe introducir en el cuadro de diálogo adecuado

para acceder a su cuenta. Cada código podrá utilizarse una sola vez.

Para poder utilizar esta tecnología, el destinatario del código de seguridad deberá utilizar un

dispositivo inalámbrico. Cuando se active esta característica y el usuario se autentique

correctamente con su dirección de correo electrónico y contraseña en la puerta de enlace de

LogMeIn, se generará una código de acceso y se enviará a la dirección de correo electrónico

inalámbrica. El usuario recibirá este código de acceso en un correo electrónico y lo introducirá

en la página proporcionada por la puerta de enlace, probando de esta forma que es el



propietario del dispositivo. Esta contraseña caducará unos cuantos minutos después de haber

sido generada, o bien, después de utilizarla, lo que ocurra antes.

Cómo habilitar los códigos de seguridad enviados por correo electrónico



3 En la ficha Seguridad, seleccione la opción Código de seguridad enviado por e-mail.

4 Introduzca su dirección de correo electrónico en el campo correspondiente.


Control de cuentas

Utilice la función Control de cuentas para llevar un seguimiento de la actividad de su cuenta de

LogMeIn. Seleccione los sucesos por los que quiere recibir una notificación automática por

correo electrónico como errores al intentar iniciar sesión o cambios de contraseña. Las

notificaciones se enviarán a las direcciones de correo electrónico especificadas (para múltiples

destinatarios, separe las direcciones de correo electrónico con punto y coma). Tenga en cuenta

que algunos de los sucesos de cuenta más importantes están activados de forma

predeterminada y no se pueden deshabilitar.

Cómo habilitar la función de control de cuentas



3 En la ficha Seguridad, bajo Control de cuentas, introduzca su dirección de correo electrónico en el campo correspondiente.

4 Seleccione los sucesos sobre los cuales desea recibir notificación automática por correo electrónico.




Autenticación de la puerta de enlace en el host

La puerta de enlace debe probar su identidad en el host antes de que se le confíen los códigos

de acceso. El host, cuando realiza una conexión a la puerta de enlace, comprueba su certificado

SSL para asegurarse de que se está conectando a uno de los servidores de puerta de enlace de

LogMeIn. Este proceso es muy similar a la forma en que la puerta de enlace autentica un cliente.

Autenticación del host en la puerta de enlace

La puerta de enlace verifica la identidad del host cuando acepta una conexión entrante que

utiliza una cadena larga de identificador único. Esta cadena es una clave compartida entre las

dos entidades y es emitida por la puerta de enlace cuando se instala el host. Este identificador

único sólo se comunica en un canal protegido por SSL y únicamente después de que el host

haya verificado la identidad de la puerta de enlace. La figura 3 ilustra la forma en la que el host

y la puerta de enlace se autentican entre sí antes de que un host pueda acceder al cliente.



Figura 3. Autenticación del host y la puerta de enlace



Cifrado de datos

El estándar SSL/TLS define una amplia elección de conjuntos de cifrado como RC4 y 3DES, y

algunas implementaciones proporcionan conjuntos más avanzados que también incluyen AES.

RC4 funciona en claves de 128 bits y 3DES utiliza claves de 168 bits. AES puede utilizar claves de

128 ó 256 bits. El cliente y el host acuerdan utilizar el cifrado más potente posible. Esto se realiza

por parte del cliente, que envía al host una lista de los cifrados que desea utilizar y el host

selecciona el que prefiera de la lista.

El estándar SSL/TLS no define la forma en la que el host debe seleccionar el cifrado final. En

LogMeIn, el host sólo selecciona el conjunto de cifrado más potente posible que el cliente ha

proporcionado.

Este método permite tanto al cliente como al host rechazar el uso de algoritmos de cifrado de

datos específicos sin necesidad de actualizar ambos componentes, yen el caso de que el

algoritmo esté roto o no sea seguro según lo evaluado.



Detección de intrusión

LogMeIn proporciona dos niveles para detectar los intentos de intrusión: SSL/TLS y Filtros de

intrusión de LogMeIn.

SSL/TLS

El primer nivel de detección de intrusión lo proporciona SSL/TLS para asegurarse de que los

datos no han cambiado durante la transmisión. Esto se consigue a través de las técnicas

siguientes:

Numeración de secuencia de

registro

Numeración de secuencia de registro significa que el remitente

numera los registros SSL/TLS y el destinatario comprueba la

solicitud. De esta forma se asegura que un pirata informático

no pueda eliminar ni insertar registros arbitrarios en el flujo de

datos.

Códigos de autenticación de

mensajes

Se agregan códigos de autenticación de mensajes (MAC) a cada

registro SSL/TLS. Esto proviene de la clave de sesión (que sólo

conocen las dos partes que se están comunicando) y de los

datos contenidos en el registro. Si falla una verificación de

MAC, se supone que los datos se modificaron durante la

transmisión.

Encadenamiento de bloques

de cifrado

El conjunto de cifrado preferido por LogMeIn también utiliza el

encadenamiento de bloques de cifrado (modo CBC), lo que

significa que cada registro SSL/TLS dependerá del contenido del

registro anterior. De este modo, la introducción al cifrado no

sólo está formada por el registro de texto plano actual, sino que

también incluye el anterior. Esto, una vez más, asegura que los

paquetes no se puedan insertar ni eliminar del flujo de datos.



Para obtener más información sobre la detección de intrusión SSL/TLS, consulte SSL and TLS:

Designing and Building Secure Systems (SSL y TLS: Diseño y creación de sistemas seguros) por

Eric A. Rescorla

Filtros de intrusión de LogMeIn

El segundo nivel está proporcionado por LogMeIn en sí y está compuesto por tres filtros de

intrusión.

Filtro de dirección IP

Cuando LogMeIn recibe una solicitud de conexión de un cliente, en primer lugar, comprueba su

lista de direcciones IP que son o no de confianza y posiblemente deniega la conexión. Un

administrador puede configurar una lista de direcciones IP en LogMeIn permitidas o denegadas

para establecer una conexión al host seleccionado (por ejemplo, puede designar la red interna y

la dirección IP doméstica del administrador como direcciones permitidas)

Filtro de denegación de servicio

Un filtro de denegación de servicio rechaza las conexiones si la dirección IP de la que proviene

la solicitud ha creado un número excesivo de solicitudes sin autenticación en la ventana de

tiempo de observación. Esto se realiza para evitar que algún usuario sobrecargue el ordenador

host mediante, por ejemplo, la solicitud automática y muy rápida de la página de conexión una

y otra vez.

Filtro de autenticación

Si el usuario ha realizado un número excesivo de intentos de conexión fallidos, el filtro de

autenticación rechaza la conexión. El filtro de autenticación se coloca para evitar que un intruso

potencial adivine un nombre de cuenta y su contraseña.



Cómo definir filtros en un host de LogMeIn

1 Acceda a las preferencias del host desde el host o el cliente:

Desde el host, abra LogMeIn y siga la siguiente ruta de acceso: Opciones > Preferencias > Seguridad

Desde el cliente, conéctese al Menú principal del host y siga la siguiente ruta de acceso: Preferencias > Seguridad

2 En Control de intrusiones, haga clic en Editar perfiles para comenzar a crear un perfil de filtro.

Para obtener más información, consulte las guías de usuario de LogMeIn Pro, Free o

Central.

Autenticación y autorización de usuarios en el host

Cuando se haya otorgado el acceso mediante los niveles anteriores, el usuario tendrá que

probar su identidad en el host. Esto se consigue mediante un paso de autenticación obligatorio

a nivel de sistema operativo.

El usuario debe autenticarse en el host utilizando su nombre de usuario y contraseña estándar

de Windows o Mac. El host normalmente transfiere esta solicitud al controlador de dominio

relevante. Este paso no sólo valida la identidad del usuario, sino que también asegura que los

administradores de red puedan controlar quién puede conectarse a un host específico.

Contraseña personal

contraseña personal es otra medida de seguridad opcional que se puede configurar en el host

de LogMeIn. El usuario puede asignar una contraseña personal al host que, al igual que la

contraseña del sistema operativo, no se almacena ni verifica en la puerta de enlace. Una

diferencia entre la contraseña del sistema operativo y la contraseña personal es que el host

nunca solicita la contraseña personal completa, por lo que el usuario nunca la introduce en su

totalidad en cada sesión de autenticación. Normalmente, el host solicita al usuario que

introduzca tres dígitos aleatorios de su contraseña personal después de que la autenticación del

https://secure.logmein.com/r.asp?r=manual_pro2

https://secure.logmein.com/r.asp?r=manual_free

https://secure.logmein.com/r.asp?r=LogMeInCentral_UserGuide



sistema operativo se haya realizado correctamente. Si el usuario introduce los dígitos correctos

(por ejemplo, el primero, el cuarto y el séptimo), se le otorgará el acceso.

Cómo definir una contraseña personal

1 Acceda a las preferencias del host desde el host o el cliente:

Desde el host, abra LogMeIn y siga la siguiente ruta de acceso: Opciones > Preferencias > Seguridad

Desde el cliente, conéctese al Menú principal del host y siga la siguiente ruta de acceso: Preferencias > Seguridad

2 En Contraseña personal, escriba su contraseña personal y vuelva a escribirla para confirmarla.

3 Haga clic en Aplicar.

LogMeIn y RSA SecurID

Para añadir un nivel adicional de seguridad superior a la sencilla autenticación por nombre de

usuario y contraseña, puede configurar LogMeIn Pro y LogMeIn Free para que sea necesaria la

autenticación de RSA SecurID. RemotelyAnywhere, el producto que utilizó por primera vez la

tecnología de LogMeIn, ha sido certificado como SecurID Ready por RSA Security en 2003. Desde

entonces, LogMeIn ha seguido manteniendo el alto nivel de seguridad correspondiente a la

tecnología RSA.

Para obtener más información sobre el producto RSA SecurID, visite www.rsa.com (en

inglés). Para obtener más información sobre cómo configurar esta función en el host

de LogMeIn Pro o LogMeIn Free, visite la Base de conocimientos de LogMeIn.

http://www.rsa.com/

https://logmeinsupport.com/kblive/crm/selfservice/displaywh.jsp?DocId=2498&SecMode=1



Figura 4. Autenticación entre los usuarios y el host

Autenticación y autorización de usuarios en el host

Una vez que LogMeIn ha verificado la identidad del usuario utilizando los métodos anteriores,

comprueba su propia base de datos de usuarios interna para comprobar los módulos internos a

los que el usuario puede acceder.

Los administradores del sistema pueden configurar LogMeIn para que los usuarios con algunos

roles tengan acceso a un subconjunto de herramientas proporcionadas por LogMeIn; por

ejemplo, el departamento de Atención al cliente puede configurarse para que sólo se pueda

visualizar la pantalla del ordenador y los datos de rendimiento, pero en realidad no se pueda

realizar ninguna acción con el ratón ni el teclado ni realizar cambios a la configuración del

sistema. Mientras tanto, el departamento de ventas puede otorgar acceso remoto completo a sus



respectivos ordenadores, pero características como el control del rendimiento o la

administración remota no estarán disponibles a los usuarios.

Al utilizar el código de acceso del sistema operativo obtenido al autenticar el usuario, LogMeIn

suplanta al usuario en el sistema operativo y realiza todas las acciones en su nombre. De esta

forma se asegura de que LogMeIn se adhiere al modelo de seguridad del sistema operativo y los

usuarios tienen acceso a los mismos archivos y recursos de red que si estuvieran delante de su

ordenador. Los recursos no disponibles para los usuarios en Windows o OS X siguen sin estar

disponibles a través de LogMeIn.

Consulte “Controlar quién puede acceder a sus ordenadores host (Control de acceso

del usuario)” en la Guía de usuario de LogMeIn Pro.

Auditoría y registro

LogMeIn proporciona unas amplias capacidades de registro. En el directorio de instalación se

guarda un registro detallado de los sucesos que se producen en el software. Los sucesos más

importantes también se colocan en el registro de sucesos de la aplicación de Windows. Estos

sucesos incluyen, por ejemplo, la acciones de conexión y desconexión. También se puede enviar

un registro detallado a un servidor SYSLOG central.

Para obtener más información, consulte "Cómo ver los archivos de registro de sucesos de

LogMeIn" en la Guía del usuario de LogMeIn Pro

Para obtener más información sobre SYSLOG, consulte "Deployable Host Preferences for Logs

and Session Recording” (Preferencias de host desplegables para registros y grabación de

sesiones) en la Guía de usuario de LogMeIn Central (en inglés).

https://secure.logmein.com/r.asp?r=manual_pro

https://secure.logmein.com/r.asp?r=manual_pro

https://secure.logmein.com/r.asp?r=LogMeInCentral_UserGuide



Reenvío de datos

La puerta de enlace proporciona cifrado de extremo a extremo mediante el reenvío de datos

cifrados entre el host y el cliente. Si está familiarizado con el funcionamiento de SSL, esto puede

resultarle imposible; después de todo, la suposición es que, ya que el cliente está seguro de que

se está comunicando con la puerta de enlace, solamente la puerta de enlace puede descifrar los

datos enviados por el cliente. Este es un punto completamente válido, pero LogMeIn ha

realizado importantes cambios en la forma en la que las sesiones SSL tienen lugar entre el host

y la puerta de enlace.

La primera parte de la negociación SSL se realiza entre la puerta de enlace y el cliente. A

continuación, la puerta de enlace transfiere el intercambio al host, el cual vuelve a negociar la

sesión SSL y acuerda una nueva clave de sesión con el cliente, proporcionando así un verdadero

cifrado de extremo a extremo.

Un ataque MITM es imposible, ya que tanto el host como el cliente verifican el certificado de la

puerta de enlace y el cliente utiliza la clave RSA pública para cifrar la información que se utiliza

para proporcionar la clave maestra SSL/TLS.



NAT transversal de UDP

Es importante explicar cómo se usa NAT transversal de UDP, especialmente porque el protocolo

UDP es considerado muy poco seguro. Esta afirmación no es completamente incierta. Si UDP se

utiliza como un medio de comunicación, la seguridad puede ser un problema grave, ya que los

datagramas de UDP son fáciles de olvidar y la dirección IP del remitente se puede imitar.

Para contrarrestar esto, LogMeIn.com no utiliza UDP como medio de comunicación en sí con las

conexiones NAT transversal de UDP. UDP se relega al nivel de red como se define en el modelo

de red ISO/OSI, con un nivel de trasporte de tipo TCP creado en su parte superior y completado

con control de flujo, escalado de banda ancha dinámica y numeración de secuencias de

paquete.

LogMeIn.com utiliza UDP en lugar de paquetes TCP (y, así, vuelve a implementar de forma

efectiva un nivel de transporte de tipo TCP) porque la mayoría de los firewalls y dispositivos NAT

permiten una comunicación bidireccional uniforme a través de un transporte UDP mientras ésta

se inicie desde el perímetro de seguridad, pero requieren una nueva configuración significativa

para los paquetes TCP e IP. Después de crear un flujo fiable de tipo TCP a partir de paquetes

UDP no fiables, el flujo se protege mediante un nivel SSL, proporcionando capacidades de

cifrado completo, protección de la integridad y verificación de extremos.

Para configurar una conexión de NAT transversal de UDP, tanto el cliente como el host envían

varios paquetes UDP cifrados a la puerta de enlace. Estos paquetes están cifrados mediante una

clave compartida por la puerta de enlace y el usuario correspondiente y se comunican a través

de una conexión SSL ya existente. Es imposible imitarlos.

La puerta de enlace utiliza estos paquetes para determinar las direcciones IP externas (Internet)

de las dos entidades. También intenta predecir el puerto del firewall que se utilizará para la

comunicación cuando se envía un nuevo paquete UDP. Transfiere sus descubrimientos a los

usuarios, los cuales intentarán configurar una conexión directa a continuación. La conexión se

produce si la puerta de enlace puede determinar el puerto en uso. Los usuarios se verifican



mutuamente utilizando otra clave compartida obtenida de la puerta de enlace. Se establece una

sesión SSL. A continuación, los usuarios se comunican directamente.

Si no se puede configurar una conexión directa, los usuarios se volverán a conectar a la puerta

de enlace mediante TCP y solicitarán que se utilice una sesión reenviada que esté cifrada de

extremo a extremo. Este proceso sólo tarda unos cuantos segundos y es totalmente visible para

el usuario. La única diferencia notoria es el rendimiento mejorado y la baja latencia cuando se

utiliza una conexión directa.

Para obtener más información, consulte la Patente número 7,558,862 de EE. UU (en inglés).

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7,558,862.PN.&OS=PN/7,558,862&RS=PN/7,558,862



Actualizaciones de software y seguridad de la puerta de enlace

El host de LogMeIn se puede actualizar mediante un proceso automático o semiautomático en el

ordenador del usuario de acuerdo a las preferencias de éste. El software del host comprueba

periódicamente el sitio web de LogMeIn.com para obtener versiones más recientes del software.

Si se encuentra una nueva versión, se descarga automáticamente y se muestra un mensaje al

usuario para que pueda permitir la actualización. El proceso de descarga sólo utiliza como

máximo un 50% del ancho de banda disponible, por lo que prácticamente no interfiere con

ninguna otra aplicación de red.

Estas actualizaciones de software están firmadas digitalmente por LogMeIn.com con una clave

privada que no se encuentra en ninguno de nuestros sistemas conectados a través de Internet.

Por lo tanto, incluso si piratas informáticos pusieran en peligro los centros de datos de LogMeIn

al controlar por completo nuestras puertas de enlace, no podrían cargar una actualización ni

ejecutar código binario en los ordenadores de nuestros clientes. Como mucho, lo único que

sucedería ante un ataque es que se accedería a la pantalla de conexión de LogMeIn de los

ordenadores de los clientes, así que, aunque se evitase eficazmente los mecanismos de

seguridad de la puerta de enlace, aún se necesitaría la introducción de las credenciales válidas

del sistema operativo para poder acceder al equipo. El forzado de contraseñas es inviable, ya

que el filtro de autenticación bloquea de forma predeterminada la dirección IP del usuario tras

la introducción de varias contraseñas incorrectas.

En caso de que nuestros clientes utilicen la misma contraseña para la puerta de enlace LogMeIn

y su ordenador, las contraseñas reales de LogMeIn no se almacenan en nuestra base de datos;

utilizamos un hash criptográfico de una sola dirección y un valor inicial aleatorio que no se

pueden forzar con los recursos informáticos disponibles en la actualidad.



Conclusión Una solución de acceso remoto bien diseñada puede aumentar la productividad en gran medida

y proporcionar una rápida rentabilidad. Cuando se realiza un despliegue con cuidado y se

utilizan las características de seguridad opcionales de LogMeIn, las ventajas son mayores que

los riesgos.

Referencias

SSL and TLS: Designing and Building Secure Systems (SSL y TLS: Diseño y creación de sistemas seguros) por Eric A. Rescorla, Addison-Wesley Pub Co, 2001. ISBN: 0-201-61598-3

SSH, The Secure Shell: The Definitive Guide (SSH, la estructura segura: Guía definitiva) por Daniel J. Barrett, Ph. D., Richard E. Silverman y Robert G. Byrnes, O’Reilly & Associates, 2001. ISBN: 0-596-00011-1

RSA Security’s SecurID Product (SecurID de RSA Security): http://www.rsa.com/node.aspx?id=1156

Soporte y documentación de LogMeIn: https://secure.logmein.com/support/

http://www.rsa.com/node.aspx?id=1156

https://secure.logmein.com/support/

LogMeIn_SecurityWhitepaper

Documents

Transcript of LogMeIn_SecurityWhitepaper