在某公司做了乙個專案，查詢公司幾十萬臺主機的root密碼是否是弱密碼。
該過程涉及到任務下發，資料處理和上報等過程，這裡不介紹其他模組，只介紹收集部分。
一、怎麼判斷linux主機密碼是否是弱密碼
首先linux下面的密碼儲存在passwd和shadow檔案中，其中passwd檔案儲存賬戶名，shadow檔案儲存密碼hash值，只有root許可權才能看到shadow檔案內容
然後linux下密碼hash格式如下：
$6$wyvk1x5b
$ymsye85080w5okrftvvjgxcmt/qrajk4e07ukxhnx4gtny3/hwfpebpj9p1g4qqmnwk0eaxumfoltnfsfm5hx1
其中黃色部分代表加密方式：
（1）如果密碼不是以$開頭，則密碼是以eds加密，文字全部為密文（暫時沒有見到）
（2）如果密碼以$1開頭，表示使用md5加密,加密後是22個字元
（3）如果密碼以$2a開頭，表示使用blowfish加密（暫時沒有見到）
（4）如果密碼以$5開頭，表示使用sha256加密，加密後是43個字元
（5）如果密碼以$6開頭，表示使用sha512加密，加密後是86個字元
綠色部分為使用以$開頭的加密方式加密時使用的salt
藍色標記部分為密碼加密後的密文
根據以上規則提取出使用的加密方式，將弱密碼庫中的密碼使用對應的加密方式加密，然後對比看是否相同，若有相同則可判定該密碼為弱密碼。
二、怎麼收集弱密碼
提取主機的密碼有如下兩種方案：（1）將幾十萬臺主機的密碼hash值全部收集到server端，然後再進行撞庫判斷；（2）將弱密碼庫下發到主機端，在主機端進行撞庫。
首先第乙個方案的好處是，收集和計算很方便，壞處是，將大規模的密碼收集到乙個地方是非常危險的操作。
第二個方案的好處是，除去了弱密碼聚集在一處的風險，壞處是將弱密碼庫下發在主機端進行計算不方便，而且下發資料量有點大。
我們最終選擇第二個方案，因為我們認為主機密碼的安全級別比較高，而弱密碼庫在公司內部不是很機密。雖然如此，我們在下發弱密碼庫的時候還是將弱密碼庫進行加密處理，在主機端再進行解密判斷，這個過程中，弱密碼庫中的密碼沒有落地，在主機記憶體中完成判斷後刪除，在一定程度上保證了弱密碼庫的安全。
三、大規模主機的相容性
一般資料處理採用python進行處理，但是基於幾十萬臺主機的情況下，python的版本很可能不一致，比如python的2.和3.版本就不相容，所以在大規模主機上執行python**時需要先檢查python的版本，如果版本統一，則可以使用python，如果版本不統一或者不相容的情況下，則需要考慮其他相容性好的語言，比如，我是用的是shell語言。
四、執行時出現的乙個問題
後來發現是使用nohup+&後台方式啟動時，該主機的sudoer檔案中規定不能執行sudo命令，導致執行失敗。注意，在執行該指令碼時，已經是在root許可權下，所以沒有必要再使用sudo。
記錄一次大量CLOSE WAIT的情況
近期的專案中，有乙個特殊的需求，對於每個客戶端程式有若干個機構，對於每個機構有不同的客戶端證書，程式間隔一段時間向服務端進行請求，根據請求的成功與否更新各機構的狀態 如正常，證書未配置，證書過期等 實際投入測試環境進行使用的時候，執行了一段時間之後，客戶端程式出現了大量的close wait的情況，...
一次對抗大規模DDoS的真實經歷
每個 都會面對網路攻擊。唯一的區別在於，如何建設防禦，以及如何進行警報和響應。在網路上很難找到關於防禦黑客攻擊的真實案例。一方面，資訊披露可能會引發官司，另一方面，披露這些資訊往往會導致不良的財務後果，因此各公司往往不情願分享相關細節。然而，如果我們完全不披露這些故事，會使其它人在不知情的情況下犯相...
收費系統體會 1 一次糾結就是一次大的進步
15號開始做系統.30號正式做完.經過了整整半個月的時間.自己在這段時間裡發生了很大的變化.無論是在技術上,還是思想上.都感覺進不了很多.利用這幾天的時間.逐步總結,完善一下收費系統.這裡主要說說自己在思想上的體會.做系統的時候,大約經過了三次大的糾結.第一次是剛剛做第乙個功能.登入模組設計.最初的...