-
Notifications
You must be signed in to change notification settings - Fork 201
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
Comments
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. |
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? |
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!
The text was updated successfully, but these errors were encountered: