ASP.NET木馬及Webshell安全解決方案

Security Fuard Solution Of ASP.NET and Webshell


原始發(fā)布地址


文章簡介:本文將為大家介紹在Microsoft Win系列的2003 SERVER IIS6.0中如何簡單快速解決ASP.NET中的危險漏洞與隱患對WEB服務器系統(tǒng)的安全威脅之詳細防范設置步驟;讀完本文,您將可以使您的網(wǎng)站服務器免去ASP.NET木馬、Webshell所面對的提升權(quán)限、跨站攻擊、甚至危害到系統(tǒng)安全的威脅。

ASP木馬、Webshell之安全防范解決辦法正文內(nèi)容:
(注意:本文所講述之設置方法與環(huán)境:適用于Microsoft Windows Server 2003 SERVER | IIS6.0)

引子:大家都知道網(wǎng)上出現(xiàn)過諸如《asp.net虛擬主機的重大隱患》等類似介紹Asp.Net的漏洞以及相應的黑客攻擊辦法的文章,以及諸如Webadmin.aspx類Asp.Net的Webshell,如果您拿去到您的asp.net虛擬主機上測試時您就知道,這東東對C盤有讀取權(quán)限,以及對整個硬盤都有 修改、刪除權(quán)限;那這樣的話,我們的網(wǎng)站、我的服務器還有什么安全可言?在黑客頻頻攻擊的今天,我們不能不為我們的服務器而擔憂...

漏洞原因:大家知道ASP中常用的標準組件:FileSystemObject,這個組件為ASP提供了強大的文件系統(tǒng)訪問能力,可以對服務器硬盤上的任何有權(quán)限的目錄 和文件進行讀寫、刪除、改名等操作。FSO對象來自微軟提供的腳本運行庫scrrun.dll中。而在Asp.Net中這個問題仍然存在,并且更加難以解決;因為.Net中對系統(tǒng)IO操作功能更加強大,如:組件不再需要用Regsvr32來注冊,而是直接在bin目錄下就可以直接用了,所以這些功能對開發(fā)Asp.Net程序有很大方便是,但卻使安全變得更為復雜了....(需進一步了解可參考《asp.net虛擬主機的重大隱患》原文)

解決方案:
大家都知道,Asp類木馬可以通過對IIS中的虛擬主機采用獨立匿名用戶來控制FSO組件的安全,讓其只能在站類活動,而不能跨站或者危害到其它硬盤的數(shù)據(jù)(注:如果您不明白可以參考一下本人以前的兩篇文章《FSO安全隱患解決辦法》;《ASP木馬Webshell之安全防范解決辦法》) Asp的安全問題與設置這里不再作討論,下面我們開始著手Asp.Net木馬/WebShell防范方法的講解:

一、在IIS6.0中,WEB應用程序的工作進程為以進程標識“Network Service”運行。而在IIS5.0中,進程外WEB應用程序則是以“IWAM_服務器名”用戶運行行,這個User是普通的本地Guests用戶。網(wǎng)上有部份人提出針對此問題用Microsoft .NET Framework Configration設置System.io的對目錄讀取的權(quán)限,但很遺憾經(jīng)過我們測試沒有成功,可能是.net framework1.1機制改了?

Network Service 是Windows Server 2003中的內(nèi)置帳戶。了解IIS5.0上的本地用戶帳戶(IUSR和IWAM)與這個內(nèi)置帳戶之間的區(qū)別是非常重要的。Windows操作系統(tǒng)中的所有帳戶都分配了一個SID(安全標識:Security ID)。服務器是根據(jù) SID,而不是與SID相關的名稱來識別服務器上所有帳戶的,而我們在與用戶界面進行交互時,則是使用名稱進行交互的。服務器上創(chuàng)建的絕大部分帳戶都是本地帳戶,都具有一個唯一的 SID,用于標識此帳戶隸屬于該服務器用戶數(shù)據(jù)庫的成員。由于SID只是相對于服務器是唯一的,因此它在任何其他系統(tǒng)上無效。所以,如果您為本地帳戶分配了針對某文件或文件夾的 NTFS 權(quán)限,然后將該文件及其權(quán)限復制到另一臺計算機上時,目標計算機上并沒有針對這個遷移SID的用戶帳戶,即使其上有一個同名帳戶也是如此。這使得包含NTFS權(quán)限的內(nèi)容復制可能出現(xiàn)問題。內(nèi)置帳戶是由操作系統(tǒng)創(chuàng)建的、一類較為特別的帳戶 或組,例如System帳戶、Network Service和Everyone 組。這些對象的重要特征之一就是,它們在所有系統(tǒng)上都擁有一個相同的、眾所周知的SID。當將分配了NTFS權(quán)限的文件復制到內(nèi)置帳戶時,權(quán)限在服務器之間是有效的,因為內(nèi)置帳戶的SID在所有服務器上都是相同的。Windows Server 2003 服務中的 Network Service 帳戶是特別設計的,專用于為應用程序提供訪問網(wǎng)絡的足夠權(quán)限,而且在IIS 6.0中,無需提升權(quán)限即可運行Web 應用程序。這對于IIS安全性來說,是一個特大的消息,因為不存在緩沖溢出,懷有惡意的應用程序無法破譯進程標識,或是對應用程序的攻擊不能進入System用戶環(huán)境。更為重要的一點是,再也不能形成針對System帳戶的“后門”,例如,再也無法通InProcessIsapiApps元數(shù)據(jù)庫項利用加載到Inetinfo的應用程序。我們已經(jīng)簡單的介紹了一下ASP.NET中關于文件IO系統(tǒng)的漏洞的防治方法,這一方法有些繁瑣,但是卻可以從根本上杜絕一些漏洞,我們討論的只是很少的一部分,更多的解決放法需要大家共同來探索、學習。(AD^_^:游刃在技術(shù)鬼神邊緣,打造服務器安全神話!創(chuàng)世紀網(wǎng)絡技術(shù)前瞻,成就互聯(lián)網(wǎng)革命先驅(qū)!服務器安全討論區(qū)[S.S.D.A]) 

