Archivo de la categoría: Seguridad

Paso a Paso: Instalar, Configurar y Securizar Node-RED en Raspberry Pi

Instalar Imagen Raspberry Pi OS (Antiguo Raspbian)

Instalación recomendada usando Raspberry Pi Imager: https://www.raspberrypi.org/software/

Raspberry Pi Imager es la forma rápida y fácil de instalar Raspberry Pi OS y otros sistemas operativos en una tarjeta microSD, lista para usar con su Raspberry Pi. Vídeo de 40 segundos de como usar Raspberry Pi Imager: https://www.youtube.com/watch?v=J024soVgEeM 

Descargue e instale Raspberry Pi Imager con un lector de tarjetas SD. Coloque la tarjeta SD que usará con su Raspberry Pi en el lector y ejecute Raspberry Pi Imager.

Configuración Raspberry Pi OS

Pasos para la instalación con monitor, ratón y teclado:

  • Seguir con el asistente de instalación que aparece al iniciar: cambiar contraseña, cambiar el nombre (hostname), configurar y actualizar Raspberry Pi.
  • Conectar a Internet. Wifi o Ethernet
  • Activar VNC y SSH para acceso remoto

Pasos para instalación headless:

Una vez entramos en Raspberry Pi, seguimos los pasos del asistente que nos indica para cambiar contraseña, cambiar el nombre (hostname), configurar y actualizar Raspberry Pi

Instalar Node-RED

No instalar la versión que aparece en software recomendado de Raspberry Pi OS.

Seguir esta instalación: https://nodered.org/docs/getting-started/raspberrypi, para ello ejecutar el comando para instalar y actualizar:

Para ejecutar Node-RED en el arranque: sudo systemctl enable nodered.service

Para comprobar que funciona abrir un navegador y enterar en: http://{your_pi_ip-address}:1880 

En caso de problemas ver el log con: node-red-log

Configurar Node-RED

Para configurar Node-RED ver: https://nodered.org/docs/user-guide/runtime/configuration

El fichero de configuración se encuentra normalmente en $HOME/.node-red/settings.js

Desde las últimas versiones es posible configurar y securizar Node-RED con un asistente ejecutando: node-red admin init que genera un fichero de configuración settings.js. Esto hace mucho más fácil empezar con Node-RED instalado bien configurado y seguro.

Ejecutar node-red admin init y configurar:

  • settings file
  • user security
  • proyectos
  • tema
  • editor mónaco
  • módulos externos

Lo único que no queda configurado es la parte de https, almacenamiento persistene de variables de contexto y la contraseña de dashboard.

Mejoras en la configuración:

  • Activar proyectos en Node-RED (en node-red admin init)
editorTheme: {
        projects: {
            enabled: true
        }
    }
  • Activar almacenamiento persistente de las variables de contexto. Activar grabar datos en local o en memoria
contextStorage: {
        default: "memoryOnly",
        memoryOnly: { module: 'memory' },
        file: { module: 'localfilesystem' }
    },
  • Activar editor mejorado (en node-red admin init)
editorTheme: {
        codeEditor: {
            lib: "monaco"
        }
    }

Autenticación y Autorización del editor Node-RED

Por defecto, el editor Node-RED no está protegido: cualquier persona que pueda acceder a su dirección IP puede acceder al editor e implementar cambios.

Para securizar Node-RED a nivel de atenticación y autorización seguir: https://nodered.org/docs/user-guide/runtime/securing-node-red para añadir usuario y password, así como otras configuraciones de seguridad.

NOTA: si se ha ejecutado node-red admin init, este paso ya está hecho.

Para habilitar la autenticación basada en usuario y password, descomentar la propiedad adminAuth del fichero de configuración. Editar el fichero settings.js con nano /home/pi/.node-red/settings.js y descomentar estas líneas:

adminAuth: {
        type: "credentials",
        users: [{
            username: "admin",
            password: "$2a$08$zZWtXTja0fB1pzD4OlKj7wCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
            permissions: "*"
        }]
    },

Para calcular la contraseña se usa: node-red admin hash-pw y una vez cifrada la contraseña pegar en password.

Reiniciar el servicio Node-RED:  sudo systemctl restart nodered.service 

Entrar en Node-RED de nuevo en http://{your_pi_ip-address}:1880 y comprobar que pide contraseña.

Si se quiere añadir un usuario de solo lectura configurar settings.js como:

adminAuth: {
    type: "credentials",
    users: [
        {
            username: "admin",
            password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
            permissions: "*"
        },
        {
            username: "readonly",
            password: "$2b$08$wuAqPiKJlVN27eF5qJp.YKo98uy6ZYONW7a/UWYxDTtwKFCdB8F19y",
            permissions: "read"
        }
    ]
}

Reiniciar el servicio Node-RED:  sudo systemctl restart nodered.service

Comprobar que el usuario de solo lectura no puede hacer deploy.

Autenticación UI (Dashboard y Nodos HTTP)

Manual: https://nodered.org/docs/user-guide/runtime/securing-node-red#http-node-security

Para proteger las rutas HTTP expuestas por los nodos y el dashboard se puede usar una autenticación básica.

La propiedad httpNodeAuth en su archivo settings.js se puede usar para definir un nombre de usuario y contraseña únicos que podrán acceder a las rutas.

Editar el fichero settings.js con nano /home/pi/.node-red/settings.js y descomentar estas líneas y poner el usuario deseado:

httpNodeAuth: {user:"user",pass:"$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN."},

La propiedad pass, usa el mismo formato que adminAuth utilizando el algoritmo bcrypt. Para calcular la contraseña se usa: node-red admin hash-pw y una vez cifrada la contraseña pegar en password.

Reiniciar el servicio Node-RED:  sudo systemctl restart nodered.service 

