Linux系統中使用者帳戶清潔與安全方法

2021-04-13 05:40:03 字數 2885 閱讀 8971

安全性是乙個龐大和具有挑戰性的主題,但每個負責伺服器端工作的人都應當知道基本步驟。cameron 概括了一些使您的使用者帳戶清潔和安全的方法。

安全性是一大難題。它不會一成不變,而且很難知道它需要擴充套件到多大程度:如果您不小心的話,當您的老闆真正想要的是不讓看門人看到他的年度預算時,您才會最終相信他需要理解安全性的好處。

不管在計算安全性的所有方面跟上潮流是多麼的具有挑戰性,畢竟有幾個領域已經足夠成熟,值得進行系統地學習。對於任何使用 linux 伺服器的人,我建議他學習的第乙個領域是帳戶管理。

注意您的使用者

在第一批專門介紹 linux 管理和程式設計的書籍中,許多都包括關於「使用者管理」或「帳戶管理」的一章。它們的意思非常明確:如何為使用您主機的人設定和維護計算帳戶和組關係。

在那時,「使用」必然意味著「登入」。帳戶管理的全部工作就是:使用諸如 useradd 、 chsh 等命令來配置 linux 帳戶,以便於由同部門開發人員占多數的使用者群使用。/etc/passwd 及其 api 是 linux 專家的關注重點。

那個時代早已成為過去,我對大多數伺服器提出的第乙個建議就是清除 /etc/passwd 的大部分內容。我的意思是:由於歷史原因,大多數電子郵件伺服器、web 伺服器、檔案伺服器等,都用 /etc/passwd 管理它們的使用者訪問。我認為這通常都是乙個錯誤。在早些時候,當可能有十幾個或二十幾個工程師共享一台高階工作站時,這是一種明智方式。但是,當一台電子郵件伺服器可能要處理幾萬名使用者(他們中的大多數只是把計算當成和飲水器或**系統一樣的公用設施)的郵箱時,傳統的 /etc/passwd 方式就是乙個錯誤。

依靠 /etc/passwd 當然是可能的。它經歷了足夠的修補和調整,足以應付令人驚訝的工作量。但不是必須如此。如果您將使用者帳戶移到專門的資料儲存,如 ldap(輕量級目錄訪問協議)甚至 rdbms(關聯式資料庫管理系統)資料儲存,您可以在可伸縮性、安全性和維護方面受益。將 /etc/passwd 限制為只供少數真正需要登入的開發人員和管理員使用。

這一實踐在安全性方面有很大好處,因為服務(電子郵件和 web 等)使用者的忙閒度與開發人員的完全不同。一旦您已設定好了一台新的伺服器,它的 /etc/passwd 就不應經常更改。監控它是否被更新 — 特別是篡改 — 是一項簡單的任務。但是,如果您正在執行乙個較大的伺服器,那麼每天都會有幾個新的和過期的電子郵件帳戶更改。需要將這些帳戶從 /etc/passwd 賦予的更大的訪問權隔離開來。

構建乙個替代性帳戶資料儲存是乙個認真而嚴肅的建議嗎?的確如此,這確實令人驚訝。為了使由無需登入的使用者占多數的非常龐大的 /etc/passwds 正常工作,過去幾年已經投入了大量的工作。如果您確實決定編寫自己的帳戶認證,並且依靠象 sendmail 這樣的傳統電子郵件程式,那麼您很可能發現自己正在為 **tp、pop3 和 imap4 伺服器編寫更改。

那些障礙常常使開發人員傾向於使用現成的軟體。我的習慣是使用別人已編寫好而我可以重用的解決方案。但是,與這些業界使用的伺服器不同的一點在於:我還是常常需要定製它們 — 例如,設定特殊訊息目錄、日誌記錄資訊或使用記帳。對我來說最重要的一點是使安全性考慮事項模組化。我希望能夠將開發人員和管理員帳戶與終端使用者服務完全分開地加以管理。通過將後者從 /etc/passwd 清除,我可以很容易地鎖定一方而不會影響另一方。

使策略自動化

