Using an RPi 3B+ as a "post office" between two subnets ? - Page 2

Chris,



I suggest you read the subjectline as well as my intitial post for this  
thread.  It might be helpfull.

Regards,
Rudy Wieser

Well is the Pi already connected to both subnets/LANs?  If not then you're
going to have to make some new connections aren't you?

Chris,



I suggest you read my intitial post for this thread.  It might be helpfull.

Regards,
Rudy Wieser

On Sun, 28 Jun 2020 13:06:48 +0200, R.Wieser wrote:


I suggest you re-think your whole setup
your reasoning is flawed from the outset as if a device's on bothe  
networks can communicate with the "Post-office" then tha become a vector  
for attack between the networks anyway.


But I suspect you are once again forwarding a non-realistic requirement  
just to see how many knots you can tie the responders up in.

On 6/28/20 8:45 AM, Alister wrote:


Yes, the bastion can talk to both systems and as such could attack both  
systems.  But that's not his concern.  He has /specifically/ asked for a  
way to configure something, a Raspberry Pi in this case, as a way point  
between two systems that can't otherwise communicate with each other.


I have seen and supported this multiple-isolated-networks many times.

It doesn't matter /why/ he wants to do it.  The fact of the matter is  
that he /wants/ to do it.

It is possible to do what he wants to do.

There is no point in passing judgement on him for what he is choosing to do.

Alister,



Well, feel free to come up with a(ny) solution that /doesn't/ have any  
"vector for attack".   Go on, try it.



Damn, there I was, thinking I put a rather simple question forward, and even  
described how I thought that it could work.   But somehow it seems to have  
gone be a bit over your head ...

I must say I do not quite understand that.   I mean, how hard is it to  
imagine a RPi which reads datablocks from one TCP/IP interface and writes it  
to the other one (and vise-verse) - and as a result dropping all IP and port  
info from either side.   That doesn't really sound like rocket-science, now  
does it ?

Regards,
Rudy Wieser

On 6/28/20 10:46 AM, R.Wieser wrote:


Nope.  I don't think that's possible.  There will /always/ be something.  
  The /realistic/ objective is to find a way that absolutely minimizes  
the possibility of attack vectors.



Seeing as how we're talking about networking and not the science of  
rockets, no, it's not rocket-science.

That being said, what you have described there is decidedly different  
than what has been discussed in this thread.

You are now describing something that actively proxies the network  
connection between hosts A and C.  This is much more akin to NAT and /  
or application layer proxies.

Interacting with TCP connections without using an existing TCP/IP stack  
*is* quite /complex/.  Is it possible, yes.  Is it reasonable, I don't  
think so.

Now I feel the need to ask:  What does "post office" mean to you?

Grant,



What are you doing !?   You're spoiling my game !   :-)



:-p



Yeah, and thats part of the problem.   Its not the first time I notice that  
people often, without as much as a thought, going for 10-pound solutions to  
hammer a quarter-of-an-inch problem in.   It might work, but don't look at  
the side effects.



It was always my full intention to use the RPi's full TCP/IP capablilities,  
with me just requesting or writing data (and the socket taking care of the  
rest).   I just wanted to make sure that the datastreams from the two  
networks would stay seperate.



Well...  Long ago people wrote messages on /paper/, put them in an also  
paper "envelope" and ....  No, really! :-)

But seriously, in this context I tried to indicate a place where one host  
could drop a message, and the other could retrieve it - without them ever  
needing to meet.    I just didn't want to be more specific than that -  
simply because I had no idea what could/would already be available.

Regards,
Rudy Wieser

On 6/28/20 12:54 PM, R.Wieser wrote:


Sorry!!!



~chuckle~

I've used a 10-pound hammer to push in a thumb tack.  But that was an  
extremely atypical use of said hammer and I didn't swing it.

The tool, and more importantly, how it's used, is EXTREMELY important.



Okay.  That sounds like you're headed towards the realm of an  
Application Layer Gateway / Proxy.



Paper?  I thought it was a stone tablet.



That's what I thought.  But such a drop box / post office is decidedly  
different than the ALG that it sounds like you're headed towards.

