Isolated Pi Bridge

Industrial
1

We want to connect 2 isolated ethernet networks with Raspberry Pi's (and keep them isolated). One Pi needs to talk to a machine on a vendor network, the other needs to talk to our corporate network. We could do this with a USB ethernet adapter, but our IT department is worried that the Pi on the vendor network could be hacked.

We only need to pass a small text file once per day, so we were considering using two USB to RS-232 or RS-485 adapters between the Pi's. We also considered using a USB to USB file transfer adapter, hardware firewall (Stratix 5700), Bluetooth, UART, I2C, and SPI. Both Pi's will be within 1m of each other.

Can anyone make a recommendation based on our priorities below?

#1: Security of our corporate network
#2: Reliability
#3: Maintainability (preferably Node-Red)
#4: Cost (must be under $3,000)
#5: Speed

2

My first thought was to get the Pi on your network to do a limited SCP copy of the file from the vendor network. This is the standard way to avoid problems on the remote network since you are in control of the connection and the only thing that can happen is that you get the file.

That should be more than sufficient security for the majority of cases and even if the vendor network is compromised, the only impact might be that the file is corrupted. Assuming that the file is text and that you validate the file before use (which is standard practice, you NEVER allow unvalidated information into your system), there is virtually no risk so long as your network does not allow connections from the outside and as long as you stick to just a file transfer (SCP, SFTP or FTPS).

The alternative is more complex and that would be to have message queues on both sides but again only allowing the Q on your side to reach out to the Q on theirs - you are always PULLing data from them, never allow them to push to you. This should be at least as secure as long as you have a well configured Q service on your side (a well configured MQTTS broker may well be more than sufficient). Potentially this will cater for higher throughput of messages but those messages will likely need to be smaller than a file transfer.

So you have lower frequency but larger transfers vs potential higher frequency smaller transfers (but also more complexity). You would need to make a choice depending on your other requirements.

Both options could be implemented with a single Pi at each end as long as you don't want anything too extreme. Both options should be secure enough from your (more importantly your IT departments) perspective.

Of course, I am assuming that the data isn't highly sensitive or that you are working in a high-security or highly regulated sector. But if you were, hopefully you wouldn't be asking these questions on an open source forum.

And just to say that this is an idea not professional advice :mage:

3 Likes
3

Wow, these are the kind of ideas we were looking for! We'll start some discussions with our IT department.

You are correct, security of the file and data doesn't matter. We just need to make sure our corporate network can't be compromised.

4

The easiest method is to not use ethernet protocol, UDP or TCP. I once came across a similar scenario, and we did the following... Ethernet <> IPX <> Ethernet. Yes, IPX. This forced encapsulation of all data into a format that could not be abused via typical Ethernet exploits. I realize IPX is ancient, but it does illustrate the concept of using a custom protocol based solution. @TotallyInformation referenced this concept above, but add one more element, if you can, use or develop a custom data format that does self-validation and self-end-point confirmation. Just having every transfer exchange public keys before and after transport, is a very simple way to validate the end points, for example. This would be like a VPN based communication link in concept. I really miss the days of Token-Ring... then even the physical network was much hardware to hack, never mind the protocol stack.

5

Oh lord, no! That is something I never miss. Trying to track down problems when the reporting device is simply the master browser that keeps shifting. Taking a week to track down a faulty cable with a single loose cable strand. Heck no.

As always, the solution needs to be proportionate to the risk & simple is usually better. The tried and trusted solution of a pull from the trusted device/network along with subsequent validation of the input is generally more than sufficient, especially when both ends are "known" even if not entirely trusted.

A VPN here would be inappropriate for sure. Using key-based login (e.g. SSH public key authentication) might be a good way to avoid password management overheads. But likely only worth if if the organisations already have a robust PKI or know how to use Let's Encrypt sensibly. PKI poorly used can easily induce a false sense of security while remaining insecure.

6