Entrar en Node-RED de nuevo en http://{your_pi_ip-address}:1880/ui y comprobar que pide contraseña.

Comunicaciones Cifradas TLS Node-RED

Node-RED proporciona soporte TLS para conexiones de red cifradas y autenticación.

Es muy fácil crear sus propios certificados SSL autofirmados y claves de cifrado utilizando herramientas de software libre. Estas claves y certificados son tan seguros como los comerciales.

Utilizaremos openssl para crear nuestra propia autoridad de certificación (CA), claves de servidor y certificados.

Estos pasos nos permitirán una conexión cifrada entre un cliente del navegador web y el servidor en Node-RED. En este caso sólo necesitamos un certificado de servidor de confianza en el Cliente.

El servidor (Node-RED) necesita: 

  • Certificado de la CA (autoridad de certificación) que ha firmado el certificado del servidor en en Node-RED (ca.crt)
  • Certificado del servidor firmado por la CA. (srv.crt)
  • Clave privada del servidor para el descifrado. (server.key)

Pasos:

  • sudo apt-get install openssl – instalar openssl
  • Crear un directorio llamado certificados en /home/pi con: mkdir certificados y entrar en el directorio para guardar los certificados y claves
  • openssl genrsa -des3 -out ca.key 2048 – Genera una RSA key privada para la CA. Pide contraseña (opción -des3)
  • openssl req -new -x509 -days 1826 -key ca.key -out ca.crt – Crear un certificado para la CA utilizando la clave de la CA que creamos en el paso anterior. Poner en CN el nombre o IP del servidor (p.e. raspberrypi.local o 192.168.1.10)
  • openssl genrsa -out server.key 2048 – Genera una RSA key privada para el servidor que será utilizada por el broker
  • openssl req -new -out server.csr -key server.key – crear una solicitud de certificado .csr. Al rellenar el formulario, el nombre común (CN) es importante y suele ser el nombre de dominio del servidor, el resto se pueden dejar vacíos. Debe utilizar el mismo nombre cuando configure la conexión del cliente. Como somos la CA, no es necesario mandar la solicitud a la CA.
  • openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360 – Utilizar la clave de la CA para verificar y firmar el certificado del servidor. Esto crea el archivo server.crt. Pide la contraseña usada para la ca.key

Con estos pasos hemos obtenido los siguientes ficheros:

  • ca.crt – Certificado de la CA
  • ca.key – Par de claves para la CA. Solo usar para crear un nuevo certificado
  • server.crt – Certificado del servidor firmado por la CA
  • server.csr – Solicitud de certificado. No es necesario.
  • server.key – Par de claves del servidor
  • ca.srl – Cada certificado emitido debe contener un número de serie único asignado por la CA. Debe ser único para cada certificado emitido por una determinada CA. OpenSSL guarda los números de serie utilizados en un archivo, por defecto tiene el mismo nombre que el archivo del certificado de la CA con la extensión sustituida por srl. Así que se crea un archivo llamado ca.srlc

NOTA: Tenga en cuenta que los certificados y las claves creadas pueden utilizarse en Node-RED, y también en un servidor web.

Para ver el contenido de un certificado en texto, porque están codificados en base64, usar: openssl x509 -in server.crt -text -noout

Editar el fichero settings.js con nano /home/pi/.node-red/settings.js y descomentar estas líneas y poner los datos de los certificados:

var fs=require("fs")

https: {
        key: fs.readFileSync('/home/pi/certificados/server.key'),
        cert: fs.readFileSync('/home/pi/certificados/server.crt')
    },
requireHttps: true,

Reiniciar el servicio Node-RED: sudo systemctl restart nodered.service

Entrar en Node-RED de nuevo en https://{your_pi_ip-address}:1880 y comprobar que no funciona http://{your_pi_ip-address}:1880

La web aparecerá como no segura en el navegador, pero se puede añadir el fichero ca.crt como certificado raíz confiable en el ordenador y ya aparecerá como una web segura.

Anuncio publicitario

Conceptos Básicos de Comunicaciones Seguras

Puesto que la base de IoT es la comunicación, debemos establecer conexiones seguras, para ello es básico la autenticación y que la comunicación sea cifrada.

Que es TLS

Transport Layer Security (TLS) y Secure Sockets Layer (SSL) proporcionan un canal de comunicación seguro entre un cliente y un servidor. En el núcleo, TLS y SSL son protocolos criptográficos que utilizan un mecanismo de handshake para negociar varios parámetros para crear una conexión segura entre el cliente y el servidor. Una vez completado el handshake, se establece una comunicación cifrada entre el cliente y el servidor y ningún atacante puede escuchar cualquier parte de la comunicación. Los servidores proporcionan un certificado X509 (normalmente emitido por una autoridad de confianza) que los clientes utilizan para verificar la identidad del servidor.

Wikipedia: https://es.wikipedia.org/wiki/Seguridad_de_la_capa_de_transporte 

Porque es TLS Importante

Imagine que está enviando una postal. Está claro quién es el destinatario de la tarjeta y el cartero se asegurará de que llegue la tarjeta. Pero, nada impide que el cartero lea el contenido de la tarjeta. De hecho, todas las personas que participan en la entrega de la postal pueden leer el contenido de la misma. Un trabajador postal malintencionado podría incluso alterar el contenido de su tarjeta!

La esencia de este escenario también se aplica a las redes informáticas en general y a Internet en particular. El uso de TCP/IP simple es como enviar una postal. El paquete TCP pasa a través de muchos componentes de la infraestructura (routers, cortafuegos, puntos de intercambio de Internet) antes de llegar al objetivo. Cada participante en el camino puede leer el contenido del paquete en texto claro (e incluso modificarlo). Este no es un escenario ficticio, la historia reciente muestra que el tráfico de Internet es frecuentemente intervenido por agencias de inteligencia. Aunque la mayoría de los atacantes no tienen muchos recursos para escuchar a escondidas su conexión, no es difícil para los atacantes sofisticados realizar ataques Man-In-The-Middle.

