本文翻譯自:A Guide to Securing the SSH Daemon
SSH(Secure Shell)是一種能夠讓用戶安全訪問遠程系統的網路協議,它為不安全網路中的兩臺主機提供了一個強加密資料通信通道,SSH是Linux、UNIX系統管理員操作和管理主機的首選方式,雖然SSH比其他通信方式更加安全,但是錯誤的配置也可能導致其出現安全問題,這篇文章的目的就是提供一個幫助你加固SSH的指南,
這篇指南將涉及到很多選項,但這些選項并不適合所有的服務器,只有你自己了解自己的環境配置、用戶基礎以及資料的重要性,因此到底哪些配置適合于你的系統,完全取決于你、你公司的安全策略或者是你組織內的某些人,
目錄
- 寫在前面
- 僅使用SSHv2 協議
- 關倍訓者延遲壓縮
- 限制身份驗證最大嘗試次數
- 禁用root賬戶登錄
- 顯示最后一次登錄的日期和時間
- 結束空閑的SSH會話
- 禁用空密碼
- 禁用基于受信主機的無密碼登錄
- 禁用基于已知主機的訪問
- 禁用基于主機的身份認證
- 禁用X11Forwarding
- 使用非常規埠
- 將服務系結到指定IP
- 保護SSH密鑰
- 保護主機私鑰
- 保護主機公鑰
- 檢查用戶特定的組態檔
- 防止特權升級
- 使用密鑰進行身份驗證
- 禁用不使用的身份驗證方法
- 禁用 GSSAPI 認證
- 禁用Kerberos認證
- 禁用口令認證
- 禁用密鑰認證
- 使用符合FIPS 140-2標準的密碼
- 使用符合FIPS 140-2標準的MAC
- 配置主機防火墻過濾傳入的SSH連接
- 使用iptables過濾SSH連接
- 通過Firewalld過濾SSH連接
- 使用UFW過濾SSH連接
- 設定一個Banner
- 其他可選程式
- 總結
寫在前面
以下內容適用于本指南,除非另有說明
- 本文所編輯的SSH組態檔指的是
sshd_config檔案,而不是ssh_config(注意ssh后面的有個d), - 任何對SSH配置的修改都需要重啟服務后生效,
- 我們所要討論的絕大多數選項已經寫在
sshd_config檔案中了,在進行配置前最好確認是否已經設定了該選項,盲目設定將會導致沖突, - SSH組態檔中有許多帶有注釋的行(注釋以
#開頭),注釋掉的選項將不會在服務中啟用,若要使其生效,需要洗掉前面的#, - 注釋通常顯示為該選項的默認值,
僅使用SSHv2 協議
SSHv1是已知的對于SSH協議的不安全實作,為了確保系統的完整性,應當將SSH服務配置為僅接受SSHv2連接,
通過取消以下行配置的注釋,來配置SSH服務僅接受SSHv2協議,
Protocol 2
備注:RedHat和CentOS在7.4版本之后使用SSHv2作為默認配置,但是“我”仍喜歡將該行寫入組態檔,
關倍訓者延遲壓縮
SSH可以使用gzip演算法壓縮資料,如果壓縮軟體中存在漏洞,就可能影響到系統,
關于在快速連接上是否需要啟用壓縮,已經進行了很多討論,普遍認為壓縮實際上會減慢處理速度,除非你使用慢速連接(調制解調器、ISDN等),如果必須使用壓縮功能,請使用延遲功能來確保在壓縮開始前對用戶進行身份驗證,
關閉壓縮功能(推薦):
Compression no
要將壓縮延遲到身份認證后,則需要修改為:
Compression delayed
這里的“快速連接”和“慢速連接”沒太理解,原文為“fast connections”、“slow connection”,可能指的就是通信信道的傳輸速率吧,
限制身份驗證最大嘗試次數
限制用戶失敗認證的最大次數是一個緩解暴力攻擊的好方法,將MaxAuthTries設定為比較小的數字(x),將會在用戶x次失敗嘗試后強制斷開會話,
限制最大身份驗證嘗試次數,請修改sshd_config中的配置為如下:
MaxAuthTries 3
You can set this number as low as you like, but 3 is a good balance between security and convenience in my opinion.
你可以任意調低這個數字,但是我認為“3”是在安全和便利之間較為平衡的設定,
禁用root賬戶登錄
如果你允許root用戶登錄,則不能將操作關聯到用戶,強制用戶使用特定于用戶的賬戶登錄可以確保問責機制,此外,這樣設定還可以進一步保護root賬戶免受其他型別的攻擊,
阻止用戶使用root賬戶登錄,請修改配置如下:
PermitRootLogin no
強烈建議使用此配置,
顯示最后一次登錄的日期和時間
這通常是現代系統中的默認設定,但是檢查其是否正確配置仍然很重要,通過列印最后一次登錄的日期和時間,用戶可以意識到未經授權的賬戶登錄事件,這將對進一步調查無法識別的訪問提供幫助,
輸出最后一次登錄日期和時間,請修改配置如下:
PrintLastLog yes
這是條安全的捷徑,
結束空閑的SSH會話
無限期地將SSH會話保持打開狀態不是一個好主意,因為用戶可能離開他們的作業站,這給了一個未授權用戶在無人看管的作業站上執行命令的好機會,最好的辦法是在短時間內終止空閑的SSH會話,不給他人留機會,
ClientAliveCountMax選項和ClientAliveInterval選項相互配合,例如要在十五分鐘(900秒)后關閉不活動的會話,修改組態檔如下:
ClientAliveInterval 900
ClientAliveCountMax 0
更多有關ClientAliveInterval的說明:
設定超時間隔(以秒為單位),在此間隔后,如果未從客戶端接收到任何資料,sshd服務端將通過加密的通道發送訊息請求客戶端回應,默認值為0,表示不會執行該操作,
更多有關ClientAliveCountMax的說明:
設定客戶端探活訊息(上文所述操作)的數量,如果發送客戶端探活訊息達到此閾值,則sshd服務端將斷開客戶端連接,從而終止會話,
指定白名單用戶
你可以通過白名單指定那些經過授權的用戶來連接SSH服務器,只有在這個串列中的用戶才有權登錄SSH,其他人則不行,這樣做好處多多,
若僅允許 "pfloyd"、 "rwaters"和 "dgilmour"這三個 用戶的話,修改組態檔如下:
AllowUsers pfloyd rwaters dgilmour
你同樣可以使用DenyUsers來禁止某些用戶,比如這樣修改組態檔:
DenyUsers root ncarter ajmclean hdorough
這個設定并不是總是可用的,如果你的環境可以支持此配置,那肯定會提高安全性的,
禁用空密碼
確保任何SSH連接都需要一個非空的密碼字串(這并不會影響SSH密鑰認證登錄模式),
修改組態檔如下:
PermitEmptyPasswords no
這是另一個簡單卻重要的配置,建議對所有非特殊情況下使用,
如果你使用密碼認證,實施密碼復雜性規則是一個明智的選擇,這些規則可以是由你的組織制定,或者嘗試以下“最佳實踐”:
- 密碼長度大于x
- 密碼至少包含x個小寫字符
- 密碼至少包含x個大寫字符
- 密碼至少包含x個數字
- 密碼至少包含x個特殊字符
- 密碼不得包含用戶名(正向或者反向)
想要了解更多有關設定密碼復雜性的資訊,可以參看《如何在RedHat中強制設定密碼復雜性》,雖然這篇文章針對RedHat的,但是它可以在任何使用最新版的PAM(可插拔身份驗證模塊)的Linux系統上運行,
禁用基于受信主機的無密碼登錄
rhosts檔案是一種控制系統間信任的關系的方法,如果一個系統信任另一個系統,則這個系統不需要密碼就允許來自受信認系統的登錄,這是一個老舊的配置,應當在SSH配置中明確禁用,
確保SSH不允許受信主機連接,請修改組態檔如下:
IgnoreRhosts yes
rhosts檔案已經很少使用了,建議在多數情況下啟用該配置,
禁用基于已知主機的訪問
known_hosts檔案用于標識服務器,當用戶啟動SSH連接時,SSH會將服務器指紋與known_hosts檔案中存盤的指紋進行比較,來確保用戶連接到的是正確的系統,這個配置與rhosts配置相互配合,確保與遠程主機連接時需要密碼(通過設定該選項,來保證每一次連接都將遠程主機視為“非信任”主機),
在身份驗證時忽略已知主機,請修改組態檔如下:
IgnoreUserKnownHosts yes
這個配置適用于絕大多數環境,
禁用基于主機的身份認證
這個功能類似于基于受信主機的認證,但是僅用于SSH-2,在我的經驗里這個功能很少使用,應當設定為no,
禁用基于基于主機的身份認證,請修改組態檔如下:
HostBasedAuthentication no
這個選項默認情況下設定為no,但是為了保險起見,我將其顯式添加到組態檔中,
禁用X11Forwarding
X11Forwarding允許通過SSH會話遠程執行程式,并在客戶端顯式圖形界面,如果沒有特殊需求,則應將其禁用,
禁用X11Forwarding,請修改組態檔如下:
X11Forwarding no
X11Forwarding很少使用,我建議在大多數系統上禁用該功能,
使用非常規埠
默認情況下,SSH監聽在TCP 22 埠,黑客和腳本小子經常對這個埠進行掃描,來判斷目標是否運行SSH,另外2222和2121也是常用的監聽埠,最好不要使用這些埠,請使用不常見的高端埠,例如示例中的9222埠,
設定SSH監聽在非常規埠,請修改組態檔如下;
Port 9222
我通常不修改位于防火墻后面的那些默認埠,但是如果您的主機暴露在互聯網或者其他不受信任的網路中,這樣的設定是必要的,
注意:不要忘記更改防火墻規則,允許流量訪問你自定義的埠,
將服務系結到指定IP
默認情況下,SSH會監聽本機上配置的所有IP地址,但是你應該指定SSH系結在特定的IP,最好是在專用VLAN中的地址,
指定系結地址,請修改組態檔如下
ListenAddress 10.0.0.5
這個設定通常與埠系結相互配合,
保護SSH密鑰
保護主機私鑰
你應該保護主機私鑰防止未授權的訪問,如果私鑰泄露,則主機可能會被假冒,因此所有的私鑰檔案都應設定為僅允許root用戶訪問(對應權限為0600),
使用ls命令列出/etc/ssh/檔案夾下所有的私鑰檔案:
ls -l /etc/ssh/*key
使用chmod命令設定私鑰檔案權限:
chmod 0600 /etc/ssh/*key
大多數情況下,私鑰檔案存盤在/etc/ssh/檔案夾下,但是也有可能存盤在其他目錄中,通過以下命令可以檢索組態檔中設定的存盤位置:
grep -i hostkey /etc/ssh/sshd_config
保護主機公鑰
雖然公鑰不如私鑰那么重要,但你還是應該對其進行保護,因為如果公鑰被篡改,則可能會使SSH服務無法正常作業或者拒絕服務,因此需要配置權限僅允許root賬戶對其進行修改(對應權限為0644),
使用ls命令列出/etc/ssh/目錄下所有的公鑰檔案:
ls -l /etc/ssh/*pub
使用chmod命令修改公鑰檔案權限:
chmod 0644 /etc/ssh/*pub
通常情況下公鑰和私鑰存放在同一目錄下,或者使用上一節的方法查找存放路徑,
檢查用戶特定的組態檔
用戶可能會在無意間將自己的home目錄或者其他某些檔案設定成全域可寫(比如777權限),在這種情況下,其他用戶將有權修改用戶特定的配置,并以其他用戶的身份登錄到服務器,可以通過使用StrictModes選項來檢查home目錄的配置,
StrictModes設定ssh在接收登錄之前是否檢查用戶home目錄和rhosts檔案的權限和所有權,StrictModes為yes必需保證存放公鑰的檔案夾的擁有者與登陸用戶名是相同的,
確保啟用嚴格模式,請修改組態檔如下:
StrictModes yes
建議使用此方法,尤其是對于有大量用戶的系統,
防止特權升級
SSH通過創建一個無特權的子行程來接收傳入的連接,實作權限分離,用戶身份驗證后,SSH將使用該用戶的權限創建另一個行程,
在我所了解的系統中,這個選項默認都是開啟的,但是為了保險起見,建議還是手動修改組態檔,顯式指定該配置:
UsePrivilegeSeparation sandbox
使用sandbox可以增加其他限制,
使用密鑰進行身份驗證
該功能并不一定在所有系統上都可用,但是使用SSH密鑰身份驗證有很多優點,密鑰驗證比人類可以輕松記住的任何密碼都要強大的多,同時還提供了無需密碼的身份驗證,使用更加便利,
啟用密鑰身份驗證,請修改組態檔如下:
PubkeyAuthentication yes
該選項在大多數系統上默認為yes,
更多有關SSH密鑰身份驗證的資訊,請參考 How to Setup SSH Key Authentication,
禁用不使用的身份驗證方法
Linux管理員知道優秀的安全實踐是停止并洗掉所有用不到的服務,同樣,你也應該禁用SSH中不使用的其他任何身份驗證方法,
在這里,我將向你展示禁用所有身份驗證的方法,但是請注意:不要全部禁用它們,請保留需要的,
禁用 GSSAPI 認證
通過“通用安全服務應用程式介面”(GSSAPI),可以使用高級配置和其他身份驗證方法(除口令、密鑰認證方式之外的),如果你不使用此功能,則請修改組態檔如下:
GSSAPIAuthentication no
禁用Kerberos認證
同樣,如果不需要則禁用:
KerberosAuthentication no
禁用口令認證
如果配置了更高級的認證方式,則可禁用口令認證:
PasswordAuthentication no
禁用密鑰認證
如果你使用了其他身份認證方式,則可以禁用密鑰身份認證,相比其他辦法,使用密鑰認證是風險較小的辦法,如需禁用,修改組態檔如下:
PubkeyAuthentication no
使用符合FIPS 140-2標準的密碼
使用符合FIPS 140-2的規范,避免使用弱加密演算法,請修改組態檔如下:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
這樣的設定限制了可用于SSH的加密方式,因此應用前需確認任何可能會用到的老舊客戶端、腳本或應用程式的兼容性,
“FIPS 140-2” 為美國國家標準和技術委員會發布的針對密碼模塊的安全需求標準,作為聯邦資訊處理標準在政府機構廣泛采用,
使用符合FIPS 140-2標準的MAC
與上一小節相同,使用符合FIPS 140-2的規范,避免使用弱加密哈希演算法:
MACs hmac-sha2-256,hmac-sha2-512
配置主機防火墻過濾傳入的SSH連接
檢查傳入SSH連接也是保護SSH的好方法,可以僅允許特定的IP或子網連接到系統,下面將演示通過iptables、firewalld 和 Uncomplicated Firewall (UFW)配置防火墻的方法,
使用iptables過濾SSH連接
允許特定IP連接:
iptables -I INPUT -p tcp -s <指定的IP> --dport 22 -j ACCEPT
允許特定的子網:
iptables -I INPUT -p tcp -s <指定子網> --dport 22 -j ACCEPT
更多有關iptables的使用方法,請參考The Basics of IPTables自己度娘
通過Firewalld過濾SSH連接
允許特定IP連接SSH:
firewall-cmd --permanent --zone=public --add-rich-rule=' rule family="ipv4" source address="<指定IP>" port protocol="tcp" port="22" accept'
允許特定子網:
firewall-cmd --permanent --zone=public --add-rich-rule=' rule family="ipv4" source address="<指定子網>" port protocol="tcp" port="22" accept'
使用UFW過濾SSH連接
允許特定IP連接SSH:
sudo ufw allow from <指定IP> to any port 22
允許特定子網:
sudo ufw allow from <指定子網> to any port 22
設定一個Banner
以我的經驗來看,這樣做弊大于利,雖然修改Banner(連接提示資訊)可以阻止一些腳本小子,但是數經驗豐富的老鳥可能會將其視為一種挑釁,因此如果確實要增加Banner,請考慮訊息的語氣,
啟用自定義Banner,請修改組態檔如下:
Banner /etc/issue
編輯/etc/issue檔案,即可添加連接到SSH后的提示資訊,
其他可選程式
有很多程式可以用來幫我們組織攻擊,其中最著名的是fail2ban,它通過掃描日志來查找惡意行為,并通過更新防火墻規則等操作來阻止可疑IP,關于fail2ban的配置不在本文的討論范圍,
總結
在本文中,我介紹了許多選項來幫助保護你的SSH服務,正如我在簡介中所述,每種設定的可用性取決于您,只有您可以權衡這些設定的便利性和安全性,了解可用的選項是一個好的開始,我認為本文涵蓋了有關安全方面的大多數選項,如果你使用了本文所有的配置,那么你的配置將超過《美國國防資訊系統局安全技術資訊指南》的要求,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/69523.html
標籤:其他
上一篇:最新通達OA11.6檔案洗掉+任意檔案上傳rce漏洞復現
下一篇:體驗一下:AndroidX
