Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

blog.newsblur.com

Post reply on HN
Print view View original

61–70 of 117 posts

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#61

Post by SahAssar »

cinbun8 wrote: post #4

Nice read. It might be a good idea to also lock a user account after N failed password attempts. Mongo does not seem to support that off the shelf - https://www.mongodb.com/community/forums/t/limit-failed-logi... Neither do other databases like PG, curiously enough. The recommendation seems to be to link to LDAP or use authentication hooks. Or perhaps use client and server certificates for increased security - https:…

How does locking a account after failed attempts to access it make sense? By failing to access the account I have proved nothing besides that I know a username (which is usually not secret).

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#62

Post by convolvatron »

bornfreddy wrote: post #42
chrismeller wrote: post #33

This is why you shouldn't be using Docker in production. It's a great tool, but it's simply not designed for that kind of environment. Edit: note I said Docker specifically, nothing about containerization.

I respectfully disagree. It solves a huge problem - reproducible app environment. It comes with its share of footguns too (hint: always explicitly specify pool of IP addresses it can use!), yes, but what doesn't?

its probably not impossible to do this without the footguns

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#63

Post by nickstinemates »

Badumtss8 wrote: post #47
nickstinemates wrote: post #29

Earlier quoted context omitted.

Use `docker network` or the equivalent in the docker-compose file. Not taking time to think about how the software works is not the fault of the software.

nginx listens on port 80. Accessible from machine. Inaccessible from outside unless allowed by ufw. docker listens on port X. Accessible on machine. Also accessible from outside regardless of ufw. No amount of time and experience will make you think that configuring a software to listen on a port will automagically poke a hole in the firewall.

The scope of Docker and nginx are incomparable, so the comparison is wrong.

It starts with the simple truth: `docker` doesn't `listen` on any port.

Or maybe a simple question: How can I run `docker run -p 8080 nginx` over and over without port conflict?

Or - lets expand scope even more. How is docker supposed to know about your choice of firewall? What about upstream firewalls? What about multiple versions of firewalls on a host (ufw vs. fern vs.)?

Can go on and on..

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#64

Post by cm2187 »

Temporary_31337 wrote: post #28
jacquesm wrote: post #9

It's a pity that the chances of nailing the perps is so low. Obviously docker and the person that put this together share some of the blame but: the original internet would have never gotten off the ground if it wasn't for people cooperating with each other rather than to try to tear things down all the time. And with the chances of your average script kiddie/hacker/idiot getting caught being lower than a typical bik…

If we accept that this is the default state of the Internet (insecure) then I think it is a correct assumption and forces everyone to think twice before exposing anything to the Internet by default. Here the default Docker behaviour was very much at fault but also the assumption that a Linux level firewall is good for Docker. We have docker deployments that are completely hidden behind NAT in AWS and such things are…

I am also puzzled that a firewall rule would be the only thing protecting user data. If any machine behind your NAT gets compromised then it is open buffet to the attackers (in addition to a misconfigured NAT like in this example). It is a bit shocking that it is 2023 and people are still doing that.

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#65

Post by nickstinemates »

convolvatron wrote: post #55
nickstinemates wrote: post #25

Earlier quoted context omitted.

> Who that wise guy in Docket team who decided to pass default firewall rules and open containers ports to public? This is pure ignorance and slandering the Docker team for it seems weird.

thats a really weird take. the whole point of developing and using infrastructure projects like docker is to package up best practices and let other people leverage them without becoming experts themselves. maybe its fair to say that we shouldn't attempt to find an individual to blame. but that doesn't mean docker as an organization didnt screw up here

So in this case the best practice is to make UFW a dependency and delegate all routing to it?

And if I don't want to use UFW or I am on a distro with another firewall, let alone an upstream firewall or other solution, tough luck?

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#66

Post by chrismeller »

Kwpolska wrote: post #52
wkdneidbwf wrote: post #41

Earlier quoted context omitted.

what. docker isn’t the problem here. dbs on public subnets, and the lack of monitoring for accidental db exposure are the actual issues here.

And running a database without authentication.

True, but even the author covered that. No one has mentioned Docker.

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#67

Post by nickstinemates »

yjftsjthsd-h wrote: post #51
nickstinemates wrote: post #25

Earlier quoted context omitted.

> Who that wise guy in Docket team who decided to pass default firewall rules and open containers ports to public? This is pure ignorance and slandering the Docker team for it seems weird.

What's ignorant about it? Or wrong, for that matter, since it can't be "slander" if it's true. Docker does bypass default firewall rules and expose container ports to the public. If I run anything else on a server (apache2, say), and tell it to bind to 0.0.0.0:80, it doesn't matter, because the firewall will block it. If I tell a docker container to bind to 0.0.0.0:80, it magically skips over any other protections an…

How is it that you can spawn many containers and have them all bind to `0.0.0.0:80` in your example?

Try doing the same with Apache2. Multiple instances listening on Port 80.

This is the difference, and the source of ignorance.

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#68

Post by luckylion »

yjftsjthsd-h wrote: post #54
wkdneidbwf wrote: post #41

Earlier quoted context omitted.

what. docker isn’t the problem here. dbs on public subnets, and the lack of monitoring for accidental db exposure are the actual issues here.

> docker isn’t the problem here I mean... if they weren't using docker it would have been fine, but because they used docker it wasn't fine. That reads like docker is the problem. That further layers could have mitigated it doesn't make docker not the problem.

If they had understood how docker works, it would've been fine, too. But because they didn't and used a software firewall as their only line of defense and didn't bother with authentication for the DB server, it wasn't fine.

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#69

Post by nickstinemates »

andybak wrote: post #48
nickstinemates wrote: post #29

Earlier quoted context omitted.

Use `docker network` or the equivalent in the docker-compose file. Not taking time to think about how the software works is not the fault of the software.

If everyone designed software like you are advocating then we'd be even worse off. What's wrong with "users should be careful" and "software shouldn't contain footguns"?

I disagree with the premise that in this instance there is a footgun. There isn't.

Re: A Docker footgun led to a vandal deleting NewsBlur's MongoDB database (2021)

#70

Post by bob1029 »

Looking at their self-reported realtime stats makes me wonder why this architecture. The current numbers imply peak database request rates in the hundreds/second.

This appears to me like another case where we could have built a simple, 1-process vertical on a single box and called it a day.

Post reply on HN