專利名稱：一種實現(xiàn)安全反向代理服務的方法
技術領域：
本發(fā)明涉及安全反向代理服務器領域，更具體的是在內(nèi)外部網(wǎng)絡之間架設安全網(wǎng)關，在網(wǎng)關上設置安全反向代理服務器，保護內(nèi)部應用服務器免于遭到破壞，增強內(nèi)部應用服務器的安全性的方法和裝置。
背景技術：
目前國內(nèi)外大中型企業(yè)均在企業(yè)內(nèi)部設置多臺應用服務器，為企業(yè)內(nèi)部資源使用的便利性提供幫助，包括:企業(yè)內(nèi)部郵件服務、協(xié)同辦公系統(tǒng)、財務管理系統(tǒng)等等。當企業(yè)用戶使用外部網(wǎng)絡通過代理服務器訪問各應用系統(tǒng)時，一般將此代理服務器成為反向代理服務器。對于此反向代理服務器來說，服務器上沒有保存任何網(wǎng)頁的真實數(shù)據(jù)，所有的靜態(tài)網(wǎng)頁及WEB程序，都依然保存在企業(yè)內(nèi)部的應用服務器上。對反向代理服務器的攻擊并不會使得企業(yè)內(nèi)部的應用服務器遭到破壞，這樣就增強了企業(yè)內(nèi)部應用服務器的安全性。目前反向代理服務器均是支持HTTP的代理，但隨著日益提高的安全等級，普通的HTTP反向代理已經(jīng)不能滿足大中型企業(yè)網(wǎng)絡安全性的需要，其迫切的需要更加完善的安全機制來滿足更高的安全需要，本方法提供一種在反向代理服務上增加認證及加解密的機制來增強外部訪問的安全性，同時提供一種減少企業(yè)內(nèi)部域名的方法。

