7 ms·

Libmodbus – A modbus library for Linux, Mac OS, FreeBSD and windows

26 points by maydemir 4y ago

airbreather 4y ago
Not sure what the intended use is, but traditional modbus is generally regarded as insecure. It's difficult to implement and meet requirements for cyber security required by functional safety, as one case example. Here are just a couple of many possible references: https://www.incibe-cert.es/en/blog/deconstructing-modbus https://www.incibe-cert.es/en/blog/deconstructing-modbus https://www.researchgate.net/publication/290732323_MODBUS_protocol_fuzzing_for_cyber-security_evaluation_of_industrial_control_systems https://www.researchgate.net/publication/290732323_MODBUS_pr... Additionally, managing address based protocols like modbus, esp where they span a battery limit or responsibility boundary can be far, far more expensive in engineering alignment efforts than most people realise. Once you go tag based, your never willingly go back to address based. These days the use OPC is often preferred, having the ability to be both secure and encrypted, as well as all the advantages of being a tag based protocol. NB: In my younger days I implemented many, many modbus links, over RS-232/485 and TCP and it really filled many practical needs, not least of which being a default industry standard that vastly increased you chances of communication between devices made by differing vendors. But these days, the focus on cyber security has really started to curb enthusiasm for modbus, but there is a drive to a newer version with security addressed. I would think the complexity added means, just go with OPC where possible.
- numlock86 4y ago
  > These days the use OPC is often preferred [...] Wishful thinking. Especially in the industry sector RS485 based Modbus is still the norm, even for new products. Also I guess you are talking about OPC UA, as OPC is just as old/bad in regards to cyber security.
  - fires10 4y ago
    The current state of cyber security in industrial networks is quite scary. Many systems rely on legacy software and can not be upgraded. Also take into account the old people running the system are often hesitant to try new technologies and often do not have the wide ranging IT and cyber security knowledge to make the right decisions. Even getting isolated networks and changing default passwords can be difficult.
  - airbreather 4y ago
    You won't be building your Grandma's control systems much longer, a whole new world is already here and OPC UA is a big part of it. A lot of PLC CPUs now come with an OPC server (and sometimes client) built in. Siemens rep here has said that medium to long term they see all their products converging on OPC and MQTT as preferred protocols. I just delivered multiple systems using the CPU based OPC server as the main serial link on Siemens S7-1500 PLC series. Just by virtue of being a tag based structure, including attributes alone, using OPC saved huge amounts of time and effort all thru testing and commissioning. Also, if your control system has functional safety involved then you will be complying with IEC/ISA 62443 cybersecurity standards as a requirement, and even if you don't have FS then you should be considering complying for best practice. OPC can be a big part of easy compliance. ICS cyber-security implementation is increasingly being mandated - https://www.whitehouse.gov/briefing-room/statements-releases/2022/01/27/fact-sheet-biden-harris-administration-expands-public-private-cybersecurity-partnership-to-water-sector/ https://www.whitehouse.gov/briefing-room/statements-releases... Using OPC UA as a serial link protocol of choice provides so many general benefits over modbus that you would be stupid not to use it if it was an option, and once there it's basically tick the box in the config to throw in security and encryption for almost zero extra effort. OPC Foundation has heaps of info at their website, it's all open source with standards, examples and reference versions of code for servers/clients available. There are also plenty of free OPC servers/clients/plugins/tools etc on the web to download and use both in design and production, but also to learn a little without shelling out cash. You can get an OPC server/client onto a sub $10 microprocessor, in an excel plug-in, thru to Oracle and SAP now have OPC modules to allow access of P2B data, as just some examples. OPC is much easier for fault finding and debugging as well, especially when you can connect multiple clients to any given server, then view any tags with their descriptions, scaling, units etc embedded, try that with modbus. If you are smart how you strcuture it, all that tag data you used to have to type in twice (PLC and HMI, scaling, units, boolean sense etc), if you are smart how you implement, you are only entering that once, in the PLC. And the protocol can support the equivelent of mammoth amounts of data exchange compared to available bandwidth, by virtue of report by exception, that is fully tuneable by the user. Having bulk equivelent bandwidth available means things like multistate indicators on your HMI can be sent to the HMI from the PLC as strings as well, ready for display, instead of just coded integers. This means you never get mismatched state indication text on your HMI and you only ever need to change the HMI state indication text in your PLC. Reality is get started learning OPC, or get left behind. While there, grab any opportunity that comes past to get a recognised competency in ICS cybersecurity - the standards require recognised and managed relevant competencies to be held for any persons that can impact cyber security during all phases of system design/implementation and ownership. Be that guy.
