CentOS 7 下安全配置 SSH (二)

我們在第一篇文章討論了一些在 CentOS 7 中配置 SSH 的方法,那些都是比較容易實作、容易理解,對用戶體驗的影響也比較少。這一篇將會介紹比較複雜的配置,需要管理員按照具體情況做出適當決定,甚至有部分建議在安全性和用戶體驗方面較具爭議性。

密鑰交換算法

SSH 伺服器和客戶端的所有通訊,都受到對稱加密算法保護(例如 AES、3DES、Blowfish 等等),對稱加密算法需要雙方擁有相同的密鑰,但是這個密鑰從何而來?如何確保雙方使用的密鑰相同?如何保證沒有第三者得到這條密鑰?每次通訊所使用的密鑰都不同,有可能嗎?

關鍵就在於使用適當的密鑰交換機制,基本上 SSH 支援兩種密鑰交換算法:Diffie-Hellman(DH)和 Elliptic Curve Diffie-Hellman(ECDH),兩者均可滿足上面所有要求,機制也很接近,分別是它們在協商過程中所使用的算法,DH 的安全性繫於 discrete logarithm(離散對數)問題的困難性,ECDH 的安全性則繫於 elliptic curve discrete logarithm(橢圓曲線離散對數)問題的困難性。不論在純數學還是資訊科技領域,除了暴力破解外,兩種算法基本都是無解的。

SSH 支援以下八種密鑰交換算法:

  1. curve25519-sha256: ECDH over Curve25519 with SHA2
  2. diffie-hellman-group1-sha1: 1024 bit DH with SHA1
  3. diffie-hellman-group14-sha1: 2048 bit DH with SHA1
  4. diffie-hellman-group-exchange-sha1: Custom DH with SHA1
  5. diffie-hellman-group-exchange-sha256: Custom DH with SHA2
  6. ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2
  7. ecdh-sha2-nistp384: ECDH over NIST P-384 with SHA2
  8. ecdh-sha2-nistp521: ECDH over NIST P-521 with SHA2

如何選擇呢?我們考慮以下三點:

  1. 對於 ECDH,不要使用 NIST 提供的橢圓曲線。首先 NIST 建議的橢圓曲線已被證實可透過「計時攻擊」(timing attack) 等方法破解,加上惡名昭彰的 Dual EC DRBG 事件,NIST 有計畫地把暗藏漏洞的隨機數產生算法 Dual EC 標準化,都令人對任何 NIST 推薦的東西心存戒懼。所以,第 6 至 8 項算法都不能用。
  2. 對於 DH,不要使用模數 (modulus) 長度少於 1024 bit 的算法,即是說第 2 項算法也不能用。美國和中國都擁有超級電腦,和資源近乎無限的黑客團隊,1024 bit 恐怕未必足以保障我們的安全。
  3. 不要使用 SHA1 散列函式,SHA1 基本上已被完全破解,當一台廉價的手提電話也可以在 10 分鐘內破解 SHA1(關鍵字:rainbow table),它還值得信任嗎?所以,第 2 至 4 項算法也不能用。

最後我們餘下第 1 和 5 兩項算法,兩者都可以用,一般來說橢圓算法的效率較高,但是傳統的 DH 算法兼容性較好,就讓我們兼收並蓄吧:

使用第五項 DH 算法,SSH 會從 /etc/ssh/moduli 隨機選擇一個長度合適的模數,由於模數的質量和保密性直接關係到 DH 算法的安全性,這裡產生兩個疑問:

  1. /etc/ssh/moduli 的模數從何而來?如果你自行安裝操作系統,安裝的過程會自動隨機產生一批從 1024 bit 到 8192 bit 的模數,保密性不用擔心。如果使用的是由服務供應商提供的 VPS 系統,很大可能他們只是把一個預先製作的操作系統影像檔複製給你,所有客戶的 /etc/ssh/moduli 都一模一樣,這樣便沒有保密性可言,解決的辦法是製作一個新的 /etc/ssh/moduli。
  2. 模數的長度足夠嗎?我們在前面說過不要使用長度少於 1024 bit 的模數,最短的可用長度是 2048 bit,最好是 4096 bit 或以上。如何避免 SSH 使用 /etc/ssh/moduli 內短過 2048 bit 的模數?唯一的方法是把那些過短的模數刪掉,或者在製作 /etc/ssh/moduli 時設定模數的最短長度。

