引子：大家都知道网上出现过诸如《asp.net虚拟主机的重大隐患》等类似介绍Asp.Net的漏洞以及相应的黑客攻击办法的文章，以及诸如Webadmin.aspx类Asp.Net的Webshell,如果您拿去到您的asp.net虚拟主机上测试时您就知道，这东东对C盘有读取权限，以及对整个硬盘都有 修改、删除权限；那这样的话，我们的网站、我的服务器还有什么安全可言？在黑客频频攻击的今天，我们不能不为我们的服务器而担忧...

漏洞原因:大家知道ASP中常用的标准组件:FileSystemObject，这个组件为ASP提供了强大的文件系统访问能力，可以对服务器硬盘上的任何有权限的目录 和文件进行读写、删除、改名等操作。FSO对象来自微软提供的脚本运行库scrrun.dll中。而在Asp.Net中这个问题仍然存在，并且更加难以解决；因为.Net中对系统IO操作功能更加强大,如：组件不再需要用Regsvr32来注册，而是直接在bin目录下就可以直接用了，所以这些功能对开发Asp.Net程序有很大方便是，但却使安全变得更为复杂了...

解决方案：

大家都知道，Asp类木马可以通过对IIS中的虚拟主机采用独立匿名用户来控制FSO组件的安全，让其只能在站类活动，而不能跨站或者危害到其它硬盘的数据，Asp的安全问题与设置这里不再作讨论，下面我们开始着手Asp.Net木马/WebShell防范方法的讲解：

一、在IIS6.0中，WEB应用程序的工作进程为以进程标识“Network Service”运行。而在IIS5.0中，进程外WEB应用程序则是以“IWAM_服务器名”用户运行行，这个User是普通的本地Guests用户。网上有部份人提出针对此问题用Microsoft .NET FrameworkConfigration设置System.io的对目录读取的权限，但很遗憾经过我们测试没有成功，可能是.net framework1.1机制改了？

