The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

Archive for April, 2014

Tails, un sistema operativo para no dejar huellas basado en Debian

 
 La privacidad en Internet es uno de los aspectos más valiosos en la actualidad. Después de los sucesos ocurridos con la NSA, ha tomado una importancia mucho mayor. En esta ocasión, les presentamos Tails, un sistema operativo construido pensando en, justamente, no dejar huellas.

Al hablar de Tails (siglas de The Amnestic Incognito Live System) resuenan dos palabras:amnesia e incógnito. Basado en Debian, este sistema operativo se encuentra preparado para proveer al usuario una experiencia anónima, que prácticamente no dejará rastros visibles. De acuerdo a Wired, tanto Edward Snowden como Glenn Greenwald lo utilizaron para llevar a cabo sus tan conocidos intercambios de información acerca de la NSA.

Radiografía de Tails

Su funcionamiento es simple: mediante un Live CD o un dispositivo USB puede ejecutarse en cualquier computadora y utilizarse como cualquier otro sistema operativo, sin llevar a cabo una instalación. Al reiniciar el equipo, todo volverá a la normalidad.

A continuación, enumeramos algunas de sus características principales:

  • Todas las conexiones a internet están configuradas para llevarse a cabo utilizando Tor (un servicio que permite conectarse a Internet de forma prácticamente anónima). Diseñado en principio por el U.S. Naval Research Laboratory, este proyecto ha tomado bastante repercusión en la actualidad. De aquí viene la palabra incógnitopresente en Tails.
  • Bloqueo de conexiones automáticas por aplicaciones. Si una aplicación intenta conectarse de forma automática, esa conexión será bloqueada por seguridad.
  • Utiliza únicamente la memoria RAM de la computadora anfitriona. De esta forma, hace imposible que mediante un análisis forense del disco rígido de la computadora se pueda llegar a los datos manipulados. De aquí la palabra amnesia.
  • Permite eliminar archivos de forma segura. Utilizando Nautilus Wipe, verifica que los datos eliminados sean quitados de memoria.
  • Las conversaciones de mensajería instantánea se llevan a cabo de forma cifrada. Para lograr esto, se utiliza OTR, un protocolo que lo hace posible.
  • Prioriza la comunicación HTTPS. Para lograrlo utiliza HTTPS Everywhere, un pluginpara el navegador Firefox.
  • Demás herramientas criptográficas, como por ejemplo cifrado de dispositivos USB conLUKS (el estándar de Linux para llevar a cabo dicha tarea) o de correos y documentos utiliando OpenPGP.

Actualmente Tails se encuentra en la versión 0.23 de forma estable, pero la 1.0 ya se encuentra en estado de release candidate y está en etapa de pruebas.

Más allá de la gran cantidad de herramientas y de su diseño orientado a no dejar rastros, es importante aclarar que la transparencia en la interacción del usuario dependerá justamente de él. Un usuario que no tome recaudos y que se exponga de forma deliberada no quedará exento de que sus acciones pasen apercibidas.

Créditos imagen: ©mikebaird/Flickr
 

El post Tails, un sistema operativo para no dejar huellas basado en Debian aparece primero enWe Live Security en Español.

 
 

El grave fallo de seguridad en GnuTLS (y II)

En un artículo anterior ya hablamos del origen y de las consecuencias para la seguridad del fallo en la librería GnuTLS, ahora nos centraremos en la forma de solucionarlo centrándonos en las distintas estrategias en función de la situación en la que se encuentre nuestra distribución.

 

¿Qué es más seguro el software libre o el privativo?

Esta es una eterna pregunta eterna, que a lo largo de la historia, ha provocado encarnizadas discusiones en los foros más diversos, pero para no entrar en la polémica, no consideraremos el hecho de que en el caso del software libre el código fuente está disponible. Creo que es evidente, tras los sonados fallos de seguridad recientes, que la disponibilidad del código fuente no ha ayudado mucho a evitarlos, es más, considero que sin herramientas automatizadas como las que proporciona Coverity, es complicado auditar miles de líneas de código fuente. Por ello creo que hay que avanzar en este tipo de herramientas y al mismo tiempo, mejorar las pruebas que se realizan del código.

Si atendemos a las estadísticas de fallos detectados en el código fuente, como índice de la calidad y/o seguridad del software, creo que la mejor referencia es el Informe anual de Coverity 2013 [PDF]. Si tenemos en cuenta que el estándar de la industria del software para considerar que un programa tiene calidad suficiente, es de menos de 1 fallo por cada 1.000 líneas de código, hemos de decir, que tanto el software libre, como el software privativo, pasan ampliamente el corte, con una densidad media de 0,59 para el caso del software libre y de 0,72 para el software privativo, como vemos, unos datos relativamente similares y mejores que el estándar. Aunque hay proyectos de software libre, como Python, que destacan de forma notable sobre la media, con una densidad de fallos de solamente 0,005.

Sin embargo, creo que es justo decir que las empresas de software privativo han hecho un gran esfuerzo en los últimos años, al pasar de una densidad de 20 a 30 errores por cada 1.000 líneas de código que presentaban 2006, a los muy aceptables 0,72 de media de la actualidad. Hay que destacar, que esas mismas fechas el software libre presentaba una densidad de solamente 0.434 errores.

Pero ¿cuál es el motivo por el que ha aumentado el índice de fallos en el software libre y ha disminuido tan notablemente el del software privativo?. Creo que el problema está en el aumento de las líneas de código de los proyectos, algo que ocurre casi inevitablemente al madurar los mismos y aumentar las prestaciones de librerías y programas. El software libre, por su modelo de desarrollo distribuido y mayores dificultades para auditar el software, es muy propenso a que aumenten los fallos cuando aumentan las líneas de código si no se establecen estrategias adecuadas para evitarlo.

Lo que sí es cierto, es que normalmente, cuando son detectados, los fallos se reparan más rápidamente en el caso del software libre, algo que también se refleja en el informe. Este hecho fue evidente con los fallos de seguridad detectados durante el concurso Pwn2own, durante el que fueron hackeados los principales navegadores del mercado. En este caso, con un concurso que se llevó a cabo entre los días 12 y 13 de marzo de 2014, la versión de Mozilla Firefox que solucionaba los problemas detectados, la 28.0, ya se podía descargar de los servidores de Mozilla el día 18 de Marzo.

Pero este no es un caso aislado, esta rapidez en la resolución de fallos también fue detectada por Coverity en ediciones anteriores del informe, destacando el caso de Amanda (software libre para realizar copias de seguridad), que tras arrojar el mayor índice de fallos cuando se analizó el código, la comunidad de desarrolladores de dicha aplicación respondió rápidamente y en menos de una semana, se corrigieron todos los errores, pasando a ser el proyecto de software libre con menos errores de todos los revisados. Por lo tanto, si consideramos el tiempo de reacción dentro de la métrica, podemos decir que el software libre también es más seguro que el privativo.

Pero ¿qué ocurrió con GnuTLS?. Según los datos de Coverity, GnuTLS se comenzó a analizar con su herramienta Coverity Scan en abril de 2011, algo que se hizo regularmente hasta junio de 2011, pero pasó mucho tiempo sin auditorías, hasta la última, que se realizó el pasado día 17 de abril de 2014, posiblemente con un afán de mejorar el código tras el fallo “goto result”. Los datos de esta auditoría son estos:

Último análisis: 17 de abril de 2014
Líneas de código analizadas: 150.350
Densidad cada 1.000 líneas: 0,55

Cambios desde la comprobación del 10 de junio de 2011
Nuevos fallos detectados 73
Eliminados 366

Fallos en la versión actual:
Totales: 487
Pendientes: 82
Solucionados: 403

