El viaje del conocimiento

Prólogo

Hoy estoy de celebración, por fin han publicado en actas la nota de mi Trabajo Fin de Máster, con esto finalizo mi Máster en Seguridad Informática por la Universidad de Jaén.

Durante los últimos dos años, me he sumergido en un proyecto que ha abarcado una amplia gama de áreas de conocimiento, ha desafiado mis habilidades y, sobre todo, me ha brindado una oportunidad invaluable de aprendizaje y crecimiento personal.

El TFM, sin duda alguna, representa uno de los desafíos más significativos y gratificantes que he enfrentado en mi trayectoria académica. Su envergadura y extensión han permitido que me sumerja en diferentes disciplinas y me haya permitido explorar aspectos diversos relacionados con mi área de estudio. A medida que avanzaba en este proyecto, me di cuenta de la amplitud del conocimiento que debía adquirir para abordar de manera adecuada cada aspecto de mi investigación.

A lo largo de este proceso, me he enfrentado a desafíos intelectuales y técnicos que han requerido una dedicación y esfuerzo constantes. Sin embargo, cada obstáculo superado ha resultado en un crecimiento personal invaluable. He aprendido a investigar, a sintetizar información compleja, a desarrollar mi capacidad crítica y a aplicar metodologías rigurosas en la búsqueda de respuestas.

Titulado "Diseño e implementación de un sistema de transmisión y monitorización de SFA en localizaciones remotas", mi TFM es un proyecto de investigación y desarrollo y continuación de mi TFG. Este proyecto define el diseño e implementación de un sistema inalámbrico de monitorización para SFA (sistemas fotovoltaicos autónomos) instalados en localizaciones remotas, como pueden ser las comunidades de los países en desarrollo.

Con este trabajo se pretende centralizar los datos de monitorización de diversos SFA y transmitirlos a través de Internet a un servidor para que sean accesibles de manera remota. Se tendrán en cuenta técnicas de seguridad para la transmisión y almacenamiento de datos así como prevención de ataques al servidor donde se almacena la información.

Finalmente, el día 25 de mayo de 2023 defendí mi Trabajo Fin de Máster frente al tribunal de la Universidad de Jaén, el cual determinó que merecía la máxima nota y matrícula de honor. En esta sección de mi blog, trato de resumir el trabajo realizado y del cual me siento muy orgulloso.

Introducción

Para comenzar, que es un Sistema Fotovoltaico Autónomo o SFA por siglas. Esto es un sistema capaz de producir energía y autoabastecerse aprovechando la energía solar. Consta de 3 partes fundamentales: el módulo fotovoltaico para generar la energía, la batería para almacenar la energía excedente que será usada cuando no haya luz solar y la carga a alimentar.

Para generar energía a partir del sol un módulo fotovoltaico se compone de muchas células fotovoltaicas. Estas células suelen están basadas en una capa P y una capa N que generan una diferencia de potencial cuando incide la luz solar.

Los SFA son muy utilizados, por ejemplo es muy común verlos en el ámbito de la agricultura para dar energía a los sistemas de riego. Sin embargo, existe todavía una gran parte de la población que no dispone de acceso a la electricidad donde los SFA tienen un papel fundamental. Ya que son utilizados como fuente principal de energía en pequeñas comunidades de localizaciones remotas. Por ejemplo, en muchas zonas de África.

Estas comunidades se componen de pequeñas viviendas, cada una con un pequeño SFA para dar energía a pequeños electrodomésticos y aparatos eléctricos.

Sin embargo, debido a los escasos recursos de estas comunidades los SFA no suelen incluir un sistema de monitorización. El cual es muy importante ya que ayuda a prevenir fallos y permite alargar enormemente la vida útil de los SFA.

Tras un estudio inicial y debido al contexto en el que se encuentran estos SFA, la solución que hemos considerado óptima es conectar todos los dataloggers en una red inalámbrica que permita enviar los datos a un servidor en Internet. Esto de beneficios como:

