A Docker Abstraction That Handles Container Security

Re:A Docker Abstraction That Handles Container Security by contingencies on Wednesday July 26, 2017 @08:42AM (#14855685)

Blocking outbound 53/* is often great. Many services don't need DNS (which is usually UDP not TCP) and it is known to be a very frequent covert channel for infiltrators. AFAIK tcp/53 is most frequently used for zone transfers... not something you'd want to encourage on most production servers!

Restricted ICMP (certain message types only) could be a default permit. If you have an internal service running over known virtual infrastructure to an external-facing proxy, MTU path discovery may be unnecessary anyway.

It doesn't have to be nazi, just better than nothing.

[ Parent | on HN ]

Re:A Docker Abstraction That Handles Container Security by fulafel on Wednesday July 26, 2017 @09:28AM (#14856008)

Those were just some examples - I was trying to point out that this method will generally give you subtly broken firewall rules.

(re DNS: the DNS protocol uses both TCP and UDP interchangeably, it switches to TCP when the message size crosses a threshold. Many kinds of DNS messages can be over the limit. See eg https://github.com/moby/moby/issues/24344)

[ Parent | on HN ]

Re:A Docker Abstraction That Handles Container Security by contingencies on Wednesday July 26, 2017 @09:55AM (#14856183)

You don't need to rigidly and purely enforce rules only from test results but rather also embedded wisdom, defaults and recommendations.

ICMP is a well known gotcha and the only such protocol in its class.

I've personally never seen a fallback to TCP requirement in the wild but you could easily say "if DNS then enable both protocols" as a general rule, and add <received wisdom>.

These are easy to add as policies and will result in better rules than manually configured systems in many cases, if documented. Everyone's happy.

[ Parent | on HN ]