[Twirrim]

Historically, MongoDB was unauthenticated and insecure by default. Because that's always a good idea.

You should never assume anyone is going to use your product in a secure fashion, and make it so that they have to at least make _some_ effort towards security.

Other than that, writing new features is fun, and you can get so many developers (that don't think about security) for the same amount of money as a good security professional, or a developer with even half an ounce of security sense, commands.

Security is always inconvenient, takes extra effort, and is invisible. So many companies and managers deprioritise it over more visible feature work, forgetting that security in and of itself IS a feature.

[jdsully]

A lot of databases have this weird idea that there is some secure "internal network" and its OK to just pretend its 1995 in there. Antirez actively blogs about how "insecure" Redis is but its OK because just don't put it on the internet [1]. Others just avoid the subject completely. Never mind that internal networks get infiltrated all the time.

Security in depth is just not a thing a lot of people think about right now.

[1] http://antirez.com/news/96

[jchw]

Okay, let's be fair, and I'm sure you realize this: having network ACLs that prevent unauthorized access is absolutely a good idea. "Internal networks" are not dead - they've become more advanced with "VPC" services and software defined networking.

Tunnelling Redis protocol over mutual TLS or something like that sounds like a good idea, but I don't think I've seen anyone doing that :(

Frankly, I would love it if there were a simple, open standard for authentication so every database didn't have to redo it. Maybe mutual TLS is that answer, though traditionally getting the infrastructure for that correct has been difficult.

[viraptor]

> I would love it if there were a simple, open standard for authentication so every database didn't have to redo it

There is: https://en.wikipedia.org/wiki/Simple_Authentication_and_Secu...

[jchw]

I've only ever seen it used with IRC but this most certainly is the closest thing. Guess I hope for more adoption in the future.

[X-Istence]

SASL is also used with Dovecot/Postfix for example.

[jdsully]

Because if you make any mistake at all Redis will allow you shell access to the machine. This is not a theoretical attack Antirez tells you how to do it in his blog post.

And as you said, nobody bothers to tunnel with TLS. Your lucky if they even use a password.

[jchw]

Yeah exactly; which is why ideally, the container or box running Redis:

- Has practically nothing other than Redis on it.

- Has Redis running with minimal permissions and capabilities.

- Has no ability to make outgoing connections.

Which I'd say is vital security practice for anything running in production.

Few people will bother with TLS and you can see that based on the fact that I don't think cloud providers generally support it, but I personally did do this with stunnel at a time. Apparently Redis now recommends spiped, which looks good to me.

[drdaeman]

What's weird about having an isolated network and leaving access controls to a separate layer?

I think the only concern is where the software listens by default. If it's TCP 0.0.0.0/[::] then someone's eventually going to make a mistake.

[stedaniels]

On an isolated network, even the compromise of a low level user/service account of a device/VM/container on that network gives you keys to the kingdom. A layered approach slows down or brings the penetration to a halt allowing time for detection and remediation.

[jchw]

In practice, people using AWS, GCP, Digital Ocean, etc. have options for setting more detailed network ACLs. Kubernetes implements a primitive called Network Policies that can also implement network ACLs, if you are running that.

In my opinion network ACLs are a pretty important part of a modern defense in depth, though you are absolutely right in that these measures are far from a panacea and usually only slow down horizontal movement.