• Un acceso rápido a los datos debido a que los datos se recogen de forma centralizada y pueden accederse desde Internet.
• Al monitorizar varios SFA de forma conjunta se permite comparar rendimientos entre unos y otros y por tanto detectar fallos individuales o patrones de fallos.
• Permite disminuir los costes. Ya que utilizar una red para enviar los datos elimina componentes redundantes y puede conseguirse que algunos sistemas de monitorización sean más simples. Un ejemplo es que no haría falta un dispositivo de almacenamiento físico en cada uno de los dataloggers.
• No es necesario desplazarse hasta la comunidad para obtener los datos de un dispositivo de almacenamiento físico como una tarjeta SD o un pen-drive.

No obstante, todos estos beneficios no son gratis ya que la red a desplegar requiere de una gran complejidad.

Antecedentes

¿Cuales son los dataloggers que hay en el mercado que podrían utilizarse para este propósito?

Pues hay muchos fabricantes, pero ninguno de ellos se adecua de forma óptima al proyecto debido a que tienen un coste muy elevado, no tienen suficientes entradas para realizar la correcta monitorización de los parámetros de un SFA o además requieren utilizar otros productos del fabricante para realizar una monitorización plena. Como es el caso del fabricante Morningstar o Schneider.

Si no se va utilizar ningún dispositivo comercial pues tendrá que fabricarse un sistema. Los problemas a enfrentar para fabricar el sistema será la elección del datalogger, cómo se va a realizar las comunicaciones entre dataloggers, cómo se van a enviar los datos al servidor y cómo va a ser el propio servidor.

Para el datalogger la forma más sencilla es utilizar una plataforma de desarrollo que ya cuente con un número suficiente de entradas y puertos de comunicaciones para conectar todos los sensores y componentes necesarios. Las plataformas más utilizadas son: Arduino, ESP32 o Raspberry PI.

Para la comunicación de estos dataloggers hay otro montón de opciones entre las que hay protocolos inalámbricos como WiFi, Bluetooth o Zigbee o soluciones privadas como Z-Wave, LoRaWAN o Sigfox.

Para las comunicaciones entre los dataloggers y el servidor pueden utilizarse soluciones privadas como LoRaWAN o Sigfox, conexión vía satélite con Starlink o Swarm o utilizar la red de telefonía móvil para conectar a Internet.

Por último habrá que determinar qué se va a utilizar de servidor. Será necesario que tenga una base de datos, que podrá ser relacional o no relacional y de una interfaz que permita subir y consultar los datos.

Objetivos

Los objetivos que se han establecido son:

• La monitorización de todos los parámetros de un SFA. Que son: corrientes y tensiones de módulo, batería y carga, Temperatura de módulo y batería. Y algunos parámetros meteorológicos, la temperatura y humedad ambiente, precipitación y velocidad del viento.
• Una gran escalabilidad. Si se quiere incorporar un nuevo dispositivo se debe realizar de forma sencilla y sin requerir cambios en la red ya desplegada.
• Robustez para evitar fallos y garantizar que se realicen las mediciones.
• Que tenga un coste reducido. El coste total de los sistemas de monitorización no puede ser elevado al coste total de un SFA.
• Tener siempre en mente la protección de la información y de los usuarios de la aplicación incorporando las suficientes medidas de seguridad.
• Y por último, fabricar un prototipo funcional.

Solución adoptada

Se han separado los dataloggers en dos sistemas.

• Un sistema orquestador denominado Nodo Master que tendrá las funciones de comunicaciones con servidor, gestionar la red entre dataloggers, monitorizar un SFA y una estación meteorológica. Para todas estas operaciones se ha elegido al ESP32 debido a su bajo coste y gran potencia.
  
• Y por otro lado, una serie de sistemas satélites denominados Nodos Slave que monitorizarán un SFA y enviarán los datos al nodo Master a través de la red de comunicación. Debido a que no realizan tantas operaciones se utiliza un Arduino Nano debido a su robustez y su bajo consumo.
  

Para las comunicaciones con el servidor se utilizará la red de telefonía móvil ya que es la que más cobertura tiene, es barata y permite una gran velocidad.

