在 EC2 安全組上允許入站 0.0.0.0/0 是否安全？
我在 AWS 上創建了一個 EC2 實例，並為我分配了一個預設的“安全組”。我知道這充當了我伺服器的虛擬防火牆。
我在使用 SSH 連接到這個 EC2 實例時遇到了問題，結果發現問題不是
0.0.0.0/0在安全組的“入站規則”中將“源”設置為，如下圖所示。保持這樣是否安全，或者我應該將來源限制為家庭網路的 IP？
如果沒有 *.pem 文件，沒有人可以 ssh 進入我的 EC2 實例，對嗎？
安全性就像洋蔥——它的全部內容都是層，像食人魔一樣的臭層。
通過允許來自任何地方的 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，但仍非零。