There’s been a delay in releasing the final paper of the three part OPC Security Whitepaper series as the paper has been going through some extensive testing. Our initial testing was with a limited amount of servers as a large amount of OPC servers exist and we’ve started to build a list on the SCADApedia noting the CLSID’s and version numbers. In a later blog I’ll show how this information is useful, but for now back to the vendor problem (or what appears to be a vendor problem).

This is a little sneak peek from our paper that discusses defining the DCOM’s endpoint configurations for a particular application, in this case, OPC servers. If you review the properties of the OPC Server you will notice the endpoint tab section which is particularly helpful for defining firewall rules as the RPC service will just dynamically allocate a port for the OPC communication. Actually the initial conversation takes place over tcp/135 and there after the RPC/OPC communication occurs over the defined endpoint or a dynamically allocated port if one was not defined.

So the problem I ran into, some OPC servers seem to ignore the defined endpoints that I entered. Further analysis and testing revealed that this limitation is tied to the vendor or developer of the OPC server itself. This makes securing a OPC server even harder and only leaves the option of defining a range for ALL RPC SERVICES or making a wide open firewall rule.

Why would vendors not implement something the rpcss service could read to handle the communications over another port? I have somewhat weak development skills, but I’m assuming this is more of a lack of strong development and QA. Is this something the OPC Foundation can chime in on or make mandatory?

In the small lab test, I installed five OPC server demos. I used Lluis’ and Ralph’s OPC security tools just to test ongoing OPC communication and had tcpview listening on the actual server for pretty netstat view. I could have used wireshark, but there’s no need as tcpview will provide (and highlight in eye piercing green) the new connections that are established between the OPC server and the OPC test tools (on another machine).

Here’s the list of servers I used (in a format output by Lluis OPC Security Checker)

C:\Program Files\neutralbit\OPC Security Tester>opctest 2kdev -l -u administrator -p xxxxxxxxx
OPC Security Tester v1.0 – NeutralBit (c) 2007

[*] <Init> Server #0: Matrikon.OPC.Simulation.1 (Matrikon OPC Server for Simulation and Testing) {F8582CF2-88FB-11D0-B850-00C0F0104305}
[*] <Init> Version: 1.1 (build 307)
[*] <Init> Vendor: Matrikon Consulting Inc (780) 448-1010

[*] <Init> Server #1: Matrikon.OPC.Modbus.1 (Matrikon OPC Server for Modbus Devices) {F8582CEC-88FB-11D0-B850-00C0F0104305}
[*] <Init> Version: 3.3 (build 30)
[*] <Init> Vendor: Matrikon Inc 780.448.1010

[*] <Init> Server #2: NETxEIB.MP.OPEN.OPC.Server.3.0 (NETxEIB MP Open OPC Server3.0) {AAEEF077-F162-4A1F-AD88-C37F35EA4030}
[*] <Init> Version: 3.0 (build 1351)
[*] <Init> Vendor: NETxEIB MultiProject Open OPC/DA Server3.0, NETxAutomation 2006

[*] <Init> Server #3: ICONICS.ModbusEthernetDA.2 (ModbusEthernetDA) {9BC87883-EEDA-11D3-9FDE-006067705B5A}
[*] <Init> Version: 3.12 (build 0)
[*] <Init> Vendor: ICONICS ModbusEthernetDA and ModbusEthernetAE

[*] <Init> Server #4: KEPware.KEPServerEx.V4 (KEPware Enhanced OPC/DDE Server) {6E6170F0-FF2D-11D2-8087-00105AA8F840}
[*] <Init> Version: 4.264 (build 401)
[*] <Init> Vendor: KEPware

[*] <Init> Server #5: Takebishi.Modbus.1 (DeviceXPlorer MODBUS OPC Server) {31A50D31-56E5-4BC2-9FDB-F55E7AD3854E}
[*] <Init> Version: 3.11 (build 2)
[*] <Init> Vendor: Modbus OPC Server by Takebishi Electric

Of the five servers tested only three (#0,#1,#2) seemed to read in the defined endpoints, two were from Matrikon and one was from NETxEIB. I setup all of the endpoints with varied ports like, 5500, 6500, 7500, …, 13500 and on up. These settings were also verified in the registry under HKEY_CLASSES_ROOT\AppId\{AppId GUID}, Endpoints, ncacn_ip_tcp,0,<port number> where indeed the port numbers are defined.