TLS es todo acerca de proporcionar un canal de comunicación seguro. TLS garantiza que el contenido de su comunicación no puede ser leído o alterado por terceros, asumiendo que se utilicen suites de cifrado seguras y que no haya ataques no descubiertos en la versión de TLS utilizada.

TLS es en realidad sólo una versión más reciente de SSL. Corrige algunas vulnerabilidades de seguridad en los protocolos SSL anteriores.

Aquí está el historial completo de las versiones de SSL y TLS:

  • SSL 1.0 – nunca se ha publicado debido a problemas de seguridad.
  • SSL 2.0 – lanzado en 1995. Desaparecido en 2011. Ha tenido problemas de seguridad.
  • SSL 3.0 – lanzado en 1996. Se depreció en el 2015. Ha tenido problemas de seguridad.
  • TLS 1.0 – lanzado en 1999 como una actualización a SSL 3.0. La depreciación prevista para el año 2020.
  • TLS 1.1 – publicado en 2006. La depreciación prevista para el año 2020.
  • TLS 1.2 – publicado en 2008.
  • TLS 1.3 – lanzado en 2018.

No sólo es TLS más seguro y eficiente, sino que la mayoría de los navegadores web modernos ya no soportan SSL 2.0 y SSL 3.0. Por ejemplo, Google Chrome dejó de ser compatible con SSL 3.0 en 2014 y la mayoría de los principales navegadores tienen previsto dejar de ser compatibles con TLS 1.0 y TLS 1.1. Google empezó a mostrar notificaciones de advertencia ERR_SSL_OBSOLETE_VERSION en Chrome.

Navegadores que usan TLS 1.3: https://caniuse.com/tls1-3 

Para comprobar la versión SSL que usa el navegador, ver: https://www.howsmyssl.com/ 

Información del INCIBE: https://www.incibe.es/protege-tu-empresa/blog/si-tu-web-cuenta-certificado-seguridad-comprueba-utilizas-version-segura-del 

Más información:

Certificados SSL

¿Qué es un certificado SSL? Básicamente podemos decir que es un estándar de seguridad global que permite que los datos transferidos al navegar vayan cifrados correctamente. Evita que la información enviada entre un navegador y un servidor pueda ser filtrada. 

Para establecer esta conexión segura, se instala en un servidor web un certificado SSL (también llamado «certificado digital») que cumple dos funciones:

  • Autenticar la identidad del sitio web, garantizando a los visitantes que no están en un sitio falso.
  • Cifrar la información transmitida.

Los certificados SSL son emitidos por Autoridades de Certificación (CA), que son organizaciones de confianza a cargo de verificar la identidad y legitimidad de la entidad que solicita un certificado.

La autoridad de certificación (CA), también a veces referido como autoridad de certificación, es una empresa u organización que actúa para validar las identidades de las entidades (como sitios web, direcciones de correo electrónico, empresas o personas individuales) y vincularlas a claves criptográficas mediante la emisión de documentos electrónicos conocidos como Certificados digitales. Un certificado digital proporciona:

  • Autenticación, al servir como credencial para validar la identidad de la entidad a la que se expide.
  • Cifrado, para una comunicación segura a través de redes inseguras como Internet.
  • Integridad de documentos firmados con el certificado para que no puedan ser alterados por un tercero en tránsito.

El rol de la CA es recibir solicitudes de certificados, autenticar las solicitudes, emitir certificados y mantener información sobre el estado de los certificados emitidos.

Hay varios tipos de certificados SSL según la cantidad de nombres de dominio o subdominios que se tengan, como por ejemplo:

  • Único: asegura un nombre de dominio o subdominio completo (FQDN).
  • Comodín: cubre un nombre de dominio y un número ilimitado de sus subdominios.
  • Multidominio: asegura varios nombres de dominio.

Otros tipos de certificados dependen del nivel de validación requerido, como por ejemplo:

  • Validación de dominios: este nivel de validación es el más económico y brinda un cifrado básico y la verificación del titular del registro del nombre de dominio. Este tipo de certificado se entrega en unos minutos o unas pocas horas.
  • Validación de organización: además del cifrado básico y la verificación del titular del registro del nombre de dominio, autentica algunos detalles del propietario, como el nombre y su dirección. Este tipo de certificado se entrega en unas pocas horas o algunos días.
  • Validación extendida (EV): proporciona el mayor nivel de seguridad debido a la investigación exhaustiva que se lleva a cabo antes de emitir este certificado según lo estipulado en las pautas establecidas por el consorcio de la industria de certificados SSL. Además de la autenticación de la entidad y la titularidad del registro del nombre de dominio, se verifica la existencia legal, física y operativa de la entidad. Este tipo de certificado se entrega en unos días o semanas.

Coste de certificados: https://www.ssl.com/es/certificados/ 

Certificado Raíz: En criptografía y seguridad informática, un certificado raíz es un certificado de clave pública sin firma o autofirmado que identifica la autoridad de certificación raíz (CA). Un certificado raíz forma parte de un esquema de infraestructura de clave pública. La variedad comercial más común está basada en el estándar ITU-T X.509, el cual normalmente incluye una firma digital de una autoridad de certificación.

En SSL/TLS, S/MIME y otras aplicaciones de Certificados X.509, se utiliza una jerarquía de certificados para verificar la validez del emisor de un certificado. Esta jerarquía se conoce como cadena de confianza. En una cadena de confianza, los certificados son emitidos y firmados por certificados que viven más arriba en la jerarquía.

