最近,和朋友们在聊及ASP.NET程序的安全性没有JAVA高,IIS(Internet Infomartion Server)的存在很多漏洞(以及新型蠕虫,例如Code Red 和Nimda),安全得不到保障。针对IIS的安全性查了些资料,发现IIS的安全性曾被普遍关注。权威人士以及Microsoft公司的竞争对手花了大量精力仔细检查并批评了IIS安全功能。Gartner调查公司甚至更进一步建议被Code Red和Nimda攻击过的公司应完全放弃使用IIS。
安全漏洞和病毒问题并不只涉及到IIS用户。事实上,第一个有记载的Internet蠕虫在1987年就被发布了,它主要是针对Unix系统,并且利用了缓冲区溢出问题。根据CERT Coordination Center(计算机应急处理协调中心)的2001年度报告:BIND(Berkeley Internet Name Domain)的多个漏洞都是其中最严重的安全漏洞。包括OpenLinux2.3、RedHat Linux、True64 UNIX、AIX 5L、HP-UX 1li、SGI、SUN Solaris、FREEBSD、NetBSD、OpenBSD在内的大多数操作系统受到了它的影响。然而IIS没有受到影响,这是因为Microsoft的DNS的实现方式并不基于BIND。根据CERT Coordination Center报告,第二严重的安全漏洞是sadmind/IIS 蠕虫,它会影响IIS和Sun Solaris系统。
安全漏洞也涉及到Open Source产品。已有大量的安全表明黑客一直在设法及更新型开放代码系统的安全,其中包括Apache Software Foundation的一个公用服务器。
IIS吸引了众多注意力,因为它是继Apache网站服务器之后被最广泛使用的Web服务器之一,所以Microsoft的产品理所当然地要接受大量的安全性检查。
大多数的IIS安全漏洞可以被合适的服务包和补丁程序修补好。本文我们将研究如何使用IIS易受攻击的风险最小化,以及如何使用ASP.NET的设置选项使其安全性最大化。
一、安全性和服务器的基础结构
同其他事情一样,没有百分之百安全的系统或应用程序。安全性是一个过程,而非终极目标,要求我们不懈地努力。
一般认为典型的Windows Web应用程序的基础结构由许多组件组成,包括一个路由器、防火墙、负载平衡与群集技术、操作系统以及IIS。
其中的每一个组件都在保护服务器基础结构的安全方面起到相应的作用。例如:在网络通信到达web服务器以前,防火墙会过滤诸如端口、包和协议的网络通信量。假定我们的Web站点打算使用HTTP和HTTPS,并且已经堵住了除80和443以外的所有端口。虽然我们可能在防火墙内关上除80和443以外的所有端口,而且这样做会大大地增加其安全性,但是站点仍然不一定是安全的。设置每一个组件并使其安全性最大化,这一点很重要。
二、计划的安全性
像应用程序开发一样,安全性包含许多阶段,如计划、实现、测试和监控:
1.应该在应用程序设计阶段之前就启动安全性的计划阶段,而且应当考虑应用程序安全性的所有方面。
2.安全性的实现阶段要实现安全性----包括开发应用程序和设置服务器或应用环境中的安全性设置----如创建用户帐户和角色、删除或禁用非法帐户等
3.设置完安全性之后,安全性的测试阶段要进行应用程序的测试,而且要保证应用程序的功能合理并且有足够的权限与外部资源连接,诸如连接一个数据库或一个服务器主机的中间层组件。
4.可以将安全性的监视阶段看作是一个展示和支持的阶段,负责支持已经被实现了的安全性,并且监视对安全性有损害的任何可能的攻击或入侵。
三、保护IIS
我们应在计划阶段甚至应在安装操作系统和IIS之前就启动IIS的安全性。在安装、设置操作系统和IIS之前,我们应该自问一下将如何使用服务器。例如我们应该问以下这类问题:
1.服务器将以何种形式存在:是Internet Web应用程序还是内部网Web应用程序
2.如何使用IIS:是每台服务器使用单独Web应用程序,还是共享主机Web应用程序
3.支持何种身份验证:匿名用户还是验证用户
4.要支持SSL(Secure Socket Layer,安全套接字层)吗
5.IIS服务器要担当FTP和NNTP主机吗
6.IIS服务器要支持SMTP服务吗
7.允许用户在Web服务器上创建、修改和删除文件吗
8.服务器要与其他的服务器相互配合吗
9.需要安装哪些服务?例如需要在服务器上安装FTP服务吗
10.需要打开哪些端口?例如:如果打算实现FTP服务,那么我们就必须打开21端口
11.如果设置IIS目录和文件?要创建和禁止哪些用户帐户
12.需要在IIS服务器上安装WebDev 和 Microsoft FrontPage扩展吗
一旦我们提供了这些问题的答案,我们就能开始确定如何设置服务器。例如:如果我们知道在服务器上不打算使用NNTP(网络新闻传输协议)、FTP和SMTP服务,那么就可以删除或者停止这些服务,这样就将会减少攻击的可能性。
要按照以下几个基本步骤保护IIS,并且禁用您不打算使用的功能,包括:
为Web站点和虚拟目录分配适当的Access Control List(访问控制列表,ACL)
禁用或者删除所有的示例应用程序
删除IIS的Admin虚拟目录和不用的脚本映射
为IIS日志文件和授权登录设置适当的ACL
3.1 设置Access Control List
设置ACL是保护IIS的第一个步骤。针对不同类型的文件,我们既可以设置Windows ACL又可以设置基于IIS的ACL。这允许我们可以根据文件类型对特殊用户授予相应类型的权限。
可以有很多种不同的方法来管理ACL,但是对于特殊用户访问特定目录,最直接的一个管理方法是简单地访问特定目录的“属性”对话框,选择“共享”选项卡,并且单击“权限”按钮,打开当前目录的权限设置对话框进行用户和权限设置。
我们应该试着允许用户只能访问他们需要那些资源,而不能再访问其他更多的资源。针对特殊文件类型的权限设置。
文件类型 |
Access Control List(访问控制列表) |
诸如.asp、.aspx、.ascx等脚本文件类型。 | Internet Guest Account(Execute) Everyone(Execute) System(Full Control) Administrators(Full Control) |
包括文件(.inc、.shtm以及.shtml) | Internet Guest Account(Read only) Everyone(Read only) System(Full Control) Administrators(Full Control) |
静态文件(.htm、.html、.gif、.jpg、.jpeg、.txt、.doc、.pdf等) | Internet Guest Account(Read only) Everyone(Read only) System(Full Control) Administrators(Full Control) |
可执行的CGI类型文件(.cgi、.dll、.cmd以及.pl) | Internet Guest Account(Execute) Everyone(Execute) System(Full Control) Administrators(Full Control) |
注意:
在典型的ASP中,许多人不愿意在包括文件中放任何代码,这是因为用户可以直接向包含文件提出请求,获得对代码的访问权限。
默认状态下,FTP(C:\inetpub\ftproot)和SMTP(C:\inetpub\mailroot)文件夹授予Everyone组Full Control(完全控制)权限。是否需要改变权限取决于应用程序的要求。例如:如果我们打算为Everyone和Internet Guest Account帐户提供Write权限,那么明确的做法是将这些文件夹移到与IIS Server所在卷不同的其他卷上,而且要强制Windows的磁盘配额限制向这些目录中写入的数据量。这样,如果有人获得对这些文件夹的访问权限,他们也不能上传大量的信息(上传大量的信息会耗尽服务器上的所有可用磁盘空间,从而使服务器变得不稳定或者降低服务器的整体性能)。
我们应该禁用Directory Browsing选项。这样将会阻止黑客导航到带有危险工具的目录。如果您不打算使用CGI应用程序,那么选择Scripts only选项提供Execute权限。
3.2 禁用父路径浏览
父路径浏览允许您在调用MapPath功能时使用".."浏览系统文件。默认状态下,该选项是被允许的。您应当禁用它,因为它能让黑客访问那些我们不想让他们访问的目录。可以按照以下步骤禁用该选项:
右击Web站点或者需要保护的虚拟目录,并且选择“属性”选项。
单击“主目录”选项卡并且选择“配置”按钮。
单击“选项”选项卡,取消"启用父路径"复选框。
3.3 删除IIS示例
当安装IIS时,随之会提供一些可用来示范安装和应用该技术的示例应用程序。建议删除产品服务器上的这些IIS示例的做法是非常明智的。这些示例使服务器易于受到攻击,因为黑客将知道存放它们的位置并且知道怎样利用它们发动一次攻击。
IIS 示例 虚拟目录
IIS示例 \IISSamples
IIS文档 \IISHelp
数据访问 \MSADC
IIS4服务器包括IISADMPWD虚拟目录,它允许用户重置windows口令。如果您已经从IIS4升级到IIS5就可以不用删除IISADMPWD虚拟目录(现在用IIS6、7的比较多)。
3.4 禁用不用的COM组件
对于许多Web应用程序并不需要在服务器上安装每一个COM组件。应用删除File System Object 等不用的COM组件,因为它们可能被用来攻击服务器。我们可以使用Regsvr32实用程序加上/u 命令行开关来取消注册COM组件。
3.5 启用日志记录
用日志来记录IIS收到的HTTP请求是一个很好的设置选项,因为日志记录使我们能验证服务器在任意给定的时间正在做什么事情,包括我们设置好的安全方案正在如何运转。
我们可以用IIS MMC启动日志记录。启动IIS MMC,并单击web站点或者您想要启用日志记录的虚拟目录,然后右击目录节点并且选择“属性”选项,打开对应的属性对话框。在web site标签内启用“启用日志记录”复选框。在启用日志记录时要确信您选择了IIS MMC Extented Log File Format(W3C扩展日志格式)选项,而且要启用下列选项来筛选Extended Properties标签。
Client IP Address
User Name
Method
URI Stem
HTTP Status
Win32 Status
User Agent
Server IP Address
Server Port
这些日志项会提供所有发向IIS请求的消息。IIS日志文件可能会受到攻击。或者黑客甚至可能试图删除IIS日志文件以便隐藏他们一起在搞的破坏。因此通过正确设置ACL来保护IIS日志是非常重要的。需要确保在%systemroot%\system32\LogFiles产生的IIS日志文件拥有下列ACL:这将阻止黑客删除IIS日志文件和掩盖他们的行踪。
Administrator (Full Control)
System (Full Control)
Everyone (RWC)
网络幼虫、爬虫、蠕虫可以访问并向全世界发布IIS日志文件,而且其他的程序会试图索引整个WEB。我们不想向全世界发布日志文件,因此应该使用robots.txt来保护日志文件不被索引程序索引。这会阻止网络爬虫检索该文件并将其放到它们的搜索引擎内容中。因此如果有人搜寻日志文件,我们的日志文件将不会出现在搜索结果中。
利用下列两行命令,可以使用robots.txt 文件关闭所有的索引。
# Discurage all web indexing User-agent:* Disallow:/
如果想获取关于robots.txt文件方面的更多信息,请访问下面URL:
http://www.robotstxt.org/wc/exclusion.html#robotstxt
3.6 安装防毒软件
在服务器上安装防毒软件并且每天更新它以保护IIS服务器,这是必须的。许多防毒软件,像Norton、卡巴斯基都允许通过Internet自动更新。另外建议装一个像360安全卫士这样的软件,对防护也比较有好处。
四、Microsoft Data Access Component 的安全性
对IIS最常见攻击之一是分解MDAC的部件----Remote Data Service(远程数据服务,简称RDS)的DATAFactory对象。该对象发布了可以在IIS上执行shell命令的不安全方法。它也使非法用户能连接任何需要保护的隐秘后端数据源,并且可以利用ODBC驱动程序来执行任何的SQL语句,然后获取在IIS服务器上被保护的非公开文件的访问权限。.NET Framework安装MDAC2.7是.NET安装的一部分。
为了保证MDAC组件的安全,我们应该考虑遵循下列步骤:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch\RDSServer.DataFactory
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch\AdvancedDataFactory
从Windows服务器上删除所有不用的ODBC驱动程序,特别是Microsoft Text Driver。然后应用严格的ACL为可信用户帐户提供访问权限。
如果用的是SQL服务器,那么就应用一个具有极少特权的用户帐户来操作服务器,并且不允许扩展存储过程。
五、锁定IIS
Microsoft 提供了一个名为IIS Lockdown Wizard的免费工具,通过它可以轻松设置IIS并使其得到最大程度的保护。IIS Lockdown Wizard能自动操作我们已经讨论过了的许多设置点。例如:如果正确使用该项向导,它能删除IIS文件映射中不想要的文件,例如文件扩展为.idc,itr,.printer等文件。该向导也包括一个名为UrlScan的工具,它是个ISAPI筛选器,能屏蔽和分析IIS接收到所有HTTP请求。当请求中有一个受限制的字符,或一个受限制的字符串时,IIS就会拒绝该HTTP请求。
IIS Lockdown Wizard官方介绍:
http://technet.microsoft.com/en-us/library/dd450372.aspx
IIS Lockdown Wizard官方下载地址:
http://www.microsoft.com/technet/security/tools/locktool.asp。
IIS Lockdown Wizard提供多种模板,可以选用最适合自己的方式来设置IIS。
5.1 服务器模板
根据不同服务器服务,选用不同的模板。
-如果您的应用程序只是驻留动态Web应用程序所需要的文件,诸如与.asp and .aspx相关的文件,那么应该选择Dynamic Web Server(ASP)选项并单击下一步按钮。如果启用View template settings复选框,那么就可以定制自己想要启用或禁用的选项, 而非简单地沿用选定模板的默认值。
注意:
如果没有发现最适合自己的IIS角色模板,那么可以选择Other(服务器不匹配任意一个列出角色)选项,这将赋予设置IIS的完全控制权。
5.2 Internet服务
如果在第一个界面中启用了View template settings选项,那么将看到如下图所示的Internet Services界面。
该界面允许我们启用和禁用各种选项。如果不打算使用FTP、SMTP或NNTP服务,就可以禁用它们。
5.3 脚本映射
向导的第二个界面使我们能够定制正在使用的脚本映射类型。注意:在该界面上,我们必须选择想要禁用的那些内容。
当IIS收到一个被映射的文件类型的请求时,将由文件类型所映射的DLL处理该项呼叫。如果您不使用这些文件类型,那么最好把它们的映射从IIS上删除。这将减少安全威胁。
5.4 附加安全设置
下一个界面 ,使我们能够设置附加安全设置。默认状态下,它将删随IIS一起提供的示例应用程序。我们可以有选择地删除下列选项:
IIS Help选项
用匿名用户权限运行系统命令如Cmd.exe和Tftp.exe的能力
向Web站点或虚拟目录写内容的能力
在分布式环境下使用WebDEV向Web服务器编制内容的能力。
如果您在服务器上不打算使用任何选项,那么最好禁用它们。
5.5 UrlScan
UrlScan是一个ISAPI筛选器,它能监视并且分析发到IIS的HTTP请求。管理员可以在%Windir%\System32文件夹的UrlScan.ini文件中设置UrlScan参数。Lockdown Wizard含有UrlScan.ini文件的若干个版本。要安装的版本将取决于选择了哪个模板。UrlScan.ini文件中有每个设置选项的部分。UrlScan实用程序产生一个日志文件UrlScan.log,它给出实用程序的状态信息,包括它拒绝了的HTTP请求。
例如:如果我们只允许使用HTTP的HEAD和POST方法,那么我们应当将UseAllowVerbs设置为1并且AllowVerbs部分指定允许的HTTP方法(HEAD和POST):
[options] UseAllowVerbs=1
[AllowVerbs]
HEAD POST
如果只想允许使用.aspx、.ascx、.asax、.htm、.html、.jpg、.jpeg和.gif等文件类型,那么应当使用下列设置:
[Options]
UseAllowExtensions=1
[AllowExtensions]
.aspx
.ascx
.asax
.htm
.html
.jpg
.jpeg
.gif
如果想要拒绝使用URL中的某个扩展名,如.com,.exe,.bat,cmd,那么可以使用下列设置:
[options]
UseAllowExtensions=0
[DenyExtensions]
.exe
.bat
.cmd
.com
说明:
在安装并设置UrlScan应用程序后,可能发现不能从VS.NET调试ASP.NET应用程序。在下面链接中可以找到解决办法:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q310588&GSSNB=1.
如果重新安装IIS Lockdown Wizard,将撤销已做的改变。
六、保护Telnet
如果想在存放IIS的地方包括Telnet服务,那么就应当考虑限制能访问Telnet服务的用户。我们可以通过创建一个名为TelnetClients的新Windows组来保护Telnet服务,然后在该组中增加适当的Windows用户帐户。当TelnetClients组存在时,Telnet服务将只允许那些在组中被定义的用户使用该服务。
摘自:http://www.cnblogs.com/a311300/archive/2009/04/08/1430197.html