On Sun, 28 Jun 2020 18:46:03 +0200, R.Wieser wrote:


Exactly!


No It sounds exactly like A ROUTER!

declaimed the following:




    As described, you have an ACTIVE PROCESS running on the R-Pi. Since the
TCP/IP interface uses source IP:port/destination IP:port (where destination
is the R-Pi) to define a connection, your active process will have to
maintain a table mapping the source:R-Pi connections to
R-Pi:other-destination. That is what a NAT router is performing! And, below
IP/port -- packets are routed by MAC address (the hardware address of
interface itself -- one interface can have multiple IP numbers assigned to
it, each of which can have many ports active)

    If you are trying to sanitize the data "dropping IP/port" you are now
looking at the aforementioned "data diode" operation. Those are designed so
that only certain packets are allowed through, 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.


    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.

    THAT form of operation is easily done using FTP (deprecated in the wild
as the log-on information is sent in the clear) or sFTP (which is already
running on an R-Pi if you have SSH enabled).

    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.

    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.

On 6/28/20 12:47 PM, Dennis Lee Bieber wrote:


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).



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.



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



Agreed.


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



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.


Yes, this the basic operation of a queuing mechanism.

Denis,



Either you are describing that as something special when every other 'puter  
does the same, or you have read something I've never said.

But to make it absolutily clear, in my explanation the RPi is *passive*.  It  
waits for connections initiated by both hosts, and only than tries to / can  
write received packets to the other interface.



Nope.   Both sides can send and both sides can receive.  The only thing that  
happens in the RPi is that the connection gets scrubbed (notice: the  
connection, not its data).



As in the above, it is supposed to be.


....

Why is it that "passive" also must mean "time delay" and (thus?) "files" ?  
I don't get it.



as well as for its multi-port usage ofcourse, which doesn't work well with  
(simple) firewalls.

But as mentioned, I had something /much/ simpler in mind - with the RPi  
being next to invisible.

Doesn't mean that I cannot also think of setting the RPi up as a  
multi-subnet data-storage device ofcourse.  Heck, I might even think of  
setting up both !

Regards,
Rudy Wieser

On 6/28/20 2:10 PM, R.Wieser wrote:


I think we have a nomenclature problem here.

I think you, R. Wieser, are using "passive" as a reference to which host  
/initiates/ the connection.

Where as some people in this thread have taken "active" vs "passive" to  
mean "doing something with the traffic to copy it from one interface to  
another".

Traditionally, in both computers and electronics, a passive device is  
one that will function without any power, conversely an active device  
will not function without power.

A DB-25 to RJ-45 adapter is passive in that it's wires and unpowered.  
Conversely, a Pi is an active device that will not function without power.

So, we get into the minutia of /what/ /specifically/ the Pi is doing and  
if it constitutes active or passive.

I think that many would support that routers, particularly routers that  
alter traffic as it passes through, are /active/ devices.

You have stated that you want to /actively/ decide what traffic to allow  
through or not.

You have also stated that you want software to read from one interface  
and write to another interface.  Both of those are active functions.

Even if you don't consider traditional routing to be active, you have  
indicated that you are considering writing a custom program to read from  
one interface and write to another, possibly via sockets with the  
existing TCP/IP stack.  This sounds very active to me.

The Pi can be both active in that it processes traffic and /reactive/ in  
that it only does so in response to external stimuli.

So, please clarify what you mean by "active" vs "passive" as well as  
"initiator" and "responder".  Please also re-state your desires while  
clearly indicating what is active / passive and initiator / responder.



The "scrubbing" supports some sort of active process on the connection.

Connection vs data is getting into the minutia and we need to share a  
common understanding of what each other means.  Lest we talk in circles  
around each other.



Unless or until corrected, I'm going to take "passive" to mean "does not  
initiate / responds to external initiation".



In typical file drop / post office scenarios, the recipient can't  
/safely/ read the file until /after/ the file is completely written.  As  
such, you are introducing a delay of some amount of time.

