技術中心主任兼技術開發部主任　張偉

　　說實話，2009年2月進入大眾網1個月內，我還不知道大眾網和大眾日報社的關系，當初應聘只是當作一份普通的網站工作來看待的，原本也只是想做個安逸的論壇管理員。但是我有個固有的毛病——工作狂，直到現在也改不了，所以工作沒幾天就被領導發現了在技術方面的能力，此后幾乎每天都通宵達旦加班寫代碼、研究系統，開始了大眾網技術生涯。

　　2009年、2010年，這些工作還比較得心應手，是以往所學的充分應用，但是2011年，我感覺要挺不住了。

　　2011年，網站的開發和運維任務像雪片般飄來，但是技術開發部的人員并沒有增加，人員培訓、任務分解、任務優化、任務重組這些項目管理的基本方法都已經用上了，仍然無法滿足網站工作的需要，需要做的運營網站系統、編輯發布系統以及網站運維必須的基本支撐系統實在太多了，通過不斷努力和取舍，在2011年的工作計劃中基本能夠排開。真正讓我感到很強的崩潰感的是3月13日出現的重大網站安全事件。

　　3月13日，論壇發現主題ID發生錯亂，從最初的8位數變為10位數，論壇主題本身應當代表的意義是論壇主題總數。突然發生這樣的變化，不可能是主題數從2千萬增加到20億，一定是由于論壇出現了BUG或者被篡改造成的。通過分析，以我們目前的系統架構能力，論壇容納40億主題沒有問題，況且實際主題數量只有2千萬；再從比較保守的角度去分析，架構中的php環境存在處理數據最大值的限制，當數字超過9位數可能會發生錯誤，即使這樣，我們的論壇最少可以容納2億主題。

　　雖然從論壇的容量來講，我們的容納能力很高，但是，已經開始出現10位數的ID，開始逼近論壇的最終容量并且已經超過了PHP環境的良好工作范圍。也就是說，如果不立即找出問題根源并解決問題的話，論壇很快就會停轉。因此技術開發部立即成立論壇問題處置小組，由技術總監李雪修為組長，由我、孫世強、丁磊、趙容濤為成員，后來崔曉輝加入，對論壇ID錯亂的問題進行專題分析。

　　經過分析查找，論壇ID分別于2月21日、2月28日、3月9日、3月15日發生過變化，并在3月15日出現論壇ID超出論壇最大允許ID數導致論壇無法發布新帖。

　　我們首先懷疑與發生論壇ID 錯亂的時間點比較吻合的新聞跟帖導入論壇功能，該功能于2 月21 日正式上線，我們首先停用了該功能，并對相關代碼進行深入分析，但分析結果表明，論壇ID 錯亂與該功能無關，因為如果是該功能導致的故障，會是由該功能發布的新論壇帖子ID 出現變化，而出現ID 變化的帖子均不是新發的帖子，ID 變化的帖子中甚至有2009 年的帖子。

　　論壇更換為Discuz 系統同時使用MySQL 數據庫已經有2 年時間了，在以往論壇ID 一直正常；論壇ID 在MySQL 數據庫中以ID 的形式保存，一一對應，同時代表著論壇帖子的基本數量級。對于MySQL 數據庫，8 位數的論壇ID 不存在溢出導致進錯位的情況（MySQL 數據庫不做任何升級的情況下，最大支持42 億的論壇帖子數量）。

　　從數據庫的角度分析，論壇故障不會是數據庫Bug 導致的。但由于論壇ID 已經變成10 位，而論壇主腳本語言PHP 在數字位數大于9 位時會出現運算錯誤，所以10 位數的論壇帖子打開會出現錯亂。

　　再從論壇Bug、安全漏洞角度入手分析，期間，我們查找了大量的網絡文章、咨詢Discuz 廠商康盛公司、咨詢綠盟等安全服務廠商，近期Discuz 論壇未爆出任何安全漏洞。同時從安全服務廠商處獲取了查找安全漏洞的一些新的思路（例如遠程包含），準備多角度分析論壇是否存在漏洞。在對可疑源代碼進行了大量細致的分析后未發現可疑、危險操作。 但是，為了保障ID 錯亂不是由論壇本身的安全漏洞導致的，我們在論壇底層做了過濾處理，當發現對論壇ID 進行處理的操作時，立即記錄操作行為發起者IP、使用的功能鏈接，同時立即終止該操作。3 月15 日，我們又在論壇數據庫中增加了MySQL 解析專用sniffer，用于嗅探記錄所有MySQL 數據庫操作，該記錄能夠完整記錄數據庫操作內容、IP 地址等信息。

