微软给了我们一个很好的工具用来使IIS安全的运行-------UrlScan,下面是它的配置文件介绍
[options]
UseAllowVerbs=1 ; 若为1,则使用[AllowVerbs]部分定义的方法,否则使用[DenyVerbs]部分定义的方法
UseAllowExtensions=0 ; 若为1,则使用[AllowExtensions]部分定义的扩展名,
否则使用[DenyExtensions]部分定义的扩展名
NormalizeUrlBeforeScan=1 ; if 1, canonicalize URL before processing
VerifyNormalization=1 ; if 1, canonicalize URL twice and reject request if a change occurs
AllowHighBitCharacters=0 ; if 1, allow high bit (ie. UTF8 or MBCS) characters in URL
AllowDotInPath=0 ; if 1, allow dots that are not file extensions
RemoveServerHeader=0 ; 若为1,则移除IIS的server标头
EnableLogging=1 ; 若为1,则开启urlscan日志功能
PerProcessLogging=0 ; if 1, the UrlScan.log filename will contain a PID (ie. UrlScan.123.log)
AllowLateScanning=0 ; 若为1,则urlscan以低优先级启动
PerDayLogging=1 ; 若为1,则UrlScan将以UrlScan.010101.log这样每日的形式生成日志
RejectResponseUrl= ; UrlScan将发送拒绝请求到指定的URL,默认是/<Rejected-by-UrlScan>
UseFastPathReject=0 ; 若为1,则UrlScan将不会使用上面的RejectResponseUrl或允许IIS记录该请求
; If RemoveServerHeader is 0, then AlternateServerName can be
; used to specify a replacement for IIS's built in 'Server' header
;则RemoveServerHeader = 0,则可以使用下面字符串替换IIS的server头部
AlternateServerName=
[AllowVerbs]
;IIS中一般支持的方法
;当上面的 UseAllowVerbs = 1 时下面的才有效
;
GET
HEAD
POST
[DenyVerbs]
;
;当使用WebDAV发布内容到IIS 服务器上时,下面的方法将会使用
;当上面的 UseAllowVerbs = 0 时下面的才有效
;
PROPFIND
PROPPATCH
MKCOL
DELETE
PUT
COPY
MOVE
LOCK
UNLOCK
OPTIONS
SEARCH
[DenyHeaders]
;
; The following request headers alter processing of a
; request by causing the server to process the request
; as if it were intended to be a WebDAV request, instead
; of a request to retrieve a resource.
;
Translate:
If:
Lock-Token:
[AllowExtensions]
;
;允许使用的扩展名
;当上面的 UseAllowExtensions = 1 时有效
;
.asp
.cer
.cdx
.asa
.htm
.html
.txt
.jpg
.jpeg
.gif
;.idq
;.htw
;.ida
;.idc
;.shtm
;.shtml
;.stm
;.htr
;.printer
[DenyExtensions]
;
;不允许使用的扩展名
;当上面的 UseAllowExtensions = 0 时有效
;
; 阻止可执行文件的执行
.exe
.bat
.cmd
.com
; 阻止比较少用的脚本
.htw ; Maps to webhits.dll, part of Index Server
.ida ; Maps to idq.dll, part of Index Server
.idq ; Maps to idq.dll, part of Index Server
.htr ; Maps to ism.dll, a legacy administrative tool
.idc ; Maps to httpodbc.dll, a legacy database access tool
.shtm ; Maps to ssinc.dll, for Server Side Includes
.shtml ; Maps to ssinc.dll, for Server Side Includes
.stm ; Maps to ssinc.dll, for Server Side Includes
.printer ; Maps to msw3prt.dll, for Internet Printing Services
; 组织对各类静态文件的讨论,可以加入.mdb、.inc等后缀
.ini ; Configuration files
.log ; Log files
.pol ; Policy files
.dat ; Configuration files
;.asp
;.cer
;.cdx
;.asa
[DenyUrlSequences]
.. ; 不允许目录遍历
./ ; Don't allow trailing dot on a directory name
\ ; 不允许反斜杠出现在URL中
: ; Don't allow alternate stream access
% ; Don't allow escaping after normalization
& ; 在单一的请求上不允许多个CGI进程运行
不可否认,SQL注入是现在网站攻击的主要手段,而在我以往做网站中都是利用字符串过滤和错误隐藏来避免这种攻击。这种方法只是从程序可以有效避免一些侵略,但实际如果在你没能力改变代码的情况下该如何防止这样的问题呢?下面我找到的两中办法,都是利用IIS来进行设置的。
UrlScan 3.1
UrlScan 3.1是一个安全方面的工具,微软官方的东西。它会检查所有IIS处理的HTTP请求。UrlScan 可以在有安全问题的HTTP请求到达应用程序之前就阻止这个请求。UrlScan 3.1 是UrlScan 2.5的一个升级版本,支持Windows Vista 和Windows Server 2008系统之上的IIS 5.1, IIS 6.0 和 IIS 7.0。
链接地址:http://www.iis.net/expand/UrlScan 这里还有很多非常有用的IIS扩展,可以看看。
IIS 6 SQL Injection Sanitation ISAPI Wildcard
这个ISAPI dll 也是通过检查HTTP请求避免SQL注入。只兼容windows 2003上的 IIS 6.0。对于Windows XP 上的 IIS 5 不支持。
这是一个开源项目:http://www.codeplex.com/IIS6SQLInjection
批改或隐藏IIS7.5的Server头信息
修改或隐藏IIS7.5的Server头信息
环境是 Windows 2008 Server R2 + IIS7.5
必须保证IIS角色下安装上ISAPI筛选器和IIS6元数据库兼容性。
首先下载 UrlScan 。然后直接安装。安装以后进入IIS管理,功能视图里ISAPI筛选器里应有UrlScan这一行。
全局配置文件
C:\Windows\System32\inetsrv\urlscan\UrlScan.ini
RemoveServerHeader=0 ; 改成1以后不显示Server AlternateServerName= ;如果RemoveServerHeader=0可以自己定义
在IIS 6 和 IIS 7 中 移除X-Powered-By xxx 的 HTTP头 的方法如下:
X-Powered-By HTTP头并不只是在Asp.net中存在,其他服务端语言,比如php, 也会包含这个HTTP头,当Asp.net被安装时,这个头会作为一个定制的 HTTP头插入IIS中,因此,我们需要将这个HTTP头从IIS的配置中删除,如果你的网站是在共享的环境下并且没有使用IIS7并使用管道模式,你不 得不为此联系你的空间提供商来帮你移除。(如果你的网站是在IIS7环境下,那你可以通过HTTP Module的形式通过编程来移除)
在IIS6中移除X-Powered-By HTTP头:
启动IIS,展开Website目录
在Website上点击右键并在弹出的菜单中选择“属性”
选择HTTP Header标签,所有IIS响应中包含的自定义的HTTP头都会在这里显示,只需要选择响应的HTTP头并点击删除就可以删除响应的HTTP头,如图:
而在IIS7中移除X-Powered-By HTTP头的方法是:
选择你需要修改的站点并双击HTTP响应头部分
所有的自定义HTTP头全在这里了,删除相应的头仅需要点击右边的”Remove”链接:
If you are building and deploying public facing web applications, security has to be one of your key consideration; ensure that you create a security threat model of your application to highlight the flow of data in your application and the possible weak points (Microsoft have a useful tool called Microsoft Security Assessment Tool which can help you with the planning process); ensure that your production environment has been hardened (and that you have run the various tool provided to spot any vulnerabilities in your infrastructure, such as Microsoft Baseline Security Analyzer and tools like CAT.NET and Paros for spotting vulnerabilities in your application code); ensure that your web application protects against Cross Site Scripting (XSS) and Cross-Site Request Forgery (CSRF/XSRF) attacks.
If you can afford the cost, adding an Intrusion Prevention System device to your network adds benefit, but if you can’t afford such a device then a tool such as UrlScan can offer some protection by blocking potentially harmful HTTP Requests. In order to use URLScan effectively you need to put an operational feedback loop in place whereby you use a tool such as LogParser (if you want a nice UI for this command line app, give Visual LogParser a try) to examine your application’s IIS Logs for suspicious activity and add rules to UrlScan and your firewall to block such requests.
Examining IIS Server logs from a high traffic public website or having a network monitoring solution such as Cacti is fascinating and terrifying in equal measures; once you have removed the noise of normal human generated traffic, the sheer volume of remaining non-human traffic generated by bots and spiders is staggering. Once you’ve filtered out all the requests generated by search engine’s crawlers there are a surprising number of other requests being made against your servers the two worst being harvesters (screen scrapers) and bots that perform vulnerability scanning and exploitation. These bots start by fingerprinting your server and then exploit any known vulnerabilities, the HTTP RFC 2068 highlights this possibility:
"Note: Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Server implementers are encouraged to make this field a configurable option."
There are two recourses to this situation, firstly you can broadcast a fake web topology, for example if your web platform is WISA (Windows, Internet Information Services, SQL Server, ASP.NET) you can configure your servers to return the response headers of a LAMP (Linux, Apache, MySQL, PHP) platform. Secondly you can cloak this information, so it isn’t broadcasted at all.
By default a WISA platform (running ASP.NET MVC) discloses its identity, by broadcasting the following response header (using Firebug):
You can turn off the X-AspNet-Version header by applying the following configuration section to your web.config:
<system.web> <httpRuntime enableVersionHeader="false"/> </system.web>
which results in the X-AspNet-Version being removed:
You can then remove the X-AspNetMvc-Version header by altering your Global.asax.cs as follows:
protected void Application_Start() { MvcHandler.DisableMvcResponseHeader = true; }
which results in the X-AspNetMvc-Version being removed:
But there is no easy way to remove the Server response header via configuration. Luckily IIS7 has a managed pluggable module infrastructure which allows you to easily extend its functionality. Below is the source for a HttpModule for removing a specified list of HTTP Response Headers:
namespace Zen.Core.Web.CloakIIS { #region Using Directives
using System; using System.Collections.Generic; using System.Web;
#endregion /// <summary> /// Custom HTTP Module for Cloaking IIS7 Server Settings to allow anonymity /// </summary> public class CloakHttpHeaderModule : IHttpModule { /// <summary> /// List of Headers to remove /// </summary> private List<string> headersToCloak;
/// <summary> /// Initializes a new instance of the <see cref="CloakHttpHeaderModule"/> class. /// </summary> public CloakHttpHeaderModule() { this.headersToCloak = new List<string> { "Server", "X-AspNet-Version", "X-AspNetMvc-Version", "X-Powered-By", }; }
/// <summary> /// Dispose the Custom HttpModule. /// </summary> public void Dispose() { }
/// <summary> /// Handles the current request. /// </summary> /// <param name="context"> /// The HttpApplication context. /// </param> public void Init(HttpApplication context) { context.PreSendRequestHeaders += this.OnPreSendRequestHeaders; }
/// <summary> /// Remove all headers from the HTTP Response. /// </summary> /// <param name="sender"> /// The object raising the event /// </param> /// <param name="e"> /// The event data. /// </param> private void OnPreSendRequestHeaders(object sender, EventArgs e) { this.headersToCloak.ForEach(h => HttpContext.Current.Response.Headers.Remove(h)); } } }
Ensure that you sign the assembly, then you can install it into the GAC of your web servers and simply make the following modification to your application’s web.config (or if you want it to be globally applied, to the machine.config):
<configuration> <system.webServer> <modules> <add name="CloakHttpHeaderModule" type="Zen.Core.Web.CloakIIS.CloakHttpHeaderModule, Zen.Core.Web.CloakIIS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=<YOUR TOKEN HERE>" /> </modules> </system.webServer> </configuration>
Now when you execute a page, you should see the following HTTP Response (with X-AspNetMvc-Version, X-AspNetMvc-Version and Server response headers removed):
One further note – the bots also fingerprint via file extensions, if you are running ASP.NET MVC, extensionless URLs implemented via the ASP.NET MVC routing system, should help avoid this type of detection.