- RedShift1 4y ago
  Anyone who's running Modbus TCP or any other fieldbus is going to do it on an isolated VLAN and if for some reason it needs to run inter site, set up a site2site VPN. I don't see the added value of encrypting the protocol itself if you have all the earlier things I said which you're supposed to do anyway regardless of the security provisions of the application protocol.
  - oofbey 4y ago
    s/is going to/should/; It's frightening how many industrial product are completely insecure, assuming/hoping/wishing the installers only use them on a secure network. But all too often that "secure network" is the network for the whole facility, with every laptop, phone, device, etc on the same "secure" network. Sure, it's got a NAT "firewall" between it and the scary scary internet. But it's far from isolated the way it should be.
    - spacemanmatt 4y ago
      Former SRE here. I sure wish more people understood that security means way more than isolation, and hardening is impossible with a bunch of squishy devices that practically conspire to flatten your security model.
  - legalcorrection 4y ago
    Zerotrust networking is the current best practice. If you’re relying on network security for something, you’ve already failed.
technothrasher 4y ago
I looked at this library for a project where I had to support modbus, but I then geeked out and wrote my own library to support as much of the useless parts of the standard as I could simply for the enjoyment of it. It gets pretty hairy at the edges because the standard isn’t complete. But most of the stuff in there I’ve never actually seen being used in the wild.

26 points by maydemir 4y ago

Not sure what the intended use is, but traditional modbus is generally regarded as insecure. It's difficult to implement and meet requirements for cyber security required by functional safety, as one case example. Here are just a couple of many possible references: https://www.incibe-cert.es/en/blog/deconstructing-modbus https://www.incibe-cert.es/en/blog/deconstructing-modbus https://www.researchgate.net/publication/290732323_MODBUS_protocol_fuzzing_for_cyber-security_evaluation_of_industrial_control_systems https://www.researchgate.net/publication/290732323_MODBUS_pr... Additionally, managing address based protocols like modbus, esp where they span a battery limit or responsibility boundary can be far, far more expensive in engineering alignment efforts than most people realise. Once you go tag based, your never willingly go back to address based. These days the use OPC is often preferred, having the ability to be both secure and encrypted, as well as all the advantages of being a tag based protocol. NB: In my younger days I implemented many, many modbus links, over RS-232/485 and TCP and it really filled many practical needs, not least of which being a default industry standard that vastly increased you chances of communication between devices made by differing vendors. But these days, the focus on cyber security has really started to curb enthusiasm for modbus, but there is a drive to a newer version with security addressed. I would think the complexity added means, just go with OPC where possible.

numlock86 4y ago
> These days the use OPC is often preferred [...] Wishful thinking. Especially in the industry sector RS485 based Modbus is still the norm, even for new products. Also I guess you are talking about OPC UA, as OPC is just as old/bad in regards to cyber security.
- fires10 4y ago
  The current state of cyber security in industrial networks is quite scary. Many systems rely on legacy software and can not be upgraded. Also take into account the old people running the system are often hesitant to try new technologies and often do not have the wide ranging IT and cyber security knowledge to make the right decisions. Even getting isolated networks and changing default passwords can be difficult.
