Modbus, blocking Write command

[NINO_ELC]

Hi all,

in my application, a V350 will be a slave in a Modbus RTU net (RS485).

I will provide, in a support text, the address map of the registers the Master (SCADA) should read to get the info required.

But, in any case the Master (SCADA) should not be able to Write in the Slave PLC memory.

As I have seen from the examples, activating the Modbus in the slave PLC enables the Master

to Read and Write to any register in the PLC.

Is there any way to block the Write command ?

(The SCADA development is a future project, which may not be granded to me)

Thanks

[Walkerok]

I asked this question recently and never got an actual answer, but I have found the answer to be no that there is no way to block a masters ability to write to a location. Your only protection is misdirection and hoping and praying that the master reading/writing your data does not accidentally mess up something important. What I am doing is the following:

1) If a location is being written to by my program then you will be ok because whatever a custer tries to write over will just be rewritten again by your program.

2) If it is a screen enterable variable that you only want local personel to be able to change and not some unknown entity in a far away land then you can take the MI the local user would write to and copy that value to a secondd MI then put that second MI on your address list so a remote master can read it but it will not be writable for the same reason it is not in my first point. While not a good solution it is better than nothing.

The inability to block memory locations from being written to is something that should be changed. I do not know how hard it would be to do this, but it should still be done anyway.

Keith

[NINO_ELC]

Dear Walkerok, thanks for the reply.

I have seen your post, and I also noticed that you got no answer.

The issue with the Write command blocking could be further extended,

as the application may need the Master (a SCADA) to Write some MI or MB as user inputs to the PLC.

In this case if the Write addressing is not correct (not rare at all) it could cause the PLC running with out any control

as temporary registers (indexes, pointers, vector bases etc.) may be affected.

I hope the Unitronics team to have a solution to this issue.

Comment:

It seems to me that in the Profibus and Allen Bradley protocols they have implemented it.

Best regards,

Nikolas

[Emil]

Currently, there is no special protection against writing via Modbus Master to Unitronics OPLC.

If the Master is SCADA, the gates are preprogrammed and I don't understand after debug how the address can be wrong?

[NINO_ELC]

Dear Emil,

the SCADA programmer can be any person with unknown skills.

If he accidentally (or during his evaluation / debugging) writes into my PLC,

the PLC application may run with no control. The result will be a disaster for the customer system.

So, I would ask for an enhanced version of Modbus functions (it seems to me that this is provided in the Profibus functions),

or another way to work around that issue, inside the PLC.

[Emil]

I'll pass this request ot our R&D.

Do you have specific project behind your question? Which controllers are used there? Do yo mind which area of memory needs to be protected and which - still open?

[NINO_ELC]

It is a project we are developing now, using V350s.

Three PLCs running the same software, having external hardware "outputs voting" and "minority voting" monitoring.

The three PLCs are to be connected through RS485 (Modbus RTU) with a future SCADA.

We have already implement, beyond the scenarios functions:

- Alarm DBs (Actives, History),

- Alarm Logging,

- SD event logging

Only the Com functions are incomplete.

For our application :

only an area of 100 coils (MBs), and another area of 100 registers (MIs)

can be open (write enabled) to Modbus Write operations.

[Walkerok]

Hi Emil,

This request is not application specific. If anything it is universal accross all possible programs. You seem to to be making the assumption that as the unitronics programmer we will have contact with the SCADA developer or whoever may be making a master. Nothing could be further from the actual chain of events. When we make a program that allows for master control it is most of the time (for me) for eventual sale to an OEM manufacturer that will in turn sell that to their customer who may or may not be the end customer so we may be 2 - 3 levels removed from who is going to be trying to implement a SCADA system. OEMs generally want to hide as best possible who the manufacturer of their parts are (to protect from their customers coming direct to us) so it is entirely likely that the end customer may not even know who we are as the actual programmer. Without write protection like I have said before and Nikolas has said here, the people writing the master can easily make a typing mistake and change the value of MI243 and not MI234 like they were supposed to, or they will have a multi write function that they make too long, or they just think they need to know something use a Modbus data sniffer to try and map out locations that we as the programmer never told them about (we do this with variable speed drives all the time so that we can do our jobs directly when the manufacturer did not make a complete modbus table 15 years ago and that person has quit,retired, or died and no one there knows what to do anymore). While we or others do not do this to maliciously hurt the operation of the equipment we are polling, mistakes can and will happen.

I will only hear about it when I get the angry phone call that my equipment is trash and does not work and I need to fly out to wherever the PLC might be tomorrow morning to fix it "or else!!". Why did the equipment not work..........because some guy I have never talked to changed a memory location I would have wanted to block but could not. It is not a question of if, but when, this event will happen.

To answer the question what makes sense is to have the ability to either dynamicaly block MBs, MIs, MLs, and DWs or to assign a block (for example MI2000 - MI4000 read only) so that I can segreagate my program in read/write and read only locations to protect myself.