第一種情況,你自行安裝操作系統,所以 /etc/ssh/moduli 的保密性可靠,不過需要砍掉短過 2048 bit 的模數,首先把長度最少 2048 bit 的模數提取出來:

這裡使用 2047 而非 2048,是因為這才是 2048 bit 模數的實際長度。下一步看一看有多少個模數被提取,倘若沒有的話,便要製作一個新的 /etc/ssh/moduli,請參閱下面第二種情況:

多少個沒有關係,總之有便可以了,最後把結果儲存為 /etc/ssh/moduli:

第二種情況,你要重新製作 /etc/ssh/moduli,首先我們產生一批「候選」質數,又名 Sophie Germain 質數,長度最少 4096 bit:

但是這批質數並不滿足 DH 算法對模數的要求,所以要進一步篩選出「安全質數」:

以上兩步很需要你的耐心等候,始終計算這麼大的質數不是容易的事(可以考慮外出吃一頓飯),完成後把結果儲存在 /etc/ssh/moduli:

驗證伺服器

交換密鑰的程序保證只有 SSH 的伺服器和客戶端擁有共同的秘密,即管是全程監視網絡通訊的黑客,也無法得知。但是,客戶端怎麼知道跟他通訊的不是一台冒牌的伺服器?怎樣證實伺服器的身份?

答案是公鑰加密技術,伺服器使用它的密鑰,把前文提及的共同秘密加密,客戶端收到後若果成功用伺服器的公鑰解密,便證明了伺服器並非假冒。至於客戶端如何得到伺服器的公鑰,則不是 SSH 範圍的事,總之這是一個可靠、可信任的程序,例如由伺服器的管理員把公鑰列印出來,由特務 007 親身交給用戶。

SSH 支援以下四種公鑰加密技術:

  1. DSA with SHA1
  2. ECDSA with SHA256, SHA384 or SHA512,視乎密鑰的長度
  3. Ed25519 with SHA512
  4. RSA with SHA1

SSH 使用的 DSA 算法只支援 1024 bit 密鑰,1024 bit 密鑰的安全性,大約等於 80 bit 對稱加密法的鑰匙,短得不能接受,所以第一項不能使用。ECDSA 使用由 NIST 提供的橢圓曲線,基於前文提及的種種問題,我們不接受任何 NIST 推薦的東西,所以第二項也不能接受。DSA 還有一個令人憂慮的問題,就是它的安全性極度依賴一個高質素的隨機數產生器,這些隨機數的保密性、唯一性和混亂性至關重要,倘若這些隨機數是可預測的、重覆的(即使不為他人所知)、或洩露其中一部份位元,都會導致 DSA 密鑰被破解

餘下第三和第四項都是可以使用的技術,第四項的 RSA 雖然配合 SHA1 使用,但對安全性無害,因為真正計算散列值的函式是 SHA2,所以驗證伺服器的實際的算式是 SHA1(SHA2(共同秘密)),儘管計算的結果的長度只有 160 bit,比 SHA2 的最短版本更短,但無損安全性。現在我們的 /etc/ssh/sshd_config 應該這樣寫:

如果配置檔案中列出了其他密鑰檔案,必須全部刪除或註釋掉。

前文解釋過,這些密鑰檔案的來源是否可靠,如何產生,對系統的安全性有很大影響,所以我們應該自行產生這些檔案,保證這些密鑰的質素。

這裡我們重新產生 ED25519 和 RSA 密鑰,RSA 密鑰的長度是令人安心的 4096 bit。

驗證用戶

