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? One idea is to let pass the traffic that goes to known ports/services and block all the others. This solution is simple but can be usable with all the devices. For instance in production it's not always needed to be able to program the device from outside but maybe we just need to see production data trough OPCUA or files from FTP.
Overview of the used setup
The idea is access devices that are locally accessible by the ctrlX CORE. For this tutorial we want to access the IndraControl XM22, as shown in the picture below.
Equipment used
The test has been done with:
- ctrlX CORE 1.20
- eth0 set to IP address: eth0 set to 192.168.1.1, eth1 set to: 192.168.2.1
- ctrlX App Firewall 1.20
Transfer data packets
Step 1: Forward data packets
In order to forward data packets it is necessary to allow it from the eth0 and eth1 interfaces:
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: NAT Setting
While we can access the ctrlX CORE itself without problems, it is still not possible to also access the other devices in our network. Why is this? If a device in the local network (192.168.1.0/24) receives a packet from a device in our external LAN, it still has as source IP the IP address of this device. As this is an IP address in the external network, how should the device know how to route the answer-packet back to our access device. There are two solutions for this:
- Setting the default gateway in the XM22 to the IP address of our ctrlX (192.168.1.1)
- By configuring a source NAT rule, what will be done in the following and explained below
Step 3: PC routing
After everything has been set up in ctrlX CORE it is necessary to setup the right rules also inside the PC. Being the PC address 192.168.2.X and the ctrlX CORE eth1 address = 192.168.2.1 the rule to be entered is the following:
- route add 192.168.1.0 mask 255.255.255.0 192.168.2.1
It means that when the PC tries to reach the 192.168.1.X it routes them through 192.168.2.1 which is the ctrlX CORE. It is possible to check if this work as assumed using the command "tracert".
Step 4: XM22 access
Now it is all set up!! When entering http://192.168.1.25 to the browser the XM22 WebAssistant page should be reachable!
Now Even IndraWorks should be able to program the XM22 passing through ctrlX CORE.
Step 5: PROTECT the controller blocking all the ports and then allow just what we need to use
To do this we need to act on the forward filter! It is here where we have to do our magic. In this example we would like to leave free just ports:
- 4840 for OPCUA
- 443 or 80 for devices web servers.
But anyone can freely decide which protocol should be accessible from the outside or not.
What we need to do is to create a new chain with default policy "Drop". in this case all the packets are blocked unless they have certain characteristics:
Ok, now we go inside the chain and we add some more settings we need to allow just what we need.
- We allow tcp port on port 4840
- we allow port 80 to see the controller web server
- we accept the traffic back from the devices otherwise will be blocked as well!
The settings are freely configurable depending on the controller needs.
Explanation
The structure of the network packets is close to what is represented in the picture below:
The image is just indicative, what is important to us is that our packet has:
- A destination address (where the packet should arrive)
- A source address (who is sending the packet)
- A Payload ( the data exchanged)
The packet takes 3 main steps to get to destination and 3 also to get back. 
Setting the routing rules on our PC in step 3 we're able to send packets destined for 192.168.1.25 to ctrlX CORE. Here is where the trick is starting.
Once the packets are inside the ctrlX CORE we can do many things, first of all we could change the destination IP applying a Destination NAT in (Number 1 in Fig.8 but this is not our case, the packets are going directly to the the forward filter (Number 2 in Fig.8 )) . Here we must be sure that the packets are not being filtered!! To do that the step number 1 of the guide is mandatory, also it is good to check inside the "Forward Filter" part of the firewall that there are no other rules that may block the packets.
The last part is the most important, before the packets leave the ctrlX the packets are passing through a SNAT (Source NAT: number 3 in Fig.8 ). In this last step the source address of the packet that, till now, is something like 192.168.2.x is then changed to 192.168.1.1 which is the ctrlX CORE address of the interfaces that is connected to the XM22.
Why that? Once the XM22 receives the packet it answers to the address in the source field. Now the XM22 knows the address of the device which sent the packet to it, as it is the address of the ctrlX CORE and can thereby send the packet back to ctrlX CORE. The rules to setup this last part are explained in step 2.
The packets that have to come back from the XM22 to the PC are automatically translated by ctrlX CORE itself on they way back.
This tutorial does not have the aim to explain all routing capabilities the ctrlX CORE can offer. We're just using a subset of features useful to obtain our goal. To fully understand what is behind the ctrlX AUTOMATION - Firewall and routing configuration a basic knowledge on computer networks and firewall rules is necessary. Starting from iptables and NFT tables.