Para conectarse a esta red se utiliza un Router 4G que crea un punto de acceso WiFi al que se conectan los nodos Master mediante el WiFi integrado del ESP32. Además, usar un Router 4G da la posibilidad a los habitantes de la comunidad de tener acceso a Internet.

Para elegir el método de comunicaciones entre dataloggers se ha realizado una comparación entre todos ellos y se han descartado los menos aptos.

Los sistemas propietarios Z-Wave, LoRaWAN y Sigfox tienen las desventajas de depender de un proveedor externo y utilizar una frecuencia por debajo del gigahercio. Esto es un inconveniente ya que la frecuencia utilizada dependerá del país en el que se despliegue. Por ejemplo, en Europa se utiliza la frecuencia 868 MHz y en EEUU se utiliza 928 MHz. Así que estas soluciones quedan descartadas.

WiFi también se ha descartado debido a que el rango que ofrece no es muy elevado y la seguridad es únicamente en acceso al medio. Una vez en la red las comunicaciones van en claro a no ser que se utilice otro protocolo que cifre los datos entre nodos.

Quedan Bluetooth Low Energy y Zigbee. La velocidad de transmisión entre estos dos es alta, mucho más en Bluetooth, pero para la cantidad de datos que se envían ambas son buenas opciones. Sin embargo, Zigbee fue un protocolo diseñado para transferencia de datos entre dispositivos IoT a largo alcance, los dispositivos que hemos utilizado pueden comunicarse hasta 1 kilómetro de distancia mientras que el dispositivo Bluetooth con mayor alcance que hemos encontrado es de 100 metros. Así que nos quedamos con Zigbee y haciendo uso de módulos XBee.

Para el servidor se ha elegido la base de datos relacional MariaDB. Ya que ofrece muy buenas prestaciones y ya se ha trabajado previamente con ella.

Para la interfaz se creará una aplicación Web dividida en dos entornos, una API REST para las comunicaciones de los nodos con el servidor y una interfaz de usuario que permita a los usuarios acceder a la aplicación mediante un navegador. Como software se utiliza Spring Boot y una arquitectura Modelo-Vista-Controlador.

A continuación, se muestra un esquema de toda la infraestructura a desplegar.

• Los nodos Slave se conectan al nodo Master y pueden hacer uso de nodos repetidores si es necesario. En el sistema desarrollado se han configurado los módulos XBee de los nodos Slave como “routers” para permitir enrutar paquetes y ser utilizados como repetidores.
• El nodo master envía los datos al servidor a través de un router 4G.
• Y el servidor consta de la base de datos y la aplicación web que permite a los usuarios conectarse a través de un ordenador.

Desarrollo del sistema

Para comprender más fácilmente toda la infraestructura desplegada se ha separado en dos partes. Una parte hardware dedica a los nodos y una parte software relativa al servidor.

A modo resumen, los componentes electrónicos de cada nodo son:

El funcionamiento del programa del nodo Master pueden distinguirse tres estados.

• Al inicio se obtienen los parámetros, se inician los sensores y se conecta a la red WiFi.
• Después el programa entra en el bucle. En esta parte del código se realizan las distintas tareas periódicas que realiza el nodo Master. La primera tarea es consultar los parámetros del nodo Master y de los nodos Slave conectados para actualizar los parámetros si fuera necesario. Se comprueba si hay que realizar una medición de datos. Se consulta el servidor para sincronizar la hora. Y por último si hay que enviar datos al servidor. Al final del bucle se consulta al XBee si ha recibido algún paquete Zigbee.
• Si se diera el caso, se verifica que tenga el formato adecuado y se comprueba si el nodo que lo ha enviado ha sido autenticado. Si no, pues se le envía un paquete de solicitud de autenticación o si ya ha respondido con los parámetros de autenticación se autentica mediante una consulta al servidor. Si el nodo sí esta autenticado pues seguramente nos haya indicado el valor de sus parámetros o nos habrá enviado datos. En el primer caso se envían los parámetros del nodo al servidor y en el segundo se almacenan los datos recibidos en la pila de datos para ser posteriormente enviados al servidor y se envía al nodo un ACK de que se han recibido correctamente.
• Para no alargar la presentación de forma innecesaria el funcionamiento del nodo Slave no lo voy a explicar porque es similar al nodo Master pero sin las comunicaciones al servidor.

