dnsmasq y la persistencia de las IPs

A veces pasa. Te obsesionas con un problema determinado, algo nimio pero capaz de perturbar tu sueño por el mero hecho de estar ahí, de existir. Pasa el tiempo y no das con la solución y, finalmente, cansado de la situación, desistes. Pues bien, lo que suele pasar es que en un plazo de tiempo no superior a las dos semanas, la solución te busca y, claro está, te encuentra. ¡Maldito Murphy!

La última solución que me buscó y me encontró, tiene que ver con dnsmasq, el servidor de DNS y DHCP que tengo funcionando en raspas, el ordenador más importante de mi casa, ese que entra en una cajetilla de tabaco. Con la limitada capacidad de raspas no hay nada mejor que un servicio ligero y muy ágil que apenas entorpece. Mi problema, decía, tenía que ver con la asignación de direcciones IP y, básicamente consistía en que tenía todo el rango separado según el tipo de solicitante (móviles, tabletas, ordenadores personales, ordenadores de trabajo, lavadoras, tostadoras, etcétera…) y en unos pocos casos, ignoraba mis instrucciones y asignaba una IP diferente, aunque reconociese al dispositivo.

Concretamente me tenía frito que mi movil, nexus no tuviese la dirección IP 20 asignada con mimo y cariño sino la 131. Tras realizar todo tipo de ajustes en la configuración del servicio, cambios en el direccionamiento IP y un largo etcétera de pruebas, todas infructuosas, claudiqué y admití mi derrota a manos de un ordenador que se llama igual que el esqueleto de las sardinas. De eso hace un par de semanas.

Hoy sólo quería saber dónde podía encontrar una lista de los dispositivos que tienen asignada una dirección IP en dnsmasq.

Una búsqueda rápida y el primer resultado, una respuesta de una lista de email, sólo dice que la tiene en el fichero que contiene los préstamos de IPs, en /var/lib/misc/dnsmasq.leases. Y es cierto, contiene esa lista, un poco más grande de lo que esperaba. De hecho, estaba a punto de cerrar el fichero cuando un dato llamó mi atención: algunos de los equipos listados sólo habían estado conectados unas horas, mucho tiempo atrás. Mirando con más detenimiento, observé que, además, esos equipos tenían direcciones IP que deberían estar asignadas a otros, como el nexus. Y todos ellos tenían un bonito cero al principio de la línea. En este punto, sólo quería llorar.

Lo que acababa de ver era una demostración del concepto de persistencia. Al principio, cuando estaba aprendiendo a usar dnsmasq le asigné a los equipos con una IP determinada un tiempo de arrendamiento muy alto, infinito concretamente. Luego decidí cambiar el direccionamiento y, aunque cambié en la mayor parte de los casos la etiqueta infinite por 12h, no limpié la base de datos y esas IPs seguían reservadas hasta el infinito y más allá. Por eso, por mucho que intentase asignarle la 20 al nexus el servidor seguía dándole una muy superior y alejada de mis sueños de orden y categorización, puesto que ya primera ya estaba asignada por siempre jamás.

Bastó una prueba para que quisiese darle cabezazos a la pared. Detuve el servicio, borré las entradas viejas del fichero /var/lib/misc/dnsmasq.leases y volví a levantar el servicio. A continuación solicité una nueva IP desde el móvil y… dnsmasq le asignó la número 20.

Por supuesto, ya le había cambiado el tiempo de asignación en la configuración para que nunca más tuviese otra IP.

¿La moraleja de esta historia? Que nunca barres toda la mierda de debajo de las alfombras. Siempre queda algo que, además, apesta.

 

Adelantado a nuestro tiempo

Definition_of_Free_Cultural_Works
He de reconocer que esta será una entrada un poco atípica. No va de nmap, de como configurar un firewall, de los intríngulis de algún lenguaje de programación ni de la Big-O-Notation. Va de algo más filosófico, o ético, una cuestión de principios, para que nos entendamos. Va de la renuncia general a un derecho fundamental, el derecho a la cultura. Y de cómo el poder del facilismo mina el interés general por preservarlo.

El artículo 44 de la Constitución Española establece que:

  1. Los poderes públicos promoverán y tutelarán el acceso a la cultura, a la que todos tienen derecho.
  2. Los poderes públicos promoverán la ciencia y la investigación científica y técnica en beneficio del interés general.

Sin embargo, los lobbies de la industria audiovisual se empeñan una y otra vez en dificultar el acceso a la cultura, en prostituirlo, en decidir qué podemos y qué no podemos consumir y cómo lo consumimos. Así nacen engendros tales como la SGAE o la AEDE, que hacen poco por artistas, escritores y consumidores y mucho por llenarse los bolsillos (podéis buscar a un tal Pedro Farré…). Y artimañanas como el DRM, el cibergrillete de los contenidos multimedia.

Es preocupante que todo esto le importe a tan poca gente. Que se levante la voz contra el cierre de un sitio de enlaces porque no vas a poder ver tu serie favorita gratis, pero no por el flagrante atentado a la neutralidad de la red que supone. Que el único boicot a las grandes discográficas y editoras, que exprimen a los autores hasta límites insospechados, se reduzca a ahorrarnos unos eurillos para ver la peli de turno o descargar el disco de moda. Que se apoye tan poco a iniciativas verdaderamente honradas, que retribuyen al creador de manera justa y que no limitan el acceso libre a la cultura.

¿Será que el de cultura libre es un concepto adelantado a nuestro tiempo? ¿Algo tan innovador que escapa a la inteligencia social del común de los mortales? Yo creo que no, que más bien es un problema de facilismo, de egoísmo, del yo-mi-me-conmigo. Y aunque pueda parecer complicado, salir de esa peligrosa triada en realidad es bastante sencillo. Podemos regalar cultura libre estas navidades. Podemos apoyar plataformas como Jamendo, autores como Gritando en Silencio o proyectos como Gutenberg. Podemos utilizar software libre en lugar de las habituales opciones privativas. Podemos no gastar un euro en artistas que apoyan a la SGAE o en compañías que promueven el DRM. Podemos compartir a diestro y siniestro, aprovechar las bibliotecas públicas, generar conocimiento para todos. Podemos difundir las bondades de una cultura universal, accesible y perdurable; una cultura en manos de todos, generada por y para todos. Poder, podemos pero ¿queremos?

Yo sí.

 

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!