發(fā)明內(nèi)容
本發(fā)明提供了一種安全的反向代理的方法。附圖1描述了其部屬環(huán)境，即在網(wǎng)關設備上部署安全反向代理服務器，安全網(wǎng)關設備位于客戶端與應用服務器之間，客戶端與應用服務器的地址為不同網(wǎng)段地址，網(wǎng)關設備上設置兩個網(wǎng)段的地址，同時在DNS服務器上指定網(wǎng)關的域名WWW.gateway, com和域名指向的地址,地址為網(wǎng)關設備與客戶端交互的地址。網(wǎng)關設備啟動反向代理服務器前，針對代理服務器和代理的應用服務器進行配置，配置主要內(nèi)容如下:錯誤消息頁面:由網(wǎng)關自行定義的簡單HTML頁面；(必選)服務端證書:由第三方信任機構簽發(fā)的證書；(必選)公鑰:與證書相匹配的公鑰；(必選)/XXX:應用服務器的簡稱；(必選)Proxy_IP_P0RT:應用服務器的實際IP地址及端口號；(必選)設置頭部信息:X-REAL_IP、X-Forwarded-For。(可選)上述配置除證書外可根據(jù)不同的應用服務器配置多個應用服務器的反向代理，同時網(wǎng)關配置防火墻開啟443端口的訪問授權。配置完成后啟動反向代理服務器，反向代理服務器利用Socket技術監(jiān)聽443端口的TCP連接，等待客戶端發(fā)起的安全連接請求?？蛻舳嗽跒g覽器上鍵入https://www.gateway.com/XXX,發(fā)起目的端口為443的TCP連接。www.gateway, com為網(wǎng)關的域名，/XXX為訪問應用服務期的簡稱，服務端應同時配置/XXX所指向應用服務期的地址與需要返回客戶端的URL進行指定?？蛻舳伺c服務端的TCP協(xié)商為正常的TCP三次握手，握手成功后在TCP的基礎上開始SSL協(xié)商。SSL協(xié)商采用單向協(xié)商，附圖2描述了其協(xié)商步驟，具體內(nèi)容如下:1、客戶端通過SSL Hello消息將它支持的加密算法、密鑰交換算法、MAC算法等信息發(fā)送給服務器。2、網(wǎng)關將報文分為三部分，第一部分確定本次通信采用的加密套件，通過Hello消息通知給客戶端；第二部分將自己公鑰信息的數(shù)字證書通過Certificate消息通知給客戶端，此證書為第三方信任機構簽發(fā)的證書；第三部分網(wǎng)關通知客戶端版本和加密套件協(xié)商結束，開始進行密鑰交換。3、客戶端驗證網(wǎng)關的證書合法性，利用證書中的公鑰加密客戶端隨機生成的前置安全數(shù)，并通過消息發(fā)送給服務端。客戶端發(fā)送Change Cipher Spec消息,通知服務端后續(xù)報文將采用協(xié)商好的密鑰和加密套件進行加密和MAC計算。客戶端計算已交互的握手消息(除Change Cipher Spec消息外所有已交互的消息)的Hash值,利用協(xié)商好的密鑰和加密套件處理Hash值(計算并添加MAC值、加密等),并通過Finished消息發(fā)送給服務端。4、服務端利用同樣的方法計算已交互的握手消息的Hash值,并與Finished消息的解密結果比較，如果二者相同，且MAC值驗證成功，則證明密鑰和加密套件協(xié)商成功。同樣地，服務端發(fā)送Change CipherSpec消息,通知客戶端后續(xù)報文將采用協(xié)商好的密鑰和加密套件進行加密和MAC計算。服務端計算已交互的握手消息的Hash值，利用協(xié)商好的密鑰和加密套件處理Hash值(計算并添加MAC值、加密等),并通過Finished消息發(fā)送給客戶端?？蛻舳死猛瑯拥姆椒ㄓ嬎阋呀换サ奈帐窒⒌腍ash值,并與Finished消息的解密結果比較，如果二者相同，且MAC值驗證成功，則證明密鑰和加密套件協(xié)商成功。至此，SSL協(xié)商完成，加密信道建立。客戶端發(fā)送SSL協(xié)商的密鑰對HTTP報文進行加密，將加密后的數(shù)據(jù)發(fā)送到網(wǎng)關，網(wǎng)關反向代理模塊調(diào)用SSL解密函數(shù)進行解密，解密后再進行HTTP報文的解析，加密信道的建立可保證客戶端訪問到網(wǎng)關這一階段的數(shù)據(jù)為加密數(shù)據(jù)，如報文被攔截或泄露也不會對用戶和企業(yè)產(chǎn)生影響。反向代理模塊并不對整個HTTP報文進行解析，其僅解析HTTP報文的請求行、消息報頭，而不對HTTP請求正文進行解析。對HTTP請求行的通用資源標識符(即HTTP URI)進行解析，確定URI為“/XXX” ；查找是否有/XXX應用服務器代理的配置選項，如果沒有，則返回HTTP 502錯誤，此處返回的是自定義頁面，避免客戶端通過錯誤頁面可以了解應用服務器的目錄構造；如果有代理，則取出/XXX的相關配置，在對HTTP頭進行解析。 解析HTTP消息報頭，提取HTTP消息報頭的所有選項，包括:"Acc印t、Accept-Language、User-Agent、Accept-Encoding、Host、Connection、Cookie 等所有選項，并將選項及選項內(nèi)容保存；創(chuàng)建一個新的BUF，重新構造HTTP請求行與消息報頭:重新構造HTTP選項Host，此選項內(nèi)容為反向代理服務器配置域名；如配置了 protocolHeader選項，則創(chuàng)建HTTP選項protocolHeader,此選項內(nèi)容為https://，此選項僅為標識，一般表示反向代理服務器接收了 HTTPS的協(xié)商，并對數(shù)據(jù)進行了解密，應用服務器一般不對其進行處理；
如配置了 X-Forwarded-For選項，則創(chuàng)建HTTP選項X-Forwarded-For,此選項內(nèi)容為真實客戶端IP地址，此處是否選擇添加此選項應根據(jù)應用服務器來判斷，如部署為以IP地址為限制的投票系統(tǒng)時，必須設置該選項，將HTTP的請求客戶端端的真實IP發(fā)送到應用服務器，避免應用服務器以IP頭的源地址進行統(tǒng)計而使統(tǒng)計數(shù)據(jù)不準確；如配置了 X-REAL-1P選項，則創(chuàng)建HTTP選項X-REAL-1P，此選項為實際直接訪問地址；重新構造HTTP選項Connection,此選項內(nèi)容為close。其他HTTP選項不予修改，完成HTTP報文頭的封裝后，根據(jù)/XXX指定的應用服務器地址和端口號將報文發(fā)送到應用服務期，應用服務期解析后將報文返回給網(wǎng)關，網(wǎng)關將數(shù)據(jù)透傳給客戶端，對于數(shù)據(jù)來說，應用服務器回傳的數(shù)據(jù)，網(wǎng)關是不做更改的，因此網(wǎng)關對用戶來講是透明的。但如果應用服務器返回錯誤消息，代理服務器會先行截取該消息并更改標頭中列出的任何URL，然后再將消息發(fā)送給客戶機。防止外部客戶機獲取內(nèi)部內(nèi)容服務器的重定向URL。由于在反向代理服務器中/XXX，可以解釋為應用服務器的地址，因此，在實際的組網(wǎng)環(huán)境下可以在DNS服務器上刪除此域名，避免域名被占用。網(wǎng)關的實現(xiàn)基于定制的硬件和操作系統(tǒng)，采用專為網(wǎng)關設計的工控機和裁減的Liunx操作系統(tǒng)，上述算法的實現(xiàn)基于我公司自有的實現(xiàn)，其主要實現(xiàn)為二個模塊:1.數(shù)據(jù)處理子模塊數(shù)據(jù)處理子模塊是安全網(wǎng)關與外界交互的唯一出入口，其采用多進程并發(fā)處理模型，同時啟動I個主進程和8個子進程進行工作，主進程負責控制反向代理引擎模塊的基礎配置信息，子進程并發(fā)接收數(shù)據(jù)和發(fā)送數(shù)據(jù)。數(shù)據(jù)處理子 模塊利用Socket技術實現(xiàn)對端口的監(jiān)控，當收到客戶端發(fā)起的請求后，調(diào)用中間層子模塊對協(xié)商報文進行處理(協(xié)商處理過程由中間層子模塊協(xié)商負責處理)。數(shù)據(jù)的收發(fā)均采用流式Socket (面向連接的Socket)來完成。當數(shù)據(jù)處理子模塊接收數(shù)據(jù)后，根據(jù)報文目的IP地址，進行判斷，當目的IP地址滿足系統(tǒng)ipTables中某一條規(guī)則時，將報文根據(jù)規(guī)則指向的接口進行轉發(fā)。2.中間層子模塊中間層子模塊負責SSL協(xié)議的協(xié)商，協(xié)商通過后數(shù)據(jù)處理子模塊調(diào)用open ssl的解密接口 SSL_read完成數(shù)據(jù)的解密操作。
四