- airbreather 4y ago
  You won't be building your Grandma's control systems much longer, a whole new world is already here and OPC UA is a big part of it. A lot of PLC CPUs now come with an OPC server (and sometimes client) built in. Siemens rep here has said that medium to long term they see all their products converging on OPC and MQTT as preferred protocols. I just delivered multiple systems using the CPU based OPC server as the main serial link on Siemens S7-1500 PLC series. Just by virtue of being a tag based structure, including attributes alone, using OPC saved huge amounts of time and effort all thru testing and commissioning. Also, if your control system has functional safety involved then you will be complying with IEC/ISA 62443 cybersecurity standards as a requirement, and even if you don't have FS then you should be considering complying for best practice. OPC can be a big part of easy compliance. ICS cyber-security implementation is increasingly being mandated - https://www.whitehouse.gov/briefing-room/statements-releases/2022/01/27/fact-sheet-biden-harris-administration-expands-public-private-cybersecurity-partnership-to-water-sector/ https://www.whitehouse.gov/briefing-room/statements-releases... Using OPC UA as a serial link protocol of choice provides so many general benefits over modbus that you would be stupid not to use it if it was an option, and once there it's basically tick the box in the config to throw in security and encryption for almost zero extra effort. OPC Foundation has heaps of info at their website, it's all open source with standards, examples and reference versions of code for servers/clients available. There are also plenty of free OPC servers/clients/plugins/tools etc on the web to download and use both in design and production, but also to learn a little without shelling out cash. You can get an OPC server/client onto a sub $10 microprocessor, in an excel plug-in, thru to Oracle and SAP now have OPC modules to allow access of P2B data, as just some examples. OPC is much easier for fault finding and debugging as well, especially when you can connect multiple clients to any given server, then view any tags with their descriptions, scaling, units etc embedded, try that with modbus. If you are smart how you strcuture it, all that tag data you used to have to type in twice (PLC and HMI, scaling, units, boolean sense etc), if you are smart how you implement, you are only entering that once, in the PLC. And the protocol can support the equivelent of mammoth amounts of data exchange compared to available bandwidth, by virtue of report by exception, that is fully tuneable by the user. Having bulk equivelent bandwidth available means things like multistate indicators on your HMI can be sent to the HMI from the PLC as strings as well, ready for display, instead of just coded integers. This means you never get mismatched state indication text on your HMI and you only ever need to change the HMI state indication text in your PLC. Reality is get started learning OPC, or get left behind. While there, grab any opportunity that comes past to get a recognised competency in ICS cybersecurity - the standards require recognised and managed relevant competencies to be held for any persons that can impact cyber security during all phases of system design/implementation and ownership. Be that guy.
RedShift1 4y ago
Anyone who's running Modbus TCP or any other fieldbus is going to do it on an isolated VLAN and if for some reason it needs to run inter site, set up a site2site VPN. I don't see the added value of encrypting the protocol itself if you have all the earlier things I said which you're supposed to do anyway regardless of the security provisions of the application protocol.
- oofbey 4y ago
  s/is going to/should/; It's frightening how many industrial product are completely insecure, assuming/hoping/wishing the installers only use them on a secure network. But all too often that "secure network" is the network for the whole facility, with every laptop, phone, device, etc on the same "secure" network. Sure, it's got a NAT "firewall" between it and the scary scary internet. But it's far from isolated the way it should be.
  - spacemanmatt 4y ago
    Former SRE here. I sure wish more people understood that security means way more than isolation, and hardening is impossible with a bunch of squishy devices that practically conspire to flatten your security model.
- legalcorrection 4y ago
  Zerotrust networking is the current best practice. If you’re relying on network security for something, you’ve already failed.

technothrasher 4y ago

I looked at this library for a project where I had to support modbus, but I then geeked out and wrote my own library to support as much of the useless parts of the standard as I could simply for the enjoyment of it. It gets pretty hairy at the edges because the standard isn’t complete. But most of the stuff in there I’ve never actually seen being used in the wild.