Modbus is a very widespread industrial communications protocol with a publicly available specification, based on a master/slave architecture. There are currently no extensive restrictions on the time at which data blocks can be managed in an industrial system; implementing this would be straightforward, and would require little development. There are currently two implementations: Modbus series (with ASCII and RTU operating modes) and Modbus/TCP.
To find out more about the protocol and its weaknesses, it is recommended to refer to the study Protocols and network security in SCI infrastructures.
In Modbus, the slave elements’ operation mode consists of always responding to the packets they receive. The ModScan tool takes advantage of this feature, directing TCP requests (therefore only available for Modbus/TCP implementations) to the standard Modbus port, 502, and thereby discovering the slaves connected to the network, as can be seen in the image below.
- Discovering the Modbus slaves’ IPs with Modscan -
- Fine tuning the search for slaves and the identification of Modbus IDs -
Once the slaves have been identified, it is easy to capture traffic with any tool designed for capturing network traffic. Capture analysis shows that communications are not encrypted, which means it is possible to identify and directly analyze the information given and the operation mode. The following image shows a traffic capture with an analysis of the stream.
- Modbus traffic capture and analysis by Wireshark -
Modbus does not authenticate sessions, which leaves both slaves and masters vulnerable to impersonation. Slave impersonation is also possible, and would mean that incorrect data could be sent to the master, although this requires a prior IP Spoofing attack.
- Diagram showing Modbus master impersonation -
The fact the packets received are not filtered in the operation mode, together with the possible impersonation of masters, gives rise to another vulnerability concerning availability. This makes denial of service possible, if multiple attacking masters deliver a great number of packets to just one slave. In this situation, the slave will try to respond to all requests, until an overload produces a denial of service. In simulated or virtualized environments, this attack is more difficult to execute owing to the greater communication capacity of computers, but it is feasible on real field elements such as PLC which implement this protocol.
Only Modbus series implementations can verify these weaknesses, and it is possible to run the same tests on a Modbus/TCP implementation, although some tests require additional hardware or specific network configurations.
Modbus’ weaknesses are rooted in its specification, meaning that they are intrinsic to the protocol; as no changes to the specification are anticipated, it is therefore necessary to introduce additional security elements, to help mitigate its security failings.
Moving on from this option, which is the most simple, the first measure to consider is the adoption of an encryption strategy for communications. Communications encryption will prevent information from being analysed in transit, in case the traffic is captured.
Devices which implement this protocol are not generally able to encrypt communications, and they must therefore use external tools, which can encrypt and decrypt the information running through the Ethernet cable.
Although this solution is effective, it is difficult in practice, as using encryption tools brings problems of management and password distribution; in addition, information encryption and decryption must be permitted by all industrial equipment to be used to by Modbus protocol.
Therefore, in order to control the traffic between slaves and the master, firewalls are the most popular solution. Conventional firewalls allow for traffic control at network level, meaning that the master and slaves’ addresses can be established as authorities, thereby preventing certain kinds of impersonation attacks. Application firewalls allow for inspection, including for the data section of the stream.
There is Modbusfw, a module for iptables which filters traffic at the level of application layer to secure networks using the Modbus/TCP protocol. It allows for the filtering of Modbus traffic packets, identifying them using the slave’s ID, the function code, the packet size or the reference number. In this way, it is possible to avoid writing on equipment that should only receive readings or vice versa, and to filter the use of diagnostic function codes (such as those used in certain Modbus network scan tools), etc.
Firewalls permit traffic control in different networks, but it is useful to use them in conjunction with intrusion detection and prevention systems (IDS/IPS) in order to detect other kinds of actions.
For the Snort IDS, and for all those based in it, there is an extension for interpreting the Modbus protocol. It is possible to define traffic control regulations for Modbus based on values that must contain different data bytes in one Modbus/TCP stream.
Using IDS/IPS systems to supervise the Modbus protocol allows the use of non-permitted functions to be recognized, as well as recognizing when data packets are sent from non-controlled IP addresses, helping, for example, to detect potential DoS attacks.
- Snort rules for detecting inadequate Modbus traffic -
Using these two tools in conjunction enables the slave or master impersonation attacks to be minimized, as well as denial of service attacks, network scans, etc. If IDS is used rather than IPS, it is possible to detect attacks, receiving corresponding alerts, but the reaction ability is lost.
Finally, as an additional security measure, not for protection against attacks but simply to be informed, it is advisable to install an events management system or SIEM, which collects all alerts registered by the IDS/IPS, firewalls, relevant information on other devices, etc.
Example of attack and countermeasure effects
The following video demonstrates a control system implemented in a laboratory, with non-simulated elements. This control system consists of a PLC with various entrances and exists, used to manage a water distribution system with four storage tanks, a supply, situated to the left of the diagram and two consumption centres on the right of the image. In addition, the system has different valves and pumps to control the flow of water between the tanks, so as to make sure that water is provided to the points of consumption.
- HMI of tank system control -
The PLC communicates with the equipment that collects the data via the Modbus/TCP protocol, using the standard port.
- Video on master impersonation and blocking writing orders -
As can be seen in the video, it is possible to impersonate a Modbus master and repeatedly send writing orders to the PLC slave, thereby forcing the state of a variable, which prevents the system from functioning correctly.
To avoid this, a firewall should be installed. When the firewall is activated, writing orders will be blocked from the variable as they are non-authorized traffic in the firewall, and the system can once again function normally.