Check the presence of the OpenSSL's bug Heartbleed (CVE-2014-0160)

What is it?

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

What leaks in practice?

We have tested some of our own services from attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.

How to stop the leak?

As long as the vulnerable version of OpenSSL is in use it can be abused. Fixed OpenSSL has been released and now it has to be deployed. Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users. Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use.

How to check if my server (https) or application (linked with OpenSSL library) has it?

For your web server Heartbleed test site and specify the hostname (or IP address) and port of your HTTPS server

For your Android’s mobile apps, install Bluebox Heartbleed Scanner and run it, it will check for any vulnerable apps installed on your phone.

Resources

Agilizar las conexiones con SSH

Introducción.

Revisando información acerca del protocolo SSH encontré en el Wiki de ArchLinux unos tips muy interesantes para agilizar las conexiones con los servidores remotos.  A continuación incluyo una reseña de estas sugerencias.

Limitar los algoritmos de cifrado.

No estoy muy seguro cuan buena opción en términos de seguridad sea hacer esto sin embargo es una opción.  La idea es limitar los algoritmos que usa el protocolo para utilizar sólo aquellos que demandan menos recursos de CPU y por ende son mas rápidos.  En este caso se sugiere utilizar ArcFour y Blowfish-CBC.

Para hacer esto en la conexión actual únicamente se debe realizar la conexión de la siguiente manera.

$ ssh -c arcfour,blowfish-cbc usuario@servidor

Si se desea realizar este cambio permanentemente es necesario modificar la configuración del cliente SSH.

$ sudo vi /etc/ssh/ssh_config

Ciphers arcfour,blowfish-cbc

Activar la compresión.

Para hacer esto en la conexión actual únicamente se debe realizar la conexión de la siguiente manera.

$ ssh -C usuario@servidor

Si se desea realizar este cambio permanentemente es necesario modificar la configuración del cliente SSH.

$ sudo vi /etc/ssh/ssh_config

Compression yes

Desactivar la comprobación de IPV6.

Para hacer esto en la conexión actual únicamente se debe realizar la conexión de la siguiente manera.

$ ssh -4 usuario@servidor

Si se desea realizar este cambio permanentemente es necesario modificar la configuración del cliente SSH.

$ sudo vi /etc/ssh/ssh_config

AddressFamily inet

Mantener viva la conexión.

Cuando se trabaja con varias sesiones remotas es frecuente que estas se desactiven por falta de uso (timeout) lo cual es bastante molesto ya que es necesario volver a conectar para continuar con el trabajo.  Esto sucede por razones de seguridad ya que intenta bloquear las conexiones que han sido abiertas y probablemente han sido abandonadas y así impedir que personas no autorizadas puedan acceder al shell, así como optimizar los recursos utilizados por parte de los usuarios.

La idea en este caso es configurar las conexiones de forma que se adecúen a los tiempos de espera que se presentan en el uso del administrador.  En mi caso utilizo los siguientes valores.

$ sudo vi /etc/ssh/ssh_config

ServerAliveInterval 60
ServerAliveCountMax 10

El primer valor  (ServerAliveInterval) le indica al cliente que envíe cada cierto tiempo (magnitud en segundos) paquetes al servidor para indicarle que la conexión continúa con vida.  El segundo valor (ServerAliveCountMax) indica el número de mensajes de vida que pueden ser enviados por el cliente sin recibir respuesta del servidor antes de abortar la comunicación automáticamente.

Crear alias para los servidores.

Esta opción es muy practica cuando se deben realizar conexiones con múltiples servidores y cada una de ellas con características muy específicas, permite establecer parámetros de conexión determinados y nombrarlos bajo un alias para permitir realizar conexiones rápidas con ellos.

La información de los alias de las conexiones es independiente para cada uno de los usuarios del sistema.  Es posible utilizar las opciones válidas del archivo /etc/ssh/ssh_config para establecer los parámetros de configuración de cada una de las conexiones.

$ vi ~/.ssh/config

Host servidor1
HostName 123.123.123.123
Port 12345
User jimezam
Host servidorweb
HostName mi.servidorweb.com
User jimezam
CheckHostIP no
Cipher blowfish

Una vez que se han establecido los alias es posible realizar las conexiones SSH referenciándolos.

$ ssh servidorweb

Crear las sesiones SSH a través de una única conexión.

Esta es la sugerencia que mas me pareció interesante ya que hasta el momento no la conocía.  Permite indicarle al cliente de SSH que envíe las sesiones a través de una única conexión, es decir, la primera vez que se realiza una sesión con un servidor y un usuario específicos el procedimiento de conexión se realiza normalmente, sin embargo las sesiones siguientes en iguales condiciones reutilizan la conexión vigente así que ya no es necesario realizar la autenticación de nuevo.

La configuración de esta opción puede realizarse en el archivo /etc/ssh/ssh_config si se desea que aplique a todos los usuarios del sistema o en ~/.ssh/config si se desea que sólo aplique a un usuario específico.

ControlMaster auto
ControlPath ~/.ssh/socket-%r@%h:%p

Enlaces.