En mi artículo Backup doméstico seguro con Linux, cifrado y ZFS (IV): Equipo nuevo, publicado a finales de 2014, comento de pasada que puedo encender un servidor mediante la tecnología WakeOnLan, pero no he explicado los detalles en casi tres años.

WakeOnLan es una funcionalidad disponible en la mayoría de los ordenadores fabricados en los últimos veinte años. Si se activa en el firmware del ordenador y este está conectado a la red con un cable ethernet, el puerto de red estará activo aunque el ordenador esté apagado (siempre que esté enchufado a la electricidad, claro).

Con WakeOnLan, el puerto ethernet permanecerá a la escucha esperando recibir un paquete de red con un formato especial: Es un paquete broadcast en cuyo interior, en cualquier parte, aparecen seis bytes con el valor 255, seguidos por dieciseis repeticiones de la dirección ethernet de la máquina que queremos despertar. Vale cualquier tipo de paquete ethernet siempre que se envíe a la dirección broadcast de la red.

Leer más…

En la configuración que describo en Activación de DNSSEC en BIND con DNS dinámico, el servidor DNS BIND genera registros NSEC en vez de NSEC3. ¿Y qué? ¿Por qué importa eso?.Lo explico clarito (creo) en Por qué es conveniente usar NSEC3 en vez de NSEC en un dominio DNSSEC.

Con todo esto ya entendemos por qué es conveniente mejorar la receta descrita en Activación de DNSSEC en BIND con DNS dinámico y pasar a usar NSEC3.

Nada más simple:

$ rndc signing -nsec3param 1 0 10 auto example.org

El primer parámetro es el hash a emplear (en este caso SHA1). El cero indica los flags a aplicar que, en este caso, no nos interesan. El 10 es el número de iteraciones. La sal en sí es el siguiente campo. Si indicamos auto, el programa proporcionará 64 bits aleatorios. Personalmente eso me parece poco, prefiero 160 bits, aunque eso incrementará el tamaño de la respuesta DNS:

$ python3 -c "import secrets; print(secrets.token_hex(40))"
611a1cf6aa1b891b4909ed9d5ebe9d11b452368b642ca7a73b4e96a7ae54639a589c4bef8afc651d
$ rndc signing -nsec3param 1 0 10 611a1cf6aa1b891b4909ed9d5ebe9d11b452368b642ca7a73b4e96a7ae54639a589c4bef8afc651d example.org

A partir de este momento la zona usará NSEC3. Veamos el mismo ejemplo propuesto en Activación de DNSSEC en BIND con DNS dinámico:

51PKTFM618079E60H7F0Q6IF0VT6P0D1.z.bt.jcea.es. 30 IN NSEC3 1 0 10 673A6224876B0486 OEPHDNT06U7U9UURA3UAPV240OVO88SP A RRSIG
51PKTFM618079E60H7F0Q6IF0VT6P0D1.z.bt.jcea.es. 30 IN RRSIG NSEC3 8 5 30 20170620071663 ...

Como vemos, la respuesta es similar al caso NSEC, pero ahora la cadena indica el rango de hashes cubierto por la respuesta NSEC3.

Si por algún motivo queremos volver a usar NSEC en la zona, haremos:

$ rndc-signing -nsec3param none example.org

Para empezar con los principios básicos, puedes leer Introducción a DNSSEC.

Gracias a DNSSEC un atacante malicioso no podrá manipular un registro DNS porque su firma digital RRSIG no puede ser falsificada. Pero, ¿puede falsificar la no existencia de un registro? Es decir, ¿puede negar falsamente que un registro DNS dado no exista?.

La respuesta es que no. Cuando DNSSEC gestiona una zona, añade multitud de registros propios. Los más evidentes son las firmas digitales RRSIG, pero hay más. Por ejemplo, los registros NSEC.

Los registros NSEC proporcionan authenticated denial of existence. Es decir, una prueba criptográfica de que un registro DNS no existe.

Su funcionamiento se describe en el RFC 4034 y el RFC 4035. Simplificando mucho, DNSSEC ordena todos los registros de la zona de forma canónica y genera registros NSEC para cubrir los huecos.

Por ejemplo, si una zona tiene los registros registro1 y registro3, pero NO registro2, una petición de DNS de registro2 se responderá indicando que el registro no existe y, además, aportará una prueba criptográfica de ello. Dicha prueba consiste en el registro NSEC asociado al nombre registro1 en el campo authority de la respuesta DNS, indicando que el siguiente nombre de la zona es registro3.

Leer más…

Aunque DNSSEC como protocolo lleva mucho tiempo entre nosotros, lo cierto es que el soporte software ha mejorado muy lentamente. Por fortuna, el progreso ha sido paulatino pero constante.

