[HECnet] Multinet Tunnel Connections to SG1::

[Johnny Billquist]

On 2012-06-07 11:54, Mark Benson wrote:
On 7 Jun 2012, at 10:09, Johnny Billquist<bqt at softjar.se>   wrote:

Yeah, I'm also starting to wonder if we're talking about different things...

I wouldn't be surprised if I am totally across-purposes as I am just a
user with a little knowledge (and we all know about a little
knowledge?) in this argument.

If nothing else, having the discussion will clear things up, and we all can learn something...

Maybe someone can explain to me the worries they have with this "wide open" thing, and how that improves by having the bridge (or router) running on a separate machine?

As far as I see it, using pcap and promiscuous mode creates 2 potential issues:

Security is possibly compromised, but promiscuous mode is only
activated as root so rhis isn't a big concern.

I can't see how it is a problem at all. If you are root, you have already compromised the system 100%. There is nothing more to say. Being able to sniff the network by setting your device to promiscuous mode is not increasing the compromise when you are already root. There is basically nothing you can't do when you are root. That is already the ultimate security issue.

So no, I can't see how promiscuous mode increase the security concerns.

There is an increase in traffic and filtering loads on the CPU because
the LAN interface is no longer filtering packets in hardware.

Right. However, since I would expect close to no one have network without switches nowadays, in reality you are not getting any packets that are filtered by the hardware in the machine anyway, so this is for most people really a non-difference.

Using a separate 'appliance' to do the work presents these possible solutions:

There is nothing of import on the appliance so immediate security is
not a problem. Packets from or intended for other destinations can
still be sniffed but you still need root access to the device.

And if you have root, then promiscuous mode is already available to you. That the bridge (or router) needs it is not increasing the exposure.

Traffic through the device and using the CPU to filter it is the
intended purpose of the 'appliance' thus it is not invading your other
tasks on a user-centric machine and it is also not compromised by
other heavy tasks absorbing CPU cycles for other things.

Right. But see above... Not to mention the fact that even your user-facing machines are most likely just burning CPU-cycles in the OS idle loop...

Indeed. In addition to the fact that I'm not clear what security threat we're talking about here...

It's minimal, but it shouldn't be totally ignored unless it's an
acceptable risk to the users concerned. Usual security caveats apply
i.e. use good passwords on the router device etc.

I'm still totally failing to see the security issues here.
Note that the bridge (or router) software running does not even open up much of an access path to the machine it's running on. You could possibly exploit bugs, but it needs to come through the normal traffic paths.

    It's just anal-retentive perfectionism, nothing more, no REAL impact,
no REAL casualties...but it makes me sleep better at night, and I can
usually achieve it pretty much everywhere else. :)

No objections to that one. Except I don't loose sleep over a few CPU cycles here, since they are pretty much zero anyway. But like I said before, I don't mind clean stuff.

Again, shut it in a small box on it's own with a single-purpose OS and
it becomes a clean(er) solution.

Yes. Cleaner. Not safer.

	Johnny