我們在第一篇文章第五章討論過使用公鑰驗證法取代密碼登入 SSH,因為鑰匙(公鑰和密鑰)的有效長度,比密碼的長很多很多,而且真正隨機,除了暴力破解外別無他法,但是暴力破解又受制於鑰匙的長度,即使超級電腦也無法解決。唯一的問題是,儲存鑰匙的電腦安全嗎?有些人認為公鑰驗證法只是把風險從伺服器轉移到桌面和手提電腦,不無道理。

所以,雙重驗證甚至多重驗證的概念應運而生,它的理念是我們必須向伺服器證明兩種不同性質的東西,才能成功驗證身份,第一樣是我們擁有什麼,第二樣是我們知道什麼。我們擁有的就是公鑰驗證法中的密鑰,我們知道的就是登入密碼,過了這兩關伺服器才會讓我們 進入系統。

假設你已經按照第一篇文章的建議設定公鑰驗證法(還沒有的話強烈建議你現在就做,伺服器的安全就在你手,還等什麼?),現在開啓 /etc/ssh/sshd_config,尋找:

請確定它設定為 yes,表示啟用公鑰驗證法,跟著尋找:

也請確定它設定為 yes,表示啟用密碼驗證法,然後尋找:

找不到這一行便自行在檔案最後加上下面一句:

它的意思是首先使用公鑰驗證法,然後密碼驗證法來驗證用戶,必須兩者同時通過才讓他們登入 SSH。修改完成後重新啟動 sshd

在網上有很多有關 SSH 用戶驗證的討論,比較熱門如下:

  1. 人人皆知大部份的用戶都不會使用安全性高的密碼,即是那些又長又難記又沒有規律的密碼,儘管使用 abc123abcdefgh12345678 的人已經越來越少,但仍有很多人用自己或家人的出生日期、車輛牌照號碼、住址等等建立密碼,所以把密碼驗證加入雙重驗證機制中,額外得到的保障並不如期望的大。
  2. 只有當一切驗證措施,都由伺服器控制,雙重驗證才有意義。例如我們要求公鑰驗證法中的鑰匙,長度最少要 8192 bit,足夠安全了吧?但我們怎知道用戶不是把密鑰放在一部手提電腦或者手提電話等容易被盜取的設備中?即使設備中的密鑰已經用密碼保護,但這個密碼夠安全嗎?誰知道不是 abc123?用戶的密碼也有同樣的問題,即使我們強迫用戶定期轉換密碼,規定密碼的最短長度和複雜程度,但怎知道用戶不是在循環使用幾個舊的密碼?這些密碼不是寫在錢包裡的一張紙條上?甚至在其他系統中共用這幾個密碼?所以這些都不是 SSH 管理員可以控制的,但卻可嚴重減弱系統的安全性。

我認為雙重驗證總比單一驗證法好,好多少或者有爭議。密碼驗證法肯定不是最理想的驗證工具,更好的方法包括「一次性的密碼」(one time password,OTP),甚至是「有時間性的一次性密碼」(time based one time password,TOTP),這些驗證法超越了 SSH 的範圍,有興趣的話可以看一下這篇文章

限制可登入的用戶

即使有良好的驗證機制,我們也要限制只有獲授權的人士可以登入 SSH,AllowUsers 正好用來施加這種限制,但是當使用 SSH 的用戶越來越多,管理上會變得越來越複雜,例如每次從系統刪除一個用戶,也要在 /etc/ssh/sshd_config 中刪除他,增加日常管理的工作量,也增加安全風險。比較好的方法是使用 AllowGroups,並且在系統中設立 ssh-users 用戶群組,網羅有權登入 SSH 的人。

新增 ssh-users 群組:

加入用戶到這個群組:

/etc/ssh/sshd_config 中加入這一行:

修改完成後重新啟動 sshd

加密算法