Como hemos dicho para la base de datos se utiliza MariaDB y para el servidor una arquitectura MVC con una API REST y una interfaz web desarrollada en Spring Boot.

Para desplegarlo se realiza mediante Docker ya que permite desplegar el sistema de forma rápida en cualquier tipo de servidor. Ya sea en una Raspberry PI o en la nube. Además, se pueden añadir imágenes de un WAF o de un balanceador de carga si se viera necesario.

A continuación, se pueden ver dos vistas de la aplicación Web. La vista principal arriba y la presentación de los datos monitorizados en forma de gráfica.

Con respecto a la seguridad se han implementado numerosas medidas. Para explicar el porqué de cada medida pues se ha seleccionado el TOP 10 de vulnerabilidades más comunes según el OWASP.

• La primera vulnerabilidad está relacionada con el acceso no autorizado a recursos. Para evitarla lo que se hace es una estricta validación de los permisos de los nodos y de los usuarios.
• La segunda vulnerabilidad ocurre cuando hay debilidades en la encriptación. Para evitarla se utiliza HTTPS en todas las comunicaciones con el servidor, los nodos cuentan con un mecanismo de SSL Pinning además de un doble cifrado de las comunicaciones. Se utilizan nonce aleatorios mediante la obtención de ruido en uno de los pines del ESP32 y las contraseñas se almacenan hasheadas en la base de datos.
• Para evitar las inyecciones se realiza una sanitización de todas las entradas de la aplicación. Tanto de los nodos como de los usuarios.
• La cuarta vulnerabilidad aparece cuando no se ha tenido en cuenta la seguridad desde un principio. Como nosotros hemos tenido siempre presente la robustez, escalabilidad y seguridad hemos evitado malas prácticas. Además, se hace uso de herramientas como Git, SonarQube y Docker Hub que realizan análisis estáticos a la aplicación.
• Se ha evitado las configuraciones por defecto y malas configuraciones.
• En la medida de lo posible se utilizan las últimas versiones del software y de las librerías.
• Para evitar fallos en la autenticación e identificación de los usuarios. Se aplica una política de contraseñas, se añaden tokens anti CSRF en todos los formularios, se incluye la cabecera X-Frame-Options para evitar ataques de clickjacking. Se evita que un usuario tenga varias sesiones abiertas al mismo tiempo y se protege la funcionalidad de login con un fail2ban.
• No se utilizan librerías de terceros, siempre de fuentes confiables y descargadas desde el repositorio de maven.
• Se lleva a cabo una monitorización de todas las acciones que se realizan en la aplicación y quién las hace. Además, se implementa un sistema de detección de acciones maliciosas mediante la validación de las entradas de los usuarios.
• La última vulnerabilidad aparece cuando un atacante es capaz de hacer que el servidor realice una solicitud a un recurso externo, y no se contempla ninguna funcionalidad que permita esto.

Además de todo lo anterior se han implementado otras medidas de seguridad:

• No se envían datos sensibles a través del método GET. Esto es para evitar que los datos sensibles aparezcan en la URL. Si hay algún proxy o servidor de VPN que monitoriza las páginas visitadas por los usuarios, los datos sensibles aparecerían en los registros.
• Todas las páginas de la aplicación devuelven las cabeceras de seguridad HTTP. Content-Type-Options, XSS-Protection, Cache-Control, HSTS, X-Frame-Options y CSP.
• Se realiza una gestión de error para evitar que trazas de error y mensajes de error por defecto se devuelvan a los usuarios.
• Se mitiga la fuga de información. No se incluyen las cabeceras Server ni Powered By. Se han eliminado los metadatos y números de versión de los archivos estáticos y se ha eliminado la información por defecto de los mensajes de error.
• Se aplica una lista blanca en la cabecera host.
• Las comunicaciones entre los nodos se realiza mediante AES de 128 bits con cambios periódicos de clave.
• Los datos enviados por los nodos Master al servidor están cifrados con AES de 128 bits. Esto significa que si un atacante lograra interceptar las comunicaciones de los nodos y romper HTTPS vería datos cifrados. Además, los nodos son doblemente autenticados, primero se autentica el nodo master que envía los datos y luego a los datos de cada nodo de forma independiente.
• Por último se ha realizado un test de penetración a la página web y a los nodos.

