Here is what happens when you leave an unsecured database for a moment...
I needed to analyze some data in a Mongo database. The database is running on a server, and the only way to connect to it was to ssh to the server first, and then use mongo, a command line client. I thought it would be more convenient to connect from my laptop using Robo 3T, a GUI client. So I enabled external connections but didn't enable authentication.
I thought that no one knows that there is database on the server so I could keep it unsecure for a moment. Around 30 minutes later... boom! All data wiped out, and a ransom demand to recover the database.
I guess it was an automated script scanning all IPv4 addresses on port 27017 looking for unsecured MongoDB instances.
Fortunately, it's a development database with no sensitive data. I'm sharing this as a cautionary tale.
Investing extra 30 minutes of securing your database, espacially when your using cloud services (public known ip ranges), (lightweight instructions are always available for any engine) will save you hours, days or even your whole company, 'cause doing it later mostly likey will be to late.
Tip for any database:
FWIW, you could have used your SSH port forwarding to expose the Mongo port from your server to the GUI client on your laptop - without opening the port to the outside world. I'm happily using this method for all my databases (in addition to the authentication).
Of course, it's easy to say "you should've ..." after the something had gone unexpectedly wrong, and the amount of time it took for your Mongo instance to be "pwned" is incredible. I'm just sharing this solution in case anyone else gets into the same situation - keep in mind that you can use SSH as kind of a VPN as well - not just for command line access.
Thanks for the hint! I'll use it next time.
Thanks for sharing. Can you shed some light on what you mean by "leave unsecured" specifically (without necessarily providing any private details)?
Might be helpful so others know what to do / not to do.
Thanks for your question. I updated my post with more details.
Thanks Lukasz! (crazy, 30min is all it took!)
Really important lesson right there.
If possible try to use a managed instance from Mongo Atlas, they have reasonable prices and are secure by default, this way you can focus on your product and not managing the infrastructure
Totally agree. I use Mongo Atlas for production environment.
Bummer.
Pro tip: never use Mongo (unless you're a sadist).
Always start with Postgres. If you really truly need unstructured data, just use the Postgres jsonb column type.
http://blog.shippable.com/why-we-moved-from-nosql-mongodb-to-postgressql
https://betterprogramming.pub/why-the-guardian-switched-from-mongodb-to-postgresql-861b6cf01e1f
https://medium.com/compass-true-north/migrating-data-from-mongodb-to-postgresql-with-no-downtime-dda2164b5658
And there's tons of other examples by googling "Postgres vs Mongo".
It's not the matter of Mongo vs Postgres. I know both. I use both happily. It could happen to any database running on any DB engine. I bet there are other black hats scanning the IPv4 addresses on port 5432 trying to apply the same tactic to unsecured Postgres databases.
Fair enough. But isn't Mongo insucure by default?
By default Mongo doesn't allow for external connections, only localhost. It was my stupidity that I enabled external connections without adding users and enabling authentication. I thought, I only need to check one thing. It will be more convenient to connect with a GUI client from my laptop. In the end, who knows that there is a database running on the server - only me. And 30 minutes later... boom, no data and the ransom demand.