Modbus
From SCADApedia
Modbus is an application layer protocol commonly used in control systems. It was published initially by Modicon in 1979, and the protocol standards are now managed by the Modbus-IDA. Modbus is one of the most widely used control systems protocol and is used in many different industry sectors for monitoring and controlling a process.
Modbus was originally used over serial communication channels. The protocol was extended to work over TCP communications and there are gateway products that convert serial Modbus to Modbus TCP and vice versa.
Contents |
Protocol Format
The Modbus protocol is very simple as compared to DNP3, OPC, Ethernet/IP and other control system protocol choices.
- The Modbus protocol only specifies the application layer.
- Modbus is strictly a request/response protocol. There is no support for report by exception or unsolicited response.
- Modbus packets are small with a maximum of 252 data bytes
The Modbus protocol format is shown in the figure below. Modbus TCP is similar except the Address byte is replaced with a 7-byte Modbus Application Protocol (MBAP) field and the CRC field is removed. The CRC field will detect errors but does not prevent an attacker from modifying the packet and recalculating CRC.
The function code identify the type of request and response. Function codes are in the range from 1 to 127. Some examples of function codes are:
- FC 1 - Read Coils
- FC 6 - Write Single Register
- FC 7 - Read Exception Status
- FC 17 - Report Slave ID
A couple of the function codes have multiple purposes that are defined by sub-function codes sent in the data field. For example, FC 8 / sub function code 01 is Restart Communications Option and FC 8 / sub function code 10 is Clear Counters and Diagnostic Register. 19 of the Modbus function codes are currently defined in the standard so there is room for future enhancements. There are also function codes available for user definition and many Modbus implementations include custom function codes.
The response message is in the same format as the request message. If the response is valid, the function code used in the response message is the same as the request function code. The requested data for reads or results of writes or other commands is included in the data field.
If there is an error, the request function code is modified by adding a binary 1 to the high-order bit position of the request function code.
- Request FC 1 (x01) becomes Error FC 129 (x81)
- Request FC 6 (x06) becomes Error FC 134 (x86)
- Request FC 17 (x11) becomes Error FC 145 (91)
Security
There are no security elements in the Modbus protocol, over serial or TCP communications. Any attacker that can reach a Modbus server (slave) will be able to read and write to the device as well as reboot the device and run diagnostic commands.
The simplicity of the Modbus protocol and widespread availability of free Modbus clients makes it relatively simple to attack a Modbus server.
Compensating Controls
Since there is no security in the Modbus protocol it is important to restrict access to Modbus slaves (servers) and, to a lesser extent, Modbus masters (clients). The method for filtering or otherwise limiting access varies based on the communication method. For example, TCP communication can be restricted by router access control lists (ACL's) and modem security features can be used to restrict access via modem.
IDS signatures for Modbus TCP can detect rogue communication and attacks against Modbus TCP slaves (servers).
CIP Integration
CIP is the higher layer protocol developed by Rockwell Automation and used in DeviceNet and EtherNet/IP. Rockwell Automation has passed control of this specification to the ODVA. In April of 2007 the ODVA announced the intention to integrate the CIP protocol with Modbus. The specification, Volume 7, was completed in November 2007 and now is available on the ODVA web site for a small fee.
Volume 7 specifies a translation from a parameter and object based CIP client to the Modbus function code, coils, discrete inputs and registers. The translation could occur in the CIP client itself or in a CIP router. The client would send a CIP implicit or explicit message to the translation function that would convert this to a Modbus TCP or serial request as appropriate. The response from the Modbus device would be converted back into a CIP format. The result is a CIP client can work with a Modbus device.
The opposite is not true. A Modbus client cannot communicate with an DeviceNet or EtherNet/IP device.
External Links
Modbus-IDA Organization Home Page
