Jump to content

Recommended Posts

Posted

Hello everybody,

 

I would like to ask you if there is possibility to protect operands when using .NET driver.

For monitoring PLC it is sufficient to use read commands.

I tried use SB 140 to protect operands, but still I can write any value to any operand

(it is also possible to connect without knowing PLC name).

This is security problem...

Thank you for any idea.

With my best regards

David

Posted

Hi, the .Net driver does not supply any way of write protecting operands, since the PLC itself doesn't support it.

The .Net driver only implements the API that are published in Unitronics website.

Unitronics supplies the source codes of the .Net driver, free or charge, so you can implement the feature that you want (reading SB 140 before committing your write requests).

Before commiting the ReadWrite requests, read the value of SB 140, and if the bit is set, then remove the Write Requests from the readwrite requests array.

You, as a programmer, can also do it in your code.

 

As for SB140, its actual purpose is to allow Read-Only remote access, meaning, when using Remote Access/Remote Operator to control the PLC, you will only see the screen of the PLC, and touch events and keyboard events will be ignored by the PLC.

 

 

Yes, the .Net driver allows you to connect to the PLC without supplying a PLC name.

The GetPLC factory has 2 flavors, with and without a PLC name, meaning: this is not a bug, but a feature. We actually use both for different needs.

(I specifically use it a lot, if for example, I want to spawn another connection to the PLC, then I take the original channel of an already existing PLC, and create a new PLC object)

The reason PLC name was added on the first place was not a security problem, but a way of identifying/verifying that the PLC you work with is actually what you meant (this is very important when working with Ethernet).

 

If the original reason would have been a security then:

* The user would not have been able to see the PLC name within the Info 

* The PLC could not have been read using a PCOM

* For establishing a connection to the PLC, the PLC would be validating the PLC name, and not the other way around

* The PLC would ignore connections if wrong PLC name was sent

 

All of the above is not true for PLC name, but very true on "Upload Project" when it is password protected (The PLC would validate the sent password and would physically deny access  to the flash area where the Project backup is stored at)

Posted

Dear Saragani,

thank you very much for your detailed explanation and your time to help me.
Unfortunately I can not anymore use PCOM protocol (.Net driver). Any 3rd party application can misuse the protocol and set any

value to the critical operands during the PLC process. As long as there is not System Bit in PLC for operands write protection,

any connection via PCOM is dangerous for application in PLC.

Thank you again for your fast reply
Have a nice weekend.

With my best regards
David

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

This site uses cookies. By clicking I accept, you agree to their use.