我在 AWS 上创建了一个 EC2 实例，并被分配了一个默认的“安全组”。我知道这充当了我的服务器的虚拟防火墙。
我有麻烦使用 SSH 连接到此 EC2 实例，结果发现问题不在于0.0.0.0/0安全组的“入站规则”中设置“源”，如下图所示。
保持这种状态是否安全，还是我应该将源限制到我的家庭网络的 IP？
如果没有 *.pem 文件，就没人能 ssh 进入我的 EC2 实例，对吗？
答案1
安全就像洋葱——它由一层层剥开，像臭气熏天的怪物一样。
通过允许来自任何地方的 SSH 连接，您已经删除了一层保护，现在完全依赖于 SSH 密钥，这在目前被认为是安全的，但将来可能会发现减少或删除该层的缺陷。
当没有更多层时，你就什么也没有了。
一个快速的方法是安装 fail2ban 或类似程序。这些守护进程会监视您的 auth.log 文件，当 SSH 连接失败时，它们的 IP 会iptables暂时添加到链中。这减少了客户端每小时/每天尝试连接的次数。我最终无限期地将不良来源列入黑名单 - 但必须挂起 SSH 并随意监听的主机每天仍可能遇到 3000 次失败的 root 登录尝试。大多数来自中国，紧随其后的是东欧和俄罗斯。
如果您有静态源 IP，那么将它们包含在您的安全组策略中是好的，这意味着世界其他地方无法连接。缺点是，如果您由于某种原因无法来自授权 IP，例如您的 ISP 是动态的或您的链接已断开，该怎么办？
一个合理的解决方案是在您的实例上运行 VPN 服务器，监听所有源 IP，然后在隧道启动后通过 SSH 通过隧道连接。当然，这不是完美的保护，但它为您的安全提供了另一层保护烧蚀装甲...OpenVPN 是一个很好的选择，
您还可以利用 AWS 的“客户端 VPN”解决方案，这是一个托管的 OpenVPN，可访问您的 VPC。抱歉，我没有这方面的个人经验。
其他（当然很薄弱的）层是将 SSH 移至不同的端口。除了减少默认端口 22/tcp 的脚本小子探测外，这实际上没有多大作用。任何努力尝试的人都会扫描所有端口并在 2222/tcp 或 31337/tcp 或任何其他端口上找到您的 SSH 服务器。
如果可能的话，您可以只调查 IPv6 ssh，同样，它只是限制了暴露，而没有增加任何实际安全性。IPv6 上未经请求的 SSH 连接数量目前远低于 IPv4，但仍然不为零。
答案2
安全性的工作方式并非二元的。您的实例永远不会“安全”。
有数百/数千种攻击媒介，您需要做出成本效益决策来防御其中一些媒介。全面防御所有这些媒介的成本高得令人难以承受。
在您的情况下，您的系统可能在监听网络接口的任何服务/应用程序中存在漏洞，例如导致数据泄露。
您已打开所有 TCP 和 UDP 端口。如果您想使用该 *.pem 以及您知道需要的其他端口，则 TCP/22 就足够了。
即使是 OpenSSH 也可能存在漏洞。因此，是的，最好只设置家庭网络 IP 范围。
答案3
如果软件是完美的，您可以像以前一样将您的服务器完全开放给互联网，但实际上存在错误和其他危害服务器的方法。
最佳做法是仅向最少数量的 IP 开放特定端口以实现您的目标。例如：
- 仅向需要它的 IP（例如您的家庭或工作 IP）开放端口 22（SSH）。
- 如果您想要提供网络流量，请向全世界开放端口 80 和 443。但是，如果您想要额外的保护，您可以使用 CDN / WAF，例如 CloudFront / CloudFlare（有免费套餐），并且只向 CloudFlare IP 开放 443 / 80。
- 仅在需要时向特定 IP 打开数据库端口。如果这样做，则必须将数据库配置为接受这些连接，而 RDS 默认情况下不会这样做
您往往只在绝对必要时才打开其他端口，并且打开的 IP 数量必须是能够满足您需要的最少数量。
答案4
你的规则越严格越好。
值得注意的是，一些家庭 ISP 会使用动态地址，如果您发现自己无法连接到您的实例，请先检查。