Conversely, an active process can read from one socket and write to  
another socket in almost parallel.  (There is a tiny but measurable  
delay.)  It can certainly start writing to the second socket before the  
data is finished being written to the first socket.



If by "simple" you mean "stateless", sure.



I'm not convinced that the Pi will be as invisible as I think you are  
thinking.

Hosts A and C will know the remote IP that they are talking to.  They  
can share that information in the data that passes between them (much  
like FTP does) and can detect that each other are not at the addresses  
they are talking to.

Does this visibility matter?  Probably not.  But it might.



~chuckle~

Grant,



Yeah, I also got that rather strong feeling, which is why I mentioned the  
above.   To allow you to become aware of my usage of the word (and context),  
and invite you to mention yours.  As you did.



:-)  Look at the package-exchanging method I described.   Although the Pi is  
not attempting to do /anything/ to those packets, the end result is still  
that the data connection (between A and C) is scrubbed.   Now, tell me if  
that means the Pi is "passive", or "active" :-)

IOW, the definition of the word "passive" (and "active" ofcourse) is  
strongly tied to the context:

Using my described method to shuttle datapackets to-and-fro:

- The Pi is passive because it does not initiate connections to either A or  
C

- The Pi is passive because it does not attempt to alter the datapackets it  
exchanges between the two sockets.

- From the POV of A and C the Pi is active, as it scrubs the datastream  
between them.

And I'm sure I forgot a few POVs :-)



I'm sorry, but I never mentioned anything of the kind  (I read that  
"actively decide" as "runtime" as opposed to "design time")

Also, as we are observing nomenclature, what does "traffic" mean to you ?  
Everything that goes over the ethernet cable (or comparable), or perhaps  
just the data thats left when all the different headers are peeled away ?  
Maybe even something in between ?   And yeah, that does make (quite) a  
difference I'm afraid. :-)



And there you have yet another context in which "passive" or its counterpart  
"active" can be used.  On the other hand, can you make the RPi actually /do/  
anything while its "passive" (not running any kind of program) ?   Other  
than being a paperweight of some sort I mean.

