Restrict Modbus access to certain MIs

[amirm]

As far as I know, once you enable a Vision CLP as Modbus master you can access any MI, MB, ML, DW, etc.

 

This leads to a security problem, as anyone can view data (passwords?) or even worse, write random data.

 

The chances are low, but the risk is high.

 

One customer is a manufacturer and will use V130 to assist the control of high power UPS, rectifiers and Inverters.

Among other things, the V130 will provide HMI to configure battery charge voltage.

If someone writes MI9999, he will set a new charge voltage. Even though the program limits the value to a valid range, the maximum value can destroy the battery bank or even start a fire.

This can be accidental or intentional.

 

To minimize the risks, I tell the user to read data on MIs 1900 - 1999, which hold copies of the real values - the real source data is stored somewhere else. If someone writes anything on these MIs, nothing will happen and values will be refreshed on next scan.

I can also change the port of Modbus from 502 to something else, to avoid the risk of an application writing data on V130 thinking it´s another device on same IP.

But these measures do not avoid tweaking of the memory outside of the 1900-1999 range.

 

 

 

 

Question: Is there a way to limit modbus access to a given set or range of MI, MB, etc?

Any operation outside the box will return "Invalid operation"

 

 

 

I just had a crazy idea of using data tables:

 

1 - Load MI, ML, DW with data from data tables (do this on first net of !Main Routine)

2 - Run the program and use MI, ML, DW

3 - Store MI, ML, DW back to data tables (do this on almost last net of !Main Routine)

4 - Call MODBUS SCAN32 on last net of !Main Routine

 

This way, if the user changes any MI by Modbus, nothing will happen, because all MIs will be reloaded on step 1.

And data tables are not accessible by modbus...

 

Going 2 steps further...

 

1 - Load MI, ML, DW with initialization data (on SB2_PowerUpBit)

2 - Store MI, ML, DW on data tables (on SB2_PowerUpBit)

3 - Load MI, ML, DW with data from data tables (do this on first net of !Main Routine)

4 - Run the program and use MI, ML, DW

5 - Store MI, ML, DW back to data tables (do this on almost last net of !Main Routine)

6 - Vector fill sensitive MIs with 0 - If user tries to read password with modbus, he will read 0.

7 - Call MODBUS SCAN32 on last net of !Main Routine

 

I just wonder how this affects performance, and what is faster? DT Direct RAW Read or DT Read Column?

 

I´ll give it a try and post results, when I have the time.

Comments are welcome.

 

[amirm]

I made a test program, and it works...

 

1 - Load MI, ML, DW with initialization data (on SB2_PowerUpBit)

2 - Store MI, ML, DW on data tables (on SB2_PowerUpBit)

3 - Load MI, ML, DW with data from data tables (do this on first net of !Main Routine)

4 - Run the program and use MI, ML, DW

5 - Store MI, ML, DW back to data tables (do this on almost last net of !Main Routine)

6 - Vector fill sensitive MIs with 0 - If user tries to read password with modbus, he will read 0.

7 - Call MODBUS SCAN32 on last net of !Main Routine

 

In my first test I was able to hide the contents on an MI (modbus always read it as 12345), make one MI read-only (modbus could read, but writes were ignored) and have a 3rd MI with full access by modbus.

 

 

In my second test I stored and retrieved all numeric operands, making all of them read-only to modbus.

 

The penalty: scan time (SI0) increased 31mS to load and save 2048 MIs, 256 MLs, 64 DWs, 512 XIs, 256 XLs, 64 XDWs and 24 MFs.

 

Data tables cannot read/store MBs directly - not that I know of.

To do the same trick with MBs/XBs, you need to use Vector - Store bits to numeric and save on some operand, then reverse.

[AlexUT]

Hi amirm,

 

By design, Modbus protocol itself provides no security against unauthorized commands or interception of data.

 

BR

[amirm]

Yes, I know. It's a major weakness of Modbus,

 

But one thing is to let anybody play with a few variables, and other thing is to let anybody read or change any variable of the whole system, and by comparison find where is the "parts counter" and change it, or scan the memory for non-zero values and try them for password.

 

Or simply randomly write values for sabotage. Once the PLC is on the ethernet, anyone in the network can fool with it and nobody will know who did it, unless there is a network sniffer like Wireshark and a manageable switch to copy traffic from all ports to the port where the sniffer PC is.

 

I'm not concerned anymore, I found a solution to avoid unrestricted peeking and poking, except for I/O ports - I haven't tried them yet.

 

As for security, one can always use encryption. LFSR is a good choice, I once used it to create "random" numbers.

[linxchas]

From my point of view, the only way to restrict ModBus slave from "unauthorized" requests is to reproduce "ModBus SCAN" in your code using TCP or UDP RAW protocol. Then you can add "Request validation"

[TT_ZX]

From my point of view, the only way to restrict ModBus slave from "unauthorized" requests is to reproduce "ModBus SCAN" in your code using TCP or UDP RAW protocol. Then you can add "Request validation"

Can you explain this method further, I not following.

[linxchas]

OK, here is how standard Modbus slave looks:

 

 

 

 

And here how ModBus SCAN can be in your own code (Example for Modbus over TCP, but UDP would be very much the same):

 

 

Subs 1.ProcessModbusRequest and 3.ComposeModbusResponce should be written based on Modbus protocol description.

Modbus is a public protocol and description you can find on http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

In the sub 2.ValidateModbusRequest you should put your specific validation requirement.

 

No doubts, this it is a piece of work. But it doable. So you should consider, if your project worth of it.

You'll probably need a bit of Unitronics help in matter of exact modbus version implemented in the controllers (especially addressing).

Reverse engineering (sniffer) will be helpful as well.

 

 

[TT_ZX]

I see where you're coming from now.  Looks like a lot of work if your unfamiliar with the details of the ModBus protocol and/or the workings of Ethernet.  Would be a great learning experience for sure.  I would like to have a go at it but I don't see myself having the time any time soon.

[amirm]

It´s a nice solution, but if you need Modbus over RS232/485, you´ll need to build and check CRC. Quite a hassle...