A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
1–10 of 275 posts
Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
#2[deleted]
Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
#3Were you using Docker raw? No orchestration? If so what's the advantage to dockerizing your data stores
Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
#4The mistake here is a MongoDB that didn't require authentication, not that docker's clunky iptables setup exposed it to the internet.
Relying solely on a host-based firewall for access control is, for reasons which must now be obvious, admin incompetence.
They are responsible for securing the containers. They didn't.
Your services should be using authentication even if they are only bound to localhost.
Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
#5The mistake here is a MongoDB that didn't require authentication, not that docker's clunky iptables setup exposed it to the internet. Relying solely on a host-based firewall for access control is, for reasons which must now be obvious, admin incompetence. They are responsible for securing the containers. They didn't. Your services should be using authentication even if they are only bound to localhost.
> The mistake here is a MongoDB that didn't require authentication, not that docker's clunky iptables setup exposed it to the internet.
If you're backing up diligently, have a problem, go to restore backup, and discover that the backups are unusable due to an issue caused by the backup software's default configuration, you could say "the mistake here is you relying on a single backup system, pardner, not the backup software's bad default configuration," and in the sense that it's good advice to have multiple backup strategies, sure, you're technically correct. But that doesn't excuse the backup software from having a dangerously bad default configuration. That would be relatively trivial to fix. That they've apparently known about for years.
Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
#6The mistake here is a MongoDB that didn't require authentication, not that docker's clunky iptables setup exposed it to the internet. Relying solely on a host-based firewall for access control is, for reasons which must now be obvious, admin incompetence. They are responsible for securing the containers. They didn't. Your services should be using authentication even if they are only bound to localhost.
Yea. Why blame softwares (with multiple user filed bugs) when you can blame the user (again)?
Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
#7The mistake here is a MongoDB that didn't require authentication, not that docker's clunky iptables setup exposed it to the internet. Relying solely on a host-based firewall for access control is, for reasons which must now be obvious, admin incompetence. They are responsible for securing the containers. They didn't. Your services should be using authentication even if they are only bound to localhost.
The docker issue and original HN thread have countless instances of folks who have hit and been hacked by the exact same issue. There is clearly a major problem with the docker documentation, usage, etc. that is causing people to continually be taken by surprise with its iptables behavior.
The blame game doesn't help solve the real problem that people are unknowingly putting services directly on the public internet when they think they are secured by a firewall. With how many millions of people use docker every day IMHO the severity of this issue is far too great to ignore. A simple mitigation to fail and warn a user when it appears they might be hitting this issue (i.e. before docker run changes iptables config, give a quick look to see if it looks like it's already configured for the most common ufw or other setup) would stop this from happening for 99% of cases.
Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
#8The mistake here is a MongoDB that didn't require authentication, not that docker's clunky iptables setup exposed it to the internet. Relying solely on a host-based firewall for access control is, for reasons which must now be obvious, admin incompetence. They are responsible for securing the containers. They didn't. Your services should be using authentication even if they are only bound to localhost.
I don't know why this is being downvoted. Multiple overlapping layers of security would have given newsblur a backup in case of accidental "footguns".
Unauthenticated mongodb instances are a pretty common problem - it's why a "script kiddie" was so successful.
Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
#9It's not all that great blaming the victim. They clearly made the right moves with at least some of their configuration decisions and leaned on the underlying platform not being bonkers (but alas, it was: https://github.com/moby/moby/issues/4737 and https://github.com/moby/moby/issues/22054).
Should they have hardened in all the other ways for defense in depth, e.g requiring authentication from localhost? Sure. Should the attacker have not done the attack? Without a doubt. But should docker have not completely undone a security control?
Yes, and the fact that docker seems to have persisted with the current state is the topic of discussion.
Previously: https://news.ycombinator.com/item?id=27613217
Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database
#10The mistake here is a MongoDB that didn't require authentication, not that docker's clunky iptables setup exposed it to the internet. Relying solely on a host-based firewall for access control is, for reasons which must now be obvious, admin incompetence. They are responsible for securing the containers. They didn't. Your services should be using authentication even if they are only bound to localhost.
I don't know why this is being downvoted. Multiple overlapping layers of security would have given newsblur a backup in case of accidental "footguns". Unauthenticated mongodb instances are a pretty common problem - it's why a "script kiddie" was so successful.
A simple runtime check by docker to detect the most common configuration issue (ufw enabled for a service port that's about to be run by a container) is just another layer of protection to add to the stack IMHO. How can it hurt?