限制Docker容器的networking访问

在Docker实例中放入一些入口规则以帮助抵御攻击仍然是有意义的，但是必须限制Docker镜像所连接的任何上游路由器的出站（Internet）访问。 原因是，如果您尝试阻止您的实例中的防火墙规则的出站访问，那么如果实例受到攻击，这些规则可能会被攻击者删除。 通过阻止实例路由器的出口，即使出现危害，也会阻止出站访问 – 攻击者也必须妥协路由器。

好的，在收到一些解释说filter是针对容器的主机的解释之后，试图完成的东西会更清楚一些。 在这种情况下，在主机上，你会添加一些类似于这样的规则：

 iptables -A FORWARD -s lo.cal.sub.net -d con.tai.ner.ip -j ACCEPT iptables -A FORWARD -s con.tai.ner.ip -d lo.cal.sub.net -j ACCEPT iptables -A FORWARD -s ! lo.cal.sub.net -d con.tai.ner.ip -p tcp --dport sftp -j ACCEPT iptables -A FORWARD -s con.tai.ner.ip -d ! lo.cal.sub.net -p tcp --sport sftp -j ACCEPT iptables -A FORWARD -s con.tai.ner.ip -m state --state related,established -j ACCEPT iptables -A FORWARD -s con.tai.ner.ip -j DROP 

前两条规则是主机和容器之间的访问。 第三条规则粗略地说，任何东西的子网都不是以SFTP为标准的， 四是出境规则基本上是双胞胎到三分之一; 第五条规则是全面的（如果还有其他相关的端口被使用的话），虽然不需要，但可以删除它。 最后一条规则是阻止访问除主机子网以外的其他任何东西。 因为访问是在前几条规则中给出的，所以不会触发，除非上述规则都不适用，在这种情况下，我们说“我们不在乎你想要什么，你没有匹配你所批准的任何东西，所以你不能从这里到达“。 来自外部的入境stream量将由第三和第四条规则来满足。

这不是一个真正的docker特定的问题。 有几种方法可以解决这个问题。

1. 使用有状态的iptables规则，允许连接入站和相关/build立的stream量，然后阻止其他一切。

2. 使用一个仅适用于sftp的服务，如不能运行shell的ProFTPD服务。

一般来说，如果你不允许你的用户得到一个shell，并且不允许他们从容器中运行程序，你不需要担心。

这只是一个快速的头脑风暴，我还没有testing过。 在生产之前，您需要在实验室中进行审核。

为防止在非SSH（SFTP）和Web端口上的出站stream量，您可能希望通过IPTABLES或其他Layer4防火墙将策略应用于DROP或REJECT来自由目的地为0.0.0.0/0的docker容器使用的段的stream量，端口是TCP22。

为了解决Web上发生的问题，您可能需要尝试设置一个过滤/caching代理的实例，例如在接口docker0上侦听的squid或bluecoat，以及正在使用的代理主人的折磨路线上网。 从那里，您可以根据许多标准来应用策略，并通过caching静态内容来节省networking利用率。 您可能想要在主机上使用NAT（我认为IPTABLES和Masquerade在Linux中提供这个function）来透明地强制使用代理（我在我的回应中描述了这一点，我只想代理HTTP，但是我不知道该怎么做使用HTTPSstream量 ）。 这意味着有理由首先进入网站，遵守贵公司的政策。

由于SSH（SFTP所依据的）的性质，除非您实施容器只能使用由您提供的密钥对的策略，否则您将无法为文件移动提供stream量阻塞。 这对你有好处，因为如果你的某个客户转移了某些非法的东西（比如知识产权侵权，或者利用你的服务来泄露带有分类标签的信息，或者他们在CP交易），如果你被带到法庭上为你的客户做的事情（认为类似于电信公司的共同承运人地位）。 这对您不利，因为您无法频繁地caching重新传输，未更改的文件，并且因为您通过技术手段将与客户签订的任何合同写入合同实质上都无法执行。