　　在3 月15 日論壇ID 出現溢出，導致論壇無法發新帖的時候，我們進行了第一次論壇帖子ID 修復，該工作于下午14：00 完成。當晚隨即發現論壇帖子ID 再次變化為9 位，經過對論壇底層記錄分析發現，出現論壇ID 錯亂并非論壇功能本身所為，我們于15 日后半夜增加了論壇數據庫嗅探。因為論壇數據庫嗅探屬于比較占用系統資源的操作，需要記錄過濾所有的數據庫操作，增加該操作會導致系統性能降低，所以只有到了萬不得已才會啟用該操作。

　　經過3 月15 日的論壇ID 變化，已經可以下結論，論壇ID 是被惡意篡改的，論壇體系中存在重大安全隱患！從篡改論壇ID 的數據庫操作動作來看，篡改者擁有的權限很高，如果不及時清理，將可能出現論壇數據被清空、被篡改為反動內容等高度危險的情況。

　　3 月16 日和17 日我們對論壇進行了大量的安全掃描（使用我們自己開發的網站安全掃描工具）和文件對比、查找，并在17 日成功記錄下了篡改操作的發起服務器，在博客所在的服務器查找到了4 個含有惡意代碼的后門文件，其中3 個為文件上傳型后門，1 個為任意代碼執行型后門，危害程度極高，我們立即對這些惡意代碼進行了清理，并對相關的用戶權限進行了限制。

　　3 月18 日上午9：20，在數據庫嗅探記錄中再次發現篡改論壇ID 的動作，但由于17 日的安全加固，該篡改行為沒有成功執行。同時嗅探記錄中發現開心公社的服務器也進行了非法操作。這樣我們就將整個論壇服務器群加入掃描目標，分別在博客服務器、開心公社服務器、UCenter 服務器掃描發現各種含惡意代碼的后門程序，其中包含文件上傳型、任意代碼執行型、base64 加密型后門。期間我們根據惡意代碼衍生情況，再次修改了我們的安全掃描軟件，為日后惡意代碼掃描工作提供了更有效的保障。

　　經過3 月19 日和20 日，對論壇服務器群所有服務器的詳細掃描、文件對比后，論壇安全隱患基本排除。截止到目前，未發現新的篡改記錄。

　　但是到3 月22 日，論壇再度出現ID 錯亂情況，說明系統中隱藏的攻擊還在進行，通過掃描，又發現幾處新的更隱蔽后門，篡改手法跟之前一樣。但是此時，我的心里已經有了很大的陰影，感覺到論壇群還存在隱藏的東西，只是還沒能發現出來。所以，在這次清理后門結束后，我們收縮了數據庫的權限設置，使得很多權限設置更加嚴密。之后幾天不斷的查找各種后門特征，找到新的特征就對論壇再次掃描，不斷重復重復再重復這個動作。但是一直沒能突破。

　　3 月25 日，論壇再次出現問題，這次是用戶ID 出現錯亂，說明之前對于主題表的權限設置生效了，入侵者沒能篡改成功，于是改為篡改用戶數據。我們及時搜查了后門也搜到幾個，同時收縮了用戶表的權限。但這件事充分驗證了之前的擔憂，說明論壇中確實還存在隱藏的后門。

　　3 月26 日，經過若干天的苦戰和偌大的心理壓力，我終于挺不住了，睡了整整一下午，起床后第一件事就是看QQ 記錄，結果，看著看著，我崩潰了。按照QQ 顯示，論壇再度出現ID 錯亂！難道我們最終的權限也被攻破了？不過還好，經過分析，QQ 消息是虛報，只是搜索引擎中存在的以前錯亂時候的殘留信息。

　　后來經過不懈的努力和大量的文件比對工作，終于在3 月27 日將博客服務器中隱藏的后門揪了出來。

　　在整個論壇ID 錯亂處置過程中，孫世強、丁磊、趙容濤、崔曉輝均表現出高度的責任心，每天加班到深夜，對每個文件都詳細對比，每段代碼都詳細斟酌，為排除論壇安全隱患做了大量的工作和努力。

　　大眾網技術，敢當不敢當？大眾網技術——敢當！