安全審查：對 ssh 登錄嘗試進行分類
我看到我自己的 ssh 登錄到 AWS EC2 Ubuntu Linux 實例為
Nov 18 07:32:21 ip-10-20-30-40 sshd[9487]: Accepted publickey for ubuntu from 15.26.37.48 port 46273 ssh2: RSA SHA256:e37A/qiEdkHHNpeksdPO當我執行一些命令來尋找漏洞時
ubuntu@ip-12-34-56-78:~$ grep "Failed password" /var/log/auth.log ubuntu@ip-12-34-56-78:~$ egrep "Failed|Failure" /var/log/auth.log ubuntu@ip-12-34-56-78:~$ grep "Failed password" /var/log/auth.log | awk '{print $11}' | uniq -c | sort -nr ubuntu@ip-12-34-56-78:~$ journalctl _SYSTEMD_UNIT=ssh.service | egrep "Failed|Failure" ubuntu@ip-12-34-56-78:~$ journalctl _SYSTEMD_UNIT=sshd.service | grep "failure"什麼都沒有出現。到現在為止還挺好。
但是當我瀏覽日誌文件時，我看到了兩個可疑的問題。首先，我看到“身份驗證失敗”：
ubuntu@ip-12-34-56-78:~$ grep "authentication failure" /var/log/auth.log Nov 14 09:23:19 ip-12-34-56-78 sshd[9711]: Disconnecting authenticating user root 98.76.54.32 port 36745: Too many authentication failures [preauth] Nov 14 09:23:22 ip-12-34-56-78 sshd[9713]: Disconnecting authenticating user root 98.76.54.32 port 36754: Too many authentication failures [preauth] Nov 16 11:45:29 ip-12-34-56-78 sshd[20710]: Disconnecting invalid user admin 15.48.27.78 port 51289: Too many authentication failures [preauth]其次，即使我 ssh through ，也會
ssh -i myKeyPair.pem ubuntu@55.89.144.233出現如下行。Nov 17 17:17:01 ip-12-34-56-78 CRON[948]: pam_unix(cron:session): session opened for user root by (uid=0) Nov 17 17:17:01 ip-12-34-56-78 CRON[948]: pam_unix(cron:session): session closed for user root Nov 17 18:23:25 ip-12-34-56-78 sshd[1004]: Invalid user stuart from 34.55.89.144 port 32946 Nov 17 18:23:25 ip-12-34-56-78 sshd[1004]: Connection closed by invalid user stuart 34.55.89.144 port 32946 [preauth] Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: Invalid user ubnt from 21.34.55.89 port 56171 Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: error: Received disconnect from 21.34.55.89 port 56171:14: Unable to connect using the available authentication methods [preauth] Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: Disconnected from invalid user ubnt 21.34.55.89 port 56171 [preauth] Nov 17 12:39:00 ip-12-34-56-78 sshd[32695]: Did not receive identification string from 233.55.89.13 port 54959 Nov 17 23:51:58 ip-12-34-56-78 sshd[1396]: Received disconnect from 144.233.55.89 port 42056:11: Normal Shutdown, Thank you for playing [preauth] Nov 17 23:51:58 ip-12-34-56-78 sshd[1396]: Disconnected from invalid user sinusbot 144.233.55.89 port 42056 [preauth] Nov 17 23:52:24 ip-12-34-56-78 sshd[1398]: Invalid user sinusbot from 144.233.55.89 port 57180我不確定一堆問題：
- 這個“謝謝你玩”是個什麼玩笑？那不是錯誤的遊戲伺服器；是嗎？
- 有很多使用者，比如“stuart”，看起來像是自動嘗試“走運”。就是這樣，只是機器人嗎？
- 是否有一種配置可以阻止這些嘗試出現或被處理？
- 過去，我曾經通過 ssh-keygen 生成一個文件，然後將其複制/粘貼到遠端伺服器，但現在我使用的是 AWS 的
ssh -i myKeyPair.pem ubuntu@11.22.33.44. 兩者在安全性上是相同的，因為任何獲取 pem 文件或私鑰的人都可以不受阻礙地進入。我做對了嗎？- 最重要的是：我記得我選擇公鑰 ssh 作為我唯一的身份驗證方法，但我也在 AWS 設置中涉足了這個和那個。什麼是我現在可以執行的測試來確認我和其他人都沒有在 ssh 中打開除公鑰以外的任何東西？
1 到 3 的簡短答案
對於不那麼雜亂的分析，我發現
last -i和lastb -i是必不可少的。
- 該
preauth符號表示登錄嘗試失敗。- 感謝您演奏樂譜有點管理員幽默。
- 記錄所有失敗的嘗試。
- 正如你所說的，“大門”是對網際網路開放的……所以，除非你配置埠敲門，否則世界上的每一台主機都已經“進入大門”。
一般來說，如果公鑰是
ssh您配置的唯一身份驗證方法，那麼腳本機器人對您來說是相當無懈可擊的。但是，您可以預期每月進行數千次嘗試，甚至更多。如果您擔心此類嘗試，您可以安裝和配置fail2ban。
更長的答案和歡迎來到矩陣
機器人和低垂的果實
對於開始查看日誌文件的大多數經驗不足的管理員來說，可能會有片刻的恐慌。我知道當我有我的時候，我開始問你發布的許多相同的問題。這是對網際網路上看似無窮無盡的黑客攻擊嘗試的常見反應。
我的技術朋友和同事向我保證，我所看到的不是有針對性的攻擊，而主要是自動腳本檢查是否容易實現。它是….
使用者名和密碼列表上有一些列表，可以在各種不太知名的地方買賣。執行腳本機器人的個人購買了這些列表中的一個或多個，並使用它來嘗試訪問特定子網中的任何機器，甚至可能爬過整個 IPv4 地址空間。
這就是為什麼你會看到一整套大約一百個名字的原因，比如：*Fred、Sally、George……等等……*你甚至可能會看到你的名字，或者類似的名字。您可能正在執行的其他服務也是如此，例如電子郵件。如果您查看該
/var/log/mail.log文件，您會看到相同類型的使用者名和密碼組合黑客嘗試。這些攻擊都是機器人。如果您在伺服器上配置了健全的安全措施，那麼您不太可能因
ssh黑客攻擊而受到威脅。SSH 密鑰
SSH 密鑰對有一個公共組件和一個私有組件。永遠不應該分發私有組件。公共組件應該放在目標伺服器的
~/.ssh/authorized_keys文件中。在公鑰身份驗證期間，私鑰和該密鑰的密碼都不會通過連接傳輸。一旦進行了身份驗證，就
ssh使用商定的對稱會話密鑰對會話進行加密。竊取了您的私鑰的攻擊者仍然需要找出您的密碼。並且該攻擊者不應該能夠在不破壞儲存您的私鑰的機器的情況下嗅探該密碼。SSH 密鑰是加密對象，因此受算法日落日期和/或在任何給定算法的整個生命週期中發現的漏洞的影響。因此，確保您的伺服器軟體經常更新並針對任何新發現的問題檢查您的使用者密鑰非常重要。
在撰寫本文時，標準算法似乎仍然是 RSA 2048。AWS 密鑰腳本根據AWS 文件生成 RSA 2048 密鑰。但是，我已將所有密鑰更改為 Curve 25519，因為這些密鑰要短得多，並且據稱該算法是獨立於任何國家機構或可能受到損害的實體開發的。
伺服器審計和記錄保存
由於您已經表明您在開始時啟用了 ssh 公鑰身份驗證並且還禁用了密碼身份驗證，因此沒有理由懷疑公鑰身份驗證已被遠端攻擊者禁用。就是這樣，除非您的 AWS 賬戶本身已被盜用。但是，您可能會收到一些關於用於訪問您的 AWS 賬戶的意外 IP 地址的通知。
如果您想要更長的日誌記錄，您可以延長由
logrotate和/或安裝auditd保存日誌文件的時間長度。您的配置的健全程度
小型/個人伺服器的健全 ssh 安全措施
- 公鑰認證和僅公鑰認證
- 禁用 root 使用者的 ssh 訪問
- 僅對
sudo需要 root 權限的使用者啟用- 使用至少 2048 位的 RSA 密鑰，或 Curve 25519 密鑰
- 永遠不要將私鑰材料放在伺服器上
- 除非絕對需要，否則禁用 X11 轉發
對於大多數新安裝，唯一應該更改的設置是啟用公鑰身份驗證和禁用 X11。
/etc/ssh/shhd_config... PermitRootLogin no ... PubkeyAuthentication yes PasswordAuthentication no X11Forwarding no ...瘋狂的 ssh 安全性
除了上述之外，啟用埠敲擊，將主機密鑰限制為單一算法，例如 Curve 25519，將伺服器的主機密鑰指紋放入域的 DNS 記錄中，並使用 DNSSEC 保護該記錄。
- 要限制伺服器的主機密鑰，只需取消註釋您將使用的算法並重新啟動
sshd伺服器。請注意，一旦完成並且您嘗試再次連接，主機密鑰將不匹配。嘗試連接時按照說明替換本地儲存的主機密鑰指紋。
/etc/ssh/sshd_config... #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key ...
sshfp要為選定的主機密鑰生成DNS 記錄：
ssh-keygen -r domain.tld -f /etc/ssh/ssh_host_ed25519_key生成的記錄可以放在您域的 DNS 區域文件中，
ssh連接將檢查該指紋。這可以防止在第一次連接或伺服器的主機密鑰更改時對 ssh 進行中間人攻擊。
- 安裝敲門
並根據文件進行配置：
knockd is a port-knock server. It listens to all traffic on an ethernet (or PPP) interface, looking for special "knock" sequences of port- hits. A client makes these port-hits by sending a TCP (or UDP) packet to a port on the server. This port need not be open -- since knockd listens at the link-layer level, it sees all traffic even if it's destined for a closed port. When the server detects a specific sequence of port-hits, it runs a command defined in its configuration file. This can be used to open up holes in a firewall for quick access. .... [options] logfile = /var/log/knockd.log [openSSH] sequence = 7000,8000,9000 seq_timeout = 10 tcpflags = syn command = /usr/sbin/iptables -A INPUT -s %IP% --dport 22 -j ACCEPT [closeSSH] sequence = 9000,8000,7000 seq_timeout = 10 tcpflags = syn command = /usr/sbin/iptables -D INPUT -s %IP% --dport 22 -j ACCEPT
- DNSSEC 配置這裡不再詳述。但是，重要的是要記住 DNS 欺騙是 DNSSEC 解決的一個真正問題。