Es fácil ver una cadena de confianza por sí mismo al inspeccionar un HTTPS certificado del sitio web. Al comprobar certificado SSL /TLS en un navegador web, encontrará un desglose de la cadena de confianza de ese certificado digital, incluido el ancla de confianza, los certificados intermedios y el certificado de entidad final. Estos diversos puntos de verificación están respaldados por la validez de la capa anterior o «enlace», que se remonta al ancla de confianza.

Firma digital: https://firmaelectronica.gob.es/Home/Ciudadanos/Firma-Electronica.html 

Comprobar seguridad de un certificado SSL:

Más información:

Noticias sobre certificados SSL:

Cómo Funciona la Comunicación Segura

Pasos:

  1. La CA genera el certificado del servidor (srv.crt) con la clave pública (paso previo ya hecho).
  2. El cliente se conecta al servidor y recibe el certificado del servidor.
  3. El cliente verifica que el certificado del servidor ha sido firmado por una autoridad de certificación (CA) válida.
  4. El cliente cifra la comunicación con la clave pública del certificado ya validado.
  5. La comunicación cifrada sólo puede ser descifrada con la clave privada del servidor que en ningún momento ha salido del servidor.

Más información:

Certificados Gratuitos con Let’s Encrypt

Let’s Encrypt​ es una autoridad de certificación que se puso en marcha el 12 de abril de 2016 y que proporciona certificados X.509 gratuitos para el cifrado de Seguridad de nivel de transporte (TLS) a través de un proceso automatizado diseñado para eliminar el complejo proceso actual de creación manual, la validación, firma, instalación y renovación de los certificados de sitios web seguros.

Su objetivo es cifrar toda la web y hacerla un lugar que respete más la privacidad. Google ha estado fuertemente empujando a HTTPS en todas partes durante los últimos años. Y Let’s Encrypt realmente ha comenzado a tener un gran impacto en la industria, especialmente en lo que se refiere a hospedaje SSL de forma gratuita.

Sólo se emiten certificados de dominio validado, no se ofrecerá la validación de organizaciones certificados de validación extendida, esto significa que los certificados no tienen una garantía, que asegura al usuario final contra pérdida de dinero al enviar un pago a un sitio web asegurado por SSL.

No cualquiera puede de repente convertirse en una autoridad de certificación, porque se necesita la confianza de diferentes plataformas. Exploradores y dispositivos confían en una entidad emisora de certificados (CA) aceptando el certificado raíz en su almacén raíz, que básicamente es una base de datos aprobado por CA que viene preinstalada con el explorador o el dispositivo.

Microsoft, Mozilla, Apple, todos tienen sus propios almacenes de raíz. Así que para convertirse en una entidad emisora de certificados, necesita tener la confianza de algunos de los grandes nombres de la industria. Cuando Let’s Encrypt se lanzó por primera ocasión recibieron firmas cruzadas de IdenTrust, que les dio la confianza de todos los principales navegadores.

Estadísticas Let’s Encrypt: https://letsencrypt.org/stats/ 

Transparencia de certificados: https://certificate.transparency.dev/. Todos los certificados emitidos o revocados son públicamente registrados y disponibles para cualquier persona a inspeccionar.

Herramienta de búsqueda de certificados: https://crt.sh/ 

Para que funcionen los certificados de Let’s Encrypt es necesario:

  • Tener el certificado IdenTrust DST X3 raíz en su almacén de confianza.
  • La plataforma debe soportar modernos certificados de SHA-2. Los certificados de Let’s Encrypt son compatibles con los navegadores modernos.

Al tener acceso a Let’s Encrypt, no es necesario entrar en el confuso proceso de obtención de las claves de su certificado, claves privadas, depurar el certificado intermedio, o generar una CSR. Básicamente es una integración con un solo clic. Let’s Encrypt también es completamente segura. Es respaldada por las corporaciones y empresas como Automattic, Mozilla, Cisco, Google Chrome, Facebook, Sucuri – sólo para nombrar unas cuantas.

Los certificados SSL de Let’s Encrypt por diseño, caducan cada 90 días y hay que programar la renovación automática o hacerlo manualmente.

Más información:

Instalar Certificado

Instalar certificado TLS/SSL confiado de Lets Encrypt:

Certbot simplifica todo el proceso: https://certbot.eff.org/ 

Instrucciones certbot: https://certbot.eff.org/instructions 

Certbot en CentOS 8: https://certbot.eff.org/lets-encrypt/centosrhel8-other 

Más información:

Instalar: 

  • sudo yum install epel-release
  • yum install certbot

Solo certificado: certbot certonly –standalone

Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/midominio.com/fullchain.pem

   Your key file has been saved at:
   /etc/letsencrypt/live/midominio.com/privkey.pem

   Your cert will expire on 2021-02-04. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"

Solo con certbot certonly –standalone ya me genera el certificado.

Para renovar hacer: certbot renew

Interesante nodo de lets encrypt para solicitar y renovar certificados: https://github.com/bartbutenaers/node-red-contrib-letsencrypt 

Mejores prácticas

Utilice siempre TLS si puede

Utilice siempre TLS si puede permitirse el ancho de banda adicional y sus clientes tienen suficiente potencia de cálculo y memoria para TLS. Como regla general, utilice siempre canales de comunicación encriptados, también para otros protocolos como HTTP, MQTT, etc…

Utilizar la versión TLS más alta posible

Aunque TLS 1.0, TLS 1.1 y TLS 1.2 no están rotos en la práctica (al menos hasta ahora), siempre debe utilizar la versión más alta de TLS que sea factible para sus clientes. Existen ataques conocidos contra TLS 1.0 y 1.1, que pueden ser mitigados. Algunos ataques están diseñados para explotar HTTP.

