作為廣受用戶認可的網頁安全類產品,iGuard的誕生也是值得分享的天存軼事之一。iGuard之源起,與其研發團隊天存信息是一家有著Web瀏覽器開發技術背景的公司不無關系。可以說,iGuard是一款無心插柳卻也順理成章的產品,它脫胎于天存團隊最初開發iBrowser/iServer——首款簡體中文Web瀏覽器/服務器的經驗積累。在iGuard誕生前,開發者已經對Web底層技術有了相當深入的理解,因此,回顧iGuard的起源,也可一窺天存信息的Web安全探索之路。
2002年,通過對Mozilla和Apache源碼2多年的跟蹤、剖析和補丁工作,我們對HTTP/S協議在瀏覽器端和服務器端的設計原理和實現細節有了較為深入的了解。我們做的補丁不僅可以任意過濾修改報文,甚至能處理自定義的通信協議。然而,技術上的先進與商業上的可行并沒有必然聯系,這些技術如何變現呢?
有了微軟的免費捆綁IE,Web瀏覽器是指望不上了,要不做個Web服務器賣錢?當時Netscape Enterprise Server列表價大約1000美元,不過這樣的好時光很快就要結束了:微軟的IIS和Apache都越來越好用和成熟了,關鍵是它們都是免費的。
天存信息的潛在產品,不是大廠免費就是已然開源。當然,憑著對HTTP協議的理解和技術儲備,天存信息轉行去做Web應用系統開發(當時B/S和C/S之爭已經明了,未來一定是B/S的天下)肯定不成問題,問題只是殺雞用牛刀有點可惜。
主材沒法做,我們就做點輔材吧。信息安全講求機密性、完整性和可用性,網頁的完整性如何保證呢?怎么確保發出的網頁沒有被改動過的呢?我們就做一個“網頁完整性檢查系統“吧:它內嵌于現有的Web服務器軟件中,當網頁被訪問時進行完整性檢查。
輔材的想法不錯,如何嫁接到主材上?在2年多的研究工作中,天訊信息對4種主流的Web服務器的接口都有了充分的了解(它們分別是:ISAPI、Apache-module、NSAPI、Java-filter),也就是說天存信息對Web服務器的榫卯結構很清楚,天存信息做一個榫頭嵌入到卯口中即可,這個榫頭天存信息稱之為Web服務器核心內嵌模塊。
還有一個問題,既然是做完整性檢查,必然需要有一個檢查基準,基準如何生成?天存信息利用在高性能高穩定服務器方面的技術積累,開發了一個高效可靠的網頁發布模塊:只有通過這個模塊發出的網頁才是可信網頁。整個過程是:網頁在被發布時生成鑒別碼(數字水印),在被訪問時檢查鑒別碼。
幾個月后,“網頁完整性檢查系統”的做好了。它的英文名很好取,因為以前我們做的瀏覽器叫iBrowser服務器叫iServer,這個新的安全產品就叫iGuard了(跟蘋果一點關系沒有)。中文名很難取,用現在時髦的說法iGuard是一個新“物種”,市場上根本沒有同類東西。如果稱為 “網頁完整性檢查系統",大部分人都不會知道什么,天存信息以其目標來稱呼它——網頁防篡改系統。
iGuard網頁防篡改系統由于其特殊的部署部位,帶來了幾個有意思的地方:1)防護模塊與Web服務器軟件一體,沒有單獨的進程和服務,對攻擊者是隱身的;2)即使網頁被某種未知技術給改了,它可以阻止網頁被發送出去,算是最后一道防線;3)發現網頁被修改后可以自動發起恢復流程,可稱之為自行運維;4)它在網頁存續的全生命周期中持續生效,陳年網頁及鏈接資源的每次訪問都會進行檢查。
應該說,當時市場上也有檢測網頁被篡改的產品,它們通過一個外部的爬蟲來監測網頁,多數稱為主頁防篡改產品。因為爬蟲效率有限且只能跟隨鏈接行進,無法對所有網頁進行防護;更重要的是它無法區分動態網頁的框架和內容,對網頁內容的變化無從判斷其合法性。至于之后出現的為網頁文件加鎖的手段,在技術上則更為簡單,基本上是一個基于操作系統底層的工具軟件而非完整的系統。
從信息安全的發展歷程來看,當時業界主要關注的還是網絡層面上的安全,即使在主機上也多采用被動保護的手段。iGuard網頁防篡改系統自誕生之日起就不自覺地采取了“保護-檢測—反應—恢復“的現代防御策略對信息主體進行保障,這使得它在Web安全市場上占有一席之地。而iGuard的主體Web服務器核心內嵌模塊也算是對天存信息Web服務器研究工作的一個紀念吧。