文/辛毅
長期以來,高校信息系統安全問題非常突出,大多數高校的信息系統缺乏有效的規劃與安全設計,尤其是網站類系統的開發成本低,多為基于開源CMS系統進行簡單的修改后上線,一些網站的架構已經過時存在大量的漏洞,沒有人員進行升級或者修補。高校的開放性造成了樓宇(非數據中心)IP直接配置服務對外開放,因缺乏必要的安全技術防護措施。這些系統成為不法分子攻擊的目標或攻擊的跳板。安全遵循“木桶原理“,此類問題會給全校整體的網絡安全造成重大的危害。信息系統需要進行安全設計、安全規劃、安全實現并在上線前進行安全檢測,執行安全準入策略從而提高全校整體的安全水平。
按照《網絡安全法》等國家相關法律法規,我校制定了《哈爾濱工業大學網絡系統安全管理規定》,按照“誰主管誰負責、誰運維誰負責、誰使用誰負責”的原則切實落實網絡與信息安全責任,并規定了“校內各系統各網站上線前須上報網絡中心進行安全檢測,未通過安全檢測的系統一律不得上線。系統運行后,須接收日常安全掃描、漏洞測試及滲透測試,對于有嚴重問題的須停網整頓。依據安全通報,使用單位須進行安全加固并提交整改報告,經檢測合格后,方能重新開放。使用單位須定期進行安全風險分析與系統漏洞測試,適時升級系統、應用軟件,修補漏洞,確保系統安全、可靠、穩定地運行”。學校在《關于校園內信息系統(網站)統一管理的通知》中要求“落實工信部及教育部文件“禁止未經保護IP對外提供服務”的工作部署。學校決定,“加強信息系統(網站)的管理,要求校內各單位將信息系統(網站)遷移至學校網站群系統或申請虛擬服務器進行服務托管。”以上管理制度與政策為開展安全準入工作奠定了政策的基礎。
在政策制定后,哈工大對于未經評測的系統停止外網訪問權限,待安全評測合格后,提交《信息系統安全技術保障方案》、《信息系統安全事件應急處置預案》、《信息系統值守方案及人員安排》及《非“僵尸”信息系統佐證》后簽訂《網絡安全承諾書》方可上線。
安全準入評測前需要用戶或開發方遵循技術文檔,并提供其系統信息。
系統遵循的文檔
1.系統要求
(1)系統必須保證為正常上線系統,須更新為最新。禁止采用失去技術升級的系統(如:Windows 2003等);禁止采用含有已知漏洞的組件、應用程序、框架(如:Struts 2.5 - Struts 2.5.10)、應用程序服務器、Web服務器、數據庫服務器和平臺定義,以上系統必須執行安全配置,禁止默認安裝。所有的軟件應該保持及時更新。
(2)保證系統服務正常與上線系統一致,無各種調試、報錯信息(如:斷點,printf等調試信息)及注釋信息,系統需刪除系統默認安裝的各種例程、文檔及管理程序;
(3)系統中禁止暴露配置信息(如數據庫連接信息),源碼備份文件,.git,.svn倉庫等。
2.服務端口要求
(1)從本機關閉不需要的端口(如:關閉Windows netbios等服務),設置本機防火墻如iptable對于訪問的源地址進行限制,同時相關服務設置類似host.allow,host.deny等策略;
(2)須按照標準端口配置http或https服務,嚴禁自行設置服務端口不報告。
3 .數據庫配置要求
(1)數據庫和應用系統如在同一臺服務器,須采用本機回路進行訪問,如前端及數據庫分為不同服務器,須設置本機防火墻訪問規則,禁止非前端服務器訪問數據庫網絡端口;
(2)使用最低權限的數據庫用戶作為Web應用所需,禁止具有不必要的額外權限。
4. 開發要求
(1)對用戶輸入進行嚴格有效過濾防止sql注入,xss跨站腳本,命令執行,crsf跨站請求偽造等,建議采用白名單過濾策略;
(2)禁止在HTTP請求中以明文或可逆編碼(如base64、url編碼等)的形式傳遞SQL語句到后端程序代入執行,禁止由Web前端直接生成和傳遞SQL語句到數據庫進行執行,數據庫查詢必須采用預編譯和參數結構化查詢。如果程序確實需要將SQL語句作為內容(非可執行代碼的形式,如學生畢業設計、代碼樣例等)到后臺,請在項目上線交付前書面說明相應的功能代碼及位置;
(3)控制上傳點,對于上傳文件類型進行嚴格控制(禁止用js進行控制),同時上傳目錄不能有執行權限,原則上不允許有未經登錄驗證的上傳點;
(4)設置有效的身份認證、會話管理及訪問控制機制,防止越權、平行權限及提權等(禁止利用js進行控制及驗證)。
5.密碼復雜度要求
系統必須有密碼復雜度檢查模塊,設置有效的驗證碼或者滑動等手段防止暴力破解,密碼長度須大于8位,含字母(大小寫)、數字及符號組合,重要系統須采用二次認證。禁止在數據庫中明文存放用戶密碼,需進行帶salt的哈希之后入庫。對于多次錯誤登錄進行封堵。如果長期不登錄默認賬號應停用處理。
6 .數據保護要求
對于身份信息、單位職務、財務信息、健康信息、訊通信息等敏感信息禁止在數據庫中明文存放。
評測前提供的信息
1.提供操作系統版本、補丁情況;
2.開放的網絡端口及用途;
3.提供所有第三方的中間件、開發包、數據庫、服務版本及管理地址,密碼(必須為復雜密碼評測后更改);
4.系統訪問路徑;
5.系統的用戶登錄路徑;
6.系統的管理端路徑;
7.系統密碼的設置策略。
評測流程及方法
接到用戶及開發方提供的技術文檔后,網絡中心技術人員采用漏掃及開源滲透工具對系統進行黑盒滲透測試并提交滲透報告,滲透測試期間測試服務器僅對滲透人員的ip開放服務保證了有漏洞的系統不能對外服務,用戶接到系統安全評測或滲透報告后須提供詳實可行的整改報告,經網絡與信息中心驗證合格后方可上線。流程如圖1所示。

圖1 評測流程
從2017年11月哈爾濱工業大學校實現數據中心統一出口管理以后,對于新上線及遷移的信息系統進行了全面的安全評測,評測的系統及網站共有126個,發現各類漏洞371個。個別系統復測10次以上才上線,極個別系統無法進行修復不能上線運行。其中不乏Struts2(S2-045)、SQL注入、Weblogic反序列化漏洞、任意文件上傳、弱口令、Fckeditor任意文件上傳、任意密碼重置等高危漏洞。其效果有幾點:首先,經過安全評測在系統上線之初將有關漏洞消滅在萌芽中,強化了系統的安全性。其次,有助于全面掌握全校的信息資產情況,與威脅情報進行關聯,可以第一時間定位到漏洞,做到有針對性的緊急響應、應急處理。第三,在系統上線前確定服務對象,對于面向校內的服務不對互聯網開放,從而劃清服務界面,規避安全風險。最后,通過安全評測準入可以對一些“僵尸”系統、“小散亂”系統及“雙非系統”進行清理,切實提高了我校的網絡安全水平。
但是,由于安全滲透人員水平有限,不能發現全部的漏洞,因此還存在一些不可預見的風險。同時由于數據中心托管系統的管理權問題,對于未經上報的代碼更新以及功能改變可能帶來新的安全風險,因此須加大日常安全掃描及巡查的力度,爭取做到第一時間發現問題并進行修補。