You, are talking to a guy that never had trouble with finding token ring issues! Of course we cheated, we used double linked loops, both forward and reverse loops! So if the traffic was clockwise or counter clockwise we always knew where to look by zone. :slight_smile: Ah, the joys of beaconing!

Moreover, I think I said VPN in concept, not literal. I never recommend any specific solution, just that key principles should be qualified and used. PKI... man, you got that right, just typing the letters gives me a hand cramp.

For example the PXE environment, where you want secure concepts honored, but not explicitly implemented in detail. LOL, regardless of what the 'security' team though was required. PXE, as secured transport? Really?

7

Our IT department was most comfortable with using a serial connection. If either Pi was compromised, it wouldn't be possible to access the 2nd Pi (aside from sending a bogus text file). We also disabled SSH on both Pi's.

With this connection we were able to send a 2.4 MB JPG in 3.5 minutes. Slow, but plenty fast for our 200 KB text file once per day.

We added the "node-red-node-serialport" module to our Node-Red palette and connected two Rasberry Pi 3B+ GPIO pins like this:
6 <--> 6
8 <--> 10
10 <--> 8

Node-Red code for Pi #1:

[{"id":"92c3a1f3.1cf57","type":"serial in","z":"7b16bbdf.248634","name":"","serial":"63bffdd8.42c784","x":80,"y":160,"wires":[["e4f84e78.517f4","95b00c19.e230f"]]},{"id":"e4f84e78.517f4","type":"debug","z":"7b16bbdf.248634","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":250,"y":160,"wires":[]},{"id":"14987050.2eb25","type":"serial out","z":"7b16bbdf.248634","name":"","serial":"63bffdd8.42c784","x":260,"y":220,"wires":[]},{"id":"e7982ac8.16e148","type":"inject","z":"7b16bbdf.248634","name":"","topic":"","payload":"howdy","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":90,"y":220,"wires":[["14987050.2eb25"]]},{"id":"63bffdd8.42c784","type":"serial-port","z":"","serialport":"/dev/ttyS0","serialbaud":"115200","databits":"8","parity":"none","stopbits":"1","waitfor":"","dtr":"none","rts":"none","cts":"none","dsr":"none","newline":"500","bin":"bin","out":"interbyte","addchar":"","responsetimeout":"10000"}]

Node-Red code for Pi #2:

[{"id":"a547c005.edffd","type":"serial in","z":"7f8c87e2.149d28","name":"","serial":"83fa47b4.296c18","x":120,"y":180,"wires":[["f167f9c5.3a4438"]]},{"id":"f167f9c5.3a4438","type":"debug","z":"7f8c87e2.149d28","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":270,"y":180,"wires":[]},{"id":"2983374a.1dcbd8","type":"inject","z":"7f8c87e2.149d28","name":"","topic":"","payload":"hello","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":110,"y":400,"wires":[["b2a889ab.2644c8"]]},{"id":"b2a889ab.2644c8","type":"serial out","z":"7f8c87e2.149d28","name":"","serial":"83fa47b4.296c18","x":260,"y":400,"wires":[]},{"id":"83fa47b4.296c18","type":"serial-port","z":"","serialport":"/dev/ttyS0","serialbaud":"115200","databits":"8","parity":"none","stopbits":"1","waitfor":"","dtr":"none","rts":"none","cts":"none","dsr":"none","newline":"500","bin":"bin","out":"interbyte","addchar":"","responsetimeout":"10000"}]

FYI, this is the site that sparked our idea: https://scribles.net/setting-up-uart-serial-communication-between-raspberry-pis/

Raspberry GPIO Serial Comms Wiring
Raspberry GPIO Serial Comms Wiring1121Ă—569 231 KB

2 Likes
8

Red and Black wires? LOL... Just was thinking PWR and GND. But, hey if it works, done deal.

9

It's what's inside that matters, not the color! But I have to admit my OCD is going bonkers also. :exploding_head:

Joking aside, @awsteve thanks for sharing the result for this unique need (at least to me).

1 Like
10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.