11–20 of 275 posts
Were you using Docker raw? No orchestration? If so what's the advantage to dockerizing your data stores
The 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 w…
Everyone knows docker runs as root, and therefore be careful using it, just as you would sudo. It seems this is a major fail in docs.
I kinda get why it's the default, but it needs to be made way better known that by default -p punches a hole through ufw.
Wait... people run their databases on public IPs?
The 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.
Security specialist here. Startups are built by generalists. Good decisions were made here which made other defense-in-depth considerations not as critical when reconciled with go-to-market needs.
If every generalist focused on every security risk in their product, they'd expose themselves to the business risk of not moving quickly enough.
It's pretty clear NewsBlur did what they could and relied on the expertise of others to not fail them in exceptionally basic, entirely avoidable ways. They were betrayed by that reliance.
The 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.
It can be both.
It'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. Shou…
I was running what I thought was an internal FTP instance for almost a week. Luckily it was about as hardened as regular ftp can be, but I noticed the problem when my service wasn't able to log in as the (very low) connection limit was filled by someone attempting passwords.
I've been using https://github.com/shinebayar-g/ufw-docker-automated to make docker compliant with ufw, and defining firewall rules as labels for the containers. It needs some work still, namely the service should be hosted in it's own container for easier updating, but it works reasonably well.