4 ms·

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 VL

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).

cpuguy83 10y ago
This is a really bad practice to follow. You can't rely on the network to be secure.
- hueving 10y ago
  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).
Cozumel 10y ago
This problem was caused by broken 'thinking' like that.
raverbashing 10y ago
> In production deployments, unsecured remote connections might be fine No. Absolutely not Unsecured local connections yes, anything from outside 127.0.0.1 should be explicitly allowed and secured (like port 80/443). Rate-limited, fail2banned, fuzzed during testing, etc
- Pxtl 10y ago
  "I opened the ports on the firewall and gave the user access, why doesn't it work!? This system is stupid." "I changed my password on one system and then on the other, but somehow my account got locked up in that brief time between changeover, how the hell do you unlock an account? This system is stupid." "We're scaling up and we're running into outdated rate-limiting settings on every service we use, some of them even having multiple layers of rate-limiting within a single service, and each setting requires hours of debugging to figure out which setting is taking down the whole project. This system is stupid." There's a reason Mongo got adoption while "secure" systems did not.
  - raverbashing 10y ago
    To be honest, the issue is that a lot of secure systems make things more convoluted, unintuitive and/or frustrating than it needs to be, then calls the user stupid when they can't set it up
- extrapickles 10y ago
  I agree. You always want to have at least two mistakes between you and getting harmed (more if you are handling anything valuable). If you only have a VLAN separating you from harm, it only takes 1 bad switch configuration or any other device on the VLAN to accidentally be running a proxy or router.
  - richardwhiuk 10y ago
    A firewall, and a VLAN configuration. If you are allowing white listed access through your frontend firewall, then you need to screw up both.
hinkley 10y ago
Before VMs and the cloud you'd buy a server with three or more network cards in it and you ended up with physically separate networks just because you could and it staved off network saturation. That it simplified your security architecture was the cherry on top. But Mongo pretty much rejected that world view (web scale!) so it's a little odd that they designed a system that only works in it.
aclsid 10y ago
But why bother though? If somehow that network defense comes down because of maintenance or whatnot, you have just tainted your most precious asset out of wanting to save a couple of minutes for securing the connection.

cpuguy83 10y ago

This is a really bad practice to follow. You can't rely on the network to be secure.

hueving 10y ago
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).

Cozumel 10y ago

This problem was caused by broken 'thinking' like that.

raverbashing 10y ago

> In production deployments, unsecured remote connections might be fine No. Absolutely not Unsecured local connections yes, anything from outside 127.0.0.1 should be explicitly allowed and secured (like port 80/443). Rate-limited, fail2banned, fuzzed during testing, etc

Pxtl 10y ago
"I opened the ports on the firewall and gave the user access, why doesn't it work!? This system is stupid." "I changed my password on one system and then on the other, but somehow my account got locked up in that brief time between changeover, how the hell do you unlock an account? This system is stupid." "We're scaling up and we're running into outdated rate-limiting settings on every service we use, some of them even having multiple layers of rate-limiting within a single service, and each setting requires hours of debugging to figure out which setting is taking down the whole project. This system is stupid." There's a reason Mongo got adoption while "secure" systems did not.
- raverbashing 10y ago
  To be honest, the issue is that a lot of secure systems make things more convoluted, unintuitive and/or frustrating than it needs to be, then calls the user stupid when they can't set it up
extrapickles 10y ago
I agree. You always want to have at least two mistakes between you and getting harmed (more if you are handling anything valuable). If you only have a VLAN separating you from harm, it only takes 1 bad switch configuration or any other device on the VLAN to accidentally be running a proxy or router.
- richardwhiuk 10y ago
  A firewall, and a VLAN configuration. If you are allowing white listed access through your frontend firewall, then you need to screw up both.

hinkley 10y ago

Before VMs and the cloud you'd buy a server with three or more network cards in it and you ended up with physically separate networks just because you could and it staved off network saturation. That it simplified your security architecture was the cherry on top. But Mongo pretty much rejected that world view (web scale!) so it's a little odd that they designed a system that only works in it.

aclsid 10y ago

But why bother though? If somehow that network defense comes down because of maintenance or whatnot, you have just tainted your most precious asset out of wanting to save a couple of minutes for securing the connection.