I'm going to stop this here though, this is getting silly.  The next thing  
we do is discussing what the definition of "is" is. :-(



How do they detect that ?    You seem to assume that A and C know each  
others IPs.   Why ?   What would that be good for ?

And even if they would know, there is no way they can reach each other.   As  
you said it, if they could than this whole conversation would be moot (and a  
big waste of time).

Regards,
Rudy Wieser

On 6/29/20 3:47 AM, R.Wieser wrote:


The Pi is is actively doing something to copy packets from one socket to  
another.  Packets won't flow between the sockets if there isn't  
something doing the copy.  That something is the active part.

This is also why I think routers are active.  Same concept, just at an  
interface level vs a socket level.



Agreed.


I agree that the Pi doesn't /initiate/ the socket connections.

But as previously stated, simply establishing a socket connection from A  
to B and C to B is not enough.  Something on the Pi must copy packets  
from socket to socket.  Thus why I state that the Pi is actively doing  
something with the data on the sockets.

An analogy.  Suppose that two directors in the company have a Jr. staff  
person go down and check their mailboxes in the mail room.  The first  
director has the staffer take a memo and put it in the out box in the  
mail room and check the first directors mail box.  The second director  
does similar.  Without the 3rd employee in the mail room taking the mail  
out of the out box and putting it in the respective directors inbox,  
there will never be any mail for the staffer to pick up and bring back  
to their respective directors.  This 3rd person, working in the mail  
room, is actively doing /something/ with the mail.  What is being done  
can be debated later.  But the fact remains, that without this 3rd  
person actively doing something with mail, communications will not flow  
between directors.

The Pi in your scenario is the 3rd person in the mail room actively  
moving things between mail boxes.

As I type this, I realize that there is a slight variation that might be  
what you're thinking.  If the staffers put the outgoing memos directly  
into the recipient's mailbox (the staffers do the routing) there might  
not be a need for the 3rd employee.  However, that is a different  
process than is happening above.  It also requires that the staffer do  
more work.  It also means that the staffers must have access to all of  
the recipient's mailboxes.



I disagree.  See above.  The packets (messages) don't go from one  
mailbox (socket) to another without the mail room employee moving them.

The mail room employee does not need to open and scrutinize the  
messages.  Something that would be invasive and extremely active.  The  
simple act of taking messages from mailbox (socket) 1 and putting them  
in mailbox (socket) 2 is an active process.  It's just less active than  
reading and spell / grammar checking it.



That's somewhat an incidental side effect that a shoe box shaped package  
won't fit in a letter slot, thus gets dropped on the floor.



You have stated that only traffic of your choosing will be forwarded.  
That means that there is a selection criteria to make the decision of if  
something is forwarded or not.  Given above about the active mail room  
employee, that is an "active decision" (per packet).



Traffic is anything that the host sends.  Some of it will make it  
through the Pi, some of it will not.  Depending on shape.



No.  The Pi won't do anything productive while being passive.  Even  
running the kernel or receiving files into a queue is a form of active  
action.  The Pi won't do anything when it's powered off, or in  
paperweight mode.



Take a look at FTP and SIP for a couple examples.



You will see that FTP and SIP both want to connect to the address that's  
inside the data that is passed, not the address of where the apparent  
connection is coming from.

declaimed the following:



    Which is an active process -- somehow you need to implement a protocol
in which one side can say "I want to transfer data to other side" AND the
other side has to say "I want to receive data from the first side"...
Somehow you will have to be able to specify the identification of this
channel AND you will have to maintain the address translation table (source
IP/Port <> destination IP/Port) for these packets. BUT, unlike a NAT
router, you don't want the router part to initiate the gateway operation
(in a router, your computer says "I want to connect to some external mode",
the router takes the information (IP/Port) of the destination, swaps out
the source IP/Port replacing it with a router NAT IP/Port (ie; the
external/ISP assigned IP address, and some unused port on the router), and
updates the NAT table. The external device then sends ACKs and return data
(if any) to the IP/port the router gave it, the router than replaces its
IP/port with the internal device IP/port (per the NAT table).

    The external host never sees the IP/port of the internal host, only the
IP/port given by the middleman router.

    "Post office"/"mailbox" systems rely on buffering sent traffic locally,
until the recipient connects and takes the stuff out of the mailbox.

    I know of nothing that does gateway type operations but only when both
external sides have issued a connection request to the middleware. You're
going to have define the full protocol of this middleware, along with
client software running on the external nodes to initiate the connections
and handle transfer and error conditions. You will NOT have just ad-hoc
(eg: any TCP/IP protocol) to go from one node to another.



    NAT router... Not just a gateway (gateways don't mask IP addresses,
they just forward stuff coming in on one interface that is not addressed to
the local machine through to the next specified interface).

    A NAT router does the IP/Port substitution, but has to maintain the
status of active connections, error retries, etc. (Note that the NAT
affects the "outgoing" side of the middle -- the source side still has to
know the IP of the destination.

    What you do NOT get is the concept that both sides connect to the
middle and negotiate a connection. For that you are going to have to create
a custom NAT system in which SOME type of packet says "I want to connect to
some service port of some named device" [using "names" without using DNS
name->IP lookups]. I say "service port" as typically the source will be
asking to connect to a server running on a known port number... The source
client, however, normally uses an "random" port number -- which complicates
matters as the other side can't say "connect to port-X of other named
device.

On 29/06/2020 04:23, Dennis Lee Bieber wrote:


The OP hasn't stated exactly what applications and/or protocols are  
required for this "post office", but if files are sufficient, you could  
use OwnCloud (roll your own Dropbox). This would allow files to be kept  
synchronised between machines but with no direct network connection  
between them. The Pi runs the OwnCloud service and accepts connections  
from each network interface, but does not route any data between the  
interfaces.

---druck

druck wrote:



That's the closest suggestion I've heard so far to using something that  
already exists, rather than implementing a roll-your-own solution ...

On 29/06/2020 08:51, Andy Burns wrote:


Well as my suggestion has been ignored by the OP in favour of continuing  
arguments in other parts of thread, I think we can gauge the validity of  
the request, and update our kill files accordingly.

--druck