201–210 of 223 posts
Earlier quoted context omitted.
The FTC sued over insecure defaults because it said "secure" on the box.
So MongoDB should state 'insecure out of the box' on their home page ? Just kidding sorry.
Earlier quoted context omitted.
For small data volumes, MongoDB Inc. will actually back things up for you for $2.50/GB/mo storage (free bandwidth), and it's a live backup with multiple historical versions (an agent on your database machine tails the oplog, so you're at most a couple seconds out of date). And their free monitoring tier is great alongside it. I'm truly surprised that they don't sell it harder; it took me years of using Mongo before I…
I used to use Cloud Manager until they started charging a fee of I think $99 per server per month. I pay $150 for my hardware per month, so I stopped using their backup and monitoring tools. Other than the cost, I recommend it for people who can afford it. Wonderful service that I was happy with for a long time.
Earlier quoted context omitted.
Next time you cross a bridge, make sure it will handle your weight ... And think about everything that can possible go wrong, what materials are used, and how old it is, etc.
Different. This isn't some deep, underlying fault that requires a lot of specialized knowledge to recognize, like a bridge that has the wrong type of struts or whatever. If the program doesn't make you put in a password ... it probably doesn't require a password. Refusing to deploy a process into production without setting a password is more like refusing to drive over a bridge that's obviously missing chunks and cru…
When our sysadmin set up our Mongo cluster, he firewalled out all IPs except our production systems, turned on authentication, set things up to ensure we used SSL, and configured backups. He didn't do this because he's an amazing sysadmin. He did it because he's competent, knows how to put a service on the Internet, and RTFM. I mean. If you can connect to something and use it without having to authenticate yourself,…
Thoughts like this are, and will forever be, the one dividing thing between a more ops-y person versus a more dev-y person. But that's fine. At our place, our mysql cookbook is maturing. This mysql cookbook makes it really easy to say "hey, we need a mysql master with these 2 databases". The only security overhead consist of generating 4 passwords in that case (and we're planning to automate that). Once you've done t…
There are devs who are unaware of the concept of authenticating access to an application?
Earlier quoted context omitted.
I first started using Mongo in 2013/4, when I deployed my app, first thing I did was to change the default port and add authentication, as the manual recommended. I'm an accountant who's a hobbyist developer. I knew very little about security then, but I read the manual. The insecure defaults were an issue sure, but anyone installing a piece of software in production without at least reading up on config options need…
Meanwhile, the FTC sued D-Link over insecure defaults in their cameras. We need good and consistent rules about this, and "well I was giving it away for free" isn't as clear a boundary as people will think it is.
Earlier quoted context omitted.
Different. This isn't some deep, underlying fault that requires a lot of specialized knowledge to recognize, like a bridge that has the wrong type of struts or whatever. If the program doesn't make you put in a password ... it probably doesn't require a password. Refusing to deploy a process into production without setting a password is more like refusing to drive over a bridge that's obviously missing chunks and cru…
The problem is that once you work with something every day for years it becomes common sense. You should always assume your users have zero experience and don't RTFM. Messing with configurations does require a lot of specialized knowledge. Not everyone has the knowledge of a Sysadmin.
Furthermore, running "apt-get install" usually isn't enough to get something exposed onto the public network, even for home users, whose routers block all incoming ports by default. Someone has to go in and explicitly open the traffic before something like Mongo gets exposed; there's no reason that labs, developer machines, etc., would be publicly accessible.
Mongo is hardly alone here; comparable services like MySQL, PostgreSQL, and Redis also install without a password by default. For MySQL, this is perhaps less noticeable because Debian/Ubuntu (and probably some other distros) include a prompt to allow the user to set a new root password as a post-install script. For PostgreSQL, the default mode uses IDENT authentication, i.e., it's accessed by dropping to the "postgres" user ... and, like all other system users, including root, this user is passwordless by default.
For Redis, it's passwordless by default and I'm sure there are many installations that have this same "vulnerability" in redis-land (there are also many installations that have real vulnerabilities, because Ubuntu's redis-server package in 14.04 hasn't been patched), because people rarely think about redis auth either. Just since last year, there is a feature called "protected mode" that requires the user to explicitly disable a flag if they intend to run a server that is a) bound to a non-loopback interface and b) not passworded (but it doesn't actually require someone to set a password). That's a cool feature, but as users don't RTFM, I'm sure they either flip protected mode to false without understanding what it does or just give up on redis and install MongoDB instead. :)
The point here is that pretty much everything you can install on a server is passwordless by default. I don't think the system of someone who never thinks about passwords would last very long at all. This is NOT a MongoDB-specific anomaly. Passwordless is the typical case for most services.
A feature like Redis's protected mode is a nice bonus, but it's not fair to lay responsibility for this at the feet of Mongo or to call it a "vulnerability", as the OP does. The responsibility lies with people who say "I'm going to put all of my company's data in here and push it live without thinking even a tiny bit about security."
Do a lot of people do that? Yes. Should MongoDB take more steps to protect such people from themselves? Maybe. But this is a very basic, very routine thing, which is easy to look up and rectify -- not some obscure anomaly buried under 600 pages of documentation or requiring a special compile-time flag. Mongo doesn't deserve the heat for people who never set up a password.
Earlier quoted context omitted.
I'm no Mongo fan, but that's a false equivalence. You don't need to use Mongo in order to survive.
And having your data stolen is preferable to starving. The point is that, morally: X is bad X being all Y's fault doesn't imply that Y should be unprotected from the consequences of X. We help each other out in this society. So in this case if you're a database developer with a good handle on deployment security, you don't put a insecure-by-default product in the hands of people who aren't. I genuinely can't understa…
Even knifes are sold with some package that prevents them from cutting before the package is removed.
I agree, I don't think your job is done just because you wrote somewhere "pay attention to this".
http://blog.mlab.com/2016/07/mongodb-tips-tricks-collection-...
When our sysadmin set up our Mongo cluster, he firewalled out all IPs except our production systems, turned on authentication, set things up to ensure we used SSL, and configured backups. He didn't do this because he's an amazing sysadmin. He did it because he's competent, knows how to put a service on the Internet, and RTFM. I mean. If you can connect to something and use it without having to authenticate yourself,…
> configured backups. This part seems to be glossed over but is a HUGE issue. It sounds like several companies have tried to pay the ransom with varying levels of success [0] ... why are they not just restoring from backup? I can only assume they don't have backups. (!) What is their DR plan if the server dies? Or someone accidentally pushes code that messes up the contents of the DB? Or someone tries to drop the dev…
I'm obviously not going to defend companies that don't have current backups (though this is practically everyone), and the importance of backups is always a great thing to emphasize, but in this case, the best option is to pay the ransom and get your stuff back.
Earlier quoted context omitted.
By this standard, every programmer who puts an app into production without understanding assembly is not technically sophisticated. We could expect every programmer to have domain knowledge of databases, even when it's not normally needed to operate one. Or we could just make databases not acknowledge writes that haven't happened, not listen on all ports, not hide information about data loss in non-clustered setups d…
at the time these versions of mongodb were released, it was only a few years old, and DID require considerable domain knowledge to run in production. This does not seem unreasonable for new immature technologies. unfortunately, I don't think this was always communicated effectively by the explosion of mongodb marketing and hype.
What do you mean? If you you mean it took knowledge to run per se: it didn't: unzip and run the service, it's up. It wasn't any more complex than any other piece of software.
Or do you mean it did require considerable knowledge to avoid data loss on software marked as 'stable'? Yes, that's the problem, and yes, that's unreasonable.