Análisis de resultados

Aquí se pueden ver un par de imágenes del prototipados. Una primera imagen en las etapas iniciales del prototipado y otra al final con el prototipo prácticamente terminado.

Aquí se puede ver el prototipo una vez desplegado, monitorizando un pequeño SFA con un módulo fotovoltaico y una batería.

Se ha desplegado también un pequeño nodo Slave sin sensores que envía datos simulados al servidor para comprobar que los nodos Slave también funcionan correctamente. Los cables rojo y blanco que aparecen aquí es para la alimentación del nodo, los datos se envían mediante el módulo XBee.

El nodo Slave tiene un consumo máximo de 0.78 vatios. Unas 10 veces menos que una bombilla led. Y el nodo Master, debido a que tiene conectado el Router 4G, tiene un consumo de 4 vatios, la mitad de una bombilla de tipo led.

El presupuesto del nodo Slave es de 180€ y el del nodo Master de 265€

El nodo Master sí estaba monitorizando el SFA, aquí muestro una captura de la presión atmosférica a principios de abril y de la corriente de la batería durante todo el tiempo que estuvo monitoreando el SFA. Pueden apreciarse claramente los ciclos de carga y descarga de la batería.

Aquí se muestran las vulnerabilidades encontradas en el Pentest Web. La vulnerabilidad más grave que se detectó fue un XSS almacenado debido a que no se validó una de las entradas de la aplicación y junto una librería de bootstrap que permitía ejecutar código javascript codificado en HTML.

• La vulnerabilidad de fallos de SSL se debe a que cuando se generó el certificado no se incluyó en la cadena el certificado intermediario y por tanto estaba incompleto. Además, también se debe al uso de suites de cifrado no tan seguras como es CBC. Sin embargo, el uso de estas suites debe asumirse debido a que las comunicaciones de los ESP32 con el servidor hacen uso de ellas y las librerías de encriptación no tienen implementado el uso de suites más seguras.
• La vulnerabilidad de enumeración de directorios y de enumeración de usuarios no se consideran vulnerabilidades. Ya que se quiere mantener como una funcionalidad las páginas personalizadas de 404, 403, etc y la enumeración de usuarios se debe a una característica implementada en la funcionalidad de compartir nodos con otros usuarios y que requiere estar autenticado en el sistema.
• Para solucionar la vulnerabilidad inyección de cabecera Host se implementó la lista blanca de dominios en esta cabecera.
• Las vulnerabilidades de Configuración insegura de cabeceras HTTP y problemas de manejo de errores tienen mala pata porque dependen del servidor Tomcat utilizado y no de la aplicación. No se ha encontrado una forma, desde el framework Spring de evitar que aparezcan algunos de los mensajes de error por defecto de Tomcat. Y estos mensajes de error, al ir ajenos a la aplicación no envían las cabeceras de seguridad HTTP. Tampoco se ha visto un riesgo muy elevado de esto más allá de fuga de información pero tendrán que asumirse mientras se busca una solución.
• Y por último para mitigar la fuga de información se han eliminado los metadatos de los archivos estáticos, como eran las imágenes mostradas al inicio de la aplicación y se han eliminado los número de versión de las librerías javascript utilizadas. Eso no significa que un atacante pueda descubrir la versión analizando el código, pero ya le estamos fastidiando un poco y obligarle a hacerlo.

Con respecto al test IoT. Se han detectado tres vulnerabilidades que tendrán que asumirse, salvo la segunda que se ha mitigado levemente.

