Best practices with server hardening

[OldTinfoil]

In some ways this is a losing battle, since Modbus was never designed with modern server architecture in mind - but what are some good best practices for hardening a Modbus server with pymodbus? I had a quick look but I haven't been able to see if there's a document / discussion that already covers this.

[janiversen]

There isn't a document covering this, but I have a different opinion than you....modbus is a communication protocol, not a server architecture, you have the same losing battle with tcp/ip who also was never designed with modern server architecture in mind.

But apart from that, pymodbus is being rebuild from within, currently we have a modern transport layer in place, which have had a lot of work done to harden it. We also use standard python server classes, that are well tested, alone due to their diverse usage.

But I am not sure I understand your question correctly a server app that uses pymodbus can do little to influence the stability, that (at least in my mind) is nearly all done within pymodbus.

[OldTinfoil]

I understand that Modbus is a communications protocol. I was opting to use 'server' instead of 'slave'.

I was looking for examples such as:

• prefer to use only discrete inputs and input registers because you can't authenticate users via Modbus and so cannot verify that user has permission to make configuration changes. Prefer configuration/control changes to occur out-of-band if possible
• change the binding port to be less than (or equal to) 2048 so that you know the software is running on a privileged port and is less likely to be hijacked by an underprivileged user on a linux host
• implement certificates on the server so the client can verify that no MitM attack has occurred with a master connection
• restrict which hosts can access the port via whitelisting (rudimentary, but raises the barrier/cost of attack)
• proxy the tcp connection via a secure protocol between hosts rather than connecting directly

Obviously, most of the above cannot be implemented via pymodbus and has to be implemented on the underlying host. But hopefully they're useful as an example of what I'm looking for. You're just python package owners and writing a complete guide on "how to harden a host" is well outside of the scope, but it would be good to know what is possible within pymodbus to improve your organisation's security posture. No-one should roll their own security after all (insert credentials into a holding register(s) to authorise a user for a given period of time 🤮).

[janiversen]

• prefer to use only discrete inputs and input registers because you can't authenticate users via Modbus and so cannot verify that user has permission to make configuration changes. Prefer configuration/control changes to occur out-of-band if possible
  Modbus was never intended to be configurable inline, in the automation that would be an unacceptable risk for hacking. a few devices do it either way custom messages which pymodbus support. Btw many devices actually have a user/password concept implemented with custom function codes.

• change the binding port to be less than (or equal to) 2048 so that you know the software is running on a privileged port and is less likely to be hijacked by an underprivileged user on a linux host

implement certificates on the server so the client can verify that no MitM attack has occurred with a master connection
restrict which hosts can access the port via whitelisting (rudimentary, but raises the barrier/cost of attack) proxy the tcp connection via a secure protocol between hosts rather that connecting directly certificates on the server so the client can verify that no MitM attack has occurred with a master connection

Done just use the tls framer.

• restrict which hosts can access the port via whitelisting (rudimentary, but raises the barrier/cost of attack)

that is open and pull request are welcome, but not something you use in the automation world.

• proxy the tcp connection via a secure protocol between hosts rather that connecting directly

Just add a modbus forwarder and it's done, but is surely never going to be used in the automation world, it's an added risk element.

It seems to me, your knowledge about modbus is not in-depth, may I suggest you read the standard documentation...it also seems you have not read the pymodbus documentation since the tls framer seems unknown to you. Maybe also read how "real" automation of e.g. a power plant in difference to e.g. IoT, that is really 2 very distinct worlds.

but as always, we happily accept pull request

[OldTinfoil]

I have read the documentation and I am aware of the framer. I was looking for any advice for things I had missed.

[janiversen]

If you know the tls framer, then I really do not understand why you have certificates in your list.

But independent of this, I have still not seen items relevant for pymodbus, remember the server is only in very special situations used in production, it is targeted for testing (see README).

If you want changes to pymodbus then we are happy to review your pull requests....if you want to discuss modbus in general then modbus.org is the place to do so.