As I am sure you are aware, MODBUS/TCP has no security or authentication features of its own.
On Victron GX devices that have MODBUS enabled, there are several MODBUS registers that can be written to that would allow control of the connected device, or contain important settings that can degrade or disable important protections. Therefore, such devices are highly vulnerable to malicious persons who can gain access to the network they are connected to. For many users, the only thing standing between their inverter and the creatures of the night is their crummy old ISP router.
In my opinion this is an untenable risk in present times, although I also recognise that MODBUS is an established and useful feature that many DIY and particularly industrial users may require. Accordingly, I request the following feature for Venus:
A new register, initially set to 1, that - if set to 1 - would allow MODBUS write commands to be executed, with these being rejected with a suitable error code otherwise. This register should be read-only within the MODBUS and MQTT frameworks.
A new slider in the Console connected to that register that allows a logged-in user to enable or disable MODBUS write commands.
The above would have the following effects:
MODBUS would be read/write by default if enabled, as has historically been the case in Victron GX devices, but logged-in users can restrict access to read commands only if desired.
MODBUS write commands can be enabled or disabled only by an authenticated user, thus preventing a malicious actor from disabling the MODBUS write command on an installed system which depends on them (although in this case they could do other horrible things to it if course).
You can disable modbus and mqtt access on the GX itself.
Would that not be sufficient?
Or are you wanting the features to be available for use but not a malicious person? If so then network security is now in the home owners court.
EDIT: note that the ModbusTCP feature here referred to is disabled by default and 99% of users doesn’t need it and are best served by leaving it disabled.
I wanted what I believe to be the most common use-case, i.e. monitoring, to be at the same time as available and safe as possible.
To someone familiar with the innards of the GX MODBUS system, it would be the work of an afternoon to implement the feature I described, and no-one could argue that it would not be sound engineering to do it in 2025. It is an easy quick fix.
By contrast, nothing would sell more inverters of comparable capability from other brands in larger numbers than for a big blue installation on an important site to go belly-up one evening because the WiFi password was the name of somebody’s dog. Anybody with any imagination would be asking why read-only MODBUS wasn’t even an option.
For me, it is about making sensible and easy improvements to safety before things happen, rather than to fold one’s hands over one’s belly and smile because one can argue it wasn’t one’s fault.
Because the system uses it to make changes so it can’t be read only.
Since it is an industry standard, not only victron would need to changed so would all other manufacturers of inverters and many other control systems.
I do hear what you are saying. The simplest is to switch off access.
(Most even poor routers close the port by default to unsolicited modbus connections).
He’s already made the suggestion on the first message. Pretty good one.
Just like someone is locking the door for write before leaving and only the ones with the key can enter later.
Read-only is not the right term - my bad. It is shorthand for this:
MODBUS request comes in on TCP connection on the WRITE function number
Check if “TCP MODBUS WRITES ALLOWED” flag is set.
If so, swallow and digest, otherwise drop (with error code if you want to be polite).
Nobody out there has to change anything. Standard MODBUS is there if two sliders are on, MODBUS write requests only are dropped if the bottom slider is off.
Although @Bob_Bobson , this is true only for the ones which don’t have other devices that are using write commands on the same network for the same target device.
Otherwise you must leave the slider on…
Nevermind, it also works for them, because they are local… Sorry.
Only the external ones are subjected to filtering, because they are passing through Cerbo.
Change the on/off slider that there is now for the ModbusTCP server functionality into a pulldown with three options:
Off (default)
Read-only access
Read/write access (formerly called On)
And any system now being on the On position will upgrade to Read/write.
The default is and will remain for ModbusTCP to be off.
Are other changes then still necessary? I’d like to prevent adding a new register, to be able to keep it simple.
With regards to the horrible Excel sheet: I’m looking for someone to improve our ModbusTCP documentation - and maintain it thereafter - if you are available for that, let me know!
Your suggestion is very good - the reason I suggested that extra register was just so that a thing could find out by means of a MODBUS query whether it is going to be able to write or not, but if it makes work then I would say forget that.
In verband met julle spreadsheet, ongelukkig beskou my brein se MODBUS dit alreeds as 'n “read only” register​:rofl:. Om die waarheid te sê, daardie spreadsheet is nie so verskriklik vanweë sy eie foutiewe eienskappe nie, maar eerder omdat MODBUS nie op sy eie 'n inspireerende onderwerp is nie
Ek kan miskien 'n voorbeeld vir julle opskryf. Ek het destyds my eie piepklein MODBUS/TCP interface geskryf in C (Unix-style TCP) wat ek dan gebruik in Python en ander scripts, of sommer op die command-line - miskien gooi ek hom later van tyd op GitHub, maar voor ek so maak wil ek die “skryf” funksie eers weer mooi deursoek vir goggas.
Ek wil juis daardie stukkie oorskryf d.m.v. dieselfde Python MODBUS ding wat julle daarsĂ´ by Victron gebruik in julle Venus kode, en ek sal daardie stukkie met julle deel as 'n voorbeeld vir julle doks.
Matthijs, I hope you will forgive me, but I am from the Cretaceous period and so I don’t know that much about MQTT and thus I forgot to mention it earlier, although LX remembered it.
It may be that you need the same three position slider there as well, if you can write stuff into the Victron GX using MQTT, assuming no separate authentication there.
The idea is good but I doubt that this would be such an easy to implement feature.
It might depend on the implementation, if my memory serves me right the declaration of a register as ReadOnly, Write or Read/Write (or enabling/disabling writes on the overall MODBUS stack) is done on declaration/startup and toggling between Read/Write & ReadOnly will probably require a restart of the MODBUS daemon.
Not that this is a real problem but implementation will likely not be trivial.
Another (extra) option can be to limit (R/W) access to a specified IP or set of IP addresses, this is what Fronius does.
MODBUS is used a lot in industrial systems and part of my job is to secure access to those but, as @lxonline already mentioned, virtually all access control to MODBUS devices is done on the network level and not on device level.
The device limiting access to specific IPs, yes.
Toggling registers or overall access from RW to RO I have never seen.
With MODBUS entering the IOT and home/consumer market more & more, security becomes less trivial.
After all, the S in IOT stands for Security.
Being a network architect I’m running my own routers in my installs but for most user installs that’s not an option.
Hardening the GX device is something I can only encourage.
From discussions with Matthijs above I think it is going more in the direction that the GX would (optionally) just drop MODBUS TCP requests where the MODBUS function number is the one for WRITE.
Thus the registers are still what they are but the GX just wont push the contents of a MODBUS TCP write request “packet” down the alimentary canal for further processing unless the GX is set to allow it to do so. This is just so that people who need MODBUS for monitoring only don’t expose themselves more than they really need to.
Whether this can easily be done in Venus or not I am not sure - my level of acquaintance with the innards of a GX is limited. However, somewhere before anything actually gets changed the GX will know that a write request has come in and can drop it rather than act on it. My own MODBUS TCP client-side code will not transmit a write request unless the calling subroutine sets a “request permission” flag in a struct in advance - two factor authentication of sorts
Your IP whitelist concept will provide a degree of protection for sure, but if a whitelisted host is compromised then obviously not. MODBUS is brilliant so long as it’s on a dedicated wire or you trust everything on your network, but this is getting difficult …
