Apparently there’s a big problem with insecure-by-default Mongodb installations (≥2.6.0): https://snyk.io/blog/mongodb-hack-and-secure-defaults/
Not sure if this affects anyone. Would it affect Meteor Galaxy installations?
—t3db0t
Grooply: Better Group Scheduling
https://www.grooply.io
This would not affect Galaxy since Galaxy does not host MongoDB.
Argh, duh. I meant Compose or any of the others.
Can’t speak for them, but I would say those services will be fine since they tend to use the most up to date version of MongoDB and have a very specific setup (ie. not the defaults that were the issue).
@alimgafar
In this case the vulnerability is particular to the latest versions (or rather, not the software itself but the defaults it ships with), but yeah, I would think that the setup details of a normal hosted db would preclude this problem with the defaults.
The vulnerability comes into play when people setup mongo on open ports with no authentication. Like anything else you either need to only allow local access or have auth enabled with strong passwords.
It’s absolutely frightening that there are that many databases being hosted without a firewall or authentication. Security 101.
Then again, it’s also kind of frightening that MongoDB allowed people to do this by default.
With every other database I’ve installed, one of the very first tasks was:
True, they’re are others out there though. When I first started using elasticsearch they didn’t even have authentication at all. I find it funny that we’re having this discussion about secure defaults on the Meteor forum page when it itself has insecure defaults (insecure & autopublish package).
That said, the lack of firewalls is the part that really makes me cringe.
Haha!
Just found that my mongodb instance on an EC2 instance was hacked.
Woohoo! 
Yes, I used no password - my bad - but no probs - no great loss, so pppffffttt to you kraken0@india.com
LOL!
Seriously though, set up authentication, maybe even change the port that mongod listens on, or use a 3rd party db host like mLab or something.
Once bitten, twice shy.
I opened my EC2 security group for port 27017 from 0.0.0.0 (anywhere) so I could connect to the mongo database from home (using MongoChef) - because its easy to develop against the real db.
One shouldn’t do it that way, but there you go …
Just an update:
Amazingly, the database that got hacked has been restored.
I have no idea how or why. I didn’t do anything since posting my previous reply.
Tonight, I was in the process of adding authentication, and started MongoChef to see the results (rather than the command line) and wow, I can see my database back… ?
So I’m doing a backup right now… just in case.
Hope this helps someone else - check your db’s again - it may be back!
It would depend on what the hosting service has installed (prebuilt binaries, compiled from source) and what additional steps they’ve taken to ensure the service is production-ready. MongoDB publishes a basic security checklist in their online security manual and Andreas Nilsson wrote a pretty comprehensive post on security best practices, with links to ancillary resources.
If you’re concerned about the security of your hosted MongoDB instance, I would send a copy of the checklist to your hosting provider and demand that they confirm that they comply with the recommendations in the checklist. Better yet, it would be far more comforting if they would publish an audit that demonstrates they meet or go above and beyond the recommendations in the checklist.
It’s difficult to ever know if a service truly complies or simply gives lip service. In this case, you could try to confirm for yourself by using Shodan, WireShark, an http browser, port scanner, or some other tools to see if you can find and gain access to your database.
I hope this helps.