在 EC2 安全组上允许入站 0.0.0.0/0 是否安全？

Question

我在 AWS 上创建了一个 EC2 实例，并为我分配了一个默认的“安全组”。我知道这充当了我服务器的虚拟防火墙。

我在使用 SSH 连接到这个 EC2 实例时遇到了问题，结果是问题没有0.0.0.0/0在安全组的“入站规则”中设置“源”，如下图所示。

保持这样是否安全，还是应该将来源限制为家庭网络的 IP？

没有 *.pem 文件，没有人可以 ssh 进入我的 EC2 实例，对吗？

Answer 1

安全工作的方式不是二进制的。您的实例永远不会“安全”。

有成百上千的攻击向量，您可以做出成本效益决策来防御其中一些向量。完全防御所有这些攻击的代价高得令人望而却步。

在您的情况下，您的系统在任何侦听网络接口的服务/应用程序中都可能存在漏洞，例如导致数据泄漏。

您已打开所有 TCP 和 UDP 端口。如果您想使用该 *.pem 以及您知道需要的任何其他端口，那么拥有 TCP/22 就足够了。

甚至 OpenSSH 也可能存在漏洞。因此，是的，最好只拥有您的家庭网络 IP 范围。

Answer 2

安全就像一个洋葱——它的所有层都是层，像食人魔一样的层。

通过允许来自任何地方的 SSH 连接，您已经删除了一层保护，现在完全依赖于 SSH 密钥，这在目前被认为是安全的，但将来可能会发现减少或删除该层的缺陷。

当没有更多层时，您将一无所有。

一个快速层是安装 fail2ban 或类似的。这些守护进程监视您的 auth.log 文件，并且当 SSH 连接失败时，它们的 IP 会被添加到iptables链中一段时间​​。这减少了clinet每小时/每天尝试连接的次数。我最终无限期地将不良来源列入黑名单 - 但是必须挂起 SSH 混杂侦听的主机可能仍然每天尝试 3000 次失败的 root 登录尝试。大多数来自中国，东欧和俄罗斯紧随其后。

如果您有静态源 IP，那么将它们包含在您的安全组策略中是很好的，这意味着世界其他地方无法连接。不利的一面是，如果由于某种原因您无法使用授权 IP，例如您的 ISP 是动态的或您的链接已关闭，该怎么办？

一个合理的解决方案是在您的实例上运行 VPN 服务器，侦听所有源 IP，然后在隧道启动后，通过 SSH 通过隧道进行连接。当然它不是完美的保护，但它在你的烧蚀盔甲中多了一层...... OpenVPN 是一个很好的选择，

您还可以利用 AWS 的“客户端 VPN”解决方案，这是一个托管 OpenVPN，提供对您的 VPC 的访问。没有亲身经历这个抱歉。

其他（公认的薄）层是将 SSH 移动到不同的端口。除了减少默认为端口 22/tcp 的 script-kiddy 探测器之外，这实际上并没有做太多事情。任何努力尝试的人都会扫描所有端口并在 2222/tcp 或 31337/tcp 或其他任何地方找到您的 SSH 服务器。

如果可能，您可以只调查 IPv6 ssh，同样它只是限制了暴露，而没有增加任何真正的安全性。IPv6 上未经请求的 SSH 连接数目前远低于 IPv4，但仍非零。

Answer 3

如果软件是完美的，你可以让你的服务器像你一样完全对互联网开放，但在实践中，存在漏洞和其他方法来破坏服务器。

最佳做法是仅向最少的 IP 开放特定端口以实现您的目标。例如：

• 仅向需要它的 IP（例如您的家庭或工作 IP）开放端口 22 (SSH)。
• 如果您想为网络流量提供服务，请向全世界开放端口 80 和 443。但是，如果您想要额外的保护，您可以使用 CDN / WAF，例如 CloudFront / CloudFlare（他们有免费套餐）并且只向 CloudFlare IP 开放 443 / 80。
• 仅在需要时才向特定 IP 开放数据库端口。如果您这样做，您的数据库必须配置为接受这些连接，默认情况下 RDS 不是

如果绝对需要，您倾向于只打开其他端口，并使用最少数量的 IP 来实现您的需要。