Introducción
Con la llegada de nuevas exigencias de ciberseguridad industrial y auditoría OT, fabricantes como Siemens han incorporado mecanismos de seguridad y trazabilidad en sus controladores: seguridad de acceso a los dispositivos, cifrado de comunicaciones y herramientas como Syslog para el registro y centralización de eventos.
Esto encaja especialmente con enfoques basados en IEC 62443, donde registrar eventos, accesos y cambios relevantes es fundamental para diagnóstico, trazabilidad y monitorización centralizada.
Hasta ahora, la manera más habitual de visualizar los eventos ocurridos en un PLC a nivel de sistema era conectarse online con TIA Portal y revisar los eventos de diagnóstico. Sigue siendo útil, pero se queda corto cuando la planta tiene más equipos y se necesita una auditoría ordenada.
Ejemplo tradicional de eventos en diagnóstico online:
En este artículo vamos a preparar una solución demostrativa con la funcionalidad Syslog configurada desde TIA Portal en CPUs Siemens compatibles, pensada para alinearse con buenas prácticas y requisitos de auditoría en plantas donde conviene centralizar lo que ocurre en los controladores.
Qué es Syslog
Syslog es un mecanismo estándar para enviar mensajes de registro desde equipos, sistemas operativos y dispositivos de red hacia un servidor central. En automatización industrial, permite que un PLC envíe eventos de sistema, cambios de estado o acciones de usuario a una infraestructura común de logs.
La solución consta de dos PLC que mandarán por UDP los eventos a un servidor montado en un contenedor LXC Linux. En ese mismo entorno montamos un dashboard que muestra los eventos en tiempo real para analizarlos, filtrarlos y exportarlos.
En próximos artículos veremos cómo llevar esta comunicación a un escenario seguro usando los mecanismos que proporciona Siemens.
Arquitectura
- Servidor Linux: contenedor LXC en Proxmox.
- PLCs Siemens: ejemplo reaprovechado de las comunicaciones OPC UA cliente/servidor.
- PLC cliente: 192.168.1.191.
- PLC servidor OPC UA: 192.168.1.192.
- Dashboard: alojado en la propia máquina Linux del LXC para visualizar en tiempo real los eventos ocurridos en los PLC.
- Comunicación: UDP, en este ejemplo sin cifrar.
Servidor Linux: rsyslog para recopilar
Para alojar los datos de los eventos vamos a usar un servidor en un contenedor Linux con rsyslog. En una infraestructura real, este servicio podría estar alojado en un servidor OT y dedicarse a recopilar eventos de toda la planta.
rsyslog es un servidor y motor de procesamiento de logs muy usado en Linux. Permite recibir mensajes Syslog desde distintos dispositivos, aplicar reglas de filtrado y almacenar o reenviar esos eventos hacia otros sistemas.
Datos del contenedor:
- Nombre: lxc-syslog-plc.
- Sistema: Debian 12.
- IP: 192.168.1.116/24.
- Bridge: vmbr0.
- RAM: 1 GB.
- Disco: 8 GB.
Los pasos de configuración del servidor son los siguientes.
Paso 1: entrar al LXC
Entramos al contenedor Linux que hará de servidor Syslog. En este laboratorio se trata del LXC lxc-syslog-plc, con IP 192.168.1.116.
Paso 2: instalar herramientas básicas
Actualizamos paquetes e instalamos las herramientas necesarias para recibir, editar y comprobar los eventos:
sudo apt update
sudo apt install rsyslog tcpdump nano iproute2 net-tools curl -y- rsyslog: recibe y procesa los mensajes Syslog.
- tcpdump: permite ver si los paquetes UDP llegan al servidor.
- nano: editor sencillo para modificar la configuración.
- iproute2 y net-tools: herramientas de red para comprobar interfaces y puertos.
- curl: útil para pruebas rápidas desde consola.
Paso 3: configurar recepción UDP
Creamos un archivo específico para la entrada Syslog de los PLC Siemens:
sudo nano /etc/rsyslog.d/10-plc-siemens-udp.confEn este archivo dejamos la entrada UDP y las reglas que separan los eventos por PLC. Así podemos tener un fichero general y ficheros específicos para cada controlador.
Paso 4: crear archivos de log
Creamos los archivos donde rsyslog escribirá los eventos recibidos:
sudo touch /var/log/plc-siemens.log
sudo touch /var/log/plc-siemens-191.log
sudo touch /var/log/plc-siemens-192.log
sudo chmod 644 /var/log/plc-siemens*.log
Paso 5: validar la configuración
Antes de reiniciar el servicio, validamos que la configuración de rsyslog no tiene errores:
sudo rsyslogd -N1
Paso 6: arrancar rsyslog
Habilitamos el servicio, lo reiniciamos y comprobamos su estado:
sudo systemctl enable rsyslog
sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager
Paso 7: comprobar que el servidor escucha
Comprobamos que el servidor está escuchando en los puertos Syslog configurados:
ss -lunp | grep -E ':514|:6514'
Para verificar la llegada de paquetes antes de mirar el dashboard, dejamos una captura abierta con tcpdump y generamos eventos desde cada PLC. En esta prueba se hizo un STOP y un START con cada controlador, confirmando que los mensajes llegan al servidor.
sudo tcpdump -n -i any "udp port 514 or udp port 6514"
PLC Siemens: configuración y envío de eventos
La configuración de los PLC para que envíen datos al servidor rsyslog es sencilla. Para ilustrar el funcionamiento usaremos el proyecto de cliente y servidor OPC UA y haremos que esos PLC envíen información a nuestro dashboard.
Nota: Siemens incorpora esta capacidad en CPUs compatibles a partir de firmware V3.1, configurable desde TIA Portal V19, permitiendo enviar eventos de la CPU a un servidor Syslog externo.
Al tratarse de un laboratorio inicial, el paso es directo:
- Abrir las propiedades del PLC en TIA Portal.
- Ir al apartado Syslog.
- Activar el envío de eventos.
- Seleccionar UDP como transporte.
- Indicar la IP del servidor Linux y el puerto de recepción.
En este caso, la IP 192.168.1.116 y el puerto 6514 son la dirección donde el servidor rsyslog espera recibir los eventos.
Conviene matizar este punto: aunque el puerto 6514 suele asociarse a Syslog seguro, aquí el transporte configurado es UDP. Por tanto, los mensajes viajan sin cifrar y esta configuración debe entenderse como prueba de laboratorio para validar eventos y analizarlos con Wireshark. Para hablar de Syslog seguro habría que configurar TLS, normalmente sobre TCP, con certificados y validación del servidor. Lo veremos en un siguiente artículo.
Resultados
A través del dashboard accedemos al archivo alojado en el LXC de Linux donde se configuró el guardado de los eventos generados por los PLC. En este caso hemos extraído los paquetes y organizado la información tanto en texto plano como en formato tabular. De aquí a una base de datos estándar solo hay un paso más.
Para provocar eventos de prueba podemos conectarnos online con TIA Portal, cambiar el modo del controlador o cargar una modificación. Si todo está bien configurado, esos eventos aparecen en el archivo del servidor y en el dashboard.
Como se puede observar, la información es muy potente. Nos indica:
- Fecha y hora del evento.
- IP del PLC que origina el evento.
- Categoría del evento.
- Evento propiamente dicho: conexión online desde TIA Portal, cambio de modo del PLC, cambios de programa, etc.
- Estado si ha habido cambio de estado en el controlador.
- Usuario que realiza la acción.
Esta información por sí misma ya es muy valiosa para tener trazado lo que ha sucedido con los PLC. Si además la insertamos en una base de datos mayor y la cruzamos con Audit Trail de SCADA, históricos de variables, GMAO, ERP o un SIEM, tendremos una visión mucho más potente de la operación.
Paquetes de datos con Wireshark y estándar RFC 5424
Filtrando por las IP de los PLC y del servidor en Wireshark, podemos ver los paquetes UDP que transportan los eventos.
El mensaje que vemos tiene esta forma:
Esto significa que Siemens convierte la información al estándar RFC 5424, definido por el IETF. Este estándar describe cómo debe formarse un mensaje Syslog para que distintos equipos y sistemas puedan interpretarlo de manera homogénea.
La estructura general de estos mensajes es:
<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MESSAGEGracias a esta estructura, un PLC Siemens puede enviar eventos con fecha, origen, severidad y datos estructurados, y un servidor como rsyslog puede interpretarlos, filtrarlos, almacenarlos o reenviarlos a un dashboard o a una plataforma SIEM.
Artículos relacionados