En mosquitto, apachem etc.., se puede elegir la versión de TLS a usar en la configuración.

No utilice SSLv3

No utilice SSLv3 ni ninguna versión anterior. El ataque a POODLE demostró que SSLv3 debe ser considerado roto. Todas las demás versiones de SSL también se consideran rotas y no deben utilizarse.

Siempre validar la cadena de certificados X509

Para evitar ataques Man-In-The-Middle, haga que sus clientes (MQTT, HTTP, etc…) validen el certificado X509 del servidor. Algunas implementaciones de clientes descuidadas utilizan un enfoque «allow-all» (a menudo en combinación con certificados de servidor autofirmados). Siempre vale la pena hacer un esfuerzo adicional para validar los certificados.

Utilizar certificados de las autoridades de certificación de confianza

Los certificados de las autoridades de certificación de confianza valen el dinero extra que cuestan. Los certificados autofirmados no se adaptan bien a muchas implementaciones de TLS y a menudo conducen a un código erróneo. Por ejemplo, código que no valida los certificados y abre la puerta a los ataques Man-In-The-Middle.

Si su broker de MQTT es público, un certificado de confianza es imprescindible. Si utiliza MQTT sobre sockets web, los certificados autofirmados no son óptimos. La mayoría de los navegadores web modernos no permiten conexiones de sockets web a recursos con certificados no confiables.

Utilizar otros mecanismos de seguridad

Además de TLS, siempre es una buena idea utilizar otros mecanismos de seguridad como el cifrado de la carga útil, las verificaciones de la firma de la carga útil y los mecanismos de autorización. En general, más seguridad nunca hace daño.

Utilice sólo suites de cifrado seguro

Hay muchas suites de cifrado inseguras disponibles para TLS. Asegúrese de permitir únicamente suites de cifrado seguras para su comunicación. Se sabe que muchas suites de cifrado están rotas y no tienen una falsa sensación de seguridad.

Cipher Suite:

Más información: https://www.hivemq.com/blog/mqtt-security-fundamentals-tls-ssl

Conceptos Básicos de Ciberseguridad

La seguridad y la privacidad de los datos son los conceptos principales de la protección de datos. 

La seguridad de los datos es la prevención de accesos no autorizados a conjuntos de datos. Dichos accesos son los que desembocan en vulneraciones o ataques, Para lograr la seguridad, las organizaciones utilizan herramientas y soluciones tecnológicas como firewalls, autenticación de usuarios, limitaciones en la red y prácticas de seguridad adaptadas a cada entorno u organización. También pueden incluirse los procesos de encriptación y tokenización de manera a que no pueda ser posible la lectura de los datos en fases clave del tránsito de los mismos, por parte de los cibercriminales.

La privacidad de los datos se encarga de asegurar que los datos; ya sean procesados, almacenados o transmitidos sean consumidos de acuerdo a las regulaciones y normas. Así también, que estos datos puedan ser manipulados bajo el consentimiento de quien sea dueño de los mismos.

Tokenización: https://en.wikipedia.org/wiki/Tokenization_(data_security) 

Los pilares de la seguridad son:

  • Confidencialidad
  • Integridad
  • Disponibilidad

Confidencialidad: Cualidad de la información para no ser divulgada a personas o sistemas no autorizados.  Se trata básicamente de la propiedad por la que esa información sólo resultará accesible con la debida y comprobada autorización.

El objetivo de la confidencialidad es, prevenir la divulgación no autorizada de la información sobre nuestra organización.

Integridad: Cualidad de la información para ser correcta y no haber sido modificada, manteniendo sus datos exactamente tal cual fueron generados, sin manipulaciones ni alteraciones por parte de terceros. Esta integridad se pierde cuando la información se modifica o cuando parte de ella se elimina. Una garantía para mantenerla intacta es la firma digital.

El objetivo de la integridad es prevenir modificaciones no autorizadas de la información.

Disponibilidad: Aquella información a la que podemos acceder cuando la necesitamos a través de los canales adecuados siguiendo los procesos correctos.

El objetivo de la disponibilidad es prevenir interrupciones no autorizadas de los recursos informáticos.

Más información:

Mejorar seguridad en entornos IoT: https://www.arsys.es/blog/seguridad-entornos-iot/ 

Guia seguridad IoT INCIBE:

Otros artículos interesantes:

Recomendaciones Seguridad IoT

Vulneravilidades comunes de los dispositivos IoT: https://www.infoplc.net/actualidad-industrial/item/108035-vulnerabilidades-dispositivos-iot

