no digas debian 9, di zurg

Debian 6 Squeeze

No puedo decir que me apasione el nombre que le han dado a la que será la versión 9 de Debian GNU/Linux, Zurg. Yo no me acordaba del personaje, del Emperardor Zurg y ya sé porque: sólo lo cita Buzz Lightyear un par de veces en las tres películas porque es su archienemigo.

Emperador Zurg (vía: wikia.com)

Quiero creer que, aunque las películas de Toy Story tienen suficientes personajes para obtener nombres de distribuciones durante años, ya han escogido los buenos y ahora nos queda los otros, aquellos que no son protagonistas o que no suenan demasiado. En ese aspecto, creo que nos queda una larga travesía de nombres extraños, más parecidos al sonido que haces al expulsar el aire tras recibir un puñetazo en el estómago que a uno de esos muñecos de plástico que tanto nos gustan.

(Actualización de seguridad y estabilidad). Liberado Debian 6.0.9 Squeeze

Debian 6 SqueezeSi la pasada semana os contábamos que Debian Wheezy había liberado una importante actualización, hoy es el turno de Squeeze con la novena entrega de la rama “oldstable“.

Tal y como comentan en el anuncio oficial, corrige fallos de seguridad localizados en varios paquetes, así como solventa en otros, “errores serios”. De  nuevo, ojo con los servidores y especialmente con la actualización de Apache, os detallo la lista de paquetes que han entrado en un server que acabo de actualizar:

apache2 apache2-doc apache2-mpm-prefork apache2-suexec apache2-threaded-dev apache2-utils apache2.2-bin apache2.2-common base-files libpq-dev libpq5 librsvg2-2 tzdata

Dada la importancia de esta actualización, os recomendamos aplicarla con brevedad. En el post, nos recuerdan que no es necesario grabar nuevos CDs, etc, sino aplicar las actualizaciones desde vuestro gestor de paquetes preferido.

Lista de cambios y aviso de la nueva release (ENG).

(Actualización de seguridad y estabilidad). Liberado Debian 7: 7.4 “Wheezy”.

Debian WheezyAcaba de ser liberada la cuarta actualización de Debian 7 “Wheezy” que tal y como comentan en el anuncio oficial, corrige fallos de seguridad localizados en varios paquetes, así como solventa en otros, “errores serios” (ojo con los servidores).

Dada la importancia de esta actualización, os recomendamos aplicarla con brevedad. En el post, nos recuerdan que no es necesario grabar nuevos CDs, etc, sino aplicar las actualizaciones desde vuestro gestor de paquetes preferido.

Lista de cambios y aviso de la nueva release (ENG).

Prevenir ataques XSS e inyecciones de código y SQL con EuropioCode

Riesgos y problemas actuales, aún no resueltos

Actualmente, los ataques XSS, las inyecciones de código y las inyecciones SQL, se suelen prevenir, mayormente, de dos formas:

1) Filtrando las entradas del usuario a nivel de la aplicación: utilizando funciones propias del lenguaje y funciones definidas por el usuario, en los algoritmos de la aplicación.

2) Aplicando herramientas como ModSecurity en forma conjunta con las reglas de OWASP, a nivel servidor, para prevenir el envío de datos que puedan resultar sospechosos.

En el primer caso, los programadores se ven forzados a efectuar trabajos de diseño realmente extenuantes. Muchas veces, se efectúa un filtrado sencillo a nivel de la aplicación, mediante el uso de funciones como strip_tags() o htmlentities() en PHP, pero cuando comienzan a aparecer requerimientos fuera de lo común en la aplicación, todo se complica. Y así nos encontramos con necesidades puntuales como por ejemplo:

  • Necesidad de facilitar y permitir el ingreso de texto con preformato (tags HTML permitidos)
  • Necesidad de permitir al usuario, el ingreso literal de código fuente en diversos lenguajes;

Y aquí, el trabajo a nivel aplicación, comienza a complicarse. No todo diseño suele ser suficiente ni todo diseño deja confiados a sus programadores. Siempre se estará alerta.

En el segundo caso y sin siquiera mediar alguna de las necesidades puntuales mencionadas anteriormente, ModSecurity termina convirtiéndose en un problema tanto para los programadores como para los administradores de sistemas. La mayoría de las veces, el servidor comienza a arrojar errores 403 al usuario y los logs de Apache, se llenan de lo que a simple vista, parecen ser falsos positivos de ModSecurity haciendo referencia a supuestos intentos de ataques por diversos tipos de inyecciones.

Pero, como siempre digo a mis alumnos:

Los falsos positivos de ModSecurity por intentos de inyección de código o SQL, son en realidad, errores de diseño a nivel de la aplicación.

La realidad, es que la mayoría de los programadores, aún en épocas donde arquitecturas como MVC son el auge de la moda en la ingeniería de Software y sobra documentación al respecto, continúa confundiendo los requerimientos visuales de la aplicación con la lógica algorítmica de la misma.

Los falsos positivos de ModSecurity se producen por errores de diseño cuando los programadores confunden un requerimiento visual con la lógica de negocios de la aplicación.

Necesitar poder permitir al usuario el ingreso de código fuente, es una necesidad visual. Es el usuario quien DEBE CREER que está ingresando código fuente. Es, a los ojos del usuario, que se debe mostrar una cadena de texto que luzca de forma idéntica (o similar) a un código fuente. Sin embargo, una aplicación JAMÁS debe permitir que se le inyecte código fuente. Y lo mismo, aplica al texto con preformato.

Entonces aquí es donde radica el problema. Los programadores no encuentran una alternativa lateral a lo que conocen y todo concluye en la ERRÓNEA anulación de las reglas de ModSecurity.