• La primera vulnerabilidad se debe a que al conectarse por USB a los nodos no se requiere de ninguna autenticación. Esto requiere acceso físico al nodo pero sí habría que implementar un mecanismo de establecer una contraseña la primera vez que se configura el nodo y requerir la contraseña cuando se conecte por USB.
• La segunda vulnerabilidad es una potencial de denegación de servicio a los nodos Slave. Si un atacante dispone del suficiente número de nodos Slave puede saturar la pila de nodos autenticados del nodo Master con sus nodos dejando fuera a los nodos Slave legítimos. Esto no se puede explotar ya que ahora mismo solo hay un nodo Slave. La forma de solucionarlo será implementar un mecanismo de lista negra con el que se pueda banear a nodos Slave de la red.
• Por último, el uso de suites de cifrado CBC que tendrá que asumirse hasta que implementen suites de cifrado más seguras en los ESP32.

Uno de los ataques a los que se ha sometido el nodo Master. Con este ataque se pretendía interceptar las comunicaciones entre Nodo Master y Servidor mediante un man-in-the-middle y poder mostrar la doble encriptación que tiene los datos. Sin embargo, la medida de SSL Pinning que se ha implementado no ha permitido hacer esto.

Mediante un ataque ARP Spoofing podemos ponernos en medio de las comunicaciones entre nodo Master y Servidor y poder ver todos los datos transmitidos. Como puede verse en la siguiente imagen, los datos que no están cifrados, como las consultas DNS pueden verse fácilmente.

Para romper HTTPS se desplegó un servidor proxy malicioso al que redirigir el tráfico de los nodos mediante un ataque TCP hijacking. Como estamos entre medias de las comunicaciones podemos modificar la dirección IP y el número de puerto de los paquetes TCP/IP de los nodos Master y el servidor y redirigirlos al servidor Malicioso. Sin embargo, al hacer esto el nodo Master se encuentra con el certificado del servidor proxy malicioso en lugar de el del servidor y rechaza la conexión, esto es el mecanismo SSL Pinning.

En la captura de wireshark puede verse como en el handshake de SSL se le envía al nodo el certificado del servidor pero el cliente lo rechaza con un mensaje "Certificado no soportado".

Conclusiones

Después de analizar los resultados se han llegado a estas conclusiones.

• El sistema es escalable, se puede añadir o quitar un nuevo nodo de forma sencilla. Cada nodo Master puede dar soporte hasta treinta nodos Slave. Si hicieran falta 31 nodos pues se desplegaría otro nodo Master al que poder conectar otros 30 Slave.
• Se permite la configuración remota de algunos parámetros de los nodos, lo que evita tener que desplazarse hasta el sistema para cambios triviales. Además, se ha incluido una salida de propósito general que permite una pequeña capacidad de actuadores a los nodos.
• Gracias a la buena planificación electrónica se han podido implementar mejoras como la tarjeta SD y reemplazar componentes dañados de forma fácil y rápida.
• La tarjeta SD garantiza la disponibilidad de los datos cuando no pueden ser enviados al servidor por cualquier motivo. A las malas podrían recuperarse directamente de la tarjeta SD.
• Es cierto que existen errores de offset en los datos que tendrían que ser solucionados. Esto destaca sobre todo en la corriente del módulo fotovoltaico. Sin embargo, gracias a la monitorización de los nodos pudo identificarse el fallo de la batería los primeros días del despliegue.
• Se han implementado numerosas medidas de seguridad tanto en los nodos como en el servidor. Para comprobar estas medidas de seguridad y encontrar vulnerabilidades se realizó un pentest web a la aplicación y un pentest IoT a los nodos.

Líneas futuras

Y para finalizar con la presentación los siguientes pasos al sistema serían:

• Corregir los fallos de offset y dar solución a las vulnerabilidades que han quedado como asumidas.
• Diseñar una aplicación que permita la configuración de los nodos de forma amigable.
• Y permitir actualizar el firmware de los nodos de forma remota.