Recomendaciones:

  • No abrir puertos innecesariamente. Si un servidor envía datos a un dispositivo IoT, este debe estar escuchando con un puerto abierto de entrada. Esto supone que el dispositivo tiene que estar escuchando en todo momento para que los datos sean enviados. Por esta razón, implementar protocolos COAP, MQTT, WebSockets y HTTP2.0 son mejores prácticas para proteger una conexión, independiente del protocolo de red usado durante el intercambio de información.
  • Cifrado de extremo a extremo. TLS / SSL protege el nivel superior del flujo de datos entre los dispositivos y cifra los datos mientras son transferidos. TLS / SSL es adecuado para la seguridad de la transmisión de datos, pero no los datos que residen en el dispositivo a menos que está encriptado. Para una verdadera seguridad de extremo a extremo, los datos deben cifrarse con Advanced Encryption Standard (AES).
  • Control de acceso basado en tokens. Mientras AES y TLS / SSL se pueden utilizar para cifrar los datos a medida que se está transfiriendo, otro reto importante es definir el control de quién y qué puede transmitir y recibir datos. Dentro del paradigma de publicación / suscripción, un enfoque de control de acceso basado en token puede ser utilizado para distribuir señales a los dispositivos para permitir el acceso a los canales de datos específicos. En su defecto usar contraseñas seguras.
  • Interfaces web seguras y certificadas. Uso de HTTPS para proteger la información transmitida con acceso mediante usuario y contraseña.
  • Autenticación y autorización. No solo prestar atención a la autenticación, sino también a los datos o recursos a los que se puede acceder.
  • Prestar atención a la privacidad. Determinar la cantidad de información personal recopilada y protegerlos adecuadamente, así como desidentificar o anonimizar.
  • Configuración de la seguridad. Usar protocolos seguros y actualizados sin vulnerabilidades conocidas. Usar las soluciones de cifrado más potentes.
  • Usar software y firmware seguro. Asegurarse de tener los dispositivos actualizados y con los parches de seguridad aplicados. No usar sistemas operativos obsoletos, ni librerías no mantenidas en el desarrollo de aplicaciones o firmware.
  • Deshabilitar funcionalidades no utilizadas. No habilitar características no usadas, no conectar dispositivos si no es necesario o apagar cuando no se use, deshabilitar o proteger el acceso remoto a los dispositivos IoT.
  • Habilitar el uso de logs. Guardar los eventos que se producen como accesos, cambios de contraseña, actualizaciones, etc..
  • Prestar atención a la seguridad física. Limitar el acceso a puertos del dispositivo y ubicarlos en sitios seguros (p.e. vandalismo, acceso de terceros, pérdidas de energía).
  • Realizar auditorías de seguridad con regularidad. Pentesting, comprobar visibilidad de los dispositivos en Internet (p.e. shodan), etc…
  • Pensar en la seguridad desde la fase de requisitos y diseño.
  • Almacenamiento de datos seguro. No exponer las bases de datos y usar procesos intermedios para insertar, modificar y acceder a los datos.
  • Gestionar y monitorizar los dispositivos IoT de forma centralizada. Comprobar su correcto funcionamiento y que no se produzcan eventos que puedan afectar a su seguridad. Poder apagar dispositivos de forma remota en caso que sea comprometido.

Configurar y Securizar Node-RED

Configurar Node-RED

Para configurar Node-RED seguir: https://nodered.org/docs/user-guide/runtime/configuration

Desde las últimas versiones es posible configurar y securizar Node-RED con un asistente ejecutando: node-red admin init que genera un fichero de configuración settings.js. Esto hace mucho más fácil empezar con Node-RED instalado bien configurado y seguro.

El fichero de configuración se encuentra normalmente en $HOME/.node-red/settings.js

El fichero de configuración por defecto es settings.js y está situado en /usr/lib/node-modules/node-red/ y puede encontrarse en https://github.com/node-red/node-red/blob/master/packages/node_modules/node-red/settings.js

Settings file: https://nodered.org/docs/user-guide/runtime/settings-file

Si no está seguro de qué archivo de configuración está usando Node-RED, debe verificar la salida del registro cuando se inicie Node-RED. Registrará la ruta completa al archivo:

  • 22 Jun 12:34:56 – [info] Settings file  : /Users/nol/.node-red/settings.js

El fichero por defecto viene con muchas opciones comentadas, para habilitarla, simplemente quitar el comentario “//”.

Al añadir una nueva opción asegurarse de añadir una coma al principio y final para separar del resto de opciones.

El fichero de flujos se encuentra por defecto en $HOME/.node-red/flows_<hostname>.json

Por defecto el directorio donde se guardan los nodos es $HOME/.node-red/nodes_modules

Existe una API de Node-RED que permite administrar remotamente en runtime: https://nodered.org/docs/api/admin/

Logging Node-RED

Ver https://nodered.org/docs/user-guide/runtime/logging

Node-RED utiliza un logger que escribe su salida en la consola. También admite el uso de módulos de logging personalizados para permitir que la salida se envíe a otra parte.

Esto se puede configurar mediante el fichero de configuración: https://nodered.org/docs/user-guide/runtime/settings-file

Securizar Node-RED (Autorización y Autenticación)

Por defecto, el editor Node-RED no está protegido: cualquier persona que pueda acceder a su dirección IP puede acceder al editor e implementar cambios.

Con node-red admin init configuro todo menos la parte de https y la contraseña de dashboard:

  • settings file
  • user security
  • proyectos
  • tema
  • editor mónaco
  • módulos externos

Para securizar Node-RED a nivel de atenticación y autorización seguir: https://nodered.org/docs/user-guide/runtime/securing-node-red para añadir usuario y password, así como otras configuraciones de seguridad

El editor y la API de administración admiten dos tipos de autenticación:

  • autenticación basada en credenciales de nombre de usuario / contraseña
  • autenticación contra cualquier proveedor de OAuth / OpenID como Twitter o GitHub

Para habilitar la autenticación basada en usuario y password, descomentar la propiedad adminAuth del fichero de configuración:

adminAuth: {
    type: "credentials",
    users: [
        {
            username: "admin",
            password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
            permissions: "*"
        },
        {
            username: "george",
            password: "$2b$08$wuAqPiKJlVN27eF5qJp.RuQYuy6ZYONW7a/UWYxDTtwKFCdB8F19y",
            permissions: "read"
        }
    ]
}

La propiedad de los usuarios es una matriz de objetos de usuario. Esto le permite definir múltiples usuarios, cada uno de los cuales puede tener diferentes permisos.

El nivel de permisos se puede configurar a nivel de los métodos de la API de administración: https://nodered.org/docs/api/admin/methods/

Las contraseñas se codifican de forma segura utilizando el algoritmo bcrypt

Para calcular la contraseña se usa: node-red-admin hash-pw

