Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Securing MooseFS public installation #88

Open
zcalusic opened this issue Dec 30, 2017 · 2 comments
Open

Securing MooseFS public installation #88

zcalusic opened this issue Dec 30, 2017 · 2 comments
Labels
community not a bug, but a question for the community documentation Issue related to documentation need feedback question Question

Comments

@zcalusic
Copy link
Contributor

I couldn't find in the documentation all details about securing MooseFS installation which would be installed on the public IP addresses, to be accessible from anywhere.

So, to be able to mount the mfs share, port 9421 on master and port 9422 on chunkservers need to be open to everybody, right? Then we secure master - cs communication by setting AUTH_CODE in master and chunkservers. Then we secure mounts by requiring password for all of them in mfsexports.cfg. Ports 9419/9420/9425 can be firewalled, as they're not used for user access.

Can the above described MooseFS cluster setup be declared secure enough to be open in public? Meaning, no unauthorized access will be possible? At this point I'm not concerned with unencrypted traffic, just that data can't be accessed, unless you have provided proper password.

This is also a great opportunity to thank you for probably the best distributed file system out there, and wish you all the best in 2018!

@acid-maker acid-maker added the question Question label Apr 17, 2018
@borkd borkd added documentation Issue related to documentation community not a bug, but a question for the community labels Dec 19, 2018
@borkd borkd pinned this issue Dec 19, 2018
@jerdna-regeiz
Copy link

I was concerned as well and as far as I can see, there is no way to secure MooseFS.

If the traffic is not protected/encrypted there is no protection at all (see replay, session hijacking, man in the mittle, and some more attacks).

My solution was to build a wireguard network and have MooseFS only listen on the wireguard interface. Thus all authentication and protection is done by wireguard transparently.

If you do this right, the performance penalty is not that hard. But you have to build a fully connected wireguard network among the MooseFS nodes. Meaning every node knows every other and knows the public key of the peer. A client of the MooseFS must know every MooseFS node in advance and have the public key configured.

To have a fallback, the MooseFS master can be configured as a wireguard router. If a client misses a node, the MooseFS will still work, but the penalty will be more pronounced as all traffic to the missing node is routed through the MooseFS/Wireguard-master.

@dagelf
Copy link

dagelf commented Apr 13, 2022

The Unix philosophy is that each program should just focus on its strength, so adding IPSec, L2TP/SSTP, Wireguard, Zerotier or any other performant network security could be leaner - and more secure and better vetted - than if this was built in. (The trend to build everything into everything is going in the wrong direction.)

Or just isolating your networks through separate switches and firewalls with VPNs inbetween, there should be no need to secure comms between nodes unless you only have one node per site.

Close ticket? Or should we document this? Where?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community not a bug, but a question for the community documentation Issue related to documentation need feedback question Question
Projects
None yet
Development

No branches or pull requests

5 participants