Como se puede ver, no son unos datos malos, de hecho, son mejores que la media del privativo del informe de Coverity, que para los proyectos en c y c++. de entre 100.000 y 500.000 líneas de código muestran una densidad de errores 0,81, pero peores para el software libre, que para ese mismo número de líneas, muestra una densidad de 0,50.

Aunque es complicado ver si los fallos remanentes de GnuTLS en este momento, como ocurrió con el “goto result”, son críticos o no para la funcionalidad y/o seguridad de la librería. De todos modos, creo que es sano realizar este tipo de auditorías del código de forma sistemática y evitar, como ocurrió con GnuTLS, el pasar varios años sin auditarlo de ninguna forma, puesto que como he indicado anteriormente, es complicado detectar fallos cuando crecen el número de líneas, o hay muchos desarrolladores en el proyecto.

 

Estrategia de actualización

Una vez que hemos tomado conciencia de que nuestro software es vulnerable, las dos vías son actualizar o parchear. Si nuestra distribución continua manteniendo soporte, la solución es sencilla, esperar que aparezca el paquete .dbm o .rpm correspondiente en los repositorios y actualizarlo lo antes posible. En este sentido, es muy recomendable considerar a la hora de elegir una distribución, el hacerlo sobre una LTS (Long Time Support), que como Ubuntu 14.04 LTS “Trusty Tahr”, que está previsto que tenga 5 años de soporte.

Si nuestra distribución ya no tiene soporte, lo más recomendable es actualizarse a una que sí lo tenga. Si hemos tenido la precaución de tener una partición /home, dicho proceso no debe ser demasiado traumático ya que nuestros datos no se deberían ver afectados si tenemos cuidado durante la instalación y elegimos las opciones correctas.

Sin embargo, puede que no nos interese o no podamos, por los motivos que sea, el proceder a la actualización de toda la distribución, en ese caso la única opción pasa por actualizar el paquete o modificarlo adecuadamente, opción que no tienen los usuarios de software privativo cuando pierden el soporte, ya que para actualizarlo/compilarlo o para parcherarlo en estas circunstancias, es imprescindible contar con el código fuente del mismo.

Podemos pensar que para actualizarlo/compilarlo, nos bastará con bajarnos la última versión de la librería del repositorio correspondiente y usar la secuencia de mandatos:

./configure
make
make test
make install

Dicha secuencia es posible que nos sirva en muchos casos, puede que en la gran mayoría, pero tiene sus riesgos que debemos evaluar. Por ejemplo, si cogemos la última versión de OpenSSL, es decir, la 1.0.1g y usamos los mandatos anteriores para instalarla en una Mandriva 2010 (Mandriva usa la OpenSSL 0.9.8 de 25 Mar 2009 y no está afectada por el fallo “Heartbleed”, pero la usaremos a modo de ejemplo de lo que estamos explicando), lo que lograremos realmente, es romper el sistema de paquetes que dependen de esta librería y con ello, no podremos instalar o desinstalar ningún paquete .rpm, lo que podemos considerar un desastre que nos puede llevar a tener que instalar todo el software, con todo lo que implica si nuestra distribución está muy “tocada” y no se han usado paquetes .rpm o .deb, para instalar todo lo que necesitamos o hemos modificado en ella y mantenemos copia de los mismos.

Hay que tener en cuenta, que cuantas más dependencias, más riesgos se corren y hay dos tipos de dependencias, las que tiene el programa o librerías para poder ser complilada y las de los otros paquetes que dependen de ella.

Por ejemplo, si intento compilar la última versión estable de la librería GnuTLS, la 3.2.9 en una Mandriva 2010, con mi configuración actual, compruebo que la única dependencia que tengo es una librería criptográfica denominada Nettle, en su versión 2.7.1. Nettle se añadió como dependencia a partir de la versión 2.10.5 de GnuTLS. Sin embargo, si yo intento desinstalar GnuTLS en Mandriva 2010 mediante su gestor de paquetes, el sistema me avisa de que hay 650 paquetes que dependen de GnuTLS, por lo que un poco de cautela no nos vendrá mal antes de decidirnos por instalar directamente la última versión de GnuTLS.

Podemos pensar que es tan sencillo como compilar e instalar Nettle y/o Gmplib, que también necesitaremos para compilar las últimas versiones de GnuTLS, si no la tenemos instalada. Pero también hay que tener en cuenta, que todo lo que instalemos puede tener otras dependencias, que pueden ser versiones más recientes de librerías existentes o de herramientas de compilación o nuevas versiones, por lo que cuanto menos dependencias generemos en nuestra actualización mejor que mejor.

En el caso de Nettle, cuando lo intento compilar solamente me lanza una dependencia, y aunque solamente se usa para las pruebas del código, es la OpenSSL 1.0.1g, que como hemos dicho, es incompatible con el sistema de paquetes .rpm de la Mandriva 2010, aunque también es cierto, que no es frecuente que una actualización a una versión más moderna de una librería genere este tipo de incompatibilidades en Linux.

En este punto hay dos opciones:

a) Tomar el código fuente de la misma versión de la librería GnuTLS que tenemos instalada en nuestro sistema, que en el caso de Mandriva 2010, es la 2.8.4, e intentar parchearla. Para ello, la tendremos que comparar con el código final del archivo /lib/x509/verify.c y con que es el parche que han generado los desarrolladores para resolver el problema, para ver si lo podemos hacer sin grandes problemas.

Para ello accedemos al ftp del proyecto y nos bajamos dicha versión, junto con suarchivo de firma. Alternativamente nos podemos bajar el .rpm con el código fuente de Mandriva.

Ahora, lo primero que tenemos que hacer, es comprobar la firma. Para ello, con gpg (GnuPG) instalado en nuestro sistema, importaremos al anillo de confianza la clave de Simón, que es uno de los desarrolladores de GnuTLS y seguidamente usaremos el siguiente mandato desde el directorio en el que se encuentran los dos archivos anteriores:

gpg --verify gnutls-2.8.4.tar.bz2.sig
gpg: Firmado el vie 18 sep 2009 10:51:45 CEST usando clave RSA ID B565716F
gpg: Firma correcta de "Simon Josefsson <<a href="mailto:simon@josefsson.org">simon@josefsson.org</a>>"
gpg:                 alias "Simon Josefsson <<a href="mailto:simon@yubico.com">simon@yubico.com</a>>"

Una vez comprobada la firma mediante el mensaje “Firma correcta de “Simon Josefsson

tar -xjvf gnutls-2.8.4.tar.bz2

Seguidamente analizaremos si es posible parchear el archivo sin problemas. Como premisa general consideraremos que el archivo no se podrá parchear directamente mediante el mandato patch de Linux, por lo que deberemos hacerlo a mano. Como sabemos, el archivo fuente del problema es “/lib/x509/verify.c”, así que nos toca compararlo con el parche y el código fuente de la última versión disponible, en lo que al problema se refiere. Como veremos, la función “check_if_ca”, se puede parchear sin problemas, ya que el código es casi idéntico a la de la versión anterior a la 3.2.9 de GnuTLS. En el caso de la función “_gnutls_verify_certificate2”, veremos que aunque se puede parchear, las cosas se complican algo más, sobre todo, si no se tiene mucha experiencia de programación en C.

b) Por lo tanto, tendremos que recurrir a la segunda opción, es decir, instalar una versión de la librería más moderna que la que estamos usando en ese momento, lo que puede tener sus riesgos.

El proceso de elección se basa en ir buscando en las distintas versiones disponibles de GnuTLS, hasta encontrar una que se parezca más a lo que tenemos que modificar, pero que no suponga un problema de dependencias. Por ejemplo, podemos probar con la ultima versión de GnuTLS que no necesitaba Nettle, es decir la 2.10.5. Si queremos conocer las diferencias entre las distintas versiones de GnuTLS, podemos recurrir a la Wikipedia.

