6 ms·

Absolutely ridiculous that MongoDB is this insecure by default.

peterwwillis 10y ago
You expected a database sitting on the public internet to be secure? A very young one, no less? Who is downvoting this? People who hate common sense?
- abiox 10y ago
  i can't downvote, but your question seemed like a nonsequitur.
- jasondc 10y ago
  +1 Ideally, databases should never have internet access
  - monksy 10y ago
    Tell that to frontend javascript devs who think they don't need a back end system. Without a public facing DB they're pretty much dead in the water.
    - bartread 10y ago
      The more things change, the more they stay the same. I'm thinking of people who back in the 90s/early noughties didn't want to bother with a middle tier application, and instead talk directly to the database from their fat clients(1) because it was easier. (1) This, btw, is what many SPA are: fat client apps running within a browser. When I came back to web development four years ago one of the biggest surprises was how much like desktop development it had become in many ways.
  - cm2187 10y ago
    If you are using one of the main cloud provider, the database they provide will almost always do. For azure at least, they protect it with a firewall that block all IPs by default. But a database with no internet access is unrealistic.
- ivanhoe 10y ago
  How about expecting that DB doesn't bind to 0.0.0.0 by default and to force passwords to be set during the installation? Is that such an unreasonable thing to expect?
  - peterwwillis 10y ago
    Yes. Expecting anything to be secure by default is unreasonable. It would be nice, but I would not just expect it, I would confirm it. Expecting it to be secure on the internet is even less reasonable.
    - ivanhoe 10y ago
      I'm not talking about it being "secure by default". Just not being obviously insecure by default is more than enough...
