5 ms·

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

• dawnerd 6y ago
  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.
  • usmannk 6y ago
    Isn’t exposing ports in your docker-compose services:redis:ports, how you’d do that? (Docker hobbyist here)
    • jcrawfordor 6y ago
      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.
      • gerdesj 6y ago
        "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.
        • acdha 6y ago
          Use Shodan.io’s monitor feature and you’ll get alerting, too.
      • gavinray 6y ago
        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 https://docs.docker.com/engine/reference/builder/#expose
        • jcrawfordor 6y ago
          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.
          • gavinray 6y ago
            Ah, my mistake. That comes off pretty asinine then, apologies.
  • umvi 6y ago
    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?
    • snorrah 6y ago
      Yes, so that you always keep security in mind.
      • umvi 6y ago
        And what if the thing I'm building isn't intended for the public internet?
        • tremon 6y ago
          Then why are you building it on the public internet?
          • umvi 6y ago
            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.
    • ObsoleteNerd 6y ago
      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.
      • umvi 6y ago
        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.
• jwr 6y ago
  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.
• nisa 6y ago
  link for the missing DOCKER-USER chain: https://github.com/docker/for-linux/issues/810 https://github.com/docker/for-linux/issues/810 - so if you are unlucky you are one apt upgrade away from data theft...
• temptemptemp111 6y ago
  Of interest: https://github.com/chaifeng/ufw-docker https://github.com/chaifeng/ufw-docker
• LdSGSgvupDV 6y ago
  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.