Una de las formas que tenemos hoy en día de averiguar como es el mundo es preguntando a la web. Se trata de desargar y analizar la información (meta-información) disponible en internet que nos puede dar pistas sobre las organizaciones en distintos ámbitos. De ello hablábamos el otro día en Alguien puede estar tratando de conocerte mejor pero hemos hablado más veces antes: demoscopía.

Hoy vamos a hablar un poquito de los servidores web en los dominios .es. En Análisis de servidores web en dominios “.es” (I) Luis Martín lanzaba un análisis a los servidores web de los dominios .es para determinar qué servidores se estaban utilizando, versiones, sistemas operativos y esas cosas. La conclusión es que el servidor mayoritario es Apache, seguido del IIS. En ambos casos, versiones no muy recientes:

Apaches con más de un año de antigüedad: 109715. Apaches con menos de un año de antigüedad: 37714.

Y también:

8799 dominios usarian IIS actualizados. 105926 usan IIS antiguos y potencialmente vulnerables.

Naturalmente, dada la naturaleza de estos datos esto no significa que todos sean vulnerables (incluso podrían estar proporcionandodatos falsos). Pero muy buena impresión no da.

El análisis continuaba con Análisis de servidores web en dominios “.es” (II), donde se analizan los lenguajes y sistemas de gestión de contenidos utilizados en estas páginas web. Los más populares parecen ser PHP y ASP.NET.

Nuevamente no parece que la actualización sea una de las prioridades de la web española.

Insisto, no hay que tomar como palabra de ley estos datos, pero a mi me dejan un poco preocupado, la verdad:

Hemos de tener en cuenta que este estudio ha sido realizado de manera muy superficial, cuidando hasta el extremo el potencial impacto y siendo lo menos agresivos posible. Toda la información obtenida está “ahí fuera” sin necesidad de “rascar”, disponible para todo el mundo incluidos aquellos sin buenas intenciones. Seguramente un enfoque más profundo (sin necesidad de ser agresivo) proporcionaría mucha más información del estado actual de servicios Joomla!, WordPress, IIS o Apache.

En Building Security Into DevOps: Security Integration Points hay una introducción al tema, que podemos completar con Putting Security Into DevOps.

Se hace un análisis inicial de esta forma de enfrentarse a los proyectos para después pasar a comentar las implicaciones y consecuencias desde el punto de vista de la seguridad (diseño/arquitectura, despliegue, modelo de amenazas, automatización, pruebas …). Y también las herramientas de seguridad como son el análisis estático, dinámico, fuzzing, revisión de código…

Aunque el sistema de filtros que introdujimos en Añadiendo filtros de correo a mi sistema con sievelib ha seguido evolucionando con varias características hoy quería traer aquí una que me preocupaba un poco: si vamos añadiendo reglas es bastante probable que en algún momento nos equivoquemos y añadamos alguna errónea. Como además estamos utilizando un sistema que controla los filtros también podría ocurrir que una actualización sobre-escriba las reglas que hayamos creado. La solución adoptada era guardar la historia de los cambios. Pero queríamos ir un poco más allá: ¿tendría sentido gestionar el histórico con un sistema de control de versiones? ¿Sería posible hacerlo?

Buscando encontramos GitPython que nos proporcionaba una interfaz adecuada para lo que estábamos plateando. El código completo en su estado actual se puede ver en addToSieve.py y nos vamos a dedicar a su parte final. Aviso: el resto del código no está muy bien organizado pero funciona razonablemente bien en mi día a día.

Hay que declarar el módulo:

from git import Repo

Al final, cuando ya hemos actualizado las reglas las pasamos al sistema de control de versiones. Instanciamos un repositorio con nuestro directorio de copias de seguridad. repoDir es una cadena de texto que contiene el directorio de trabajo (en mi caso es ~/Documents/config donde guardo varias configuraciones con control de versiones).

	repo = Repo(repoDir)
	index = repo.index

Elegimos el fichero de reglas que acabamos de grabar, lo almacenamos en el fichero que estamos utilizando (en mi caso se llama sogo.sieve, añadimos todos los ficheros del directorio al repositorio y hacemos el commit (con el nombre y la fecha como mensaje):

	
	sieveFile=c.getscript('sogo')
	file=open(repoDir+repoFile,'w')
	file.write(sieveFile)
	file.close()
	index.add(['*'])
	index.commit(name+'sogo')

Finalmente borraremos del servidor algunos filtros almacenados, dejando los últimos cinco nada más. No se hace el push dentro del programa para evitar el tener que teclear otra contraseña y no parece necesario.

Buscando otros proyectos he visto que en history.py hacen algo parecido en un programa de gestión de contraseñas que estoy probando, passpie.

Tenemos un poco descuidada la parte de programación de esta bitácora. Espero poner algo de código en los próximos días pero eso cuesta más tiempo y no es algo que fluya libremente en estos tiempos.

El caso es que lei la primera parte de Coding for SSDs – Part 1: Introduction and Table of Contents y me resultó interesante. La guardé, en parte para ponerla aquí, y en parte para leer el resto de capítulos (aquí estoy reconociendo que sólo he leído el primero). La programación a bajo nivel no es lo mío, pero siempre es bueno tener una idea sobre estas cosas.

Los fallos que viven y sobreviven a múltiples actualizaciones y cambios terminarán teniendo su propia categoría por aquí. No hace mucho leíamos 11-year-old VM escape bug opens host machines to compromise y lo traemos aquí a título de inventario.

“The VENOM vulnerability has existed since 2004, when the virtual Floppy Disk Controller was first added to the QEMU codebase,” the researchers shared. If you’re wondering why it is still added to new virtual machines by default, it’s because it’s still occasionally used in a number of situations.

No hay mucho más que decir. Siguiendo la moda, el fallo tiene su propia página web: VENOM.