Network Service 是Windows Server 2003中的内置帐户。了解IIS5.0上的本地用户帐户(IUSR和IWAM)与这个内置帐户之间的区别是非常重要的。Windows操作系统中的所有帐户都分配了一个SID(安全标识:Security ID）。服务器是根据 SID，而不是与SID相关的名称来识别服务器上所有帐户的，而我们在与用户界面进行交互时，则是使用名称进行交互的。服务器上创建的绝大部分帐户都是本地帐户，都具有一个唯一的 SID，用于标识此帐户隶属于该服务器用户数据库的成员。由于SID只是相对于服务器是唯一的，因此它在任何其他系统上无效。所以，如果您为本地帐户分配了针对某文件或文件夹的 NTFS 权限，然后将该文件及其权限复制到另一台计算机上时，目标计算机上并没有针对这个迁移SID的用户帐户，即使其上有一个同名帐户也是如此。这使得包含NTFS权限的内容复制可能出现问题。内置帐户是由操作系统创建的、一类较为特别的帐户 或组，例如System帐户、Network Service和Everyone 组。这些对象的重要特征之一就是，它们在所有系统上都拥有一个相同的、众所周知的SID。当将分配了NTFS权限的文件复制到内置帐户时，权限在服务器之间是有效的，因为内置帐户的SID在所有服务器上都是相同的。Windows Server 2003 服务中的 Network Service 帐户是特别设计的，专用于为应用程序提供访问网络的足够权限，而且在IIS 6.0中，无需提升权限即可运行Web 应用程序。这对于IIS安全性来说，是一个特大的消息，因为不存在缓冲溢出，怀有恶意的应用程序无法破译进程标识，或是对应用程序的攻击不能进入System用户环境。更为重要的一点是，再也不能形成针对System帐户的“后门”，例如，再也无法通InProcessIsapiApps元数据库项利用加载到Inetinfo的应用程序。我们已经简单的介绍了一下ASP.NET中关于文件IO系统的漏洞的防治方法，这一方法有些繁琐，但是却可以从根本上杜绝一些漏洞，我们讨论的只是很少的一部分，更多的解决放法需要大家共同来探索、学习。

Network Service帐户在创建时不仅仅考虑了在IIS6.0中的应用。它还具有进程标识W3WP.exe的绝大部分（并不是全部）权限。如同ASPNET用户为了运行ASP.net应用程序，需要具有IIS6.0服务器上某些位置的访问权限，进程标识 W3WP.exe 也需要具有类似位置的访问权限，而且还需要一些默认情况下没有指派给内置组的权限。

二、为了管理的方便，在安装IIS6.0时创建了"IIS_WPG"组(也称为IIS工作进程组,IIS Worker Process Group)，而且它的成员包括Local System (本地系统）、Local Service(本地服务)、Network Service(网络服务)和IWAM帐户。IIS_WPG 的成员具有适当的NTFS的Acls权限和必要的用户权限，可以充当IIS 6.0中工作进程的进程标识。

三、因此，Network Service帐户提供了访问上述位置的权限，具有充当 IIS 6 工作进程的进程标识的充足权限，以及具有访问网络的权限。Msdn上说：在Windows Server 2003中，用户上下文称为NETWORK SERVICE。这些用户帐户是在 .NET Framework安装过程中创建的,它具有唯一的不易破解的密码，并仅被授予有限的权限。ASPNET或NETWORK SERVICE用户只能访问运行Web应用程序所需的特定文件夹，如Web应用程序存储 已编译文件的\bin 目录。要将进程标识设置为特定用户名，以取代ASPNET或NETWORK SERVICE用户标识，您提供的用户名和密码都必须存储在machine.config 文件中。但是根据实际情况，asp.net的system.io可以无限制访问不设防的服务器路径。不知道这算不算一个ms的重大漏洞。而且根本不能使iis以machine.config的用户执行asp.net程序。

四、如何解决呢？答案就是—应用程序池。

IIS 6.0在被称为应用程序隔离模式(隔离模式)的两种不同操作模式下运行,它们是:工作进程隔离模式和IIS 5.0隔离模式。这两种模式都要依赖于HTTP.sys作为超文本传输协议(HTTP)侦听程序；然而，它们内部的工作原理是截然不同的。

工作进程隔离模式利用IIS 6.0的重新设计的体系结构并且使用工作进程的核心组件。IIS 5.0隔离模式用于依赖IIS 5.0的特定功能和行为的应 用程序。该隔离模式由IIs5Isolation ModeEnabled配置数据库属性指定。

您所选择的IIS应用程序隔离模式对性能、可*性、安全性和功能可用性都会产生影响。工作进程隔离模式是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单独地监视 其健康状况。安全性的提高是由于应用程序不再象IIS 5.0和IIS 4.0的进程内应用那样用System帐户运行，默认情况下，w3wp.exe的所有实例都在一个权限有限的“网络服务”帐户下运行，必要时，还可以将工作进程配置成用其他用户帐户运行。

五、解决办法操作步骤：

1、我们将每一个Asp.Net虚拟主机站点都分配一个独立的应用程序池，并赋予不同的权限。下面我就针对此来做一个示例：首先，我们为网站创建两个用户(一个是App_31896.net_User、密码为App_31896.net,一个是IUSR_31896.net_User、密码为IUSR_31896.net）

2、依次打开"计算机管理器"→"系统管理工具"→"本地用户和组"→"用户",然后新增两个用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、然后再建立相应的网站。依次打开Internet 信息服务→本地计算机→网站→新建→31896.net的网站，目录为E:\Vhost\31896.net^_^→编辑31896.net网站的属性→主目录→应用程序池→App_31896.net →目录安全性→身份验证和访问控制→编辑，选择我们刚才建立的IUSR_31896.net_User,并输入相应的密码IUSR_31896.netr→保存并退出。

6、最后设定IIS的站点目录权限Acls以及整个服务器系统的安全，这里就不再详细讨论，关于服务器的整体系统安全可以参考下本人的Win Server2003服务器整体安全技术白皮书。（IIS站点权限参考《FSO安全隐患解决办法》与《ASP木马Webshell之安全防范解决办法》这两篇进行；关于IIS的运行权限请参考《IIS 6.0所需要的默认ACLs权限[即NTFS的硬盘权限]》此文进行）

好了，我们已经简单的介绍了一下ASP.NET中关于文件IO系统的漏洞的防治方法，这一方法虽然有些繁琐，但是却可以从根本上杜绝一些漏洞，这里我们讨论的只是很少的一部分，更多的解决放法需要大家共同来探索、学习。当然如果你发现了更好的办法可别忘了告诉我哟^_^

笔者后记：这里为大家介绍的仅仅是本人在处理ASP.NET木马、Webshell上的一些心得体会。在下一篇中将为大家介绍如何简简单单的对系统某些相应的服务进行降权处理，以防止溢出、提权等攻击、加强服务器系统的安全。其实服务器、系统的安全是个整体的概念；远远不止这些,可能你其中有一小点的疏忽就可以让你的网站、甚至服务器沦陷。因此安全策略必需走防患未然的道路，任何一个小地方都不能马虎、今天关于防Asp.Net安全隐患小技巧就为大家介绍到这里...

关于其它方面的服务器安全配置经验我们在下一篇文章再见吧:-) (注：由于本人才疏学浅，如文中有错误实为在所难免，还请各位看官见谅!旨在抛砖引玉，如果您有更好的办法请别忘了在论坛跟贴^0^,先行谢过!)