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
Chris,
I suggest you read my intitial post for this thread. It might be helpfull.
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 ...
I agree.
And/or iptables to drop any traffic that is not allowed by network interface, source and destination IP-address, and port.
-- Regards, Kees Nuyt
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 The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
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.
-- Grant. . . . unix || die
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.
-- Grant. . . . unix || die
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.
-- Grant. . . . unix || die
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.
-- Grant. . . . unix || die
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.
-- Grant. . . . unix || die
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. . . . unix || die
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 The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
Exactly!
No It sounds exactly like A ROUTER!
-- We are anthill men upon an anthill world. -- Ray Bradbury
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 The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
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.
-- Grant. . . . unix || die
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.