raverbashing 10y ago
"Recent" versions aren't. If you install .rpm/.deb versions you're also covered (And anyone who deploys any service on an internet-facing server should know what they're doing) See https://blog.shodan.io/its-the-data-stupid/ https://blog.shodan.io/its-the-data-stupid/
- jlgaddis 10y ago
  > (And anyone who deploys any service on an internet-facing server should know what they're doing) I agree that they should. History has shown us, however, that they very often don't.
Cozumel 10y ago
If people RTFM it would never have been an issue.
- beambot 10y ago
  Defaults matter. Been shown time & time again... and not just for computers (look at organ donation!).
- lawn 10y ago
  If people constantly misuse the design, the people isn't to blame but the design itself.
- homakov 10y ago
  No they shouldn't, that's not how secure engineering works.
threeseed 10y ago
This is Hacker News not Fox News. At least be intellectually honest. It's not insecure by default. It just binds to all interfaces. Apache and Nginx both do this and we don't consider them to be insecure. Should a database be doing this ? That's debatable since it's a tradeoff between security and ease of use. But that said if you are running an internet facing server without a firewall then you will have bigger problems than just your database.
- e12e 10y ago
  I've always thought that the biggest service openbsd did, was teach people to remove unneeded stuff and turn off unused services. Remember when people used to sneer that X years without remote root in the default install was no wonder, because the Base install didn't do anything useful? I also don't get this "firewall" idea. Why make something listen for everything, and then place a system outside to restrict it? Why not just whitelist what you want to listen to in the first place? Note, I get that binding an application to localhost and then letting a dedicated proxy do the heavy lifting to link up with other systems (eg stunnel or haproxy) - but what does packet level filtering really gain you? In general I see firewalls as just adding complexity - one more source of bugs and potential mis-configuration. (Say the fun when ipv6 exposes the soft inner network that everyone thought was "firewalled" when in fact it just had broken connectivity due to chappy NAT borne from scarcity of routable addresses).
  - vacri 10y ago
    If you don't necessarily know what's going to be running on a machine, a firewall gives you control over what's allowed in or out. If a lazy dev installs some tool that listens to everything on a machine that's on the internet, a firewall will protect you from their laziness. In an ideal world, everyone would care about this stuff (and have time to properly set these things), but we're not in an ideal world.
    - e12e 10y ago
      Right. I would rather fix the broken developer once, than paper over systems with a firewall. Perhaps I'm too idealistic. (IMHO proper devops does this - helps give devs a proper view of system administration by sharing knowledge and responsibilities). I'm also pessimistic enough that I think allowing development to install back doors (eh, "useful helper daemons") willy-nilly in production systems is a bad idea ;-)
liveoneggs 10y ago
insecure defaults are a key driver for increased adoption! It's worked for, at least: mongodb, redis, jboss, and elasticsearch

You expected a database sitting on the public internet to be secure? A very young one, no less? Who is downvoting this? People who hate common sense?

abiox 10y ago
i can't downvote, but your question seemed like a nonsequitur.
jasondc 10y ago
+1 Ideally, databases should never have internet access
- monksy 10y ago
  Tell that to frontend javascript devs who think they don't need a back end system. Without a public facing DB they're pretty much dead in the water.
  - bartread 10y ago
    The more things change, the more they stay the same. I'm thinking of people who back in the 90s/early noughties didn't want to bother with a middle tier application, and instead talk directly to the database from their fat clients(1) because it was easier. (1) This, btw, is what many SPA are: fat client apps running within a browser. When I came back to web development four years ago one of the biggest surprises was how much like desktop development it had become in many ways.
- cm2187 10y ago
  If you are using one of the main cloud provider, the database they provide will almost always do. For azure at least, they protect it with a firewall that block all IPs by default. But a database with no internet access is unrealistic.
ivanhoe 10y ago
How about expecting that DB doesn't bind to 0.0.0.0 by default and to force passwords to be set during the installation? Is that such an unreasonable thing to expect?
- peterwwillis 10y ago
  Yes. Expecting anything to be secure by default is unreasonable. It would be nice, but I would not just expect it, I would confirm it. Expecting it to be secure on the internet is even less reasonable.
  - ivanhoe 10y ago
    I'm not talking about it being "secure by default". Just not being obviously insecure by default is more than enough...

raverbashing 10y ago

"Recent" versions aren't. If you install .rpm/.deb versions you're also covered (And anyone who deploys any service on an internet-facing server should know what they're doing) See https://blog.shodan.io/its-the-data-stupid/ https://blog.shodan.io/its-the-data-stupid/

jlgaddis 10y ago
> (And anyone who deploys any service on an internet-facing server should know what they're doing) I agree that they should. History has shown us, however, that they very often don't.

Cozumel 10y ago

If people RTFM it would never have been an issue.

beambot 10y ago
Defaults matter. Been shown time & time again... and not just for computers (look at organ donation!).
lawn 10y ago
If people constantly misuse the design, the people isn't to blame but the design itself.
homakov 10y ago
No they shouldn't, that's not how secure engineering works.

threeseed 10y ago

This is Hacker News not Fox News. At least be intellectually honest. It's not insecure by default. It just binds to all interfaces. Apache and Nginx both do this and we don't consider them to be insecure. Should a database be doing this ? That's debatable since it's a tradeoff between security and ease of use. But that said if you are running an internet facing server without a firewall then you will have bigger problems than just your database.

e12e 10y ago
I've always thought that the biggest service openbsd did, was teach people to remove unneeded stuff and turn off unused services. Remember when people used to sneer that X years without remote root in the default install was no wonder, because the Base install didn't do anything useful? I also don't get this "firewall" idea. Why make something listen for everything, and then place a system outside to restrict it? Why not just whitelist what you want to listen to in the first place? Note, I get that binding an application to localhost and then letting a dedicated proxy do the heavy lifting to link up with other systems (eg stunnel or haproxy) - but what does packet level filtering really gain you? In general I see firewalls as just adding complexity - one more source of bugs and potential mis-configuration. (Say the fun when ipv6 exposes the soft inner network that everyone thought was "firewalled" when in fact it just had broken connectivity due to chappy NAT borne from scarcity of routable addresses).
- vacri 10y ago
  If you don't necessarily know what's going to be running on a machine, a firewall gives you control over what's allowed in or out. If a lazy dev installs some tool that listens to everything on a machine that's on the internet, a firewall will protect you from their laziness. In an ideal world, everyone would care about this stuff (and have time to properly set these things), but we're not in an ideal world.
  - e12e 10y ago
    Right. I would rather fix the broken developer once, than paper over systems with a firewall. Perhaps I'm too idealistic. (IMHO proper devops does this - helps give devs a proper view of system administration by sharing knowledge and responsibilities). I'm also pessimistic enough that I think allowing development to install back doors (eh, "useful helper daemons") willy-nilly in production systems is a bad idea ;-)

liveoneggs 10y ago

insecure defaults are a key driver for increased adoption! It's worked for, at least: mongodb, redis, jboss, and elasticsearch