Andy,
:-) The last time I looked at it you /couldn't/ seperate them. Than again,
that was Win98. Can't remember having ever tried to put multiple ethernet
cards in a 'puter after that though.
Regards,
Rudy Wieser
There's *nothing* you can't do if you run PPP over your serial
connections, they'd have a full TCP/IP stack and you could ping,
portscsan, ftp, ssh to your hearts content ... not that I suspect you'd
want to.
However I guess must people here are left wondering why you think you
need absolute network isolation for a handful of rPis that, let's face
it, are unlikely to be running fort knox, or a nuclear power plant, and
that you could likely get a suitable level of isolation for your
purposes over a single ethernet port using VLANs ...
The only other real option is VLANs and a smart switch - USB
ethernet is simpler.
That depends - if both networks have DHCP servers then just
configure the new interface to use DHCP (probably default), plug it in and
watch it connect.
You would have to do extra work to get packets passed between them.
Once you have them both connected you can run services listening to
either or both. You could set up samba with a share visible to both
read/write and use it like a drop box, or you could set up an ftp server,
This is pretty much off-the-shelf. In your position I'd probably go
with samba and set up a share or two.
Samba is an open source SMB server, there's a vast amount available
on configuring it.
You don't need to disable anything, you would need to enable
routing for there to be connections between the interfaces.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
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.
--
hmm, lunch does sound like a good idea
would taste like a good idea too
Ahem,
I was thinking more in the direction of a a "hat" plugged onto the RPi's I/O
connector, but I get the message.
That sounds easy enough.
Part of my problem is that I have no idea what the RPi OS does when it sees
two network interfaces. Under Windows it would blabber all kinds of
(discovery) broadcasts and data over both - which is not what I want to have
happen.
Which would be falling right into the target-zone of my programming hobby.
:-)
Yeah, I know.
That sounds good.
Perhaps even good enough to continue in this direction ...
Regards,
Rudy Wieser
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.
There are a number of options. Some are more practical than others.
Adding an additional network interface to a Linux machine is fairly
easy. Configuring said Linux machine to not forward traffic between the
two interfaces is also relatively easy. (Linux itself defaults to /not/
forwarding. But some distributions change that.)
That makes me think that you want hosts A and C to communicate with each
other across some routed network. This differs from my previous
understanding of what I thought you wanted. I thought you /explicitly/
wanted hosts A and C to NOT be able to talk to each other at all.
Further, that any ""communications (read: exchange of files / etc.)
would be done but putting files in a common location, B.
Welcome.
If anything, Linux, and the Raspberry Pi suffer from too many options.
Typically, in scenarios like the one you're asking about, it's okay if
the services listen on multiple interfaces on B. The purpose is to
prevent A and C from being able to talk to each other directly. So, A
talking to B on the AB interface is fine, as is C talking to B on the BC
interface. There usually is no harm in something like Samba listening
on multiple interfaces. Presuming you are using the same protocol on A
and C, in some ways having Samba (et al.) on B listen on multiple
interfaces is required.
:-)
Learning opportunities are good. But you may want to avoid painting
yourself into a corner and making things harder on yourself than is
strictly necessary. Why re-create programs if you can use existing
programs. Especially if said existing programs will happily work with
the isolation that you desire.
It's possible to do this on a single Ethernet connection. It just takes
more knowledge and a little more work.
It's entirely possible to rely on /protocol/ isolation to do what the OP
wants on a /sing.e/ common network.
Hosts A and B can communicate with each other over IPv4 and hosts B and
C can communicate with each other over IPv6. If host A has zero IPv6
support and host C has IPv4 completely disabled, there is no way for
hosts A and C to talk directly to each other.
It's even possible to do this with IPv4. Configure completely different
subnets. Configure firewalling so that hosts A and C block any and all
traffic from each other. Or better, configure hosts A and C so that
they only allow traffic from B.
This filtering could be IP and / or MAC based. I think MAC based would
be simpler and more robust.
There are many ways to do what the OP wants to do on a single Ethernet
interface.
PPPoE, MPLS, etc are options too.
Your suggestions are correct for many environments. However I suspect
that the OP's environment is decidedly different. If the OP has three
devices, hosts A, B, and C cabled together (in a daisy chain), chances
are quite good that there won't be a DHCP server.
Linux (and most other OSs) simply need a setting changed. It's not as
if the OP needs to do something to allow each and every connection.
I sort of suspect that the OP might prefer an (S)FTP(S) server over
Samba. Both Samba and NFS (NAS protocols) can easily have their files
modified (presuming the user has permission) with non-network-aware
scripts / programs. Conversely, (S)FTP(S) is typically not a mounted
file system. As such, there is an access barrier that makes things a
little safer than NAS protocols.
Something a simple as an rm that has gone awry can't effect things on
(S)FTP(S) the same way that it can a mounted NAS file system.
If I were going to do a NAS protocol, I'd use the one that is native to
the platform. Seeing as how the Raspberry Pi is Linux (at least what
we've discussed thus far) I'm going to suggest that NFS be used.
Samba in particular has some down sides compared to NFS related to how
the ""server sees the connections. NFS inherently supports multiple
users over the same connection. Samba does not do so nearly as cleanly.
This may not matter in this situation.
The Linux kernel doesn't forward packets by default. But some Linux
distributions do enable forwarding by default.
He would also need to add routes to A & C so that they would know to get
to each other via B.
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
The biggest one is speed.
There are some other more esoteric things that can be done (much much
much easier) on Ethernet.
Ethernet can easily be point-to-multipoint supporting more than two
computers. RS-232 can't do that. (Yes, other serial specifications
can, but they aren't on the Pi.)
Depending on how you use the serial interface, yes, you can port scan
other computers across the serial connection. SLIP and PPP come to
mind. Have you ever used the Internet over a dial-up-modem? ;-)
I still doubt it. I remember seeing high single / low double digit Mbps
on UARTs in the past.
The fact that the UARTs are hanging off of a USB interface doesn't
change the fact that they are still a UART.
It will depend on the type / mode of USB communications that is used.
Yes, USB Gadget /can/ appear as a network interface. USB Gadget can
appear as a /serial/ interface. (This underlying serial / USB
functionality is how USB-to-RS-232 adapters work.) Linux has the
ability to pick /which/ gadget mode(s) are used. As such, you can make
a USB connection look like a serial connection and not a network connection.
Linux kernel will quite happily support multiple network interfaces and
will not enable communications between hosts on separate networks
without you doing something to enable it.
Some Linux distributions may change this kernel default as part of their
start up scripts.
There is some minutia about which address A uses when talking to B, be
it AB or BC. But this minutia shouldn't impact what you are doing.
Comparing the Linux TCP/IP stack to a Microsoft TCP/IP stack, especially
one 20+ years old, is disingenuous. It's sort of like saying that
anything faster than 10 Mbps Ethernet connections is cost prohibitive
and outside the reach of anything but servers.
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?
It *should* be that easy - worst case you have to add a config file
for the USB ethernet.
If DHCP is enabled on the interface (almost certainly) then it will
broadcast a DHCP discover and listen for an offer, once all that has
settled down and it has an IP address it will settle back and listen on it
with any active services (probably only ssh) that haven't been configured
not to (every service I can think of can be configured to listen on a
specific address and/or interface so you can arrange for it to provide
selected services to one network and not the other if you want).
It's not much work - set a flag on the Pi and tell the two subnets
that they can find each other via the Pi. Until you do that the Pi is the
only thing that can see and be seen on both subnets.
I think you'll find it the path of least resistance, and the path
that offers maximum future possibilities.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
It also entails more risk.
Yes it is - but it is even more fragile from a security perspective
than VLANs.
Apart from promiscuous mode and/or packet injection.
One glitch in the firewall rules and it all falls open.
The OP explicitly mentions two subnets - so that doesn't fit.
That is indeed the extra work - my point is that it won't just
happen.
That is of course an option and there are many more.
Ouch nasty I've not seen that except on builds meant for routers,
and not on anything common on a Pi.
For everyone but the hackers yes.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
Grant,
:-) Now I still know nothing.
The thing is I know very few options, and I named both ("hat" and dongle).
However, I do know that using an USB dongle will throttle the speed to that
of the USB port. I have no idea if any of the other possibilities will do
better.
No, no intermediate network. The hosts are always in the same room.
I did, and stil do. But I also said /directly/.
Instead of an UUCP program dropping a file somewhere where the other side
can read it I was thinking of a program which reads a data paccket from one
interface and that writes to the other - in the process dropping all headers
(containing the MAC, IP, port) in either direction (replaced by ones from
the RPi). It would be real-time communication, but definitily not directly.
Hmmmm... Does that UUCP program allow one interface to write a file while
the other interface is reading from it at the same time ? That would be
comparable.
True. As long as that process does not inadvertedly creates some kind of an
U-turn allowing data to pass from one interface to the other (allowing a
direct A-to-C communication). Yeah I know, that sounds a bit paranoid,
but its better to make sure that that can't happen than (much) later pay the
price for it.
Agreed. But I would not have any qualms to install SAMBA twice, once for
each interface, only coming together on the file-storage level.
The former doesn't automatically follow from the latter.
Why else ? Because I want to see if I can do it myself. :-) Its also a
good(?) way to get to know the OS a bit under its surface. Besides, if that
fails I can always fall back on stuff that others wrote.
They won't. But as I have quite a bit of experience with programming and
TCP/IP on a Windows machine I don't think that writing a program for it*
will give me much trouble.
*simple file-transfer first, maybe automatic clipboard exchange later.
Regards,
Rudy Wieser
On Sun, 28 Jun 2020 18:46:03 +0200, "R.Wieser"
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.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Yes, a single Ethernet NIC is more risky than multiple Ethernet NICs.
But there are ways to mitigate it with belt and suspender redundancy.
Depending on the OP's neeed, the simplicity and minimal additional risk
might be acceptable.
I don't completely agree.
It's trivial to have a kernel without IPv6 support. It's slightly more
complicated to have a kernel without IPv4 support. (At least the last I
looked.)
I think that 802.1Q VLAN tagging is great. I've done a LOT with it in
my career. But there are ways around it.
One extremely important thing is do you trust the A & C endpoints? Or
are you considering them to be hostile and defending against them. The
latter requires completely different, and likely more complex, solutions
than the former.
Not necessarily.
You can put the firewall rules on both systems.
You can add static ARP entries.
You can put the systems in separate subnets without a route.
Yes, all of these things can be overcome. But that goes back to the
question of trusting A & C.
The existence of a DHCP server (or not) is independent of subnets.
Besides, what I'm describing would be two different subnets.
|-----| Cable 1 / Subnet A
[A]---[B]---[C] Hosts A / B / C
|-----| Cable 2 / Subnet B
(See comment's below.)
Yep.
It is highly dependent on what the OP is wanting to do.
But it is decidedly a possibility where the OP can end up with the
system routing traffic without doing any additional action. ;-)
Trust of the devices is extremely important.
Even if there is a hacker on A, C will have to have a route to get back
to A. The hacker can't always do it without some support on the other
end for bidirectional communications.
I get the impression that the OP is in control of all three systems, and
as such, probably trusts them about the same.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.