透過密鑰交換算法,SSH 伺服器和和客戶端協商了一條只有他們知道,但偷窺網絡通訊的人無法知道的密鑰,在伺服器和客戶端雙方驗證身份後,便使用這條密鑰和一種對稱加密法把所有通訊內容加密,這一章討論的,就是如何選擇安全可靠的對稱加密法。CentOS 7 的 SSH 支援以下對稱加密法:

  1. 3des-cbc
  2. aes128-cbc
  3. aes192-cbc
  4. aes256-cbc
  5. aes128-ctr
  6. aes192-ctr
  7. aes256-ctr
  8. aes128-gcm@openssh.com
  9. aes256-gcm@openssh.com
  10. arcfour
  11. arcfour128
  12. arcfour256
  13. blowfish-cbc
  14. cast128-cbc
  15. chacha20-poly1305@openssh.com

我們首先簡單解釋一下這些稀奇古怪的名稱:

  1. 3DES, AES, ARCFOUR, BLOWFISH, CAST, 和 CHACHA20 都是加密法名稱。
  2. 加密法名稱後面的數字,例如 aes128-cbc 中的 128,是加密鑰匙的長度 (單位是 bit),不過 CHACHA20 中的 20 是名稱的一部分,不是鑰匙長度。沒有數字表示鑰匙長度固定。
  3. 連字符 (-) 後面的是加密法的工作模式,例如 aes128-cbc 中的 cbc 就是 Cipher-block Chaining (密碼塊鏈接),其他包括 ctr (Counter) 和 gcm (Galois/Counter Mode)。不過 poly1305 是訊息鑑別碼 (message authentication code) 名稱,並非 chacha20 的工作模式。

現在怎樣選擇好呢?我們有以下的篩選條件:

  1. ARCFOUR (又名 RC4) 已經被發現存在太多安全漏洞而被很多通訊協定明文禁止使用,包括 TLS,所以我們不會使用 10-12。
  2. 鑰匙長度當然越長越好,但是最少也要 128 bit,所以我們不會使用 3DES,雖然它理論上最長的鑰匙長度是 168 bit,但在 meet-in-the-middle 攻擊下,鑰匙的有效長度縮短至 112 bit。
  3. 工作模式方面,cbc 已被認為不夠安全,所以我們不會使用任何 cbc 的選項。
  4. 最佳選擇是把鑑別和加密合併的模式,即是 gcm 或者 poly1305。

所以我們理想的名單是 8, 9 和 15,其中 9 使用的鑰匙比 8 的長,而 15 又比 9 優勝,原因是 chacha20 是一個串流加密法 (stream cipher),它會把訊息的長度加密,不過 SSH 中的 GCM 卻不會加密訊息的長度,較大機會做成安全隱患

我們最後的加密法名單是 15, 9, 8,另外加上 7, 6, 5 三個具備 ctr 工作模式的加密法作為後備,如果你全部 SSH 客戶端都支援 15, 9, 8 三種加密法,便無需 7, 6, 5 了。在 /etc/ssh/sshd_config 中加入這一行:

訊息鑑別碼

訊息鑑別碼的用來辨別訊息是否被更改,有人認為一條已經被加密的訊息怎能被更改呢?即使更改了也沒法解密成可閱讀的文字吧?事實上隨便解密一條來歷不明的訊息,會洩漏很多加密鑰匙和原文的資訊

所以發送訊息的一方,必須先把訊息加密,然後根據密文和一條加密鑰匙,計算一個訊息鑑別碼,最後把密文和訊息鑑別碼一起發送給對方。接收的一方必須檢驗密文和訊息鑑別碼是否吻合,只有當兩者吻合才開始解密程序。

由於訊息鑑別碼是如此重要,一些加密法已經被改進,把計算訊息鑑別碼的程序包含在內,前面討論加密算法時提及的 GCM 模式正是如此,所以任何在 GCM 模式操作的加密法都一併計算了訊息鑑別碼,其他模式例如 CBC 和 CTR 等等,則必須另行計算訊息鑑別碼。

如何把加密和計算訊息鑑別碼兩項工作合併也有考究,基本上有以下三種方法:

  1. Encrypt-Then-Mac (EtM),意思是首先把原文加密,然後用密文計算訊息鑑別碼。
  2. Mac-Then-Encrypt (MtE),意思是首先計算訊息鑑別碼,然後把它連同原文一起加密。
  3. Encrypt-And-Mac (E&M),意思是首先把原文加密,然後附上原文的訊息鑑別碼。

