About MauroRiboniMX

The Goal Production machines are really different one from the other but any machine has a controller (or more) that can be a target during a cyber attack, so how to protect our production? Sometimes we just need to protect the exchange of the data between the controller and the network LAN and we know that this communication will be just over OPC UA. OPC UA secured Overview of the used setup The idea is to take one or more machine OPC UA servers which are/can be unrestricted and or unencrypted and share just the necessary data of the ctrlX Data Layer over a tailored made OPC UA server. Here there are the devices used and the IP addresses involved. Test Layout Equipment used The test has been done with: ctrlX CORE installed system apps release 2.02 (from 1.20 is good) XF10 set to 192.168.1.1, XF51 set to: 192.168.2.1 Apps: OPC UA Client and OPC US Server 2.02 (from 1.20 is good) A good and updated OPC UA test client, the "famous" one is good otherwise also UA.TestClient will fit perfectly IndraControl XM22 as unrestricted open OPC UA server Share the OPC UA data and restrict the permissions Step 1: Connect OPC UA client to the server(s) To test this feature we connect the ctrlX CORE OPC UA app to the servers in the network. The steps are the following: Add a new OPC UA client Insert the connections parameters of the OPC UA server and make the device persistent Adjust the parameters, save and press on connect, if it is successfully the dialog will show "CONNECTED" Check that the data are present on the ctrlX Data Layer OPC UA Client Connections Parameters Connections Parameters Adjusting Device Connected Data Layer OPC UA Client To automate the client connection and disconnection please give a look to this guide: Connect OPC UA client to MLC and Siemens S7 OPC UA server.  Step 2: Setup ctrlX OPC UA server and run the "Test" client to check the settings. We can tune the server to support (or not) various security standards. we have to navigate trough "OPC UA -> Server", click on the edit button, tune the server and then save. Go to the edit button OPC UA Server Settings Now it's time to check the connectivity with your favourite test client. We have to: Open the tool and check the connection, trust the certificate of the ctrlX CORE. The first connection try will fail. In ctrlX CORE we have to navigate to: "Settings -> Certificates -> OPC UA server" and trust the certificate of the test client. We can retry and now use the functionality. Use your ctrlX CORE credentials with full access. Standard is "boschrexroth". Trust OPC UA Certificate Trust OPC UA Certificate Server Side The client has now full access to the ctrlX CORE OPC UA server and then to the end-device server. Now we are going to restrict it. Step 3: Restrict the OPC UA access introducing a scope and a user To restrict the access to the ctrlX Data Layer our developers have introduced something really cool called scopes. In the scopes we can grant to some users special access for some node or subnodes of the ctrlX Data Layer. To implement this feature in the current setup we need to make the following setups: Create a scope with the right capabilities which involves the nodes that we want keep free or with a certain restriction. Create a user with OPC UA server permission and the permission introduced by the scope. Use the user credential to access to the ctrlX Data Layer. Let's start with the scopes. We need to go to settings and then ctrlX Data Layer. In datalayer/security/scopes we can create a scope with the following structure: Scope example As we can see we can specify a lot of subnodes with the needed capability. We need an identifier and a name. The name will be displayed in the permission list to give to the user the scope capabilities. Here there the scope we're going to use. The user will see just what is behind the selected none with just read capabilities. { "identifier": "datalayer.restriction", "name": "MyRestrictedPermissions", "description": "Write what you want", "permissionsR": [ "opcuaclient/device1/i=85/ns=2;s=Logic/ns=2;s=Application/ns=2;s=Application.testUA/**" ] }   Scope implementation  We insert now an user which is named "service" which will have just the following capabilities: Sever Permissions Datalayer Permission Accessing with the "service" credentials we're able to access just to the right nodes with the right permissions. Final result   Have fun 😎 ... View more

The Motivation Production machines are really different one from the other but any machine has a controller (or more) that can be a target during a cyber attack. So how to protect our production? Just take outside some service that we need using a Port forwarding and then filter all the others. This solution is simple but usable with most of the devices. Masquerading Overview of the used setup The idea is to access devices that are locally accessible by the ctrlX CORE. For this tutorial we want to access an IndraControl XM22, as shown in the picture below. Test Layout Equipment used ctrlX CORE installed system apps release 2.02 XF10 set to 192.168.1.1, XF51 set to: 192.168.2.1 ctrlX AUTOMATION - Firewall app 2.02 (not working for 1.20) IndraControl XM22 as target device in the network Transfer data packets Step 1: Forward data packets In order to forward data packets it is necessary to allow IP forwarding between XF10 and XF51 interfaces: ctrlX CORE Web UI - Ethernet port XF10 settings From firewall point of view it is also necessary to allow the packet forwarding (by default it is allowed). Then we will restrict it in order to select which package has to run.  Step 2: DNAT  and MASQUERADING Settings Now we have to setup the ctrlX CORE so that once we're interacting with the port 8082 of it we're in fact getting in contact with port 80 of the XM22. To achieve that we need to first access the firewall app and add a chain in the DNAT section if not present. DNAT chain Once we have created the chain we have to edit it and add a rule: any TCP request on port 8082 will be "DNATted" to port 80 of 192.168.1.25 so we have to match any packet over TCP protocol with destination port 8082. DNAT setting Now we have to fix the packets that are coming back using a masquerade directive. To achieve that we add a chain on the SNAT section and a rule containing the MASQUERADE directive. SNAT section Masquerade directive Step 4: XM22 access Now it is all set up! When entering http://192.168.2.1:8082  to the browser the XM22 WebAssistant page should be reachable! XM web Interface Step 4: PROTECT the controller blocking all the ports and then allow just what we need to use  Please refer to: Cybersecurity: use ctrlX CORE as a powerful net-filter for any controller!  ... View more