Hacker News Reader

Comment by nisa | Hacker News Reader

It's also easy to get bitten by Docker. You can secure your server with iptables/ufw only to discover that docker happily punches through your firewall and you need to filter on the DOCKER-USER chain - and even that was broken: https://unrouted.io/2017/08/15/docker-firewall/ https://github.com/docker/for-linux/issues/690

View on HN

Seriously this is the most annoying thing ever, especially if someone on your team things you need to expose the ports to redis in a docker compose. I’ve come back from a weekend where my redis instance was being used for crypto mining.

Anything that is insecure by default in 2020 should be killed off IMO.

Isn’t exposing ports in your docker-compose services:redis:ports, how you’d do that? (Docker hobbyist here)

My guess would be that they went with "ports" instead of "expose" which makes it public. But even with careful composition of your docker-compose you might want to be careful, Docker can interact with iptables in surprising ways and long iptables rulesets are almost comically difficult to validate sometimes. The result is that if you're using both Docker (and even more if you use Compose, Kubernetes, some other orchestrator) and doing anything else with iptables (including using it as a host firewall) you need to take a lot of caution to make sure you don't mess anything up. These tools usually confine their changes to custom chains to make this stuff easier to sort out but at the same time it can make it more difficult to understand what's happening, particularly with the use of tagging and etc.

In general I would recommend putting some kind of protection between machines running Docker (and especially orchestrators) and the internet. This could be cloud provider mechanisms (security groups, ACLs, etc), a firewall appliance, NAT gateway configuration, etc. depending on the situation. It's not necessary, but it makes the situation easier to audit/validate, and more layers of protection seldom hurt. If nothing else it means that much of the time you'll need to make a mistake in two places instead of one, in order to have an unintended exposure.

"and long iptables rulesets are almost comically difficult to validate sometimes."

Use nmap to evaluate your policy from the outside, don't try to validate it in your head by inspection.

Use Shodan.io’s monitor feature and you’ll get alerting, too.

Friendly FYI, "EXPOSE" is a no-op that is only meant as visual documentation to end-users.

  "The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published."

Second paragraph:

https://docs.docker.com/engine/reference/builder/#expose

I'm referring to docker-compose, where 'port' and 'expose' are container configuration options that behave differently from the Dockerfile keyword.

Although the similar words with different meanings no doubt contribute to confusion.

Ah, my mistake. That comes off pretty asinine then, apologies.

Secure by default is super onerous though. What if I just want to try out something before committing to it, do I really need to jump through a bunch of security hoops?

Yes, so that you always keep security in mind.

And what if the thing I'm building isn't intended for the public internet?

Then why are you building it on the public internet?

I'm not. I'm just using flask/mongodb/whatever for some internal app. But if it's secure by default I need to jump through a bunch of hoops to secure something that won't even be on the public internet.

Absolutely. Laziness isn't an excuse for not caring about security. Security should be the top of your mind any time you connect anything to the internet.

The fact it's not, is why we're seeing major attacks/leaks/etc almost every single day now.

Right, well now we know why secure by default isn't a thing. If your product is super onerous to use, people will switch to a competitor that is easier to work with.

A secure by default product is a dead on arrival product.

Of course you don't need to waste time setting up security properly. And it's such a pain locking and unlocking your car and your house every time you go in and out too. Tell me, where do you live again?

I'm 58 and bald, so channeling yoda is easy: a valuable lesson you need to learn, and learn it the cheap way or the expensive way you can.

The cheap way is to invest in a cheap VPS for a month, fire up sshd and a webserver, and then check the logs when the month is up.

The expensive way is to carry on treating security as an afterthought. It'll cost you your pride, your reputation, and possibly your career.

Then you just pass the `--disable-all-security` flag. (Or whatever similar method the project you're using exposes to allow that.) Secure-by-default doesn't have to be complicated; it's just a way to ensure people don't shoot themselves in the foot without comprehending what they're doing.

Exactly. Do people complain about how hard it is to spin up mysql or postgres?

Thank you for this reply; it's my favorite post in the entire discussion. It illustrates perfectly why insecure defaults are a terrible way to implement "tutorial mode".

Yes, this is terrible, and when I discovered this, I was appalled how it seemed no one was taking this seriously.

When you use ufw with a default DENY policy, you tend to assume that whatever isn't explicitly listed gets DENIED. This is not the case with Docker, and I think it's just a matter of time until someone loses big because of this issue.

I have encountered this firewall problem (deploy service locally by docker). In that time, I managed to manually set iptable to solve the problem.

But, after some search, I found that simply setting "network_mode" to "host" could solve my problem. So, I ended up not to deal with iptable.

If someone want to deploy some self-hosted service, I would suggest using traefik v2. Outfit docker quite well especially with letsencrypt.

link for the missing DOCKER-USER chain: https://github.com/docker/for-linux/issues/810 - so if you are unlucky you are one apt upgrade away from data theft...

Reply on news.ycombinator.com