唯一已被證明可靠的方法只有 EtM,其他方法都不要使用。

最普遍使用的訊息鑑別碼是 HMAC,它容許我們選擇一個散列函式 (hash function) 來計算訊息鑑別碼,SSH 支援 HMAC 和多種散列函式。此外 SSH 也支援一種比較新的算法 UMAC,它在不犧牲安全性的情況下,做出比 HMAC 更高的計算效率。

以下是 SSH 支援的訊息鑑別碼算法:

  1. hmac-md5
  2. hmac-md5-96
  3. hmac-ripemd160
  4. hmac-sha1
  5. hmac-sha1-96
  6. hmac-sha2-256
  7. hmac-sha2-512
  8. umac-64
  9. umac-128
  10. hmac-md5-etm@openssh.com
  11. hmac-md5-96-etm@openssh.com
  12. hmac-ripemd160-etm@openssh.com
  13. hmac-sha1-etm@openssh.com
  14. hmac-sha1-96-etm@openssh.com
  15. hmac-sha2-256-etm@openssh.com
  16. hmac-sha2-512-etm@openssh.com
  17. umac-64-etm@openssh.com
  18. umac-128-etm@openssh.com

選擇時我們需要考慮以下的因素:

  1. 我們不會考慮 MD5 和 SHA1 散列函式。雖然經過 HMAC 包裝後,我們不能再對 MD5 和 SHA1 進行衝突攻擊 (collision attack),消除了這兩個函式最致命的毛病,但是何必還糾纏於這些破破爛爛的函式?儘快把這些舊東西扔掉吧。
  2. 一定要優先使用 EtM,其他算法只能在客戶端不支援 EtM 時才使用。
  3. 散列函式的輸出,必須最少 128 bit,所以刪除了 umac-64。
  4. 加密鑰匙的長度必須最少 128 bit,這跟我們對加密算法的要求是一致的,幸運地所有 MAC 算法都符合這一項要求。

/etc/ssh/sshd_config 中加入這一行:

自動離線

讓一個長期閒置的 SSH 保持連線,對系統資源來說固然浪費,也可能因資源耗盡令一些正常的用戶無法登入,對安全性來說更是極大的威脅,這些連線為什麼長期閒置?倘若用戶已經完成工作,何不索性登出?倘若是忘記了登出,這些客戶端會否被其他人非法使用?客戶端程式是否發生錯誤,非正常地中止了?

為了解決這個問題,我們可以要求 SSH 在相隔若干時間(例如 60 秒)後沒有收到訊息,便向客戶端查詢:「你仍在嗎?」,倘若客戶端回覆說:「我仍在啊!」,那便皆大歡喜,重新計算閒置時間,倘若客戶端沒有回應,那也不能假定客戶端程式已死掉,可能系統過於繁忙,或者網絡短暫當掉,暫時無法回應,SSH 伺服器等 60 秒再查詢,如果連續查詢了若干次後(例如 5 次)仍然杳無音訊,便可以手起刀落,把連線切斷。

我們可以在 /etc/ssh/sshd_config 使用以下設定:

第一句指示 SSH 當客戶端連續 60 秒沒有送來任何訊息,便查詢一下它是否仍在,正常的客戶端收到這個查詢會自動回覆「我仍在啊!」。若果客戶端死掉或者網絡斷線,伺服器便收不到回覆。必須注意用戶無需作出任何反應,運作正常的客戶端會自動回覆。

第二句指示 SSH 連續 5 次收不到客戶端的回覆便自行斷線。

如果第二句 ClientAliveCountMax 設定為 0,表示 SSH 不會向客戶端發出查詢,只要 60 秒沒有受到任何訊息,便立即斷線,如此設定正好保障一些在離開電腦前忘記登出或關閉客戶端的用戶。

此外,我們也可以指示 SSH 用戶登入的時限,超時仍然不能登入的話便要重新連線,浪費入侵者的時間,減低暴力破解的速度。

