Permissive forwarding rule leads to unintentional exposure of containers (2021)

I know whoever was in charge of configuring Dockers iptables routes should have known this and messed up, but that is fucked up.

Are people just now discovering the FORWARD chain?

Also, if 172.16.0.0/12 is bound to the docker0 interface then the kernel will see packets from IPs in that range that come in on other interfaces as martians and drop them.

2. k8s is not a fad. Nor is it wrapper or really even equivalent with docker the container bit.

That being said, Docker is more than just "Linux containers" or FreeBSD jails; the key thing it brought was the push/pull commands, which made setting up and distributing containers a lot easier, as well as some other UI/UX things. I think these ideas are implemented badly, but they do add value.

Compare this with FreeBSD jails, where the instructions were "download the base set from the FreeBSD ftp and extract it to the destination dir, manually set up /dev, twiddle with /etc/rc.conf, muck about with ifconfig for networking, etc."

Looking at the current handbook[1], things are better now: there's bsdinstall and /etc/jail.conf, but e.g. jail.conf was added only a few months before Docker was released, but the key value proposition of Docker (push/pull) is still missing. Right now, setting up nginx or PostgreSQL in a FreeBSD jail is more work than setting it up system-wide. People don't use Docker because it runs in containers per se, they use it so they can run something in one easy step.

IMHO Docker is more or less the Sendmail of our age[2]; we just have to wait for "Docker Postfix" or "Docker qmail" :-) I'd make a punt, but I don't really have that much time.

[1]: https://docs.freebsd.org/en/books/handbook/jails/#jails-buil...

[2]: People have forgotten now, but Sendmail solved a lot of issues in the early 80s and dealt with the wildgrowth of different email systems better than anything else; while crusty and ugly, it added a lot of value when it was first released.

Sure containers like LXC and bsd-jails existed, but I think the feature that won the hearts of devs was the incremental builds that let people fail quickly in a forgiving way.

With jails, the best I know of achieving this is creating a base jail filesystem (thin jail), and creating a new one. (Apologies in advance if another tool addresses this).

UX alone can be a multi-billion dollar business, for example Dropbox was just a folder that syncs. I'll leave you to find that classic HN comment about it. Docker just executed poorly and didn't have much worth paying for.

Fascinating. I'm admittedly very new to container-land, but my understanding was precisely the opposite - that Docker invented this concept and practice of building a runtime environment that can then be replicated and deployed to many hosts. Do you have any search terms or articles I should pursue to learn more about the predecessors?

I've read through this[0], but it mostly suggests that approaches prior to Docker provided isolation/jailing, which is an important part of containerization but neglects a lot of tooling around building, deploying, etc.

[0] https://blog.aquasec.com/a-brief-history-of-containers-from-...

EDIT: various other comments ("The Docker UX is what made the difference, not the underlying tech. Building containers in an easy incremental and reproducible way that could then be stored in a repo and pulled over HTTP was the evolution in packaging that was needed.", "I think the feature that won the hearts of devs was the incremental builds that let people fail quickly in a forgiving way", "Containers were painful as hell to set up and use; it was like using Git, but worse. Docker made it convenient, simple, and useful. By now everybody understands that immutable artifacts and simple configuration formats are extremely effective") seem to support this perception.

EDIT2: Thanks to all those that replied!

But considering the pride in finding the right incantation to build C/C++ code, to set up a system service, to set up routing rules or any other advanced feature... I guess anything that tries to hide it will count as hype

* The public registry. Obviously, there are a lot of downsides to this with respect to security, but the convenience of "just install docker and then you can run basically anything that has already been uploaded to Docker Hub" can't really be overstated.

* OCI. They were kind of forced into this much later on, but it's great to have a standard for how to package a container image and a bundle that can be loaded into a runtime. Containers may have already existed, but there was not standard way to package, deliver, and run them.

* The Dockerfile. For better or worse, it isn't perfect and is full of footguns, but as the "hello world" equivalent of build systems go, it's pretty easy to get started and understand what it's doing.

* I think, but am not certain, that Docker was the first to combine containers with union filesystems, saving quite a bit of disk space when you're running many containers that share layers. This also helped usher in the era of read-only root filesystems and immutable infrastructure.

It's also important to remember that developers are not the only people involved in delivering and running software. I see a lot of complaining here that containers add friction to their workflow, but look at it from the perspective of systems administrators, IT operators, and SREs that have to install, configure, run, monitor, and troubleshoot potentially hundreds of applications, some internally developed, some third-party, all using whatever language, whatever runtime, and whatever dependency chain they feel like without regard to what the others are doing. Having a standardized way to package, deliver, and run applications that is totally agnostic to anything other than "you need Linux" was pretty powerful.

That it uses containers is just an implementation detail, to me.

All the docker replacements will be useless to me if they don't come with a huge repository of pre-built relatively-trustworthy up-to-date containers for tons of services.

I love no longer needing to care much about the underlying distro. LTS? Fine. I still get up-to-date services. Red hat? Debian-based? Something else? Barely matters, once Docker is installed.

On my home server it even saves me from ever having to think about the distro's init system.

Bonus: dockerized services are often much easier to configure than their distro-repo counterparts, and it's usually easier to track down everything they write that you need to back up, and that's all the same no matter what distro they're running on.

Docker is throwing off incredible amounts of cash with Docker Desktop licensing alone.

It already was, but yes.

No, the docker bridge network is not on a routable subnet.

edit: based on comments, added the FORWARD table, which supersedes Docker's rules and should block new connections forwarding from external interfaces.

edit 2: I'm wrong, this doesn't fix the bug. If you run `docker network create foobar`, it will move its rules up above the custom FORWARD rules. Ugh.

edit 3: Modified to add the rules to the DOCKER-USER table, which according to Docker[1], will always be evaluated first. So now it should actually fix the problem. They explain in the docs how to fix this situation, actually, and even how to prevent Docker from modifying iptables. Another example of why we should RTFM...

  for tool in iptables ip6tables ; do
    for intf in wlan+ eth+ ; do
      for table in INPUT DOCKER-USER ; do
        $tool -I $table 1 -i $intf -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
        $tool -I $table 2 -i $intf -m conntrack --ctstate INVALID -j DROP
        $tool -I $table 3 -i $intf -m conntrack --ctstate NEW -j DROP
    done
  done
  iptables-save > /etc/iptables.rules
  ip6tables-save > /etc/ip6tables.rules

It is. There are millions of servers out there with major security issues. Every few months there's another big story of a data breach from nothing more than a database left open.

Yes, if you're running docker on Linux. On Mac and Windows docker has to create a little linux VM so it's more isolated and not directly accessible without explicitly publishing ports.

Agreed that podman has been a great experience in comparison.

It's a neat trick for development environments but for real traffic you'll still have to actually do the iptables BS.

The attacker and host will generally need to be on the same network so that the attacker's packets are not dropped because they are addressed to a non-routable private IP address.

You could access the containers at 106.12.52.111 if you were in the same network (e.g. 106.12.52.0/24) and the packets did not have to traverse a router.

> Also is this still exploitable if you reject everything at the iptables level before you start using Docker?

Yes. Docker appends the FORWARD chain with custom rules that explicitly forward traffic to published ports.

My solution has always been to just use some external firewall (outside of the docker host machine.) Often cloud providers have this as a feature, to configure a firewall for your vps/network.

This can be quite separate from Docker being a security nightmare at the same time.