Wake On Lan, o cómo encender ordenadores de forma remota

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…

BORRADOR: Evaluación de Apache Traffic server como proxy/caché HTTPS en ambos

Advertencia

Este documento se escribió en junio de 2013 como un borrador de informe para un cliente. El informe no llegó a completarse nunca porque al cliente le bastó el borrador para avanzar al siguiente paso del proyecto.

Por tanto, se trata de un documento incompleto y que, además, refleja el estado de la tecnología en junio de 2013. Las cosas han evolucionado desde entonces, naturalmente.

La necesidad concreta del cliente es un proxy HTTPS cuyo backend sea también HTTPS.

Este documento se ha publicado por interés histórico y con el permiso explícito del cliente.

1   Introducción

En un documento previo se evaluó el uso de Apache HTTP server como servidor proxy/caché cuando tanto las conexiones desde el navegador del usuario como las conexiones del proxy a los sistemas “upstream” deben estar protegidas por HTTPS. La conclusión fue que Apache HTTP server es muy versátil y capaz, pero no cumple nuestros requisitos de escalabilidad.

En el mismo documento se revisaban someramente otras alternativas y se recomendaba evaluar en primer lugar otro producto Apache: Apache Traffic Server.

Los motivos para este recomendación son:

Leer más…

BORRADOR: Evaluación de Apache HTTP server como proxy/caché HTTPS en ambos extremos

Advertencia

Este documento se escribió en junio de 2013 como un borrador de informe para un cliente. El informe no llegó a completarse nunca porque al cliente le bastó el borrador para avanzar al siguiente paso del proyecto.

Por tanto, se trata de un documento incompleto y que, además, refleja el estado de la tecnología en junio de 2013. Las cosas han evolucionado desde entonces, naturalmente.

La necesidad concreta del cliente es un proxy HTTPS cuyo backend sea también HTTPS.

Este documento se ha publicado por interés histórico y con el permiso explícito del cliente.

1   Introducción

DXXXl CXXXn se pone en contacto telefónico conmigo la tarde del domingo 28 de abril de 2013, indicándome que las divisiones de banca del grupo SXXXr han sido amenazadas con ataques de denegación de servicio, que se realizarían a partir del 7 de mayo.

Con el fin de protegerse en lo posible, se está procediendo a configurar sistemas y a contratar servicios externos de paliación de ataques DDoS. Simultáneamente se planea desarrollar tecnología interna con este fin, con el propósito de disponer de varias vías de defensa alternativas, con diferentes costes y calidades.

En la conversación telefónica se me encarga la evaluación del servidor web Apache como plataforma proxy para la detección y prevención de ataques a servicios HTTPS. El plazo disponible es de una semana y el trabajo se tasa en XXX €.

2   Requisitos

El proyecto requiere cumplir estos requisitos:

Leer más…

Usar NSEC3 en vez de NSEC en un dominio DNSSEC con gestión de DNS dinámico

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

Mantenimiento

El valor de la sal hay que cambiarla de vez en cuando, tal y como se describe en Activación de DNSSEC en BIND con DNS dinámico.

Por qué es conveniente usar NSEC3 en vez de NSEC en un dominio DNSSEC

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…

Activación de DNSSEC en BIND con DNS dinámico

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…

Sincronización de sonido cuando la tasa de audio es irregular

Entradas anteriores sobre este tema:

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…

Elimina los mensajes duplicados en tu IMAP4 (II)

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…

Elimina los mensajes duplicados en tu IMAP4

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…