La herramienta le pedirá la contraseña que desea usar y luego imprimirá el hash que se puede copiar en el archivo de configuración.

Hay servicios web que permiten calcular el hash: https://passwordhashing.com/BCrypt

Command line administration: https://nodered.org/docs/node-red-admin 

Más información:

Autenticación HTTP Node-Red

Para proteger las rutas HTTP expuestas por los nodos y el dashboard se puede usar una autenticación básica.

La propiedad httpNodeAuth en su archivo settings.js se puede usar para definir un nombre de usuario y contraseña únicos que podrán acceder a las rutas.

  • httpNodeAuth: {user:»user»,pass:»$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.»},

La propiedad pass, usa el mismo formato que adminAuth utilizando el algoritmo bcrypt

Manual: https://nodered.org/docs/user-guide/runtime/securing-node-red#http-node-security

Securizar node red dashboard: https://github.com/node-red/node-red-dashboard/blob/master/README.md#securing-the-dashboard

Más información:

SSL en Node-Red

Para usar https con Node-RED seguir estos tutoriales:

Lo configuro el https en  $HOME/.node-red/settings.js

Líneas a descomentar/configurar:

var fs=require("fs")

https: {

key: fs.readFileSync('/user/myuser/privatekey.pem'),

cert: fs.readFileSync('/user/myuser/certificate.pem')

},

requireHttps: true,

Aplicar cambios de la nueva configuración con: node-red -s settings.js

Y restart node:

  • node-red-stop
  • node-red-start

Pero si tienes systemctl: systemctl start nodered.service

Como exponer un Node-Red de forma segura en Internet: https://github.com/node-red/cookbook.nodered.org/wiki/How-to-safely-expose-Node-RED-to-the-Internet

Certificados Autofirmados

Es muy fácil crear sus propios certificados SSL y claves de cifrado utilizando herramientas de software libre. Estas claves y certificados son tan seguros como los comerciales.

Utilizaremos openssl para crear nuestra propia autoridad de certificación (CA), claves de servidor y certificados.

Estos pasos nos permitirán una conexión encriptada entre el servidor y el cliente al igual que la que existe entre un cliente del navegador web y un servidor web. En este caso sólo necesitamos un certificado de servidor de confianza en el Cliente.

El servidor necesita: 

  • Certificado CA de la CA (autoridad de certificación) que ha firmado el certificado del servidor en el Broker Mosquitto (ca.crt)
  • Certificado del servidor certificado por la CA. (srv.crt)
  • Clave privada del servidor para el descifrado. (server.key)

Pasos:

  • sudo apt-get install openssl – instalar openssl
  • Crear un directorio llamado certificados en /home/pi con: mkdir certificados y entrar en el directorio para guardar los certificados y claves
  • openssl genrsa -des3 -out ca.key 2048 – Genera una RSA key privada para la CA. Pide contraseña (opción -des3)
  • openssl req -new -x509 -days 1826 -key ca.key -out ca.crt – Crear un certificado para la CA utilizando la clave de la CA que creamos en el paso anterior. Poner en CN el nombre o IP del servidor (p.e. raspberrypi.local o 192.168.1.10)
  • openssl genrsa -out server.key 2048 – Genera una RSA key privada para el servidor que será utilizada por el broker
  • openssl req -new -out server.csr -key server.key – crear una solicitud de certificado .csr. Al rellenar el formulario, el nombre común (CN) es importante y suele ser el nombre de dominio del servidor, el resto se pueden dejar vacíos. Debe utilizar el mismo nombre cuando configure la conexión del cliente. Como somos la CA, no es necesario mandar la solicitud a la CA.
  • openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360 – Utilizar la clave de la CA para verificar y firmar el certificado del servidor. Esto crea el archivo server.crt. Pide la contraseña usada para la ca.key

Con estos pasos hemos obtenido los siguientes ficheros:

  • ca.crt – Certificado de la CA
  • ca.key – Par de claves para la CA. Solo usar para crear un nuevo certificado
  • server.crt – Certificado del servidor firmado por la CA
  • server.csr – Solicitud de certificado. No es necesario.
  • server.key – Par de claves del servidor
  • ca.srl – Cada certificado emitido debe contener un número de serie único asignado por la CA. Debe ser único para cada certificado emitido por una determinada CA. OpenSSL guarda los números de serie utilizados en un archivo, por defecto tiene el mismo nombre que el archivo del certificado de la CA con la extensión sustituida por srl. Así que se crea un archivo llamado ca.srlc

Para ver el contenido de un certificado en texto, porque están codificados en base64, usar: openssl x509 -in server.crt -text -noout

Más información:

Información completa en: https://aprendiendoarduino.wordpress.com/2021/02/28/practica-4-instalar-configurar-y-securizar-mosquitto-y-node-red-en-raspberry-pi/

Gateways IoT

Un Gateway IoT es un dispositivo físico o un programa de software que sirve como punto de conexión entre la nube y los controladores, sensores y dispositivos inteligentes. Todos los datos que se mueven a la nube, o viceversa, pasan por el gateway, que puede ser un dispositivo de hardware dedicado o un programa de software. Un gateway IoT también puede denominarse pasarela inteligente o nivel de control.

Algunos sensores generan decenas de miles de puntos de datos por segundo. Una pasarela proporciona un lugar para preprocesar esos datos localmente en el borde antes de enviarlos a la nube. Cuando los datos se agregan, se resumen y se analizan tácticamente en el borde, se minimiza el volumen de datos que deben ser enviados a la nube, lo que puede tener un gran impacto en los tiempos de respuesta y en los costes de transmisión de la red.

