Syslog in Siemens PLCs: traceability and cybersecurity from the controller

With new industrial cybersecurity and OT audit requirements reaching the plant floor, manufacturers such as Siemens have incorporated security and traceability mechanisms into their controllers: device access security, communication encryption and tools such as Syslog for event logging and centralization.

This fits especially well with approaches based on IEC 62443, where recording events, access and relevant changes is essential for diagnostics, traceability and centralized monitoring.

Until now, the most common way to view system-level events in a PLC was to connect online with TIA Portal and review the diagnostic events. It is still useful, but it is limited when a plant has more devices and needs orderly auditing.

Traditional example of online diagnostic events:

In this article we are going to prepare a demonstration solution using the Syslog functionality configured from TIA Portal in compatible Siemens CPUs, intended to align with good practices and audit requirements in plants where it is useful to centralize what happens in the controllers.

Syslog is a standard mechanism for sending log messages from equipment, operating systems and network devices to a central server. In industrial automation, it allows a PLC to send system events, state changes or user actions to a common log infrastructure.

The solution consists of two PLCs that send events via UDP to a server running in a Linux LXC container. In that same environment we also mount a dashboard that shows the events in real time so they can be analyzed, filtered and exported.

In future articles we will see how to move this communication into a secure scenario using the mechanisms Siemens provides.

• Linux server: LXC container in Proxmox.
• Siemens PLCs: example reused from the OPC UA client/server communications project.
• Client PLC: 192.168.1.191.
• OPC UA server PLC: 192.168.1.192.
• Dashboard: hosted on the same Linux LXC machine to display PLC events in real time.
• Communication: UDP, without encryption in this example.

To host the event data we are going to use a server in a Linux container with rsyslog. In a real infrastructure, this service could be hosted on an OT server and dedicated to collecting events from the whole plant.

rsyslog is a widely used log server and processing engine in Linux. It can receive Syslog messages from different devices, apply filtering rules and store or forward those events to other systems.

Container data:

• Name: lxc-syslog-plc.
• System: Debian 12.
• IP: 192.168.1.116/24.
• Bridge: vmbr0.
• RAM: 1 GB.
• Disk: 8 GB.

The server configuration steps are as follows.

Enter the Linux container that will act as the Syslog server. In this lab it is the lxc-syslog-plc LXC, with IP address 192.168.1.116.

Update packages and install the tools needed to receive, edit and check the events:

sudo apt update
sudo apt install rsyslog tcpdump nano iproute2 net-tools curl -y

• rsyslog: receives and processes Syslog messages.
• tcpdump: checks whether UDP packets reach the server.
• nano: simple editor for configuration files.
• iproute2 and net-tools: network tools to inspect interfaces and ports.
• curl: useful for quick console tests.

Create a dedicated file for the Siemens PLC Syslog input:

sudo nano /etc/rsyslog.d/10-plc-siemens-udp.conf

In this file we define the UDP input and the rules that split events by PLC. This gives us one general file and one specific file for each controller.

Create the files where rsyslog will write the received events:

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

Before restarting the service, validate that the rsyslog configuration has no errors:

sudo rsyslogd -N1

Enable the service, restart it and check its status:

sudo systemctl enable rsyslog
sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager

Check that the server is listening on the configured Syslog ports:

ss -lunp | grep -E ':514|:6514'

To verify packet arrival before checking the dashboard, leave a tcpdump capture open and generate events from each PLC. In this test, a STOP and a START were performed on each controller, confirming that the messages arrive at the server.

sudo tcpdump -n -i any "udp port 514 or udp port 6514"

The PLC configuration to send data to the rsyslog server is simple. To illustrate how it works we will use the OPC UA client and server project and make those PLCs send information to our dashboard.

Note: Siemens includes this capability in compatible CPUs from firmware V3.1, configurable from TIA Portal V19, allowing CPU events to be sent to an external Syslog server.

Since this is an initial lab setup, the flow is direct:

1. Open the PLC properties in TIA Portal.
2. Go to the Syslog section.
3. Enable event sending.
4. Select UDP as the transport.
5. Enter the Linux server IP address and reception port.

In this case, IP 192.168.1.116 and port 6514 are the address where the rsyslog server expects to receive the events.

This point is worth clarifying: although port 6514 is usually associated with secure Syslog, the transport configured here is UDP. Therefore, the messages are not encrypted and this setup should be understood as a lab test to validate events and analyze them with Wireshark. To truly talk about secure Syslog, TLS should be configured, normally over TCP, with certificates and server validation. We will cover that in a following article.

Through the dashboard we access the file hosted in the Linux LXC where the events generated by the PLCs were configured to be stored. In this case we have extracted the packets and organized the information both as plain text and in table format. From here to a standard database there is only one more step.

To generate test events, we can connect online with TIA Portal, change the controller mode or download a modification. If everything is configured correctly, those events appear in the server file and in the dashboard.

As you can see, the information is very powerful. It shows:

• Date and time of the event.
• PLC IP address that originated the event.
• Category of the event.
• Event itself: online connection from TIA Portal, PLC mode change, program changes, etc.
• Status if there has been a state change in the controller.
• User who performs the action.

This information is already very valuable for tracing what has happened in the PLCs. If we also insert it into a larger database and cross it with SCADA Audit Trail, variable histories, CMMS, ERP or a SIEM, we get a much more powerful view of the operation.

Filtering by the PLC and server IP addresses in Wireshark, we can see the UDP packets that transport the events.

The message we see has this form:

This means Siemens converts the information to the RFC 5424 standard, defined by the IETF. This standard describes how a Syslog message must be formed so different equipment and systems can interpret it consistently.

The general structure of these messages is:

<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MESSAGE

Thanks to this structure, a Siemens PLC can send events with date, origin, severity and structured data, and a server such as rsyslog can interpret, filter, store or forward them to a dashboard or SIEM platform.

• Siemens S7-1500 OPC UA Client: reading and writing in TIA Portal
• Siemens S7-1500 OPC UA Server: TIA Portal V20 and PLCSIM
• Secure Siemens PLC Communication with HMI and PC/PG
• Secure OPC UA in Siemens S7-1500: certificates, UA Expert and Sign & Encrypt