Security

為什麼讓沒有密碼的使用者是個壞主意(在這種情況下)?

  • June 11, 2021

我考慮過是在此處發布還是在安全 SE 中發布…但決定使用 Unix SE,因為這實際上不是關於密碼學的問題,而是更多關於 Linux 使用者/權限的問題。也許我的 google-fu 今天很弱,但到目前為止我遇到的唯一事情

  1. 在沒有任何具體例子的情況下,對它是“不好的做法”或“不贊成”有非常籠統的回答,或者
  2. 有回复假設沒有密碼的使用者具有 root 訪問權限或以其他方式放棄所有可能的保護。

需要明確的是:我並不是在提倡這樣做,實際上是在尋找這樣做的正當理由,但我想找到具體的原因,而不僅僅是“這很糟糕”。:-)

因此,讓我先設置一個讓我開始思考這個問題的例子:

假設我正在考慮建立一個家庭系統,我的root帳戶上有一個強密碼。此外,我將擁有一個名為 fred 的非 root 帳戶,該帳戶不在admin 組中wheel(或sudoers在 Debian / Ubuntu 上)。在這個系統上,我還將擁有/home一個單獨的、LUKS 加密的分區,該分區在引導過程中被解鎖。換句話說,在 GRUB 和登錄管理之間仍然輸入了密碼 - 但登錄管理器設置為自動登錄。除此之外,假設我還設置(從根):password -f -u fred強制解鎖密碼fred(有效地使密碼為fred空)。


**在這種情況下,我可能會遇到什麼樣的安全問題?感覺應該有一些很好的理由讓你不想這樣做。**但目前唯一想到的是:

  • 當螢幕保護程序鎖定觸發時,LUKS 分區不會關閉(至少,不是在 Cinnamon 上,並且假設一個設置為觸發)。因此,如果有人闖入我的房子並且fred已經登錄,他們可以坐下來打開顯示器,然後繼續查看任何fred可以訪問的東西 - 只要他們沒有先拔掉/重啟/帶走電腦(從而重新鎖定LUKS)。而且我懷疑如果我足夠努力,我可能會找到一種方法來在螢幕保護程序被觸發時呼叫腳本,然後從所述腳本中鎖定 LUKS,從而關閉這個漏洞(或者也許 kde/xfce/gnome/etc 已經有一些方法照顧這個?)。

即使fred有一個很好的強密碼,他也無法在沒有管理員身份的情況下安裝軟體/弄亂系統設置。而且,我不確定,但我認為瀏覽器/Wine 對文件的訪問不會改變。這裡有什麼比有密碼更危險fred 嗎?

編輯:我認為這並不重要,但發行版是 Fedora(啟用 SELinux),但如果您對另一個發行版(或沒有 SELinux)的回答感到更自在,那很好。

編輯#2:關於ssh/ samba。我通常設置一個/media/sdb1/shared文件夾之類的東西,而不是使用 samba 的$HOME共享或任何它們被稱為的東西。我發現在像在家這樣的小型使用者設置中設置它相當容易(我顯然不會在工作環境或併非所有使用者相互信任的設置中這樣做)。但我總是使用單獨的、受密碼保護的 samba 使用者帳戶(與登錄時使用的使用者不同),並且我遵循幾個指南來加強我的smb.conf設置。如果您在此設置中發現缺陷,我將認為它們對於在登錄帳戶上使用空白密碼攻擊假設場景/設置是有效的fred(但請記住,samba 帳戶密碼不是空白)。

對於ssh,我想確認預設情況下所有帳戶(不僅僅是root)都拒絕空白密碼。如果不是,那麼我會認為 FelixJN 的回答是有效的。否則,我會 - 類似於samba- 可能使用我通常使用的相同設置,這是預設配置的強化版本。我不記得為此更改了許多設置,因此我將嘗試查看是否可以準確找到我通常修改的設置並將它們包含在此處。在我腦海中,我知道我改變了埠號,這並不重要。

在確認ssh拒絕時,我驚訝地發現在 LM19passwd上似乎不支持-f(強制)標誌,所以奇怪的是我只能在 fedora 上創建一個空白密碼的非 root 使用者。當我試圖ssh從 LM19 盒子到 Fedora 時,它被拒絕了:

   $ ssh -p 2468 fred@fedora-testbox
   fred@fedora-testbox's password: 
   Permission denied, please try again.
   fred@fedora-testbox's password: 
   Permission denied, please try again.

除了埠,看起來我還增加了可接受的最小密碼/MAC/KexAlgorithms,減少LoginGraceTime/ MaxAuthTries/ MaxSessions,設置PermitRootLogin no/ UsePAM yes/ ChallengeResponseAuthentication no。For PermitEmptyPasswords: no 似乎是預設設置,但我已明確表示。

我能想到的最大實際原因是某些網路軟體可能允許某人在沒有密碼的情況下遠端登錄您的機器。風險不在於您知道的軟體,而在於您沒有考慮過的軟體。也許是您的發行版隨附的軟體。

對於無密碼使用者,您的工作是檢查您機器上的每個網路連接服務,看看它是否允許在沒有密碼的情況下進行遠端登錄。

一般的安全原則是,您希望通過鎖定所有人而不是讓任何人進入來“失敗”。如果您有無密碼的使用者,那麼錯誤和簡單的疏忽更容易在某處解鎖某些後門。

一個這樣的例子可能是電子郵件伺服器。如果您有一台具有公共 IPv4 地址的機器,那麼可以保證,每週甚至每天都會嘗試登錄 SMTP **。**黑客只是循環遍歷每個 IPv4 地址來尋找易受攻擊的機器(只有 40 億個地址)。

同樣的 SSH。OpenSSH 被配置為拒絕沒有密碼(沒有身份驗證)的登錄嘗試,所以這很可能是安全的。但我每天都會看到一些黑客試圖找到密碼為空的使用者名。他們只是在數以千計的常用使用者名中循環,以期獲得好運。

引用自:https://unix.stackexchange.com/questions/653764