How the modern containerization trend is exploited by attackers

Re:How the modern containerization trend is exploited by att... by chatmasta on Thursday June 14, 2018 @09:29AM (#17311499)

Isn’t the real problem mentioned in this article that people are running their docker daemon unauthenticated on public endpoints? That’s not the default behavior right? So people have actually gone out of their way to make themselves insecure.

Look at the names of the containers in the article. Nobody is pulling these themselves. The problem is attackers compromising docker hosts and pulling arbitrary containers.

What safeguards does docker provide against exposing the daemon publicly, accidentally or otherwise?

[ Parent | on HN ]

Re:How the modern containerization trend is exploited by att... by nassyweazy on Thursday June 14, 2018 @11:41AM (#17312469)

The daemon is listening by default on a non-networked unix socket so if you're exposing listening on the network, you're already out of the default behavior (which is totally normal but that means that you've started regarding the instructions/doc on how to do so, and our doc page on this matter also includes security guidelines to enforce TLS verification/whitelisting daemon-side).

There is currently no "superduper-safe-mode" that enforces `--tls-verify` at the daemon-level to prevent lack of client verification/whitelisting. This can be discussed, the issue obviously being the UX (that means getting proper certs, specifying them in the config etc..).

[ Parent | on HN ]