01 Terminology Interpretation
1 word = 2 bytes;
1 byte = 8 bits.
Checksum: A checksum is derived from the preceding data through a certain algorithm to verify the correctness of the data set. When inputting codes as data into a computer or other devices, input errors can easily occur. To reduce such input errors, coding experts have invented various error detection methods and set up checksums based on these methods.
Common checksums include: SUM (Checksum), XOR (Byte XOR Check), LRC (Longitudinal Redundancy Check), CRC (Cyclic Redundancy Check)…
Discrete Input: Mainly used to read a single bit of data, such as the status of an IO;
Coil: Switch output signal, mainly used to write a single bit of data, forming paired operations with discrete inputs;
Input Register: Mainly used to read 16 bits, which is two bytes of data;
Holding Register: Mainly used to write 16 bits of data.
PLC: Programmable Logic Controller, a type of programmable storage device used to store programs internally, execute logical operations, sequential control, timing, counting, and arithmetic operations, and issue user-oriented commands to control various types of machinery or production processes through digital or analog input/output.
Serial Communication: With the application of computer systems and the development of microcomputer networks, communication functions have become increasingly important. Here, communication refers to the exchange of information between computers and the outside world. Therefore, communication includes information exchange between computers and external devices, as well as between computers. Since serial communication transmits information one bit at a time over a single transmission line, fewer transmission lines are needed, and it can utilize existing telephone networks for information transmission, making it particularly suitable for long-distance transmission. For those external devices that are not far from the computer, such as human-machine exchange devices and serially stored external devices like terminals, printers, logic analyzers, and disks, using serial communication to exchange data is also common. In real-time control and management, communication between CPUs in a hierarchical distributed control system is generally done serially. Thus, serial interfaces are commonly used in microcomputer application systems. Many peripherals and computers communicate serially, where the term serial communication refers to the information transfer method between peripherals and interface circuits, while the CPU and interface still operate in parallel.
Serial Port: A serial port is a very common communication protocol for devices on a computer, and should not be confused with the Universal Serial Bus (USB). Most computers contain two RS232-based serial ports. The serial port is also a common communication protocol for instruments and meter devices; many GPIB-compatible devices also come with RS-232 ports. At the same time, the serial communication protocol can also be used to obtain data from remote collection devices.
The concept of serial communication is very simple; serial ports send and receive bytes bit by bit. Although it is slower than parallel communication, which sends data byte by byte, a serial port can send data on one line while receiving data on another. It is simple and can achieve long-distance communication. For example, when IEEE488 defines the parallel communication state, it stipulates that the total length of the device line must not exceed 20 meters and that the length between any two devices must not exceed 2 meters; while for serial ports, the length can reach 1200 meters.
Typically, serial ports are used for transmitting ASCII character codes. Communication is accomplished using three lines: (1) Ground, (2) Send, (3) Receive. Since serial communication is asynchronous, the port can send data on one line while receiving data on another. Other lines are used for handshaking, but are not mandatory. The most important parameters of serial communication are baud rate, data bits, stop bits, and parity. For two ports communicating, these parameters must match:
a. Baud Rate: This is a parameter that measures communication speed. It indicates the number of bits transmitted per second. For example, 300 baud means sending 300 bits per second. When we mention clock cycles, we are referring to the baud rate. For example, if a protocol requires a baud rate of 4800, then the clock is 4800Hz. This means the sampling rate of serial communication on the data line is 4800Hz. Typically, telephone lines have baud rates of 14400, 28800, and 36600. Baud rates can be much higher than these values, but baud rate and distance are inversely proportional. High baud rates are often used for communication between instruments that are very close together, a typical example being GPIB device communication. b. Data Bits: This is a parameter that measures the actual data bits in communication. When a computer sends a packet of information, the actual data will not be 8 bits; standard values are 5, 7, and 8 bits. How to set it depends on the information you want to transmit. For example, standard ASCII code is 0-127 (7 bits). Extended ASCII code is 0-255 (8 bits). If the data uses simple text (standard ASCII code), then each data packet uses 7 bits of data. Each packet refers to a byte, including start/stop bits, data bits, and parity bits. Since the actual data bits depend on the selected communication protocol, the term “packet” refers to any communication situation. c. Stop Bits: Used to indicate the last bit of a single packet. Typical values are 1, 1.5, and 2 bits. Since data is timed on the transmission line and each device has its own clock, it is likely that there will be slight desynchronization between two devices during communication. Therefore, stop bits not only indicate the end of transmission but also provide an opportunity for the computer to correct clock synchronization. The more stop bits suitable, the greater the tolerance for clock desynchronization, but the data transmission rate also becomes slower. d. Parity Bit: A simple error detection method in serial communication. There are four error detection methods: even, odd, high, and low. Of course, there can also be no parity bit. For even and odd parity, the serial port will set a parity bit (one bit after the data bits) to ensure that the number of logical high bits transmitted is either even or odd. For example, if the data is 011, then for even parity, the parity bit is 0, ensuring the number of logical high bits is even. If it is odd parity, the parity bit is 1, resulting in three logical high bits. High and low bits do not truly check the data, simply setting logical high or low for verification. This allows the receiving device to know the state of a bit, providing an opportunity to determine if noise has interfered with communication or if the transmitted and received data are out of sync.
02 Background
As early as 1971, Modicon introduced the Modbus protocol, giving birth to Modbus RTU and Modbus ASCII. Later, Schneider Electric acquired Modicon and launched the Modbus TCP protocol in 1997. In 2004, the National Standardization Committee of China officially designated Modbus as a national standard, marking the beginning of Modbus’s contribution to industrial communication in China.
Through this protocol, controllers can communicate with each other, and controllers can communicate with other devices via the network. The Modbus protocol features standardization, openness, support for various electrical interfaces, a simple and compact data frame format, large data transmission volume, and good real-time performance, making it widely used in industrial control systems and becoming a universal industrial standard. Analyzing the implementation principles and security of the Modbus protocol is of significant practical importance for enhancing the security of industrial control systems. Modbus RTU and Modbus ASCII are mainly used in serial communication, while Modbus TCP is commonly used in Ethernet communication. Today, Modbus has become the standard communication protocol in the industrial field and is a commonly used connection method between industrial electronic devices.
03 Protocol Principles
Modbus uses a simple Master-Slave protocol (Client/Server protocol) for communication. The client acts as the master, sending requests to the server; the server (slave) analyzes the request upon receipt and responds accordingly. The communication frame used is called an Application Data Unit (ADU), which includes the communication address segment, function code segment, data segment, and checksum segment, as shown in the following figure:
Generally, monitoring systems (HMI) act as the Master, while PLCs, electric meters, and instruments act as Slaves. The HMI system continuously polls various relay and register values from the Slave, then displays and processes various logical calculations and control adjustments.
The function code segment and data segment combination is called the Protocol Data Unit (PDU). The function code segment occupies one byte, with a value range of 1-255, where 128-255 are reserved for abnormal message response packets. The function code numbers range from 1-127, with 65-72 and 100-110 being user-defined codes.
04 Transmission Methods
The Modbus protocol is an application layer message transmission protocol that includes three message types: ASCII, RTU, and TCP. The protocol itself does not define the physical layer; it only defines the message structure that the controllers can recognize and use, regardless of the network through which they communicate.
When using the Modbus protocol over a serial connection, either RTU or ASCII mode can be selected, specifying the message, data structure, commands, and response methods, and requiring data validation. The ASCII mode uses LRC validation, while the RTU mode uses 16-bit CRC validation. When transmitted over Ethernet, TCP is used, and this mode does not use validation because the TCP protocol is a reliable connection-oriented protocol.
05 Differences Between Modbus RTU and Modbus ASCII
Modbus is an application layer protocol that defines data units (ADU) independent of the underlying network, allowing communication over Ethernet (TCP/IP) or serial links (RS232, RS485, etc.). There are two transmission modes for the Modbus protocol over serial links—ASCII mode and RTU mode. ASCII stands for American Standard Code for Information Interchange; RTU stands for Remote Terminal Unit.
First, let’s look at how Modbus works.
Modbus adopts a Master-Slave communication mode, where only the Master device can initialize the transmission, and the Slave device responds based on the Master’s request. Typical Master devices include field instruments and display panels, while typical Slave devices are Programmable Logic Controllers (PLCs).
In Master-Slave communication over serial links, a Modbus Master device can connect to one or N (up to 247) Slave devices. Communication between Master and Slave devices includes unicast and broadcast modes.
In broadcast mode, the Modbus Master device can simultaneously send requests to multiple Slave devices (address 0 is used for broadcast mode), and Slave devices do not respond to broadcast requests.
In unicast mode, the Master device sends requests to a specific Slave device (each Modbus Slave device has a unique address), and the request message frame will contain function codes and data, such as function code “01” used to read the status of discrete coils. After receiving the request, the Slave responds and feeds back the message to the Master device.
In communication between Master and Slave devices, either ASCII mode or RTU mode can be used.
In ASCII (American Standard Code for Information Interchange) transmission mode, the message frame starts with a colon (“:”, ASCII 3A Hex) and ends with a carriage return and line feed (CRLF, ASCII 0D and 0A Hex), allowing the transmission character set to be hexadecimal 0-9 and A-F; the Slave devices in the network monitor the transmission path for the colon (“:”). If present, they decode the message frame and check if the address in the message matches their own; if it matches, they receive the data; if not, they ignore it.
In ASCII mode, each 8-bit byte is split into two ASCII characters for transmission. For example, the hexadecimal number 0xAF is split into ASCII characters “A” and “F” for transmission, doubling the amount of characters sent compared to RTU. The advantage of ASCII mode is that it allows up to 1 second of time between characters without causing communication failure. This mode uses Longitudinal Redundancy Check (LRC) for error checking.
When the controller is set to communicate in RTU mode on the Modbus network, each 8-bit byte contains two 4-bit hexadecimal characters, and this mode has no start and end markers. Its advantage is that it can transmit more data at the same baud rate.
In RTU (Remote Terminal Unit) mode, each byte can transmit two hexadecimal characters, for example, the hexadecimal number 0xAF is sent directly as 0xAF (binary: 10101111), making its transmission density twice that of ASCII mode; RTU mode uses Cyclic Redundancy Check (CRC), summarized as follows:
The specific format is shown in the figure.
06 Modbus TCP and Its Considerations
6.1 Host and Slave, Server and Client
[In the Modbus protocol]
The host sends Modbus requests, and the slave responds to the host based on the request content. In the Modbus protocol, the host is always the active party, while the slave is always the passive party.
[In network applications]
In network applications, there are clients and servers, where the client (e.g., a browser) sends requests to the server, which returns content (e.g., HTML text) to the client.
[In Modbus TCP]
The host is the client, while the slave is the server. Do not think that the server is more important; the host is also important, so the host is the server.
6.2 Is Multi-Host Possible?
Based on previous analysis, since the host is the client, Modbus TCP supports multiple hosts, and multiple hosts and slaves can exist within a local area network. The connection capacity of the slave (the number of hosts it can connect to) is determined by the maximum TCP connections of uIP.
6.3 Brief Introduction to Modbus TCP Protocol
Modbus TCP and Modbus RTU are essentially the same, but there are some differences.
a. The slave address becomes less important and is often ignored. In a sense, the slave address is replaced by the IP address.
b. CRC validation becomes less important and can even be ignored. Since TCP packets already contain validation, Modbus TCP simply cancels CRC validation to avoid redundancy.
The TCP mode was created to allow Modbus data to be transmitted smoothly over Ethernet, using TCP port 502. The protocol’s physical layer, data link layer, network layer, and transport layer are all based on the TCP protocol, only modifying and encapsulating the Modbus protocol at the application layer; the receiving end unpacks the TCP packet to retrieve the original Modbus frame, then parses it according to the Modbus protocol specification and re-encapsulates the returned data packet into the TCP protocol before sending it back to the sender. Unlike the data format transmitted over serial links, the TCP mode removes additional addresses and checks, adding a message header instead, with the specific format shown in figure 4.
In Modbus TCP, there is an MBAP header that contains the following parts:
| Field | Length | Description | Client | Server |
|---|---|---|---|---|
| Transmission Flag | 2 bytes | Sequence number during MODBUS request and response transmission | Generated by the client | Copied during response |
| Protocol Flag | 2 bytes | Modbus protocol defaults to 0 | Generated by the client | Copied during response |
| Length | 2 bytes | Length of the remaining portion | Generated by the client | Generated by the server during response |
| Unit Flag | 1 byte | Slave flag (slave address) | Generated by the client | Copied during response |
[Note]
[1] The transmission flag can be understood as a sequence number to prevent MODBUS TCP communication misalignment, such as a later response arriving at the host before an earlier one.
[2] The unit flag can be understood as the slave address, which is no longer important.
6.4 Relationship Between Modbus TCP and TCP IP
Modbus TCP can be understood as an application layer protocol occurring over TCP. Since it is a TCP protocol, a complete MODBUS TCP message must include the TCP header, IP header, and Ethernet header.
07 Function Code Usage
The client initiating the Modbus transaction creates the Modbus Application Data Unit. The function code (in the PDU) indicates to the server which operation will be performed.
The function code field of the Modbus data unit is encoded with one byte. The effective range is decimal 1-255 (128-255 are reserved for abnormal responses). When sending a message from the client to the server, the function code field indicates which operation will be executed by the server.
The data field of the message sent from the client to the server includes additional information that the server uses to perform the operation defined by the function code. This field also includes discrete item and register addresses, the number of items being processed, and the actual number of data bytes in the field.
In some requests, the data field may not exist, in which case the server does not need any additional information. The function code only specifies the operation.
Types of Function Codes
Function codes are mainly divided into valid function codes, abnormal function codes, and error function codes.
If no errors related to the requested Modbus function occur in a correctly received Modbus ADU, the response data from the server to the client will contain the normal function code from the request. If errors related to the requested Modbus function occur, the response data will contain an abnormal code and an error code.
For example, the client can read the on/off status of a set of discrete outputs or inputs, or the user can read/write a set of register data contents. When the server responds to the client, it uses the function code field to indicate a normal (no error) response or some kind of error (called an abnormal response). For a normal response, the server only responds with the original function code, as shown in the following figure:
For an abnormal response, the server returns a code equivalent to that of the client, setting the most significant bit of the original function code to logic 1 and adding the abnormal code followed by the error code to notify the client of the reason for the abnormality. As shown in the following figure:
Valid Function Codes
There are more than twenty valid function codes, but generally, the most commonly used are 1, 2, 3, 4, 5, 6, 15, 16, and two special-use codes 20 and 21, which are General Reference Registers. Most Modbus devices do not provide this register. The main control data in PLCs includes the following four types. These eight function codes process this control data, detailed as follows:
Four Types of Control Data:
DI: Digital Input (Discrete Input), one address per data bit; users can only read its status, not modify it. Represented by one bit as On/Off, used to record the status input of control signals, such as switches, contact points, motor operation, limit switches, etc. In PLCs, it is referred to as Input relay, input coil, etc.
DO: Digital Output (Coil Output), one address per data bit; users can set, reset, and read back the status. Represented by one bit as On/Off, used to output control signals to activate or stop motors, bells, lights, etc. In PLCs, it is referred to as Output relay, Output coil, etc.
AI: Analog Input (Input Register), one address 16-bit data; users can only read, not modify, represented by a 16-bit integer to record the numerical input of control signals, such as temperature, flow, material quantity, speed, rotational speed, valve opening, liquid level, weight, etc. In PLCs, it is referred to as Input register.
AO: Analog Output (Holding Register), one address 16-bit data; users can write and read back, represented by a 16-bit integer to output the numerical value of control signals, such as temperature, flow, speed, rotational speed, valve opening, feed quantity, etc. In PLCs, it is referred to as Output register, Holding register.
08 Security Analysis of the Modbus Protocol
The Modbus protocol is a typical industrial control network protocol, and studying its security is of great importance for enhancing the security of industrial control networks. Generally, security issues with protocols can be divided into two types: one is security problems arising from the design and description of the protocol itself; the other is security problems arising from incorrect implementations of the protocol. The Modbus protocol also has both of these issues.
8.1 Inherent Problems of the Modbus Protocol
The vast majority of industrial control protocols, at the design stage, only considered functional implementation, efficiency improvement, and reliability enhancement, without considering security issues. The Modbus protocol is no exception, even though it has become a de facto industrial standard. From the previous principle analysis, it can be seen that its inherent security issues are: lack of authentication, authorization, encryption, and the problem of function code misuse.
(1) Lack of Authentication
The purpose of authentication is to ensure that the received information comes from legitimate users, and control commands sent by unauthenticated users to devices will not be executed. During the communication process of the Modbus protocol, there are no relevant definitions regarding authentication; an attacker only needs to find a legitimate address to establish a Modbus communication session using function codes, thus disrupting the entire or part of the control process.
(2) Lack of Authorization
Authorization ensures that different privileged operations are performed by authenticated users with different permissions, greatly reducing the probability of operational errors and internal attacks. Currently, the Modbus protocol does not have a role-based access control mechanism, nor does it classify users or define user permissions, allowing any user to execute any function.
(3) Lack of Encryption
Encryption ensures that information between both parties during communication is not illegally obtained by third parties. In the Modbus protocol communication process, addresses and commands are all transmitted in plaintext, making it easy for attackers to capture and analyze the data, providing convenience for attackers.
(4) Function Code Misuse
Function codes are an important part of the Modbus protocol, and almost all communications contain function codes. Currently, function code misuse is a major factor leading to Modbus network anomalies. For example, illegal message lengths, short cycles of useless commands, incorrect message lengths, and delayed confirmation of abnormal codes can all potentially lead to denial-of-service attacks.
8.2 Problems Arising from Protocol Implementation
Although the Modbus protocol has been widely used, developers do not often possess security knowledge or are unaware of security issues when implementing specific industrial control systems. This leads to various security vulnerabilities in systems using the Modbus protocol.
(1) Design Security Issues
Modbus system developers primarily focus on functional implementation issues, with security problems rarely being considered during design. Design security refers to fully considering security during design, addressing potential exceptions and illegal operations that may occur in Modbus systems. For instance, if a node is maliciously controlled and sends illegal data during communication, it is necessary to consider how to discern and handle such data.
(2) Buffer Overflow Vulnerabilities
Buffer overflow refers to filling data into a buffer that exceeds the buffer’s capacity, causing the overflow data to overwrite valid data. This is one of the most common and dangerous vulnerabilities in software development, which can lead to system crashes or be exploited by attackers to gain control of the system. Most Modbus system developers lack security development knowledge, leading to many buffer overflow vulnerabilities, which can have serious consequences if exploited by malicious actors.
(3) Modbus TCP Security Issues
Currently, the Modbus protocol can be implemented on general computers and general operating systems, running on TCP/IP to meet developmental needs. Thus, the inherent security issues of the TCP/IP protocol inevitably affect the security of industrial control networks. Common attack methods in the IP Internet, such as unauthorized network data acquisition, man-in-the-middle attacks, denial-of-service attacks, IP spoofing, and viruses/trojans will all impact the security of Modbus systems.
8.3 Security Recommendations
Currently, the security measures taken by Modbus systems are generally inadequate. Here, we refer to information security industry research combined with the specific security issues of industrial control systems to propose some security recommendations that can effectively reduce the threats faced by industrial control systems.
(1) Start from the Source
Vulnerabilities in industrial control networks often arise from implementation processes. If security measures are implemented from the source, involving security design, secure coding, and security testing throughout the entire lifecycle of the Modbus system’s requirements design, development implementation, internal testing, and deployment, it can greatly eliminate security vulnerabilities and reduce the overall security risks of the Modbus system.
(2) Anomaly Behavior Detection
Anomalous behavior indicates potential threats, regardless of whether there are attackers. Therefore, developing dedicated anomaly detection devices for Modbus systems can greatly enhance the security of industrial control networks. For Modbus systems, it is first necessary to analyze the various operational behaviors that exist, describing behaviors using a six-tuple model based on “subject, location, time, access method, operation, object”; then analyzing whether the behavior is anomalous; and ultimately deciding to record or alert.
(3) Security Auditing
The security audit of Modbus involves deep decoding analysis of protocol data, recording key information such as operation time, location, operator, and operational behavior, achieving security audit log recording and auditing functions for the Modbus system, thus providing traceability for security incidents after they occur.
(4) Use Network Security Devices
Utilize intrusion prevention systems and firewalls as network security devices. A firewall is a serial device that, through settings, only allows specific addresses to access the server and prohibits external addresses from accessing the Modbus server, effectively preventing external intrusions; intrusion prevention devices can analyze specific operational content of the Modbus protocol, effectively detecting and blocking various abnormal operations and penetration attacks from both internal and external sources, providing protection for the internal network.
-
(Content sourced from the internet, copyright belongs to the original author)
-
Disclaimer: If there are copyright issues, please contact us for deletion! No individual or organization shall bear related legal responsibilities.
-