Network Service帳戶在創(chuàng)建時不僅僅考慮了在IIS6.0中的應用。它還具有進程標識W3WP.exe的絕大部分(并不是全部)權(quán)限。如同ASPNET用戶為了運行ASP.net應用程序,需要具有IIS6.0服務器上某些位置的訪問權(quán)限,進程標識 W3WP.exe 也需要具有類似位置的訪問權(quán)限,而且還需要一些默認情況下沒有指派給內(nèi)置組的權(quán)限。

二、為了管理的方便,在安裝IIS6.0時創(chuàng)建了"IIS_WPG"組(也稱為IIS工作進程組,IIS Worker Process Group),而且它的成員包括Local System (本地系統(tǒng))、Local Service(本地服務)、Network Service(網(wǎng)絡服務)和IWAM帳戶。IIS_WPG 的成員具有適當?shù)腘TFS的Acls權(quán)限和必要的用戶權(quán)限,可以充當IIS 6.0中工作進程的進程標識。

三、因此,Network Service帳戶提供了訪問上述位置的權(quán)限,具有充當 IIS 6 工作進程的進程標識的充足權(quán)限,以及具有訪問網(wǎng)絡的權(quán)限。Msdn上說:在Windows Server 2003中,用戶上下文稱為NETWORK SERVICE。這些用戶帳戶是在 .NET Framework安裝過程中創(chuàng)建的,它具有唯一的不易破解的密碼,并僅被授予有限的權(quán)限。ASPNET或NETWORK SERVICE用戶只能訪問運行Web應用程序所需的特定文件夾,如Web應用程序存儲 已編譯文件的\bin 目錄。要將進程標識設置為特定用戶名,以取代ASPNET或NETWORK SERVICE用戶標識,您提供的用戶名和密碼都必須存儲在machine.config 文件中。但是根據(jù)實際情況,asp.net的system.io可以無限制訪問不設防的服務器路徑。不知道這算不算一個ms的重大漏洞。而且根本不能使iis以machine.config的用戶執(zhí)行asp.net程序。

四、如何解決呢?答案就是—應用程序池。
IIS 6.0在被稱為應用程序隔離模式(隔離模式)的兩種不同操作模式下運行,它們是:工作進程隔離模式和IIS 5.0隔離模式。這兩種模式都要依賴于HTTP.sys作為超文本傳輸協(xié)議(HTTP)偵聽程序;然而,它們內(nèi)部的工作原理是截然不同的。

工作進程隔離模式利用IIS 6.0的重新設計的體系結(jié)構(gòu)并且使用工作進程的核心組件。IIS 5.0隔離模式用于依賴IIS 5.0的特定功能和行為的應 用程序。該隔離模式由IIs5Isolation ModeEnabled配置數(shù)據(jù)庫屬性指定。

您所選擇的IIS應用程序隔離模式對性能、可靠性、安全性和功能可用性都會產(chǎn)生影響。工作進程隔離模式是IIS 6.0操作的推薦模式,因為它為 應用程序提供了更可靠的平臺。工作進程隔離模式也提供了更高級別的安全性,因為運行在工作進程中的應用程序的默認標識為NetworkService。 以IIS 5.0隔離模式運行的應用程序的默認標識為LocalSystem,該標識允許訪問并具有更改計算機上幾乎所有資源的能力。 
 

