Earlier quoted context omitted.
What does this have to do with Javascript?
MongoDB is written in Javascript.
That's ridiculously incorrect.
The MongoDB hack and the importance of secure defaults
81–90 of 223 posts
Re: The MongoDB hack and the importance of secure defaults
#82Earlier quoted context omitted.
At a guess, it became popular through easy setup. That includes not having to configure login. That's why so many other systems are insecure. Security nearly always increases friction.
In other disciplines they call this pandering. I'll never know why some of us see it as virtue.
It's easy to see why having a lot of users is desirable.
Re: The MongoDB hack and the importance of secure defaults
#83Earlier quoted context omitted.
In production deployments, unsecured remote connections might be fine, because security would be handled at the network layer (e.g. by deploying MongoDB on a VLAN which only was accessible by your MongoDB clients which were on separate servers).
This is a really bad practice to follow. You can't rely on the network to be secure.
That's true in many cases, but if the network is solely for database access and the only servers with access to it would be configured with DB credentials anyway, then the path to compromise is equivalent (get into a server with db credentials/network access).
Re: The MongoDB hack and the importance of secure defaults
#84No matter what your defaults are, if a sysadmin doesn't understand that some software is OK to connect to a public-internet addressable interface while other software is not, their shit is going to get hacked (or, as in this case, accessed). This is the equivalent of leaving your data in a file cabinet in your lobby and being surprised someone took it. The answer isn't to add self-locking little office locks to the f…
Network oriented software created after 2000 has zero excuse for allowing unauthenticated writes from the general internet by default.
Tell that to redis.
No, seriously. Please. I've been banging that drum for years.
Re: The MongoDB hack and the importance of secure defaults
#85No matter what your defaults are, if a sysadmin doesn't understand that some software is OK to connect to a public-internet addressable interface while other software is not, their shit is going to get hacked (or, as in this case, accessed). This is the equivalent of leaving your data in a file cabinet in your lobby and being surprised someone took it. The answer isn't to add self-locking little office locks to the f…
No, it's the equivalent of selling a car that doesn't require the key to be present to start by default.
If the software is insecure out of the box, that's crap vendor behavior.
Re: The MongoDB hack and the importance of secure defaults
#86Earlier quoted context omitted.
We usually can't see the same problems happening in front of our noses. Why shouldn't we discuss why docker images run as root by default then?
I think we absolutely should discuss this - the number of images I see on Docker Hub that run complex network services as the root user really concerns me. The security measures implemented by Docker reduce the risk but absolutely do not eliminate it, you're taking a big risk there. This issue, along with its related issues with permissions on persistent storage, is one of the major reasons I'm hoping to move away fr…
What Docker security measures do you mean? Actually, I was wondering recently what isolation Docker provides that a basic chroot-jail doesn't.
Re root permisions I guess if you're running a typical network daemon (Apache, say), then requiring Docker to run as root is no worse than running the service on the host; root would be a requisite anyway for the daemon to open privileged ports/gain logging permissions etc. before dropping to "nobody" or what have you.
Re: The MongoDB hack and the importance of secure defaults
#87No matter what your defaults are, if a sysadmin doesn't understand that some software is OK to connect to a public-internet addressable interface while other software is not, their shit is going to get hacked (or, as in this case, accessed). This is the equivalent of leaving your data in a file cabinet in your lobby and being surprised someone took it. The answer isn't to add self-locking little office locks to the f…
No, it's the equivalent of selling a car that doesn't require the key to be present to start by default. If the software is insecure out of the box, that's crap vendor behavior.
I think it is more like the equivalent of a refrigerator without a lock. You aren't supposed to keep a refrigerator outside your locked home. You can and do see people fit refrigerators with locks for that purpose, but when you do that there are tons of other things you will need to do, and I don't think it is optimal for the refrigerator people to try to solve them. (That said, as the issue here is "localhost or 0.0.0.0", I don't think keys or locks are good analogies: more like, when they come and install your refrigerator, they should probably install it inside, as that's the place it should be used, but surprisingly if you don't tell them this ahead of time they install it outside, so you can get access to it more quickly from your car, which is insane.)
Re: The MongoDB hack and the importance of secure defaults
#88When 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, wouldn't it naturally cross your mind to check that others can't do the same? It's just common sense.
Re: The MongoDB hack and the importance of secure defaults
#89Earlier quoted context omitted.
This is not unique to MongoDB however Elasticsearch is similar. The line they seem to tow is "this is made to be run behind a firewall." I agree its unacceptable but its unfortunately not unique to MongoDB.
That's not a fair comparison. ElasticSearch doesn't have authentication in the free edition. You gotta pay to get the authentication plugin. ElasticSearch => Dropped authentication (i.e. an important aspect for security) to get a chance at monetization. MongoDB => Dropped everything, including your data. YOLO!
Elasticsearch never had authentication. So they never dropped it from the free version. I feel like it is an appropriate comparison. The general response to Elasticsearch's lack of security was "your'e supposed to run it behind a firewall"
Elasticsearch got all the way to version 1.4 with no authentication as part of the design. Between 1.4.1 and 1.5 release candidates is when they announced Shield as part of their enterprise offering.
Here are the release dates and announcements:
https://www.elastic.co/blog/shield-know-security-coming-soon
Re: The MongoDB hack and the importance of secure defaults
#90I don't mean to defend Mongo here, but as a counter argument to the broad principle: Ubuntu doesn't ship with iptables blocking all incoming connections by default. Should it?
Yes.