On 6/28/20 12:47 PM, Dennis Lee Bieber wrote:
> If you are trying to sanitize the data "dropping IP/port" you are
> now looking at the aforementioned "data diode" operation.

I think we have different understandings of what "data diode" is and does.

To me, a "data diode" is a one way flow control device (much like the
electrical component that only allows current flow in one direction).

> Those are designed so that only certain packets are allowed through,

When you start talking about conditionally allowing data to flow or not
flow (in one or both directions) you start getting into a firewall that
filters traffic based on IP and / or protocol and / or port and / or state.

> and often use fiber optics between the two sides to ensure that there
> is NO wired connection (some may also be unidirectional -- data from
> the secure side is sanitized (some can actually edit out parts of the
> packet if the packet format is set up) and sent out on the unsecured
> side, but the unsecured side can not send data to the secure side.

This sounds more like a firewall combined with a "data diode".

> Your original post implied the R-Pi would be a more passive device. One
> side would dump a file to (a directory on an R-Pi storage device
> -- recommend USB drive if this is busy system, to avoid SD card
> failure), At some later time the other side would retrieve the file
> from the R-Pi.

Agreed.

> THAT form of operation is easily done....

There are many ways to achieve this simple data drop / post office
functionality.

> On the R-Pi, create a set of users/passwords (at minimum, one for
> each side, at most one per external machine). Set these users for
> very minimal privileges -- basically put them in a "post office
> group" and set the storage directories to be RW for users in this
> "post office group". Also set the home directory for those users to
> the top of the post office directory tree.

Now you get into multi-user access to the data drop / post office and
what they can see (read) / modify (write) / delete (also write).  This
quickly devolves into a deep and dark rabbit hole.

> Source host can sFTP using its login credentials, PUT the data file.
> Destination host, at some later time will sFTP with its credentials
> at some later time, check for new files, GET those files, and then
> DELETE the files.
Yes, this the basic operation of a queuing mechanism.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05