由此可見,我們只能使用工作進程隔離模式解決.net的安全問題。默認情況下,IIS 6.0在工作進程隔離模式下運行,在這種模式中,對于每一個Web應用,IIS 6.0都用一個獨立的w3wp.exe的實例來運行它。w3wp.exe也稱為工作進程(Worker Process),或W3Core。

可靠性和安全性�？煽啃缘奶岣呤且驗橐粋�Web應用的故障不會影響到其他Web應用,也不會影響http.sys,每一個Web應用由W3SVC單獨地監(jiān)視 其健康狀況。安全性的提高是由于應用程序不再象IIS 5.0和IIS 4.0的進程內(nèi)應用那樣用System帳戶運行,默認情況下,w3wp.exe的所有實例都在一個權(quán)限有限的“網(wǎng)絡服務”帳戶下運行,必要時,還可以將工作進程配置成用其他用戶帳戶運行。

五、解決辦法操作步驟:
1、我們將每一個Asp.Net虛擬主機站點都分配一個獨立的應用程序池,并賦予不同的權(quán)限。下面我就針對此來做一個示例:首先,我們?yōu)榫W(wǎng)站創(chuàng)建兩個用戶(一個是App_31896.net_User、密碼為App_31896.net,一個是IUSR_31896.net_User、密碼為IUSR_31896.net)

2、依次打開"計算機管理器"→"系統(tǒng)管理工具"→"本地用戶和組"→"用戶",然后新增兩個用App_31896.net_User與IUSR_31896.net_User密碼分別為:App_31896.net與IUSR_31896.net。選擇“用戶不能更改密碼”與“密碼永不過期”,然后分別把App_31896.net_User添加到iis_wpg組,把IUSR_31896.net_User添加到Guests組。將用戶趕出其它組成員。

3、然后,打開IIS管理員器新建相應的應用程序池。依次打開Internet 信息服務→本地計算機→應用程序池→新建→應用程序池,新建一個名字為App_31896.net的應用程序池。

4、編輯App_31896.net應用程序池的屬性→標示→配置→用戶名→瀏覽→把用戶名改為我們剛才建立的App_31896.net_Use并輸入相應的密碼App_31896.net。

5、然后再建立相應的網(wǎng)站。依次打開Internet 信息服務→本地計算機→網(wǎng)站→新建→31896.net的網(wǎng)站,目錄為E:\Vhost\31896.net^_^→編輯31896.net網(wǎng)站的屬性→主目錄→應用程序池→App_31896.net →目錄安全性→身份驗證和訪問控制→編輯,選擇我們剛才建立的IUSR_31896.net_User,并輸入相應的密碼IUSR_31896.netr→保存并退出。

6、最后設定IIS的站點目錄權(quán)限Acls以及整個服務器系統(tǒng)的安全,這里就不再詳細討論,關于服務器的整體系統(tǒng)安全可以參考下本人的Win Server 2003服務器整體安全技術(shù)白皮書。(IIS站點權(quán)限參考《FSO安全隱患解決辦法》與《ASP木馬Webshell之安全防范解決辦法》這兩篇進行;關于IIS的運行權(quán)限請參考《IIS 6.0所需要的默認ACLs權(quán)限[即NTFS的硬盤權(quán)限]》此文進行)

好了,我們已經(jīng)簡單的介紹了一下ASP.NET中關于文件IO系統(tǒng)的漏洞的防治方法,這一方法雖然有些繁瑣,但是卻可以從根本上杜絕一些漏洞,這里我們討論的只是很少的一部分,更多的解決放法需要大家共同來探索、學習。當然如果你發(fā)現(xiàn)了更好的辦法可別忘了告訴我喲^_^

筆者后記:這里為大家介紹的僅僅是本人在處理ASP.NET木馬、Webshell上的一些心得體會。在下一篇中將為大家介紹如何簡簡單單的對系統(tǒng)某些相應的服務進行降權(quán)處理,以防止溢出、提權(quán)等攻擊、加強服務器系統(tǒng)的安全。其實服務器、系統(tǒng)的安全是個整體的概念;遠遠不止這些,可能你其中有一小點的疏忽就可以讓你的網(wǎng)站、甚至服務器淪陷。因此安全策略必需走防患未然的道路,任何一個小地方都不能馬虎、今天關于防Asp.Net安全隱患小技巧就為大家介紹到這里...

關于其它方面的服務器安全配置經(jīng)驗我們在下一篇文章再見吧:-) (注:由于本人才疏學淺,如文中有錯誤實為在所難免,還請各位看官見諒!旨在拋磚引玉,如果您有更好的辦法請別忘了在論壇跟貼^0^,先行謝過!)

                                                    海騰數(shù)據(jù)中心(技術(shù)部整理)
                                                    2007-10-12