圖1:安全網(wǎng)關部署環(huán)境圖2:單向SSL協(xié)商過程
權利要求
1.一種網(wǎng)關作為安全反向代理服務器的方法，所述的網(wǎng)關設置在用戶與服務器之間網(wǎng)絡上，所述方法包括步驟: (1)客戶端連接反向代理服務器在網(wǎng)關上開放的443端口，三次握手后建立TCP連接，在TCP連接基礎上建立SSL安全信道； (2)安全信道建立后，網(wǎng)關接收客戶端向應用服務器發(fā)送的被加密的HTTP請求，網(wǎng)關對此請求進行解密處理； (3)解密后網(wǎng)關對HTTP報文進行解析，根據(jù)解析的URI，判定反向代理指定的應用服務器； (4)繼續(xù)解析HTTP頭信息，對HTTP頭進行改造，增加部分頭信息后將報文發(fā)送到應永服務器。
2.如權利要求1所述的方法，其特征在于網(wǎng)關可接收443端口的TCP連接。
3.如權利要求1所述的方法，其特征在于TCP連接建立后，客戶端與網(wǎng)關進行SSL協(xié)商。
4.如權利要求1所述的方法，其特征在于SSL協(xié)商完成后，客戶端發(fā)送的HTTP數(shù)據(jù)為加密數(shù)據(jù)，網(wǎng)關對數(shù)據(jù)解密后才可以進行解析。
5.如權利要求1所述的方法，其特征在于網(wǎng)關包括識別HTTP請求，并對請求頭部進行解析的裝置。
6.如權利要求1所述的方法，其特征在于網(wǎng)關可構造部分頭信息，并根據(jù)應用服務器的實際需要構造不同的頭部信息。
7.如權利要求1所述的方法，其特征在于網(wǎng)關包括代替Web服務器對客戶端HTTP請求進行應答的裝置。
8.如權利要求1所述的方法，其特征在于網(wǎng)關包括對數(shù)據(jù)包進行端口轉發(fā)的裝置。
全文摘要
本發(fā)明公開了一種安全的反向代理的方法。即在網(wǎng)關設備上部署安全反向代理服務器，安全網(wǎng)關設備位于客戶端與應用服務器之間，客戶端與網(wǎng)關之間進行SSL連接，構建安全信道，使客戶端與網(wǎng)關之間的數(shù)據(jù)為加密數(shù)據(jù)，避免數(shù)據(jù)被竊聽。在反向代理服務器上支持簡單的URI域名識別，減少組網(wǎng)環(huán)境下的域名設置。
文檔編號H04L29/08GK103139185SQ20111039491
公開日2013年6月5日 申請日期2011年12月2日 優(yōu)先權日2011年12月2日
發(fā)明者李洪宇 申請人:中科信息安全共性技術國家工程研究中心有限公司