和將開發人員帳戶與使用者服務分開幾乎同樣重要的是使策略自動化。為建立和刪除帳戶 — 既包括開發人員(/etc/passwd)的也包括終端使用者(電子郵件、web 和資料庫等)的 — 建立明確而詳細的過程。儘管將這些納入可執行檔案是很好的規定,但並不完全有必要。重要的是過程是可理解的和明確的。不小心的帳戶建立和刪除 總是會留下安全性漏洞。應當與人力資源、客戶支援或其它相關部門一起檢查您的過程。如果不親身體驗替代方案,那麼您很難認識到這是多麼關鍵。

當您沒有為新增和除去使用者帳號編寫過程時,則總會出現這樣的結果:假定新員工周一報到,那麼他或她可能到周五仍不能訪問其公司檔案。或者,某人辭職,在假日聚會做了道別,可在二月份開始時仍在檢索特殊用途的公司資產。

帳戶自動化乙個附帶的好處是它鼓勵更加徹底的驗證。如果開發人員沒有用不同特性配置帳戶的方便辦法,他們很可能不會執行那些預計將使配置發生變化的應用程式。

我最近親身經歷了這樣的情況。我因某個緊急事件而被召來,當時實現小組實際上在「正確地」允許經理檢視雇員業績評審 — 甚至包括那些不屬於他們管理的雇員!儘管聽起來可笑,但這是典型的安全性問題。它甚至在分析和設計評審期間被指出過幾次。雖然每次都向決策者反映了這個問題,但由於它是巨大而混亂的問題集合的一部分,所以它每次都在沒有明確決議的情況下被忽略。

只有當一位支援專家最終建立起乙個一般例項的具體示例(在該示例中有幾位經理,每位經理有多份雇員報告)時,錯誤才得到應有的注意。不要臨陣磨槍;要定期對所有種類的使用者帳戶的配置進行徹底的測試。

保持警覺

安全性最困難的部分,至少對我們中的許多人而言,是如何避免犯錯。安全性是屬於「最弱環節」事件之一,乙個漏洞就可以使您目前的所有投資(不管多麼龐大、計畫多麼周詳)一錢不值。要做好安全性工作,您必須對原本不會考慮的事情保持警覺。

美國****常常是證明那種挑戰的嚴重程度的最好例子。常在有關「反恐」的安全問題新聞中出現的某聯邦機構維護乙個**,在那裡使用者密碼在用於更改使用者首選項的頁面上公開地顯示。相當多的組織解決頻繁發生的丟失密碼問題的方法是:根據或多或少的公共資訊 指定密碼(例如,「您的密碼是您出生地的頭四個字母,加上您出生年份的後兩位數字」)。

如何能避免這樣的災難性錯誤?遺憾的是,幾乎沒有系統的方法能「聰明地」成功實現這樣的抽象目標。但是,在需要採取的有用步驟中,對 risks 文摘的研究和嚴格的工程檢查是有用的步驟之一。

您還應該養成讓其他人試驗您的想法的習慣。您可能認為「軟體檢查」不過是找出開發人員的源**中放錯地方的標點符號的一種方法,但它實際上是非常有趣和高效的實踐。特別是,檢查是對需求文件、**和所有其它產品的同行評審進行組織的極佳方法。請進行檢查。通過別人的眼睛檢視您的工作。您將有可能了解許多關於您伺服器的安全或不安全性的資訊。

linux系統中使用者

一 使用者身份介紹 1 系統管理員使用者,uid user identification 0,2 系統使用者,uid為1 999,預設的程式都有獨立的系統使用者負責,執行,進而控制被破壞的範圍,3 普通使用者,uid 從1000開始,由管理員建立,用於日常工作的使用者,注 建立使用者時,uid不能重...

Linux 系統中使用者切換

1.linux系統中使用者切換的命令為su,語法為 su fmp c command s shell help version user arg 引數說明 f fast 不必讀啟動檔案 如 csh.cshrc 等 僅用於csh或tcsh兩種shell。l login 加了這個引數之後,就好像是重新登...

Linux系統中使用者切換

1.linux系統中使用者切換的命令為su,語法為 su fmp c command s shell help version user arg 引數說明 f fast 不必讀啟動檔案 如 csh.cshrc 等 僅用於csh或tcsh兩種shell。l login 加了這個引數之後,就好像是重新登...