We had the firewall on our cryoSPARC master server set up to allow all connections on ports 39000-39010:
# These ports are used by cryoSPARC
iptables -A leave_open -p tcp --match multiport --dports 39000:39010 -j ACCEPT
The machine subsequently got flagged by information security services for having an open MongoDB port.
Much to my surprise, it turns out the MongoDB instance used by cryoSPARC allows anyone from anywhere to write to it without authentication? Is this a misconfiguration on my part? Here is my test, with some Mongo messages removed:
[cnsit@lizard ~]$ mongo --host kraken.biosci.utexas.edu:39001
MongoDB shell version v4.2.0 connecting to: mongodb://kraken.biosci.utexas.edu:39001/?compressors=disabled&gssapiServiceName=mongodb
<snip a bunch of irrelevant messages>
meteor:PRIMARY> use security_test
switched to db security_test
meteor:PRIMARY> db.users.find()
{ "_id" : ObjectId("5daa0b7f367d5157103ff967"), "hackername" : "pgoetz" }
meteor:PRIMARY> db.users.insert({hackername: "jmclellan"})
WriteResult({ "nInserted" : 1 })
meteor:PRIMARY> db.users.find()
{ "_id" : ObjectId("5daa0b7f367d5157103ff967"), "hackername" : "pgoetz" } { "_id" : ObjectId("5daa0dfa04d2ae2aa7031e53"), "hackername" : "jmclellan" }
I created the security_test database previously and added {“hackername” : “pgoetz”} so the second connection demonstrates that the data is persistent. All the cryosparc stuff is in a database called meteor:
meteor:PRIMARY> show databases
admin 0.000GB
local 0.089GB
meteor 51.660GB
security_test 0.000GB
A cryoSPARC master instance needs to be set up in a way such that ports 39000, 39001 and 39002 are available to the workers nodes and port 39000, the web application, is the only port that a user needs to access cryoSPARC. This connection to the web application over 39000 is typically done through SSH port forwarding into the internal network.
At the moment, it is assumed that anyone with access to the database port is a trusted user and that the database port is not open to all. We are working on a solution to support use cases such as user isolation and data security.
Hi, yeah… this is a serious cybersecurity issue. As users may use public login servers to run the master, the mongod instance is hence also running on said public (internet visible) server.
at a minimum, the mongod instance should be user and password protected. having the workers access through an application proxy rather than directly to the mongo database is also advised.
Hi @yee379, thanks for the comments. Currently we do leave all network and user security choices up to users and while improvements are always possible, the expectation is that cryoSPARC should not be run on completely publicly internet-visible machines where dangerous ports are open.
CryoSPARC master applications all run without sudo rights and only use ports in the 39000+ range. If a machine is on the public internet, serving the cryoSPARC web application should only be done via ssh tunneling for port 39000 or via a secure authorized reverse proxy - and even these choices are up to users to take at their own discretion.
We hope to continue to improve database and system security in the sense of “keeping honest users honest” but we will not be attempting to make cryoSPARC an application that can be hosted on the open internet or in any environment where users are not generally trusted. It is outside our scope to provide security against malicious users who through some other means gain access to your internal networks and then can interfere with the cryoSPARC application.
This misconfiguration also prevents us from using cyroSPARC in our environment, unfortunately - our security folks won’t allow a running database server with absolutely no authentication.
Just to be clear, the issue isn’t the port being open on the Internet - that is prevented by both our own packet filtering and our institution’s firewall. But the database needs to be protected from other users on the same machine, who may otherwise (perhaps accidentally) connect to the database and break things. Simple username and password authentication, even stored plaintext in a cryoSPARC config file, would trivially fix this.