TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Disabling Docker ICC still allows raw ethernet communication between containers

113 点作者 bthornbury大约 7 年前

10 条评论

bthornbury大约 7 年前
Note that this repros on a default unprivileged container, with the default seccomp profile, and SELinux enabled.<p>Relevant filed issue: <a href="https:&#x2F;&#x2F;github.com&#x2F;moby&#x2F;moby&#x2F;issues&#x2F;36355" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;moby&#x2F;moby&#x2F;issues&#x2F;36355</a><p>There are three immediate workarounds.<p>1. Dropping `CAP_SYS_RAW` in docker run will prevent the raw socket from being opened (and is always a good idea).<p>2. Placing each container on it&#x27;s own bridge network blocks this communication but requires you to manually specify the subnets of those networks to work around dockers default limit of 31 networks.<p>3. Create ebtables rules, to filter below the ip layer (layer 2) see the repo for an example.
评论 #16427427 未加载
sydney6大约 7 年前
FreeBSD&#x27;s Jails doesnt allow raw socket access by default since i have been using it (~10Y) and probably even much longer.<p>edit: Since 2004 to be precise.<p><a href="https:&#x2F;&#x2F;www.freebsd.org&#x2F;releases&#x2F;5.3R&#x2F;relnotes-amd64.html" rel="nofollow">https:&#x2F;&#x2F;www.freebsd.org&#x2F;releases&#x2F;5.3R&#x2F;relnotes-amd64.html</a><p>So well documented. Gotta love it.
评论 #16426494 未加载
评论 #16425780 未加载
geofft大约 7 年前
Even if you used ebtables to filter out containers talking to each others&#x27; MAC addresses, wouldn&#x27;t they be able to send broadcast or multicast packets to communicate with each other?<p>I guess it&#x27;s not clear to me if the vulnerability&#x2F;bug&#x2F;whatever here is &quot;two conspiring containers can establish a covert channel&quot; or &quot;a malicious container can send normal-looking traffic to a container, bypassing that container&#x27;s firewall rules.&quot;<p>It does seem like the right answer is unique bridge networks per container. On physical networks, it&#x27;s hard to prevent two untrusted devices on the same L2 domain from establishing a covert channel. (And it&#x27;s hard to prevent two networked untrusted, conspiring devices anywhere on the internet from establishing a covert channel, if they&#x27;re trying hard enough.)
评论 #16425819 未加载
评论 #16428282 未加载
评论 #16425748 未加载
blattimwind大约 7 年前
&gt; This behavior is highly unexpected, and in highly secure environments, likely to be an issue.<p>If your &quot;highly secure&quot; environment relies on docker for isolation (a software neither meant nor designed for security), then it hardly qualifies as &quot;highly secure&quot; in the first place.
评论 #16425844 未加载
评论 #16426526 未加载
yanslookup大约 7 年前
Is the idea that an attacker would enumerate mac addresses and scan for connections? Or is there a way for an attacker to discover neighboring container mac addresses?
评论 #16426516 未加载
jlgaddis大约 7 年前
Since iptables only works for IPv4 packets (EthType 0x0800), it doesn&#x27;t really seem unusual that you could still pass back and forth frames with different EtherTypes.<p>There&#x27;s a reason why filtering frames at layer 2 is a thing, but I suppose the average developer&#x2F;Docker user wouldn&#x27;t really be aware of it. I&#x27;m a senior network engineer at $work (ISP) and there are several locations in the network where I do this (the most common location is probably at IXP exchanges).<p>Layer 2 security is something that most people overlook.
fapjacks大约 7 年前
Well, this is kind of unexpected, but &quot;highly secure&quot; environments surely won&#x27;t be running containers on the default bridge without any of the capabilities configured.
评论 #16427570 未加载
eyeareque大约 7 年前
Could it be possible to spoof ether frames with udp in them? Like say dns responses from the othe containers dns queries? Or to spoof the same MAC address as a peer container?
kuschku大约 7 年前
The interesting question will be how this applies to Kubernetes using flannel, considering that creates a separate network bridge per container.
评论 #16427912 未加载
iforgotpassword大约 7 年前
Why not just put each docker container in its own VM? Problem solved without any ugly hacks, clean and elegant.
评论 #16428311 未加载
评论 #16427561 未加载