Anular las reglas de ModSecurity, es el peor error que un SysAdmin puede cometer

La idea de este post, justamente, es brindar esa solución lateral que “le de el gusto” a todos, sin comprometer la seguridad del sistema.

Una solución que conforma a todo el mundo

La solución consiste entonces, en encontrar una manera de permitir al usuario ingresar código fuente en la aplicación, sin que lo que se envíe sea código fuente.

Y para ello, la única alternativa es:

Convertir las entradas del usuario en cadenas alfanuméricas.

Solo las cadenas de texto puro, son las que nos darán la seguridad y tranquilidad que necesitamos. Si lográsemos convertir luego, esa cadena de texto alfanumérico en algo que VISUALMENTE, se asemeje a lo que originalmente ingresó el usuario, estaríamos hallando una forma 100% segura de prevenir las inyecciones de todo tipo.

Y a tal fin, es que creé a  EuropioCode, un nuevo algoritmo de codificación alfanumérica, que puede ser aplicado a cualquier cadena de texto.

EuropioCode -actualmente en fase beta-, cuenta con dos librerías:

  1. Una librería JavaScript para codificar los campos de un formulario del lado del cliente (es decir, codificar el/los campo/s antes del envío del formulario al servidor);
  2. Una librería PHP que por un lado, refuerza la codificación del lado del servidor (en caso que la librería JS sea ignorada y ModSecurity no se encuentre operativo) y por otro, decodifica la cadena como entidades HTML hexadecimales, de forma tal que dicha entrada solo se interprete visualmente pero sea incapaz de ejecutarse.

En el repositorio oficial en Launchpad, se pueden obtener tanto las librerías JS y PHP como códigos con ejemplos de uso.

Actualmente, está en constante desarrollo por lo que recomiendo a los programadores, hacerse un branch del repositorio:

bzr branch lp:~eugeniabahit/europiocode/trunk

El repositorio está manejado con Bazaar, el sistema de control de versiones desarrollado por Canonical (fabricantes de Ubuntu), que forma parte oficial del proyecto GNU.

Si utilizas Git, otro sistema de control de versiones o simplemente, nunca has utilizado un sistema similar, aprender a usar Bazaar te llevará solo 5 minutos con este tutorial.

Para implementar EuropioCode, solo necesitas unas pocas líneas de código. Te recomiendo mirar (y probar) los ejemplos de uso incluidos en el repositorio.

Por favor, ten en cuenta que EuropioCode:

  • No es un encriptador de texto y por lo tanto, no cifra la información. Solo convierte caracteres NO alfanuméricos en código que sí es alfanumérico.
  • No es una librería pensada para proveer privacidad al usuario ni salvaguardar datos. Es un pseudo-código alfanumérico para reinterpretación de caracteres NO alfanuméricos.

Esta vez sí, Happy Hacking!

[Tutorial] Cómo crear backups cifrados e incrementales en Debian y derivados con Déjà Dup

Deja DupYa he comentado en algún podcast que por lo general, siempre suelo instalar mis máquinas Debian (escritorio) con LVM cifrando la raíz, /home y la swap (una buena “feature” de Debian, si cifras vía dm-crypt tu /home, por seguridad te obliga desde el instalador a cifrar la swap por los datos que se podrían extraer almacenados en RAM).

Como además de mis equipos portátiles también tengo cifrados los de escritorio, según mi criterio, no tendría mucha lógica guardar las copias de seguridad sin esa capa de cifrado y ahí es donde entra en escena Déjà Dup (el nombrecito se las trae, lo sé ;D).

También es importante comentar que tras más años de los que recuerdo usando KDE, llevo unos meses con GNOME (modo clásico y “flashback según equipos, menos recursos que un Shell “puro”) y XFCE ya que la integración con (en adelante) Deja Dup es muy buena (este tuto lo estoy escribiendo desde Debian Testing y GNOME 3.8.4).

Cuando hablo de mejor integración, me refiero a poder hacer click con el botón del ratón y ver un menú contextual (más abajo veréis las capturas) con el texto: “restaurar los ficheros que faltan” y es pinchar el disco, y ver restaurado el fichero o directorio sin problemas. También los indicadores de progreso de la copia de seguridad, o el aviso emergente caso de haber programado una tarea, del inicio de la copia.

En el título pongo Debian y derivados, ya que es válida para otras distros como Ubuntu o Mint, pero está empaquetado en muchas más con algún ligero cambio. Por ejemplo, en Ubuntu se pueden lanzar backups contra Amazon s3 o Ubuntu One, pero las funcionalidades son similares. Para el cifrado utiliza GPG (GNU Privacy Guard) todo un clásico, mediante un sistema de cifrado simétrico. También trabaja con herramientas tan conocidas como Rsync, etc. Os recomiendo ver info más detallada de cómo funciona.

Así que ya sabéis, sólo un aptitude install deja-dup y empezar con esos backups. Os pongo unas cuantas capturas de pantalla para que podáis ver en modo gráfico lo que os he ido comentando. Sencillo, seguro y efectivo, concepto KISS a tope.

Seleccionando la opción de cifrado e introduciendo la frase de paso.

Aquí podéis configurar opciones de la copia de seguridad.

Un ejemplo con la frecuencia de las copias de seguridad.

La opción que os comentaba de restauración y el menú contextual.

Seleccionando el fichero a restaurar.

Confirmación y ubicación (coge la ruta de forma automática).

Progreso de la restauración.

Y confirmación de que todo ha salido ok.

Un vistazo después a los ficheros .gpg.

Eso es todo, espero que lo encontréis útil y no dejéis de hacer vuestros backups.