這一句指示 SSH 倘若用戶在 120 秒內不能成功登入便自動斷線。

以上使用的數字都是示範,每一台伺服器,每一個管理員,每一個用戶都有不同的需要和安全需求,不可能有一組完美的設定,大家看着辦吧。

加入以上設定後重新啟動 sshd

有些人認為 ClientAliveIntervalClientAliveCountMax 本來的設計是檢查死掉了或斷線的客戶端,不是幫助忘記善忘的用戶登出系統,標準的做法是使用 TCPKeepAlive 選項,它才是為了這個用途而設計出來的。

我同意 ClientAliveIntervalClientAliveCountMax 本來不是為此而設計的,但是 TCPKeepAlive 卻有安全隱患,主要問題是「中間人」(Man-in-the-Middle) 可以偽冒客戶端向伺服器發出「我仍在啊!」訊息,ClientAliveIntervalClientAliveCountMax 所使用的訊息是透過加密頻道發送,「中間人」不可能偽冒。

登入監察

我們都不希望伺服器受到暴力入侵,暴力入侵是指黑客嘗試所有可能的密碼,直到成功登入,SSH 有一些設定可用來防範暴力入侵,前面提過的 LoginGraceTime 是其中之一,它限制每一個連線的登入時間,超時便會中斷連線。但是入侵者通常使用程式自動登入,而非人手輸入密碼,在時限屆滿前可能已經嘗試了千萬個密碼,有鑑於此,我們必須限制每個連線嘗試登入的最高次數:

這一句指示 SSH 倘若用戶連續 6 次不能登入便自動斷線。

此外,入侵者也不會只使用一個連線,他們會動員成千上萬的「喪屍電腦」(zombie machine) 同時接上我們的伺服器,同時嘗試所有可能的密碼,即使每個連線只容許 6 次嘗試,但如此大量的連線,嘗試的速度仍然非常可觀,系統和網絡的資源也會被嚴重消耗,所以我們必須限制連線的最高數量:

這一句指示 SSH 最多容許 100未登入的連線,除非部分連線成功登入,或者因為超過了 LoginGraceTime 時限而被中斷,否則不接受新的連線。

但是仍然有一個問題,數量龐大的「喪屍電腦」不停嘗試連線到伺服器,每當有一個連線被釋放,立即被另一台「喪屍電腦」佔據,正常的用戶和管理員怎能登入?不登入又還怎麼能解決危機?MaxStartups 有一個厲害的手段:

它指示 SSH 當未登入的連線達到 10 個的時候,新的連線便會有 30% 的機率被中斷,這個機率隨着未登入的連線數量上升而線性遞增,當數量達到 100 個的時候,便完全拒絕新的連線。很多人喜歡把最後一個數值弄大一點,例如 100 甚至 500,這樣伺服器不那麼容易被 DDoS 弄致動彈不得,當然,在網絡層面抵抗 DDoS 最有效率,應用程式 (SSH) 應該是最後使用的手段。

不分類但同樣重要的安全配置

這裡列舉了一些比較少用,只要保留它們的預設值便可以的配置選項,倘若不慎更改了配置值,在特定情況下會引起做成安全隱患。在新系統中你不用費神處理,但是在舊系統你還是最好檢查一下,小心駛得萬年船。

第一個是 IgnoreRHosts,如果你遵照本文第一部份的指示,使用第二代 SSH 通訊協定 (Protocol 2),亦沒有開啟 HostbasedAuthentication (預設關閉),可以不用理會這個選項。如果你使用第一代通訊協定,請立即重讀本文的第一部份,按照指示轉用第二代通訊協定。如果你開啟了 HostbasedAuthentication,請立即把它關掉,例如:

總之,正常情況下 (Protocol 2HostbasedAuthentication no),這個選項不發生作用,這個選項的預設值也是安全的。否則的話,請立即把你的系統調整到正常情況。