En contraposición con la infraestructura cloud tradicional, basada en grandes centros de datos que centralizan el poder computacional, otros paradigmas como Fog Computing proponen la distribución de esta capacidad de cómputo hacia los extremos de la red. Este paradigma busca solventar los problemas de comunicación de datos entre los dispositivos generadores y consumidores de los mismos al acercar los centros de procesado y análisis de datos hacia ellos, reduciendo de esta forma la latencia y el uso de la infraestructura de red.

Se habla de Edge Computing en referencia a una infraestructura, que se puede entender como un caso específico de Fog Computing. Un escenario típico puede ser el caso de uso de Internet of Things (IoT) en el que los nodos de computación se necesitan estar físicamente cerca de las fuentes de datos, como un robot industrial o un sensor de presión de un tanque de combustible o un indicador de consumo de la red eléctrica. En general se puede definir un nodo de computación Edge como un hardware con capacidad de cómputo situado físicamente cerca de los dispositivos o equipos que hacen uso de sus recursos, bien sea en la propia maquinaria, en una planta de producción o en un almacén.

Más información:

Otra ventaja de una pasarela de IoT es que puede proporcionar seguridad adicional para la red de IoT y los datos que transporta. Dado que el gateway gestiona información que se mueve en ambas direcciones, puede proteger los datos que se mueven hacia la nube de fugas y dispositivos de IoT de ser comprometidos por ataques externos maliciosos con características tales como detección de manipulaciones, cifrado, generadores de números aleatorios de hardware y motores de cifrado.

La pasarela IoT desempeña un papel importante en la gestión de los dispositivos. Cada dispositivo (sensor/actuador) tiene un caso de uso diferente y emite mensajes a través de diferentes canales como Wifi, BLE, Zigbee, Ethernet, RF, LPWAN, LTE, etc. y el gateway realiza varias funciones como conectividad de dispositivos, traducción de protocolos, agregación, filtrado, correlación, seguridad, actualizaciones, administración y más. Se sitúa entre los dispositivos y la plataforma de nube.

Además un Gateway puede hacer conexión VPN segura entre localizaciones diferentes, permitiendo unir de forma segura diferentes puntos a través de Internet.

Routers y Gateways industriales inteligentes https://ewon.biz/es  

Hace no tantos años la conexión remota era por módem o por GSM con conexiones pto a pto. En la actualidad usamos internet para el telecontrol, pero es un problema el tema de la seguridad. Ya existen dispositivos como el router industrial eWON Flexy https://ewon.biz/es/productos/flexy modular que es servidor OPC UA y cliente openvpn, es muy potente para conectar y dar funcionalidades adicionales a unos autómatas.

eWON monta la VPN y al ser servidor modbus TCP y OPC UA, es posible acceder remotamente y de forma segura a los datos del autómata e integrarlo con datos de otras localizaciones.

Ejemplo Gateway LoRa:

Y el código: https://github.com/jecrespo/aprendiendoarduino-lora/blob/master/Demo_LoRa/rf95_server/rf95_server.ino 

Programación de los Gateways IoT:

Gateways Industriales

Los gateways industriales permite la traducción de protocolos típicamente industriales como Modbus RTU/ASCII/TCP a PROFINET o PROFIBUS a protocolos de Internet como HTTP o MQTT, permitiendo actualizar los dispositivos industriales a los nuevos protocolos de comunicación en Internet. 

Los gateways de IIoT o «nube» se distinguen por su énfasis en servir datos de dispositivos hasta una nube u otros componentes de la Internet industrial. Los factores diferenciadores incluyen el uso de un microprocesador y un sistema operativo estándar, como la plataforma Intel IoT, así como el soporte de APIs de Transferencia de Estado Representacional (REST), Transporte de Telemetría de Colas de Mensajes (MQTT), y otros protocolos de integración y transporte de datos de la IoT. También se puede utilizar para este fin la OPC UA (Arquitectura Unificada).

Estos gateways también pueden añadir una capa adicional de seguridad con el uso de VPNs u otras comunicaciones seguras.

Más información:

Matriz de selección de gateways industriales: https://www.moxa.com/Moxa/media/Resources/DownloadFile/mgate-quick-card-en.pdf

Existen diversas opciones para gateways industriales para conversión de protocolos:

Anybus hace pasarelas y dispositivos de comunicaciones. Las pasarelas permiten hacer un upgrade a Industrial ethernet:

HMS es el distribuidor de anybus: https://www.hms-networks.com/

Seguridad en Gateways

Un Edge Gateway se encuentra en la intersección de los sistemas de borde (edge), entre la Internet externa y la intranet local que está siendo utilizada por los otros dispositivos de su ecosistema. Por lo tanto, es el punto de acceso clave para la conectividad de red, tanto dentro como fuera del ecosistema de dispositivos.

Existen tres principios fundamentales de la seguridad: confidencialidad, integridad y disponibilidad. Deberá asegurarse de que todas las comunicaciones entre el gateway y los dispositivos cumplen cada uno de los tres principios mientras se produce la comunicación en las redes internas y externas.

También vale la pena señalar que la puerta de enlace es a menudo la primera en ser atacada por dos razones:

  • Tiene una mayor potencia de procesamiento, que puede utilizar para ejecutar aplicaciones más intensivas. Más potencia significa mejor software, pero mejor software significa más vulnerabilidades para que un hacker las explote.
  • Debido a su ubicación como dispositivo Edge entre Internet e Intranet, el gateway es el punto de entrada de cualquier vector de amenaza (así como la primera línea de defensa del sistema).

Las recomendaciones sobre la seguridad de un dispositivo de pasarela de la IoT constan de tres pasos.

  • Identidad para el dispositivo Gateway. Dar al gateway una identidad (utilizando un certificado digital X.509). 
  • Habilitar la identidad «sólida» para el dispositivo Gateway
  • Utilizar el Gateway para proporcionar identidad a su ecosistema

Más información: