Groov EPIC and RIO firewall tips

Just a few tips regarding the groov family firewall. (Feel free to add your own as time goes by).

  1. Since both EPIC and RIO run Linux, you can not open a port lower than 1024.
    The reasons for not less than 1024 are steeped history but generally revolve around the fact that when you talk to a service below 1024 you are talking to a secure service and thus you know its an elevated privilege service and the Linux user that runs groov Manage does not have root (superuser privileges) permission.
    Now days its more about the certificates that the server or service is using, but in the old days, only root users had access to privileged ports, so you knew who you were talking to.
    Bottom line, groov Manage won’t let you open a port less than 1024 and even if you have shell, you probably should not do it either.

  2. Even if you open a port, that does not mean your program is going to ‘just work’.
    What do I mean by that? It means that if you open port 2233 for your Node-RED application, that does not mean it will ‘just work’. You will still need to build a Node-RED flow with the correct nodes to listen and respond to the incoming UDP/TCP traffic on that port.
    Remember, you don’t need to open a port to PUSH data out (that’s the whole power of MQTT), you only need to open a port if you have an application connecting to the EPIC/RIO and need to extract data from it. ie, the old poll-response model.

  3. If you are a shell user and want to double check that groov Manage really has opened the firewall on your nominated port here is an example command and its response ('cause none of us have trust issues right?) that you can use to check.

opto@EPIC-Ben:~$ sudo ufw show raw | grep 22001
       0        0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpts:22001:22002 /* Opto22 Control Engine */
       0        0 DROP       tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0            tcp dpts:22001:22002 /* Opto22 Control Engine */
       0        0 DROP       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpts:22001:22002 /* Opto22 Control Engine */
       0        0 ACCEPT     tcp  --  tun0   *       0.0.0.0/0            0.0.0.0/0            tcp dpts:22001:22002 /* Opto22 Control Engine */
       0        0 ACCEPT     tcp      eth0   *       ::/0                 ::/0                 tcp dpts:22001:22002 /* Opto22 Control Engine */
       0        0 DROP       tcp      eth1   *       ::/0                 ::/0                 tcp dpts:22001:22002 /* Opto22 Control Engine */
       0        0 DROP       tcp      wlan0  *       ::/0                 ::/0                 tcp dpts:22001:22002 /* Opto22 Control Engine */
       0        0 ACCEPT     tcp      tun0   *       ::/0                 ::/0                 tcp dpts:22001:22002 /* Opto22 Control Engine */
opto@EPIC-Ben:

Breaking it down a little. Since you are working with the firewall, you need to be sudo. ufw is the name of the firewall command we are using, in this case uncomplicated firewall (UFW). We are asking to ‘show’ the rules. We want the ‘raw’ output to see the good stuff.
That command alone is going to be a fire-hose and fill the screen with stuff we don’t care about, so we then pipe (|) the output through grep (a filter) and only look for the text ‘22001’ (In this examples case, the PAC Control engine port).
You can see the command output below.
We are ACCEPTing TCP packets on ETH0 and TUN0, and DROPing packets to that port on ETH1 and WLAN0.
Note that its TCP only and if we were using UDP, it would show up as well.
Here is what that rule looks like in groov Manage.

Hopefully those few tips will give you a start to your adventure of getting custom stuff done behind the EPIC or RIO firewall.

2 Likes

Over the past year, we have had many people ask about using port 502 for ModbusTCP.
In all cases, it is because you have a Modbus master on the network somewhere that is fixed (hardcoded) for port 502 and you need to poll the Modbus registers on the EPIC/RIO.
Of course, we have allowed for this and the groov devices are ModbusTCP slaves out of the box, they will respond to poll requests on port 502 and return the registers data.

But what if you want to use say, PAC Control, Codesys, or Node-RED as the Modbus slave?
Port 502 is below 1024 and none of those services can run as root or be secure so it’s not possible, right?
Well, there is a very easy two-step method to get this working, and the how is revealed by the SSH command mentioned in the last post.

Let’s issue the command for port 502 and see what comes back…

sudo ufw show raw | grep 502

       0        0 ACCEPT     tcp  --  eth0   *  tcp dpt:8502 /* Opto22 ModbusTCP */
       0        0 DROP       tcp  --  eth1   *  tcp dpt:8502 /* Opto22 ModbusTCP */
       0        0 DROP       tcp  --  wlan0  *  tcp dpt:8502 /* Opto22 ModbusTCP */
       0        0 ACCEPT     tcp  --  tun0   *  tcp dpt:8502 /* Opto22 ModbusTCP */
       0        0 REDIRECT   tcp  --  *      *  tcp dpt:502 redir ports 8502
       0        0 REDIRECT   tcp  --  *      lo tcp dpt:502 redir ports 8502

The first 4 lines are as per the groov firewall settings:

image

I accept connections on eth0 and tun0.
But what are those next two lines…??

Port 502 is a hard ‘wired’ redirect to port 8502, so knowing that, what can we do?
If you go into the I/O services → Configuration menu in groov Manage, you can see a very important setting:

If you turn off the I/O Modbus/TCP slave, nothing is listening on port 8502… so now you can use the PAC Control Modbus toolkit or the Codesys Modbus library, or the Node-RED Modbus nodes and configure them to use port 8502, any traffic on port 502 will come in and hit those listening services.

So to sum up.
There is a hard-wired port re-direct from port 502 to port 8502.

  1. Turn off the groov Manage Modbus slave from listening on port 8502
  2. Turn on your Modbus server software to use port 8502.

Of course, if you are not using any Modbus, turn off the firewall on port 8052 and port 502 will be dead.

1 Like

Building on this concept a little more…

We know from the first post in this thread that we can’t use the port redirect feature of EPIC on port numbers lower than 1024, but what if you have some Modbus software that can only use port 502?

Let’s say this software is on your IT network and you need to talk to a ModbusTCP device that also can only use port 502, and it’s on your OT network.
Perhaps you already have PAC Control, Codesys, or Node-RED already talking to the Modbus device.
Is there any way you can route port 502 traffic through the EPIC?

Well, if you exploit the post above (traffic on 8502 is internally routed to port 502 and you can free up port 8502 by turning off the ModbusTCP slave listener in the EPIC), and add a little Node-RED glue, then yes… Here is the overview.

+--------------+        +---------------+       +--------------+
|              |        | EPIC          |       |              |
| Modbus       |        | 8502 -> 502   |       | Modbus       |
| software     |    IT  |               |OT     | device       |
|              +------->| Node-RED      +------>|              |
| Fixed port   |    Eth0| 502 <-> 502   |Eth1   | Fixed port   |
| 502          |        |               |       | 502          |
|              |        |               |       |              |
+--------------+        +---------------+       +--------------+

Then you build a flow in Node-RED that is like a tiny router…

It is a bit of a different way of using Node-RED (the data flow is bi-directional) and the dual Ethernet ports of the EPIC (this won’t work on the RIO for example).
The node on the left listens for traffic on port 502 on Eth0 and sends it to the IP address of your physical Modbus device IP on port 502 by the node in the middle.
When your device answers on port 502 Eth1, the node on the right sends that reply back out port 8502, which, don’t forget, is internally routed back out port 502 to your software.
Do note, that this means your ModbusTCP device should be on the same subnet as Eth1 is configured for.

Here is the flow ready to import - Don’t forget to change the IP address for your ModbusTCP device and hit deploy:

[{"id":"d0ed337.b37dbd","type":"tcp in","z":"d21748e8407fa754","name":"listen on:8502","server":"server","host":"","port":"8502","datamode":"stream","datatype":"buffer","newline":"","topic":"text","base64":false,"tls":"","x":330,"y":240,"wires":[["7de967f0.d50a08"]]},{"id":"7de967f0.d50a08","type":"tcp request","z":"d21748e8407fa754","name":"10.192.52.158:502","server":"10.192.52.158","port":"502","out":"sit","ret":"buffer","splitc":" ","newline":"","tls":"","x":570,"y":240,"wires":[["c4fce4d0.df1838"]]},{"id":"c4fce4d0.df1838","type":"tcp out","z":"d21748e8407fa754","name":"reply: all open connections will be messaged","host":"","port":"","beserver":"reply","base64":false,"end":false,"tls":"","x":950,"y":240,"wires":[]},{"id":"8fe98e16b940b880","type":"comment","z":"d21748e8407fa754","name":"Do not change.","info":"","x":340,"y":200,"wires":[]},{"id":"2e1c2e2beeb5f00e","type":"comment","z":"d21748e8407fa754","name":"Set modbus IP address","info":"","x":580,"y":200,"wires":[]},{"id":"d504ccba6a5444df","type":"comment","z":"d21748e8407fa754","name":"Do not change.","info":"","x":860,"y":200,"wires":[]}]