Las versiones modernas de BIND (la versión 9.10 de BIND se publicó en la primavera de 2014), uno de los servidores DNS más populares, disponen ahora de gestión completa y automática de DNSSEC para el caso de zonas DNS gestionadas mediante DNS dinámico.

Si estás verde en el tema DNSSEC, te recomendaría que leyeses primero mi artículo Introducción a DNSSEC.

Para el caso de zonas gestionadas mediante DNS dinámico, BIND funciona de la siguiente manera:

• Cualquier cambio en la zona se almacena en una pequeña base de datos binaria no documentada, gestionada por BIND de forma interna y automática.

• Esa pequeña base de datos se vuelca a texto cada cierto tiempo, típicamente cada diez minutos. Ese documento de texto tiene el formato habitual de una zona DNS normal y corriente.

  En caso de corrupción de la base de datos de la zona, BIND puede utilizar el backup de texto para reconstruirla.

  Podemos incluso hacer ediciones manuales de la zona simplemente parando BIND, borrando la base de datos de la zona y editando su fichero de backup en texto. Cuando lancemos BIND otra vez, la base de datos se reconstruirá a partir del texto.

Que la gestión se realice de esta manera posibilita que BIND efectúe actualizaciones en la zona. Esto es necesario por la propia gestión de DNS dinámico (crear, borrar y modificar registros), pero la misma flexibilidad permite que BIND automatice la gestión DNSSEC de la zona. BIND lo hace todo, incluyendo actualizar el número de serie de la zona para sincronizar los servidores de DNS secundarios.

Leer más…

Entradas anteriores sobre este tema:

• Cómo corregir la desincronización de audio en un fichero Matroska.
• Determinar automáticamente el desfase de audio en un fichero MKV.
• Sincronización de sonido cuando la tasa de refresco de vídeo es irregular.
• Resincronizar audio cuando el vídeo se congela un momento.
• Determinar automáticamente el desfase de audio en un fichero MKV (II).
• Determinar automáticamente el desfase de audio en un fichero MKV (III).

Hoy me he encontrado con un caso nuevo: tasa de audio irregular con huecos en las marcas de tiempo.

La fuente original en este caso está montada a base de trozos de audio, y entre unos audios y otros hay huecos. Dichos huecos no son trozos de audio en silencio, sino que ni siquiera existen tramas de audio durante esos segundos. Es decir, revisando las marcas temporales de las tramas de audio, vemos que hay huecos.

¿Qué ocurre cuando un reproductor se encuentra con esos huecos?. Pues que simplemente meterá silencio. Bien.

El problema surge cuando exportamos una pista de sonido con huecos en las marcas temporales a un formato que no incluye marcas temporales o bien que las normaliza. El efecto es que esos huecos desaparecen. Desaparecen esas pausas.

Leer más…

En Elimina los mensajes duplicados en tu IMAP4 presento un pequeño programa Python que busca y elimina los correos electrónicos duplicados en nuestros buzones IMAP4. Os remito a dicho artículo para entender por qué necesito todo esto.

Para ello, el programa analiza el contenido de todas las carpetas IMAP4, extrae las cabeceras de todos los mensajes y los compara buscando duplicados.

Este proceso es simple, pero lento en tiempo y costoso para el servidor IMAP4, ya que debe analizar todos y cada uno de los mensajes del sistema. En configuraciones de correo como la mía, con cientos de buzones, millones de mensajes y docenas de gigabytes de contenido, estos defectos se notan.

En esta ocasión presento un segundo programa Python para realizar la misma tarea de manera diferente:

Leer más…

De las muchas cosas que me molestan de una página web, las cabeceras y pies estáticos que se comen parte de la pantalla son de las más habituales. Afortunadamente, nos podemos deshacer de ellas con facilidad.

Veamos un ejemplo:

Leer más…

Como ya se ha explicado en el pasado, utilizo getmail para alimentar el servidor IMAP4 que tengo en mi propio portátil.

Getmail tiene varios problemas. Por ejemplo, guarda la lista de mensajes procesados solo cuando la descarga IMAP4 se completa con normalidad. Si ocurre cualquier problema, el proceso volverá a empezar desde el principio. Dado mi volumen de correo, tener el portátil apagado una semana supone una descarga de correo de varias horas, y si la conexión se corta durante el proceso, getmail volverá a empezar.

Esto ocasiona retrasos y molestias innecesarias, pero el mayor problema es que tendré mensajes duplicados. O triplicados. O cuadruplicados.

Aunque se trata de un problema ocasional, invita a errores: da lugar a una lista inmensa de mensajes a revisar, o puedes borrar un mensaje respondido y quedarte con una copia que no tendrá la marca de contestado.

He escrito el siguiente programa para hacer frente a este problema:

Leer más…