第二個是 ListenAddress,它令 SSH 只接受來自某些主機的連線,把來在網絡不知名地方的黑客拒諸門外,也減低了伺服器受到 DDoS 攻擊的機會。它無疑十分有用,但也很費工夫管理,情況就像本文第一部份中提到的 AllowUsers 選項。

第三個是 UsePrivilegeSeparation,登入 SSH 包含好幾個步驟:接受網絡連線、驗證用戶、執行客戶端指令等等。這個選項告訴 SSH 伺服器每一個步驟使用不同的進程 (process) 執行,每個進程只具備必須的權限。即使某一個步驟的 SSH 程式碼有安全漏洞,也因為權限有限而不會做成過多的破壞。這個選項預設值是 sandbox,這是最安全的設定。

第四個是 Compression,開啟後 SSH 伺服器與客戶端的通訊便會被壓縮,提高通訊的效能,在頻寬較低、CPU 效能較高的環境下,效果尤其明顯。這個選項跟系統安全有甚麼關係?這牽涉到 SSH 何時啟動數據壓縮這個工序。簡單來說,伺服器與客戶端連線後,第一步是交換密鑰 (請參閱前面有關密鑰交換算法的討論),第二步是驗證用戶 (請參閱前面有關驗證用戶的討論),數據壓縮就是在交換密鑰後發動的,注意當時還未驗證用戶,萬一連線進來的是一個黑客,壓縮的程式碼又有安全漏洞,驗證的過程便不可靠了。為了避免這種情況,我們可以指示 SSH 把數據壓縮延後到成功驗證用戶後:

這是預設的設定,可以把安全性提高一點點,儘管不是很巨大的改善,但既然是預設的,甚麼也不做便得到最好的,建議不要撥弄它。

第五個是 TCPKeepAlive,前面討論自動離線的部份已經談過這個選項,基於它的安全問題,不應該開啟這個選項,它的預設值也是關閉的。

第六個是 UseLogin,它指示 SSH 使用 Linux 的 login 指令來驗證用戶,Login 的安全性與 SSH 根本不在同一個檔次,就好像石器時代的斧頭不能跟現代的衝鋒槍相提並論,毫無疑問應該關閉這個選項,預設值也是關閉的。

第七個是 AcceptEnv,它列出哪些從客戶端送來的環境變量可被伺服器接受,Linux 不少運作受環境變量影響,這設計的原意是讓用戶(包括普通用戶)對系統的運作有更高和更細緻的控制權,但如果貿貿然接受從客戶端送來的變量,很容易做成安全隱患,比較有名的包括 LD_PRELOAD 攻擊,儘管你的客戶都是誠實可靠的人,但很難保證他們的電腦沒有受到入侵,所以這一道防線絕對不能鬆懈。我建議只接受跟文字語言相關的環境變量,包括所有以 LC_ 為首的變量名稱:

輔助工具

如果你讀到這裡,恭喜你,你對如何安全配置 SSH 有了更多認識,但是 SSH 始終是應用程式,很多來自網絡的攻擊比較容易在網絡層面偵查和堵截。所以建議你同時使用防火牆、日誌監察、濫用預警等程式,從多方面增強 SSH 的安全性。以下是一些比較多人討論的工具:

  • ufw – 防火牆設定工具,預防大量的登入請求
  • ban2fail – 監察 SSH 日誌找出可疑的黑客活動

參考資料

  1. Secure Secure Shell
  2. Top 20 OpenSSH Server Best Security Practices
  3. Security Guidelines on OpenSSH

CentOS 7 下安全配置 SSH (二) 有 “ 2 則迴響 ”

    1. 為甚麼要這樣做呢?沒有兩個系統是相同的,所以也不會有一個「萬用設定檔」適合所有系統。優秀的管理員應該理解每一項設定的技術細節,賦予最合乎系統利益的數值,這是我花這麼多功夫寫這兩篇文章的用意。不客氣說句,從網上抄寫拼貼別人的程式、設定檔,不願意花時間精神學習技術內容的,都屬於尸位素餐的管理員。

發表迴響

你的電子郵件位址並不會被公開。