SSH(sshd)終極安全加固指南

SSH(Secure Shell)是一種能夠讓用戶安全訪問遠程系統的網絡協議,它爲不安全網絡中的兩臺主機提供了一個強加密數據通信通道。SSH是Linux、UNIX系統管理員操作和管理主機的首選方式。雖然SSH比其他通信方式更加安全,但是錯誤的配置也可能導致其出現安全問題。這篇文章的目的就是提供一個幫助你加固SSH的指南。

這篇指南將涉及到很多選項,但這些選項並不適合所有的服務器,只有你自己瞭解自己的環境配置、用戶基礎以及數據的重要性,因此到底哪些配置適合於你的系統,完全取決於你、你公司的安全策略或者是你組織內的某些人。

寫在前面

以下內容適用於本指南,除非另有說明

  • 本文所編輯的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連接

白名單

Match參數是個有意思的參數,其在全局不變的情況下,允許個別符合的例外。這點用兩個社會詞概況最恰當不過—-“走後門”,“開小竈” 。可能很多人在用這個參數時表示不生效,請注意兩點:一點是man裏的提示:until either another Match line or the end of the file.(需要寫在sshd_config的最後或者實完後在下面加一行Match all),另一點是Match規則匹配後,後面的參數項在別起一行時是不頂格寫的。

例1:只允許192.168.2.5主機進行root登陸

Match Address 192.168.2.5

例2:多個主機或IP段

Match Address 192.168.184.8,202.54.1.1,192.168.1.0/24

例3:用戶加IP多匹配

Match User zabbix Address 192.168.1.0/24

例4:通配符匹配

## Match 192.168.1.1 to 192.168.1.9 ##

Match Address 192.168.1.?

## Match 192.168.1.{2,3....} ##

Match Address 192.168.2.*

## Allow any host in the ".home.lan" set of domains ##

Match Host *.home.lan

## Allow everyone except foo user ##

Match User *,!foo

Match適用的參數很多,基本sshd裏大部分參數都是適用的。而且從上面的示例上也可以看出,Match完全符合上面的需求。

ssh參數和本需求相關的部分就介紹到這裏,在測試的時候還需要注意一點,每次ssh的配置變更,都需要重啓ssh服務器才能生效的,重啓上也可以使用sshd -T和sshd -t測試配置。

檢查傳入SSH連接也是保護SSH的好方法,可以僅允許特定的IP或子網連接到系統,下面將演示通過iptablesfirewalld和 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的安裝可以參考這:

對於 Ubuntu/Debian 系統,fail2ban 可使用 apt-get 安裝包管理指令:
sudo apt-get install fail2ban


對於CentOS 系統運行 yum:

yum install fail2ban

 

在/etc/fail2ban/jail.conf中找[ssh]或[sshd]新加"enabled = true"

[sshd]
enabled = true

...

1) 如果在 Ubuntu/Debian 系統下,在命令行執行:

sudo service fail2ban start
1) 如果在 CentOS 系統下,在命令行執行:

service fail2ban start

 

 

也可使用 TOTP (基於時間戳的一次性動態口令)來加固 SSH 的安全。下面的例子,用到了谷歌認證器   Google Authenticator ,如下圖:

 

總結

在本文中,我介紹了許多選項來幫助保護你的SSH服務,正如我在簡介中所述,每種設置的可用性取決於您,只有您可以權衡這些設置的便利性和安全性。瞭解可用的選項是一個好的開始,我認爲本文涵蓋了有關安全方面的大多數選項,如果你使用了本文所有的配置,那麼你的配置將超過《美國國防信息系統局安全技術信息指南》的要求。

 

參考:

https://www.freebuf.com/articles/system/246994.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章