En este caso, y para ahorrar trabajo a los lectores, una vez bajado el código fuente de esta versión y comprobada la firma, el parche que propongo aplicar para solucionar el problema de GnuTLS es este que muestro seguidamente. A pesar de esto, recomiendo echar un vistazo al código del archivo “verify.c” resultante tras aplicar el parche y compararlo con el de la versión 3.2.9 GnuTLS. Como se podrá comprobar, mi parche se parece mucho al creado para la versión 3.2.9 por el desarrollador Nikos Mavrogiannopoulos, que por otra parte, es el código en el que se basa el mismo, a excepción de la inicialización a cero de la variable “ret”, que no aparece en el código de la versión 3.2.9:

--- verify.c	2010-12-06 14:04:44.000000000 +0100
+++ verify.nuevo	2014-03-09 18:24:37.489058578 +0100
@@ -116,7 +116,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   result =
@@ -125,7 +125,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   result =
@@ -133,7 +133,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   result =
@@ -141,7 +141,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   /* If the subject certificate is the same as the issuer
@@ -181,6 +181,7 @@
   else
     gnutls_assert ();
 
+fail:
   result = 0;
 
 cleanup:
@@ -274,7 +275,7 @@
   gnutls_datum_t cert_signed_data = { NULL, 0 };
   gnutls_datum_t cert_signature = { NULL, 0 };
   gnutls_x509_crt_t issuer = NULL;
-  int ret, issuer_version, result;
+  int ret = 0, issuer_version, result=0;
 
   if (output)
     *output = 0;
@@ -307,7 +308,7 @@
   if (issuer_version < 0)
     {
       gnutls_assert ();
-      return issuer_version;
+      return 0;
     }
 
   if (!(flags & GNUTLS_VERIFY_DISABLE_CA_SIGN) &&
@@ -328,6 +329,7 @@
   if (result < 0)
     {
       gnutls_assert ();
+      result = 0;
       goto cleanup;
     }
 
@@ -336,6 +338,7 @@
   if (result < 0)
     {
       gnutls_assert ();
+      result = 0;
       goto cleanup;
     }
 

Para aplicarlo, nos bastará con crear un archivo denominado “verify.patch”, con el contenido anterior y tras copiarlo al directorio en el que se encuentra “/lib/x509/verify.c”, ejecutaremos el mandato:

patch < verify.patch

Una vez aplicado el parche, podremos proceder a compilar la librería, para ello, usaremos la siguiente secuencia de mandatos:

./configure --prefix=/usr --with-default-trust-store-file=/etc/ssl/ca-bundle.crt --enable-gtk-doc
make
make check

Estos mandatos y en especial “configure”, nos informarán si todo está bien para compilar y si la compilación tiene éxito. Si nos aparece algún error en este proceso, lo más probable es que sea un problema de dependencias que deberemos resolver adecuadamente. He de decir, que mi distribución está configurada como estación de trabajo de desarrollo, por lo que la mayoría de los paquetes necesarios para poder configurar y compilar un programa ya estaban instalados y también es cierto que estos paquetes están bastante actualizados, por lo que estos tres mandatos se ejecutaron sin problemas.

Ahora, si todo está bien, estamos en disposición para instalar nuestra librería y la documentación asociada, lo que podemos hacer con los mandatos:

make install
make -C doc/reference install-data-local
ldconfig

Sin embargo, el mandato “make install”, aunque parece que es la opción más usada, tiene sus riesgos, sobre todo, si luego no está disponible la operación o regla “unistall” para “make”, que nos permitiría eliminar el código que se acaba de instalar en caso de problemas.

Para solucionarlo de forma elegante yo suelo usar el mandato checkinstall. Que tras la configuración, compilación del programa, comprobación del programa e introducción de unos datos que nos pide, nos permite generar un paquete .rpm o .deb, según la distribución que usemos, que será más sencillo de instalar y desinstalar en caso necesario. En este caso, dadas las enormes dependencias de GnuTLS en Mandriva 2010, no se recomienda desinstalar directamente el .rpm de la versión anterior antes de usar “make install”, lo que hace mucho más recomendable el hacerlo mediante un paquete .rpm, como si fuera una actualización más del sistema.

NOTA: Si hacemos varias pruebas de compilación antes de instalar, hay que seguir el procedimiento anterior en todas ellas y entre prueba y prueba, es necesario eliminar los archivos de la compilación anterior mediante el mandato “make clean”.

Para los más osados, les diré que tras instalar Nettle 2.7.1 y obviando instalar la última versión de SSL, pude compilar e instalar sin problemas la versión 3.2.9 de GnuTLS, que por otra parte, funciona también sin problemas y con ello, de paso, tengo Nettle, que aunque no era necesaria antes de la instalación de GnuTLS, es una librería, que junto congmplib, que es una librería de aritmética de precisión variable y que ya estaba instalada en mi sistema, son más que interesante para trastear cosas relacionadas con la criptografía.

Finalmente, ya que estamos, podemos actualizar el archivo /etc/ssl/ca-bundle.crt, que contiene los certificados de las CA en el formato adecuado, para actualizarlo, podemos seguir este procedimiento, que nos garantizará que tenemos los certificados adecuados y que se han eliminado los que ya no son necesarios o los que son inseguros, por lo que recomiendo usarlo de vez en cuando.

Con este artículo he intentado explicar algo de lo que posiblemente se habla en muchos sitios y que es inherente al software libre, la posibilidad de adaptarlo a nuestras necesidades, pero también es cierto, es que no se hace en muchas ocasiones, principalmente por ser una opción de último recurso. Pero como hemos podido ver, es posible y relativamente accesible, incluso para personas que no tienen sólidos conocimientos de programación, si tienen acceso al código que se ha modificado para solucionar el problema.

Evidentemente este procedimiento será más complicado o incluso, imposible, cuanto más se alargue la línea temporal, básicamente por el problema las dependencias directas e inversas del paquete que tengamos que actualizar. Evidentemente, cuanto más cerca se encuentre la versión del paquete a actualizar a la versión que usamos en nuestro sistema, menos problemas tendremos. Por ello, he considerado interesante hablar del procedimiento a seguir para parchear un fuente e instalarlo en nuestro sistema sin demasiados riesgos y hablando de los posibles problemas que se nos pueden presentar en el proceso.

Del mismo modo, cuanto más sepamos de programación, más sencillo se nos hará modificar los fuentes y en caso necesario, incluso podremos hacer un parche a nuestra medida ,si el que hay disponible no se adapta demasiado a nuestra versión del programa, lo que puede ser un buen paso previo para participar activamente en un futuro en proyectos de programación.

Evidentemente, complicado o no, hemos demostrado que es posible hacerlo y todo hay que decirlo, es una opción que no está disponible, ni siguiera como un último recurso, a los usuarios de software privativo, que tendrán que optar por pagar una nueva licencia y actualizarse a una nueva versión, aunque ello les suponga incluso la necesidad de actualizar todo o parte de su hardware o perder la posibilidad de usar determinado software que era de su interés. Evidentemente, si somos una empresa tentemos un serio problema de este tipo y no sabemos como solucionarlo, otra opción sería contratar los servicios de alguien que sepa hacerlo.

Desde mi punto de vista, el software libre, además de más seguro en este momento, nos proporciona opciones y oportunidades que deberíamos valorar seriamente desde el principio.

“Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre.”


Cómo configurar correctamente la seguridad en nuestro router

+TAG 

 

 

Este será un artículo que dedicaremos a mostrar cómo configurar correctamente la seguridad de nuestro router ADSL inalámbrico, esa cajita que nos instaló nuestro proveedor de internet cuando contratamos el servicio, o que compramos para tener WiFi; y, que habitualmente muchos dejan tal y como fue instalada, sin pensar que, mantenerla en esas condiciones es lo mismo que dejar la puerta de nuestra casa abierta, solo que en este caso se trata de nuestra puerta virtual.

Para empezar y antes de adentrarnos en la seguridad en routers, comenzaremos por explicar qué cosa es un router ADSL inalámbrico o enrutador ADSL inalámbrico. Este equipo es el que permite que los paquetes de datos procedentes o con destino a la red sean correctamente encaminados desde y hacia los ordenadores conectados, ya sea mediante cable o de manera inalámbrica

Este es un equipo que por lo general, realiza varias funciones.

  • Modem ADSL: modula las señales enviadas desde red local para que puedan transmitirse por la la línea ADSL hacia la red (internet) y demodula las señales recibidas desde esta, para que los equipos de la red local puedan interpretarlas.
  • Puerta de enlace: es la salida hacia internet de la red local.
  • Enrutador: dirige los paquetes procedentes de internet hacia el equipo destinatario en la red local y viceversa. La identificación de origen y destino la realiza de acuerdo a las direcciones IP correspondientes.
  • Punto de acceso inalámbrico y switch: permite la comunicación inalámbrica con los equipos de la red local, actuando como punto de acceso, incorporando además, por lo regular, un switch con 2 o 4 puertos de red.

Configuración del router por defecto

seguridad en routers

Los proveedores de servicios de internet (ISP) instalan los router con una configuración predeterminada en la que están fijados los parámetros que garantizan la conectividad y el servicio, pero con un número muy limitado de opciones de seguridad previamente configuradas.

Habitualmente la configuración de seguridad está basada solamente en una clave de acceso inalámbrica, que utiliza un sistema de cifrado WEP. Desafortunadamente, este sistema de cifrado es fácil de descifrar y para ello existen numerosas herramientas disponibles en la red. Además, el nombre de usuario y contraseña de administración que traen por defecto los equipos es además básico y predecible.

¿Qué necesitamos tener para empezar la configuración?

Antes de comenzar, debemos asegurarnos de contar con los elementos necesarios para acometer el trabajo:

  • Manual de Usuario del router que vamos a configurar, ya sea en versión impresa o electrónica. Es necesario asegurarse de que se corresponde exactamente con la marca y modelo del equipo. En la mayoría de los casos, el ISP entrega junto con elrouter una versión impresa resumida del manual, no obstante, también está disponibles para descarga en el sitio del fabricante y/o en el del ISP.
  • Cable de red: normalmente el ISP entrega un cable junto con el equipo, pero cualquier cable normal de red nos puede servir.
  • Un ordenador, preferiblemente uno portátil, por contar estos tanto con red inalámbrica como cableada.

Configurando nuestro router

Ya entrando en materia, comenzaremos por decir que los routers ADSL inalámbricos se configuran mediante una interfaz de administración web contenida en el firmware del equipo. Para acceder a esta interfaz, solamente se requiere un ordenador conectado alrouter y un navegador web.

Aunque la conexión del ordenador al router puede realizarse tanto de manera inalámbrica como por cable, por razones de comodidad recomendamos que se realice de manera cableada. Por otra parte, es necesario que las preferencias de conexión de red del navegador web, esté configurado “Sin proxy” durante todo el proceso.

seguridad en routers

Conectando el ordenador al router vía LAN

Comenzaremos conectando el cable de red en nuestro ordenador y luego conectamos el otro extremo en uno de los puertos de red del router. No deben desconectar el cable WAN, usualmente el conector está identificado en color amarillo. Cualquiera de los puertos de red restantes puede ser utilizado.

seguridad en routers

Una vez conectado el cable de red, comprobaremos que la conexión de red está funcionando correctamente. Para ello debemos deshabilitar la red inalámbrica en nuestro ordenador y proceder a abrir cualquier página en nuestro navegador. Si la página se abre normalmente, es que la conexión LAN está correctamente establecida, con lo que podemos comenzar a trabajar.

seguridad en routers

Accediendo a la interfaz de administración

El primer paso será buscar en el manual de usuario cuál es la dirección que debemos teclear en el navegador para acceder a la interfaz de administración del router, así como el nombre de usuario y contraseña a utilizar. Generalmente es 192.168.1.1 o bien 192.168.1.254, así como el usuario y contraseña de acceso suele ser “admin” en ambos casos (sin comillas), de todas formas, atención a lo que dice el manual de usuario de su equipo.

Si los datos que aportamos son los correctos, entonces ya estamos dentro de la interfaz web de administración de nuestro router. La misma difiere entre las distintas marcas y modelos de equipos existentes en el mercado, pero por lo regular mantienen ciertas similitudes en cuanto a la forma de presentar los datos y los nombres de las opciones del menú. Si en lo adelante, la opción a utilizar que mencionamos no aparece exactamente así en su equipo, debe buscar una con nombre similar o de igual significado. No se preocupe demasiado, la mayor parte de las veces, cada pantalla de menú que se le muestre va acompañada de una ayuda visual para auxiliarlo en el proceso.

Guardar una copia de seguridad de la configuración del router

En la mayoría de los routers, tenemos la opción de realizar copias de seguridad de la configuración y además restaurar hacia el equipo las configuraciones previamente guardadas. Al hacer clic sobre la opción guardar copia de la configuración actual (que es uno de los nombres bajo los que puede aparecer), se nos mostrará una ventana con un navegador de archivos para que seleccionemos la carpeta donde vamos a realizar la salva.

Durante el tiempo que dure la realización de la copia no debemos desconectar ni manipular el router o el ordenador. Este proceso se realiza bastante rápido, pero en ocasiones, dependiendo del tipo de conexión utilizada, es posible que demore un poco más.

Frecuentemente en esta misma pantalla de configuración encontramos la opción de restaurar el equipo a una configuración previamente guardada. En caso de que durante la modificación de los parámetros de seguridad este deje de conectarse correctamente a internet o nos bloquee completamente el acceso a él, deberemos hacer uso de esta opción para regresar al equipo al estado original en que se encontraba.

seguridad en routers

Cambiar la contraseña de administración y mejorar la seguridad

El cambio de la contraseña de administración de nuestro equipo es el primer y más importante paso a tomar para incrementar la seguridad de nuestra red. Usualmente existe una opción dentro del menú relacionada con la administración de credenciales, como por ejemplo “establecer contraseña“. Para realizar el cambio debemos suministrar primero la contraseña actual y después introducir dos veces la nueva contraseña.

seguridad en routers

Este es un buen momento para anotar en un lugar seguro la nueva contraseña de administración establecida, que será la que necesitaremos de ahora en adelante para acceder a la interfaz de configuración. Favor de tomar nota de que esta contraseña NO es la utilizada como clave de acceso a la red inalámbrica.

Una vez realizados estos cambios, debemos pinchar en el botón correspondiente para hacerlos permanentes. Esta opción puede aparecer como “Aplicar”, “Guardar” o “Salvar”. Al realizar esta acción, puede mostrarse una barra de progreso. Durante este proceso y hasta tanto la barra no llegue al final, deberemos abstenernos de manipular el router o el ordenador.

Al concluir, automáticamente nuestro navegador nos deberá mostrar nuevamente la ventana para introducir las credenciales. El nombre de usuario no ha sufrido cambios, por lo que será el mismo que aparece en el manual de usuario y que utilizamos anteriormente, mientras que la contraseña es la nueva que acabamos de establecer.

Cambiar el nombre SSID de la red

El SSID es el acrónimo de service set identifier y se refiere al nombre que identifica a nuestra red inalámbrica. En ocasiones los ISPs asignan SSIDs a los routers relacionados con su propio nombre, por ejemplo, en España, los routers instalados por la compañía ONO tienen como SSID un nombre que comienza por “ONO” seguido de otros 4 caracteres alfanuméricos.

Para cambiar el SSID o nombre de la red inalámbrica deben acceder a alguna opción del menú principal que indique datos de red inalámbrica, por ejemplo en mi router Netgearsería: “configuración inalámbrica” .Una vez hecho clic sobre esta opción en el menú se les mostrarán datos o información de la red que pueden cambiar, específicamente el SSID o nombre que identifica a la red inalámbrica.

seguridad en routers

Lo único que tenemos que hacer es escribir el nuevo nombre que hemos seleccionado, teniendo la precaución de no utilizar caracteres extraños que luego dificulten mucho su escritura en dispositivos móviles con teclados táctiles en pantalla.

Cambiar el sistema de cifrado y la clave de acceso

En la misma pantalla también deben aparecer las opciones de sistemas de cifrado a utilizar. Usualmente, WEP es el sistema predeterminado en la mayoría de los routers, pero como comentamos anteriormente, es el sistema más frágil de todos. Una opción es cambiarlo por el de mayor grado de complejidad, que resulta ser WPA-PSK [TKIP] + WPA2-PSK [AES]. Para ello solo marcaremos con el ratón esa opción y a continuación la pantalla nos debe mostrar la posibilidad de introducir una clave de acceso.

seguridad en routers

Esta clave de acceso será la que utilizaremos para autenticar cualquier equipo en la red inalámbrica. Es necesario señalar que algunos dispositivos muy antiguos no son capaces de manejar el sistema de cifrado WPA-PSK [TKIP] + WPA2-PSK [AES]. Si tuvieras equipos con esa limitación deberás decidir entre no conectarlos a la red o utilizar un sistema de cifrado menos seguro.

seguridad en routers

Una vez realizados estos cambios, debemos volver a pinchar en el botón correspondiente para hacerlos permanentes, esta opción puede aparecer como “Aplicar”, “Guardar” o “Salvar”.

Configurar la lista de acceso por tarjeta inalámbrica

La configuración de la lista de acceso por tarjeta inalámbrica también es conocida comoanclaje por dirección MAC. La configuración de este parámetro crea un listado de las direcciones MAC de los equipos autorizados a conectarse a nuestra red, de manera tal que cualquier otro equipo que lo intente, aún cuando logre descubrir nuestra clave de acceso correcta, será rechazado por el router.

Podemos encontrar esta opción en alguna pestaña o ventana cuyo título sea “Configuración inalámbrica avanzada” o “Seguridad inalámbrica”, puede variar un poco pero generalmente los fabricantes ponen nombres similares.

seguridad en routers

El sistema nos solicitará las direcciones MAC de los dispositivos que autorizamos a conectarse a la red, debemos introducirlas de una en una.

Para saber tu dirección MAC en Windows debes abrir el menú inicio y escribir ejecutar, se te abrirá una pequeña ventana en la cual debes escribir cmd y presionar Enter, ahí se te abrirá una ventana con fondo negro llamada terminal o consola, en ella escribes lo siguiente:
ipconfig

Es conveniente aclarar que cuando esta opción está activada, cada vez que necesitemos conectar un nuevo equipo a la red, deberemos acceder a la interfaz de administración y agregar la dirección MAC del mismo.

Desactivar la emisión SSID

La emisión SSID es la función que mantiene al router radiando constantemente el nombre SSID del equipo. O sea, que cualquiera con un tableta, laptop o celular detectará que existe una red inalámbrica cerca, la nuestra. Es aconsejable esconder nuestra red desactivando la emisión del SSID.

Pueden ocultar (o mostrar luego si lo desean) su red mediante una opción que distinguirán claramente, generalmente ubicada en el apartado de “Seguridad inalámbrica” (o similar), pueden ver mediante la imagen anterior cómo sería en un Netgear. Simplemente descarquen la opción “Activar emisión SSID” o “Emisión SSID”.

seguridad en routers

Desactivar la emisión SSID tiene una desventaja; cuando necesites conectarte, tus equipos deberán tener configurado de antemano el acceso a tu red y en el caso de que necesites conectar un nuevo equipo, entonces tendrás que teclear el nombre SSID de la red oculta para que se conecte a la misma. En cualquier caso, es un detalle a tener en cuenta.

Conclusiones

Con esto hemos concluido la configuración de los parámetros de seguridad de nuestrorouter ADSL inalámbrico, ahora solo nos resta volver a probar que el mismo funciona correctamente y que nuestros equipos se conectan y navegan por la red sin problema alguno. Una vez realizadas las pruebas y comprobado que todo funciona sin problemas, nos quedaría guardar la nueva configuración.


Heartbleed y certificados SSL: por qué hay que renovarlos y por qué no se está haciendo bien . Genbeta by Guillermo Julián

 
Heartbleed

A estas alturas ya es imposible que no hayáis oído hablar de Heartbleed. Después del descubrimiento de uno de los fallos de seguridad más importantes en la historia de Internet, las empresas y startups han tomado las medidas necesarias para corregirlo y mitigar daños, incluyendo avisar a los usuarios para que cambien sus contraseñas.

Entre las medidas para mitigar los daños se encuentra la revocación y renovación de los certificados SSL. Recordemos que en HTTPS (y demás conexiones SSL/TLS) esos certificados sirven para cifrar las comunicaciones y asegurarte de la identidad del servidor. Si un atacante obtiene la clave privada podría escuchar y descifrar el tráfico que creemos seguro.

Tras la revelación, se generó una discusión sobre si se podían filtrar las claves SSL con este ataque. No había pruebas determinantes de que se pudiese. Cloudflare, una empresa de servicios para sitios web (CDNs, seguridad, estadísticas…) y una de las primeras en conocer el fallo – 12 días antes de su publicación -, argumentó que era extremadamente difícil que esas claves se filtrasen salvo que se hubiese reiniciado el servidor hace poco.En su blog tenéis los detalles técnicos de su teoría.

Sin embargo, se ha demostrado que, al contrario de lo que proponía Cloudflare, sí se pueden filtrar esas claves. De hecho, las pruebas de concepto no son especialmente complicadas ni costosas.

Revocar los certificados no es un camino de rosas

Netcraft - SSL reissues

Si antes ya era urgente cambiar los certificados, ahora lo es más. Por desgracia, este proceso está lejos de ser perfecto.

El primer problema es la propia infraestructura. Los procedimientos no están pensados para revocaciones a gran escala de tantos certificados, y se especula que incluso podrían fallar y caerse en algún caso.

Además, los navegadores gestionan mal la revocación de certificados. En el momento en el que Facebook (por ejemplo) dice que su certificado SSL está revocado, se publica su número de serie en las listas CRL y en los servidores OCSP. La teoría es que los navegadores se conecten a estos sitios para comprobar qué certificados han dejado de ser válidos.

En la práctica, sólo Internet Explorer y Opera lo gestionan bien y muestran un aviso al usuario diciendo que el certificado se ha revocado. Chrome y Firefox ignoran en muchos casos esas listas si el sitio web no tiene certificados de validación extendida (EV).

En Chrome se pueden volver a activar las comprobaciones en Ajustes: hay que pulsar el enlace “Ajustes avanzados” y, en la sección HTTPS/SSL, pulsar en “Comprobar certificados revocados”. En Firefox, por desgracia, las listas CRL ya no están soportadas en las últimas versiones y no se pueden volver a activar (o no he encontrado la forma de hacerlo).

Otro problema es que no se están siguiendo los procedimientos todo lo bien que deberían seguirseSegún Netcraft, además de fallos en los nombres u otros detalles en los nuevos certificados, muchos administradores no están revocando sus certificados, sino simplemente renovándolos. Esto abre la puerta a que un atacante siga usando sin problemas un certificado ya comprometido.

En total, sólo unos 30.000 sitios web habrían renovado sus certificados de los 500.000 que estarían afectados según las estimaciones de Netcraft. Habrá que estar atentos a esas revocaciones y ser precavidos a la hora de conectarnos a redes en las que no confiemos del todo. Dicho de otra forma: tenemos Heartbleed para rato.

– 
La noticia Heartbleed y certificados SSL: por qué hay que renovarlos y por qué no se está haciendo bien fue publicada originalmente en Genbeta por Guillermo Julián.


¿Qué es EMV, y por qué es un tema candente?

 

Quizás las conozcas por nombres diversos: EMV (Europay MasterCard Visa), tarjetas con chip integrado, o simplemente tarjetas inteligentes. Pero como sea que las llames, son un tema candente en lo que respecta a fraudes de tarjetas de crédito. Algunos no están familiarizados con esta tecnología, y otros la conocen sólo como algo frustrante al viajar. En esta publicación explicaremos la diferencia entre este tipo de tarjetas y las habituales, y por qué son un foco de discusión luego de la fuga de datos de Target.

¿La quieres con cinta magnética o chip?

La tecnología de banda magnética a la que estamos tan habituados tiene alrededor de 40 años. Sus primeras versiones funcionaban como la cinta de los casetes de audio: almacenaban datos en un revestimiento de óxido de hierro contenido en una tira de plástico anexada a la tarjeta, que luego era pasada por un lector. Poco ha cambiado de esta tecnología desde sus comienzos, y hay pocos instrumentos con los que proteger estas tarjetas de un uso fraudulento.

En tanto, el uso de tarjetas con chip se hizo frecuente para transacciones de crédito y débito a principios de 1990. Tres compañías se unieron para implementar estos servicios: Europay, Mastercard y Visa (de ahí su nombre). En vez de almacenar los datos con tecnología magnética, tienen un chip unido a la tarjeta. Esta es la tecnología por defecto en algunos países del mundo, y los sistemas de pago con lectores de tarjetas comienzan a hacerse menos comunes.

Lo distintivo es que cuentan con un microprocesador unido a ellas, que actúa como una pequeña computadora. Se accede de forma interactiva a los datos del chip, el cual requiere de respuestas específicas de un lector para poder revelar su información.Esto hace que, para los cibercriminales, la réplica de estas tarjetas sea significativamente más dificultosa y costosa.

Los datos específicos pueden variar un poco: cada una tiene un chip y un código PIN, por lo que para llevar a cabo un pago será necesario leer la información bancaria y luego ingresar el código correspondiente. Esto evidencia que los usuarios proveen dos mecanismos de autenticaciónalgo que el usuario tiene (la tarjeta) y algo que el usuario conoce (el código PIN).

El proceso de compra es similar al utilizado con tarjetas de débito, excepto que no será deslizada por un lector, sino que será ingresada dentro de él. Algunos plásticos contienen además una banda magnética para llevar a cabo transacciones en lugares que no dispongan de esta tecnología, y en algunos casos no se requiere el código PIN, sino sólo la firma.

¿Cómo ayudan a prevenir el fraude?

Mientras una tecnología se mantenga más tiempo sin cambios, los cibercriminales tendrán más oportunidades de encontrar una forma de vulnerarla. Esto es justamente lo que sucedió con las tarjetas con banda magnética: cuatro décadas fueron suficientes para que entiendan y aprendan cómo robar la información que contienen, lo que representa una gran cantidad de fraudes. En la reciente fuga de datos de Target, esto se llevó a cabo gracias a malware que recuperaba de la memoria RAM la información de las tarjetas de crédito ingresadas en los dispositivos donde se efectuaban los pagos, y finalmente se la distribuía al criminal.

Esta técnica evidenció que aunque los vendedores tuvieran los datos cifrados en sus discos y aunque la información se transmitiera por Internet, no estaba protegida. Cabe destacar que si bien el uso de cifrado disminuye significativamente el tiempo durante el cual los datos están en riesgo, algunos atacantes utilizan malware diseñado paraaprovechar el pequeño tiempo donde se encuentran expuestos.

Entonces, el uso de tarjetas EMV no mitiga los ataques utilizando malware que recupere los datos de la memoria RAM, porque no todas las transacciones requieren la presencia física de una tarjeta de crédito. Que los cibercriminales no cuenten con un plástico limita mucho la utilidad que puedan darle; no obstante, hay formas de utilizar estas tarjetas inteligentes de forma no presencial, y esta táctica ha sido la elegida por ellos durante años.

La mayoría de los casos de fraude en países que utilizan esta tecnología son transacciones no presenciales, como por ejemplo compras en línea, donde el chip no puede ser utilizado para validación. Algunos comercios, por ejemplo los de Canadá, han encontrado una forma de combatir esto, requiriendo que los usuarios de las tarjetas inicien sesión en su cuenta bancaria en vez de proveer de información financiera directamente a los vendedores.

La implementación importa

Como podemos observar en el caso de las restricciones de Canadá, la forma en que los comercios implementan el EMV hará una gran diferencia respecto a cómo esta tecnología reducirá el fraude. Idealmente se busca que:

  • Una tarjeta con chip no tenga banda magnética
  • Haya un número de intentos muy limitado para ingresar el código PIN
  • Una firma nunca sea aceptada a cambio de un código PIN
  • Se establezcan medidas de seguridad adicionales para asegurar las compras no presenciales

En todo lo relativo a seguridad y privacidad, la meta es hacer que el acceso a nuestros datos sea prohibitivamente dificultoso o complicado para nuestros adversarios. Si bien migrar de la tecnología de tarjetas con banda magnética hacia aquellas con chip no terminaría con el fraude bancario, sería un paso hacia la dirección correcta y nos encaminaría hacia mejores medidas de seguridad en transacciones con tarjetas de crédito.

Créditos imagen: ©DennisSylvesterHurd/Flickr 

El post ¿Qué es EMV, y por qué es un tema candente? aparece primero en We Live Security en Español.

 
 

Gentoo Hardened

 
Security Art Work by Joel Sevilleja 

En este post voy a hablar sobre una distribución, que por alguna misteriosa razón que no llego a entender, no suele ser utilizada. Hablo por supuesto, de Gentoo en su modalidad “Hardened”.

(N.d.A: Los siguientes párrafos evangelizan hacen una introducción a Gentoo, por lo que si el lector ya la conoce, puede saltar directamente a Gentoo Hardened)

Gentoo es una distribución rolling-release (lo que quiere decir que la distribución se actualiza continuamente con nuevas funcionalidades, además de para solucionar bugs). No obstante, su mayor característica es que los “paquetes” han de ser compilados por el usuario con una herramienta llamada “emerge”, que forma parte del sistema Portage.

Seguramente, el lector debe estar pensando que compilarse los propios paquetes es una pérdida de tiempo y que mejor gastar una Ubuntu / Debian / CentOS que ya te lo dan todo hecho. Pero, estamos en el año 2014 y si bien a comienzos del año 2000 la instalación de un sistema de escritorio podía durar una semana, con una máquina moderna podemos tener un sistema funcional en una noche, siempre y cuando sepamos lo que estamos haciendo. Y fíjense que estoy hablando de un sistema de escritorio, donde suele haber mayor cantidad software (y de mayor tamaño), que en un servidor.

Utilizar Gentoo tiene una serie de ventajas, de las que destacan las siguientes:

  • El sistema es mucho más flexible: se puede mezclar software de distintas ramas (Gentoo dispone de dos ramas: testing y estable) sin problemas, ya que todo se compila y se enlaza a medida, con una granularidad definida por el usuario, y no por los mantenedores de la distribución.
  • Gentoo soporta varias ramas de cada paquete, y no se centra en mantener la última versión ofrecida por el desarrollador. Por ejemplo, ahora mismo Gentoo soporta PHP en sus versiones 5.3, 5.4, 5.5 y 5.6 (este último hard-masked), y dentro de cada rama, soporta varias sub-versiones, como por ejemplo PHP 5.5.7, 5.5.9 y 5.5.10.
  • El software se compila para las características de la máquina. Basta con introducir la variable CFLAGS con el valor “-march=native -O2 -pipe” en el fichero/etc/portage/make.conf y GCC hará todo el trabajo por nosotros, optimizando incluso para la cantidad de líneas de caché de las que dispongamos.
  • El sistema portage define las “USE FLAGS”, que no son más que banderas que activan o desactivan características del software. Por ejemplo, mi sistema puede no tener un dispositivo Bluetooth. Entonces, ¿bajo qué lógica tengo que instalar dependencias de Bluetooth?
  • Si alguien desarrolla un parche para un software que añade alguna característica que necesito o veo atractiva, en la mayoría de distribuciones debo bajarme los fuentes, compilarlos e instalarlos a mano, haciendo que con el tiempo, el sistema de ficheros esté lleno de basura porque esos ficheros no están bajo el control del gestor de paquetes de turno. En Gentoo basta con dejar caer el parche en “/etc/portage/patches/
 
 

Semi-Synchronous Replication at Facebook

 After intensive testing and hack, we started using Semi-Synchronous MySQL Replication at Facebook production environments. Semi-Synchronous Replication itself was ready since MySQL 5.5 (GA was released 3.5 years ago!), but I’m pretty sure not many people have used in production so far. Here are summary of our objective, enhancements and usage patterns. If you want to hear more in depth, please feel free to ask me at Percona Live this week.

Objective / Why Semisync?

  The objective of the Semi-Synchronous Replication is simple — Master Failover without data loss, without full durability.

 First, let me describe why the objective is difficult without semisync.

 There are a couple of fast slave promotion (master failover) solutions. My own MHA covers both fully automated and semi-automated MySQL failover solution. Fully automated means both failure detection and slave promotion are done automatically. Semi automated means failure detection is not done but slave promotion is done by one command. Time to detect failure is approximately 10 seconds, and actual failover is taking around 5 to 20 seconds, depending on what you are doing during failover (i.e. forcing power off of the crashed master will take at least a few seconds). Total downtime can be less than 30 seconds, if failover works correctly. I’m using term “Fast Failover” in this post, which includes both automated and semi-automated master failover.
 In MySQL 5.6, GTID based failover is also possible. Oracle’s official tool mysqlfailover automates MySQL master failover using GTID. The latest version of MHA also supports GTID.

 Both mysqlfailover and MHA rely on MySQL replication. MySQL replication is asynchronous. So there is a very serious disadvantage — potential data loss risk on master failover. If you use normal MySQL replication and do automated master failover with MHA/mysqlfailover, you can do failover quickly (a few seconds with MHA), but you always have risks of losing recently committed data.

 
 If you don’t want to take any risk of losing data, you can’t do fast master failover with normal MySQL replication. You have to do the following steps in case of master failure.

– Always set fully durable settings on master. By fully durable I mean setting innodb_flush_log_at_trx_commit=1 and sync_binlog=1.
– On master crash, wait for a while (10~30 minutes) until the crashed master recovers. Recovery takes long time because it involves OS reboot, storage and filesystem recovery, and InnoDB crash recovery.
– If the crashed master recovers, you can continue services without losing any data. Since all data exist on the master, slaves can continue replication. BTW official 5.6 had a bug causing all slaves broken in this scenario, but this bug was fixed in 5.6.17.
– If the crashed master doesn’t recover (H/W failure etc), you need to promote one of slaves to a new master. There is a risk of losing some data but you don’t have any other choice.

 This “safer” approach has two issues.
– Longer downtime. This is because you have to wait for master’s recovery.
– You can’t eliminate risks of losing data. If master is dead and never recovers, your risk of losing data is the same as doing fast failover.

 So, in bad cases, you have to suffer from both longer down time and losing data.

 Semi-Synchronous Replication is helpful to prevent from losing data.

 If you do not care about data loss risk, there is no reason to use Semi-Synchronous replication. You can use normal MySQL replication and do fast failover with mysqlfailover or MHA. Facebook is one of the companies to care about data loss risk with MySQL, so that’s why we were interested in Semi-Synchronous replication a lot.
 
 Semisync replication was originated from Google in 2007. Official MySQL supported from 5.5. Actual implementation algorithm was substantially different from Google’s.

 MySQL Cluster and Galera offers synchronous replication protocol in different ways. I do not cover them in this blog post.

 Semi-Synchronous Replication currently has two types of different algorithms — Normal Semisync and Loss-Less Semisync. Let me explain the differences.

Differences between Normal Semisync and Loss-Less Semisync

 Loss-Less Semisync is a new Semisync feature supported in official MySQL 5.7. Original implementation was done by Zhou Zhenxing as “Enhanced Semisync” project, and also filed as a bug report. Oracle implemented based on his idea, and named Loss-Less semisync for it. So Enhanced Semisync and Loss-Less Semisync have same meanings. I say Loss-Less semisync in this post.

 Normal semisync and loss-less semisync work as below.

1. binlog prepare (doing nothing)
2. innodb prepare (fsync)
3. binlog commit (writing to fscache)
4. binlog commit (fsync)
5. loss-less semisync wait (AFTER_SYNC)
6. innodb commit (releasing row locks, changes are visible to other users)
7. normal semisync wait (AFTER_COMMIT)

 On normal semisync(AFTER_COMMIT), committing to InnoDB is done before waiting for ack from semisync slave, so the committed rows are visible from applications, even though semisync slaves may not have received the data. If master is crashed and none of the slaves received the data, the data is lost but applications may have seen them. This is called phantom reads, and in many cases it’s problematic.

 Loss-less semisync (AFTER_SYNC) avoids the problem. Loss-less semisync commits InnoDB after getting ack from one of semisync slaves. So when committed data is visible from applications, one of the semisync slaves have received that. Phantom read risk is much smaller: if both master and the latest semisync slave are down at the same time, data is lost. But it’s much less likely to happen compared to normal semisync.

 To avoid data loss and phantom reads, Normal Semisync can’t meet your expectations. Using Loss-Less Semisync is needed.

 With Loss-Less Semi-Synchronous replication, committed data should be on one of the slaves, so you can recover from the latest slave. You can always do fast failover here.

Reduced Durability

 When you do fast failover, you can set reduced durable settings on master as well as slaves. Reduced durability means innodb_flush_log_at_trx_commit != 1 and sync_binlog != 1. With Semi-Synchronous replication, you can immediately start failover when master is down. When promoting a slave to the new master, identify the latest slave (highly likely one of the Semi-Synchronous slaves but not guaranteed) and apply differential logs to the new master. Master’s durability does not matter here, because there is no way to access master’s data during failover. So you can safely reduce durability. Reducing durability has a lot of benefits.
– Reducing latency on (group) commit because it doesn’t wait for fsync().
– Reducing IOPS because the number of fsync() calls is significantly reduced: from every commit to every second. Overall disk workloads can be reduced. This is especially helpful if you can’t rely on battery/flash backed write cache.
– Reducing write amplification. Write volume can be reduced a lot, even less than half in some cases. This is important especially when using flash devices, because less write volume increases flash life expectancy.
 

Requirements for Semisync Deployment

 To make Semisync work, you need at least one semisync reader (slave with semisync enabled) within the same (or very close) datacenter as the master. This is for latency. When semisync is enabled, round-trip time(RTT) between master and one of the semisync slaves is added to transaction commit latency. If none of the semisync slave is located within close datacenter, RTT many take tens or hundreds of milliseconds, which means you can commit only 10~100 times from single client. For most environments, this will not work. You need a slave within close datacenter.

 To make fast failover work without data loss, you need to make sure Semi-Synchronous Replication is always enabled. MySQL Semisync has a couple of points where optionally semisync is disabled:
– Exceeding timeout (exceeding rpl_semi_sync_master_timeout milliseconds to get ACK from all of the semisync slaves)
– No semisync slave (can be controlled via rpl_semi_sync_master_wait_no_slave)
– Executing SET GLOBAL rpl_semi_sync_master_enabled=0

 If you want to enable semisync always, you make sure these scenario won’t happen. Set infinite or very long timeout, and have at least two semisync readers.

 

 Facebook Enhancements to Semi-Synchronous Replication

 
 We spent a lot of time for testing Semi-Synchronous replication in 2013. We found some S1 bugs, serious performance problems, and some administration issues. Our MySQL Engineering team and Performance team worked for fixing issues and finally our Operations team deployed Semisync in production.

 Here are our major enhancements.

Backporting Loss-Less Semisync from 5.7

 As described above, Loss-Less Semisync is needed to prevent data loss and phantom reads, so we backported Loss-Less Semisync patch from official MySQL 5.7 to our Facebook MySQL 5.6 branch. It will be merged to WebScaleSQL branch soon.

 Interestingly, when we tested semisync performance, Loss-less semisync gave better throughput than normal semisync, especially when the number of clients is large. Normal semisync caused more mutex contentions, which was alleviated with loss-less semisync. Since Loss-less semisync has better data protection mechanism, we concluded there is no reason to use normal semisync here.

Semisync mysqlbinlog

 Starting from MySQL 5.6, mysqlbinlog supported remote binlog backups, by using –raw and –read-from-remote-server. On remote binlog backups, mysqlbinlog works like a MySQL slave. mysqlbinlog connects to a master, executing BINLOG DUMP command, then receiving binlog events via MySQL replication protocol. This is useful when you want to take backups of the master’s binary logs. Slave’s relay logs and binary logs are not identical to master’s binary logs, so they can’t directly be used as backups of the master’s binary logs.

 We extended mysqlbinlog to speak Semisync protocol. The reason of the enhancement is that we wanted to use “semisync mysqlbinlog” as a replacement of local semisync slaves. We usually run slaves on remote datacenters, and we don’t always need local slaves to serve read requests / redundancy. On the other hand, as described at above “Requirements for Semisync Deployment” section, in practice at least two local semisync readers are needed to make semisync work. We didn’t like to run additional two dedicated slaves per master just for semisync. So we invented semisync mysqlbinlog and use it instead of semisync slaves, as shown in the below figure.

 Compared to semisync slave, semisync mysqlbinlog has a lot of efficiency wins.

– semisync slave has lots of CPU overheads such as query parsing, making optimizer plans. semisync mysqlbinlog does not have such overhead.
– semisync slave writes 2x (relay log and binary log). semisync mysqlbinlog writes binary log only.
– For semisync slave, the way to write to relay log is not efficient. IO thread writes to kernel buffer per each binlog event. For regular auto-committed transactions, it consists of three binlog events (query BEGIN, query body, and commit XID). When using InnoDB only, writing to kernel buffer for every XID event is enough (though it does not cover DDL). By writing to kernel buffer for every XID event, it makes the frequency of kernel buf flush by less than 1/3. semisync mysqlbinlog could easily do such optimizations. We have not done yet, but it is even possible to make mysqlbinlog send back ACK before writing, to a file, and the extension is very easy.
–  Slave causes contention between SQL thread and I/O thread, so IO thread itself slows down, which slows down semisync master throughput too. Semisync binlog does not have such overhead because there is no SQL thread.

 With mysqlbinlog reader, master failover step becomes a bit tricky. This is because mysqlbinlog is not mysqld process so it doesn’t accept any MySQL command, such as CHANGE MASTER. When doing master failover, it is highly likely that one of local mysqlbinlog has the latest binary log events, and the events should be applied to a new master. New MHA version (0.56) supported the feature.

 In this configuration, mysqlbinlog processes need to be highly available. If all semisync mysqlbinlog processes are down, semisync is stopped or suffering from long wait time.. 

Reducing plugin_lock mutex contention

  Prior to MySQL 5.6.17, there was a performance bug that transaction commit throughput dropped significantly when there were non-semisync many slaves or binlog readers, even if there was only a few semisync readers. On typical deployments, there are two or three semisync readers and multiple non-semisync readers, so performance drop with many non-semisync readers was annoying.
 The performance drop was caused by “plugin_lock” MySQL internal mutex on master. For those who don’t know, semisync is a plugin in MySQL, and it’s not installed by default. The plugin_lock mutex was needed by semisync binlog dump threads only, but actually the mutex was held by all binlog dump threads. We looked into the problem further.
 First we tried replacing plugin_lock mutex with read/write mutex. It actually did not help much. But Linux profiling tools showed that plugin_lock still caused contentions. During profiling, we learned that most/all glibc rw-locks had an internal lock (mutex-like thing) on which threads could stall. The pattern was get lock, get exclusive access to cache line to modify data, release lock. This was relatively expensive for plugin_lock mutex, since it doesn’t do any expensive I/O inside.

 So switching plugin_lock to read/write lock was actually a bad idea. It was needed to remove below plugin related locks as long as possible. There are four major plugin related mutexes in MySQL.
– plugin_lock
– plugin_lock_list
– plugin_unlock
– plugin_unlock_list

 We also noticed that Delegate classes had read/write locks and they caused very hot contentions (especially Binlog_transmit_delegate::lock). The read/write lock protects a list, so probably switching to lock-free list was possible. BTW we noticed that performance schema did not collect mutex statistics on the mutexes on Delegate classes (bug#70577). 

 The real problem was all of the above locks were held not only by semisync binlog readers, but also non-semisync binlog readers.

 Based on the above factors, we concluded removing all plugin mutexes was not easy, then we decided to optimize to hold these locks by semisync binlog readers only, and not holding by non-semisync binlog readers. The below is a benchmark result.

 x-axis was the number of non-semisync binlog readers, y-axis was concurrent INSERT throughput from 100 clients. The number of semisync binlog readers was always 1 to 3. Detailed benchmark conditions were described in a bug report.
 Hopefully our patches were finally merged to 5.6.17 and 5.7 so everybody can get benefits easily.

 With all of the enhancements, we could get pretty good benchmark results with semisync.

 This is a mysqlslap insert benchmark on the master, with one semisync slave/mysqlbinlog running. x-axis is the number of clients, y-axis is the number of inserts on the master. Enhanced means loss-less semisync.
 Normal slave is traditional (non-semisync) slave. Enhanced mysqlbinlog is our semisync usage pattern. As you can see, loss-less semisync beats normal semisync due to internal mutex contention reductions. semisync mysqlbinlog also beats semisync slave because of much less overheads. This shows that loss-less semisync scales pretty well.
  

Conclusion and Future Plans

 After several performance improvements, Semi-Synchronous replication became good enough for us. From performance point of view, I expect that single-threaded application performance will be next low-hanging fruits. On our benchmarks, we got around ~2500 transaction commits per second with semisync (0.4ms per commit). Without semisync, it was easy to get ~10000 transaction commits  per second (0.1ms per commit). Of course semisync adds RTT overhead, but on local datacenter network, RTT is much lower than 0.3ms. I think there is another semisync overhead here, so will revisit this issue and will work with Oracle Replication team and outside experts.