☰

為什麼沒有密碼的使用者是一個壞主意（在這種情況下）？

tag-icon • tag-icon security users password non-root-user privileges
為什麼沒有密碼的使用者是一個壞主意（在這種情況下）？

我考慮過是否將其發佈在這裡或在安全 SE 中...但決定使用 Unix SE，因為這實際上並不是一個關於密碼學的問題，而是更多關於 Linux 用戶/權限的問題。也許我的谷歌今天很弱，但到目前為止我遇到的唯一的事情

  1. 在沒有任何具體例子的情況下，對這是一種「不好的做法」或「不受歡迎」做出非常籠統的回答，或者
  2. 有回覆假設沒有密碼的使用者俱有 root 存取權限，或以其他方式放棄所有可能的保護。

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

因此，讓我舉一個實際上讓我先思考這個問題的例子：

假設我正在考慮設定一個家庭系統，我的帳戶有一個強密碼root。另外，我還會有一個名為 fred 的非 root 帳戶那是不是在管理員群組中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 box 到 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，設定了// 。為了：MaxAuthTriesMaxSessionsPermitRootLogin noUsePAM yesChallengeResponseAuthentication noPermitEmptyPasswordsno 似乎是預設值但我已經明確表示了。

答案1

我能想到的最大的實際原因是某些網路軟體可能允許某人無需密碼即可遠端登入您的電腦。風險不在於您了解的軟體，而是您沒有考慮到的軟體。也許是您的發行版附帶的軟體。

對於無密碼用戶，您的工作是檢查電腦上的每個網路連線服務，看看它是否允許無需密碼的遠端登入。

一般的安全原則是，您希望透過將所有人鎖定在外面而不是讓任何人進入來「失敗」。 。

電子郵件伺服器就是這樣的一個例子。如果您有一台具有公共 IPv4 位址的計算機，那麼保證有將要每週甚至每天嘗試登入 SMTP。駭客只需循環遍歷每個 IPv4 位址，尋找易受攻擊的機器（位址只有 40 億個）。

同樣的 SSH。 OpenSSH 設定為拒絕沒有密碼（無需身份驗證）的登入嘗試，因此這很可能是安全的。但我每天都會看到一些駭客試圖找到密碼為空的使用者名稱。他們只是循環使用數千個常見的用戶名，希望能獲得幸運。

答案2

我通常會考慮這幾個方面：

  1. 遠端存取：

如果您有任何遠端存取選項，例如ssh主動訪問，那麼出於顯而易見的原因，這是一扇敞開的大門。在這種情況下，第 2 點和第 3 點尤其適用。

  1. 資料隱私和安全：

您的用戶暴露了非特權用戶可能不應該獲得的信息，當然您的日期可能會被任何人刪除。有些人只是破壞性的。

  1. 系統安全：

當然，正式使用者沒有管理員權限，但沒有系統是不可破解的。一旦有人以用戶身份訪問，沒有人會阻止他們上傳惡意軟體、利用安全漏洞、在本地編譯程序，然後破壞系統...

這取決於你願意在別人的道路上扔多少塊石頭。

所以問題是，當您還可以進行自動登入並至少避免其中一些風險，從而使實體存取的需求盡可能高時，為什麼還要使用非密碼使用者呢？

相關內容