Thank You

Keith

[Joe Tauser]

+1 on Keith's comments. I've had third party SCADA people stomp on my stuff as well - it usually involves a "programmer" who views communication with the PLC as a necessary evil to glorify his screen and database making brilliance. "I typed in the wrong Modbus address? Oh. No big deal."

What's needed is a SCANEX function blocks where you define blocks of what's allowed to go through; every other request is blocked. I've worked with Modbus I/O modules where this is the case- you get a read or write error if you try to access an address not defined in their documentation.

Joe T.

[NINO_ELC]

Dear Emil,

the feature in Profibus looks like with what is required for Modbus.

Could you implement the same feature for Modbus too?

"Define in the Slave the area which is accessible by the Master",

and if the Master attempts to Write in this area an error coded reply will be transmitted back.

Although I believe that what is needed is a new SCANEX fb, as Joe Tauser has mentioned in his post,

which seems not so difficult.

I totally agree with Walkerok and Joe comments (+1 , +1 on both guys comments by me too).

Anybody have worked with remote I/O modules or other industrial equipments like Drives, Meters, Indicators etc.

have met the situation of wrong addressing commands.

This feature is provided build even in products costing 45 Euro (panel indicator),

which is about the cost of the extra serial port in the Unitronics PLC, but the PLC is not just a dummy indicator.

PLC is included in the system to perform the control of it.

Leaving a "back door" open, providing access to the control logic can be a disaster.

[Emil]

I think it's out of discussion that such option can be useful. I know there are other products which have it.

We already discussed this topic with our R&D, but it's not so easy, as it seems.

Currently such project is not scheduled.

[eugen]

I'm also interested to block unauthorized writes to PLC registers. There is any news for implementing such option?

[SUNreal]

Good morning, colleagues!  Is write protection implemented for Vision PLC registers via Modbus?

[Fernando Castro]

On 2/5/2023 at 9:27 PM, SUNreal said:

Good morning, colleagues!  Is write protection implemented for Vision PLC registers via Modbus?

I am pretty sure the answer is No, and that it won't be possible at all because on how the Modbus protocol was implemented on Unitronics devices.

[Joe Tauser]

35 minutes ago, Fernando Castro said:

I am pretty sure the answer is No

This is correct.  The entire memory range of a Vision PLC is open to reads and writes.

If you need selective Modbus control you have to go to a UniStream.

Joe T.

[kratmel]

It is clear that the direct use of Slave Modbus mode does not have any protection against reading or writing to PLC memory.

I haven't tried to do something like password protection, but I think it's possible to run your own exchange Modbus commands using the Protocol FB when starting the PLC.

Here are the possible options:

- set the password that must be set (writed) by master (using an address that does not exist in the PLC and own "Simulated Modbus" protocol) and put the PLC in full access Slave mode via standard Modbus (and disable "Simulated Modbus" protocol until the next restart of the PLC or the programmed standard modbus write command action - reset the password);

- create your "Local simulated Modbus" with a set of available cells for writing or only reading via Protocol FB.

I was building "My Modbus"  to read a record of User defined Modbus codes in the range 65-72 (Not implemented in PLC). Everything worked without problems, so I think it's easy to create something like this to give write and read access to only specified cells using standard modbus codes or User defined Modbus codes.

[Fernando Castro]

13 hours ago, kratmel said:

I haven't tried to do something like password protection, but I think it's possible to run your own exchange Modbus commands using the Protocol FB when starting the PLC.

I mean, you are not wrong but after doing that, I don't see the point on using Modbus. If you are already sending and receiving commands thru Protocol FB. then you can do your own thing and validate messages first then copy received values to a specific memory area. 

I feel like the Modbus benefit is that is already a feature on a lot of devices. and you don't need to do an extra TCP/IP communication layer to send your data.

All of us professionals in automation knows that Modbus does not offer any security and that is kind of a "legacy" protocol but still very relevant tool.... It's up to the controls engineer to design the network in a way that should be Isolated from "extrange devices."

however, I have seen that the implementation of Modbus on other brands usually consist in two steps: 1. communication and 2. mapping the Modbus registers to actual registers inside of the PLC memory, which makes it easier to code too.

To be honest if the application is critical, needs to use Modbus, and anyone could connect to the same network, then vison series PLCs are not the right tool for the job.

[Joe Tauser]

2 hours ago, Fernando Castro said:

To be honest if the application is critical, needs to use Modbus, and anyone could connect to the same network, then vison series PLCs are not the right tool for the job.

+1

 

Joe T.

[kratmel]

4 hours ago, Fernando Castro said:

I mean, you are not wrong but after doing that, I don't see the point on using Modbus.

The main idea proposed by me is to use the standard SCADA Modbus protocol for connection.

That is, by making your own limited  Modbus protocol in the PLC, you can allow users to read or write something via SCADA without worrying about the possibility of messing up the settings.

In my case user can only set setpoint and read statistic via free  SCADA.