OSMC es una distribución Debian para Raspberry PI (entre otros) que incluye Kodi. Con ella puedes convertir tu Raspberry PI en un centro multimedia, conectarla a la televisión, manejarla desde el mando a distancia, etc.

El OSMC se maneja fundamentalmente desde el mando a distancia de la televisión, pero es una instalación Debian que tiene acceso remoto también mediante SSH. Esto es muy útil para, por ejemplo, instalar más cosas en la Raspberry PI y utilizarla para más tareas que el propio centro multimedia que proporciona OSMC.

OSMC suele publicar una actualización mensual, accesible desde el mando a distancia de la televisión. El problema se da cuando ese OSMC está en casa de tus padres, por ejemplo, y tienes que estar recordándoles de vez en cuando que tienen que actualizar, o bien es una de esas muchas pequeñas tareas que te toca realizar cuando estás de visita.

Aprovechando el acceso remoto por SSH que proporciona OSMC, sería posible realizar las actualizaciones a distancia, pero el procedimiento Debian normal no funciona correctamente, pudiendo llegar a dañar la instalación OSMC. Ocurren cosas extrañas, como que los comandos habituales de actualización no funcionen, que la conexión SSH se corte a mitad del proceso, etc. En resumen, un desastre.

Tras un tiempo lidiando con estos problemas, me decidí a realizar una consulta en el foro oficial de OSMC. El procedimiento correcto es el siguiente:

$ sudo systemctl start manual-update

Este comando cierra el Kodi en ejecución, actualiza el sistema y vuelve a lanzar el Kodi, previo reinicio del sistema operativo si es necesario.

Este procedimiento puede cambiar en el futuro, pero, de momento, todo funciona como debe.

Veo muchos administradores de sistemas recomendando el uso de ssh -A con alegría, sin explicar los riesgos de seguridad asociados.

Todos sabemos que ssh permite entrar en servidores remotos de forma segura. Suponiendo que ese servidor sea una frontera y queramos saltar de allí a otros servidores de la red interna, tenemos diferentes posibilidades:

• Tener una clave ssh en ese servidor frontera, lanzar un ssh-agent en él y cargar la clave. El problema es que tenemos una clave ahí y, por tanto, necesitamos poder confiar en ese servidor.
• Utilizar ssh para establecer un túnel con el servidor frontera y emplear dicho túnel para enviar conexiones ssh nuevas a los servidores internos. Esta configuración es segura, pero complicada y poco transparente.
• Utilizar ssh -A para que al establecer sesiones ssh a otros servidores (una vez que estamos conectados al servidor frontera), la solicitud de autenticación se canalice al ssh-agent de nuestro propia máquina personal. La clave ssh nunca sale de nuestra máquina.

ssh -A parece perfecto y seguro, salvo por un pequeño detalle: nuestro ssh-agent local completará cualquier petición de autenticación que le llegue. Si estamos conectados a un servidor malicioso, los malos podrían solicitar a nuestro ssh-agent autenticaciones para servidores diferentes, conectarse a ellos con nuestra identidad y hacer allí lo que les de la gana, incluyendo instalar sus propias claves públicas ssh para poder entrar con posterioridad sin depender de nosotros. Todo ello en milisegundos y sin que nos enteremos.

Leer más…

En Estaciones meteorológicas de baja calidad, WeeWX y modificaciones en la base de datos "a pelo" explico los motivos por los que a veces resulta conveniente modificar manualmente los registros de la base de datos de la estación meteorológica gestionada con WeeWX.

El procedimiento cambia bastante en la última versión WeeWX, como describo a continuación. En realidad el proceso se ha simplificado.

Leer más…

En Wake On Lan, o cómo encender ordenadores de forma remota explico cómo despertar una máquina concreta de la cual conoces su dirección ethernet. El último paso que necesito en mi entorno es obtener la dirección IP a partir de esa dirección ethernet.

En mi caso no puedo recurrir al típico truco de asignación fija de dirección IP porque no tengo control de la infraestructura y mi padre cambia de router con frecuencia. Puedo conectarme a la Raspberry PI que tengo en su red local a través de una VPN y, desde ella, saltar al servidor una vez que lo haya encendido.

La dirección IP local del servidor puede cambiar, así que tengo que localizarla. Existen muchas formas de hacerlo: arrancar una VPN cuando se enciende el servidor, registrarse en un servicio DNS, enviar paquetes de identificación en la red local, etc.

Leer más…

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…