I know that Opto has done a lot of work with the Groov system to increase security among its products, but I’m curious about what I believe to be a huge, gaping security hole with the system:
Is there any way to prevent anybody with basic knowledge from downloading new code to a controller? As far as I know, anybody could download PAC Project basic for free, find the IP address of a controller, and download a strategy to the controller with no real authentication, regardless of what’s already running on the controller.
Am I missing something? Is there some way of requiring authentication for downloads? Limiting downloads to a specific IP address range?
@Lou_Bertha: I appreciate the response. That’s helpful for Groov controllers, though not so much for earlier generation controllers. Additionally, unless I’m missing something, that would require signing in and changing rules each time I want to download, since I don’t see an IP filter for firewall rules within my Groov controllers.
For groov, keep in mind, if its easy, its not secure.
Since you don’t seem to want to use your groov Manage admin user/pass to simply change the firewall settings to keep your controller secure, you could come up with a way to keep your RESTful calls secure and use them to enable/disable a port redirect each time you download.
I have seen @torchard setup a groov View screen for @bensonh that fires off a port redirect and tears them down after a timer expires, its pretty quick, but again, it will be on you to secure that groov View screen or RESTful command trigger.
Older PAC systems do not have the firewall but you can change the Port for access (PACManager). This adds additional layers to prevent your scenario of downloading a new configuration or you could lock up the controller from access via PACControl. Just saw @Beno comment as I was about sent this comment.
As I noted we setup the “outside” connection which prevents PACControl Access but the internal “protected” network would allow changes and modifications. Protection can be limited access network, smart switches, etc. This is the preferred setup for both PAC and EPIC.
Physical isolation is your best protection. We often setup the primary network as an Isolated Network for peer to peer communications (EPIC and PAC), local (at the panel level) operator interfaces for plant operations. The secondary network is setup with remote Operator Interfaces, Internet Connection, etc. (on EPIC firewall setting to limit access for PACControl, etc.)
Remember on any TCP/IP system, all you need to do is add a duplicate IP address to screw up communications. This is why utilizing a smart switch is recommended if you are looking for added layers of protection, limited access, etc.
No perfect scenario but having a protected isolated network is cleanest and most secure to allow modifications via PACControl with the secondary Ethernet Connection (assuming open) setup for limited access (allow Groov View, MQTT, etc.)
@Beno: I appreciate the additional guidance. I’m fine with logging into my Groov controllers and changing rules around downloads. I was unaware of the IP address filtering for PAC controllers, but I’m glad to know of that. I don’t suppose there’s any hidden feature I’m unaware of that’s going to protect my LCM4 controllers I still rely on, right?
@Lou_Bertha: thank you for the follow up. Definitely valuable information.
