Slashdot Mirror
Over 650 TB of Data Up For Grabs From Publicly Exposed MongoDB Database (csoonline.com)
itwbennett writes: A scan performed over the past few days by John Matherly, the creator of the Shodan search engine, has found that there are at least 35,000 publicly accessible and insecure MongoDB databases on the Internet, and their number appears to be growing. Combined they expose 684.8 terabytes of data to potential theft. Matherly originally sounded the alarm about this issue back in July, when he found nearly 30,000 unauthenticated MongoDB instances. He decided to revisit the issue after a security researcher named Chris Vickery recently found information exposed in such databases that was associated with 25 million user accounts from various apps and services, including 13 million users of the controversial OS X optimization program MacKeeper, as reported on Slashdot on Wednesday.
Read the documentation for the software which even comes with reasonable guides for Linux and Windows?
https://docs.mongodb.org/v3.0/core/security-network/
For best results and to minimize overall exposure, ensure that only traffic from trusted sources can reach mongod and mongos instances and that the mongod and mongos instances can only connect to trusted outputs.
Sorry but anybody working in this space should know better.
The issue here really isn't SQL vs NoSQL. It's about securing the data and access. Lack of security is not inherent in NoSQL, it just occurs more often than SQL databases.
Well, I'd have to disagree here. If I install a MongoDB on some cloud VM using the default setup, I have an insecure database available on the internet. If I install Postgres, well... I can't even access the database remotely.
Much of the time NoSQL is a problem looking for a solution. I've had to deal with this a number of times before - and I'd concur what the AC above posted - the culture around NoSQL often seems to be "squeee! I have a NoSQL database.. look at my awesome speed" without investing time getting to know existing SQL properly. Or securing the systems.
Case in point: a while ago I replaced an Elasticsearch database with 40 lines of decent SQL. It wasn't rocket science (MySQL), but it was an order of magnitude faster and less complicated as it didn't require an additional server and the data pump between the SQL and Elasticsearch databases. Yes, I know Elasticsearch isn't a NoSQL db in the same sense as Mongo, but it was part of swag (4 in total) non-traditional databases in use papering over poor indexing / querying on the existing MySQL db. Oh.. and no security. That's the NoSQL culture I've experienced, and not just at one shop. All over the place.
We lost something when database administrators were given short shrift and we all became "full stack developers". So much knowledge has just gone out the window.
The issue here really isn't SQL vs NoSQL. It's about securing the data and access. Lack of security is not inherent in NoSQL, it just occurs more often than SQL databases.
Well, I'd have to disagree here. If I install a MongoDB on some cloud VM using the default setup, I have an insecure database available on the internet. If I install Postgres, well... I can't even access the database remotely.
Ummm, unless something has changed recently the respective "createdb" tools for both MySQL and Postgres make it very simple to start up a new DB with an open root account and listening on an IP.
I agree with your general view on NoSQL and who tends to use it, but it's the ones using it that are the problem here and not the software itself. The only argument against NoSQL/Mongo here is that it is shocking in this day and age for any server to allow un-authed access. That can be applied to many server software packages though including OSS SQL DBs.
What this is really a symptom of is the people with no real experience that are just about "getting the job done" rather than understanding the actual problem and the potential risks. I don't know how many times I've seen cases in my career where the first sign of communication issues causes people to start tearing down the security barriers. Most of the time the real problem was a minor config issue (going over the wrong interface, missing host to host ACL, listening on the wrong port, etc..), but the damage done to "just get it working" is rarely ever fixed.