urlscan for windows server 2008

Windows Server 2008 上跑 urlscan，第一件事不是去下载，而是先确认 IIS 版本。urlscan 3.1 是最后一个支持 IIS 7 的版本，但它的安装包默认只认 IIS 6 的 metabase 路径。如果你直接双击 MSI，它会报错说找不到 IIS。解决办法是手动解压 MSI，把 urlscan.dll 和 urlscan.ini 拷到系统目录，再用 appcmd 注册 ISAPI 筛选器。这个过程我做过不下十次，每次都觉得微软当年对 Server 2008 的兼容性处理得实在潦草。

具体路径：把 urlscan.dll 放到 C:\Windows\System32\inetsrv\，urlscan.ini 放到 C:\Windows\System32\inetsrv\urlscan\。然后打开 IIS 管理器，点服务器节点，进“ISAPI 筛选器”，添加一个名为 UrlScan 的筛选器，可执行文件指向那个 dll。别用“添加 ISAPI 筛选器”向导里的浏览按钮，它默认过滤 .dll 文件，直接手输路径更快。

注册完筛选器，IIS 会立刻加载它。但 urlscan.ini 的默认配置在 Server 2008 上会拦掉一些正常请求。比如 [Options] 段里的 UseAllowExtensions=0，意思是禁止所有扩展名不在允许列表里的文件。默认允许列表只有 .asp、.htm、.html 这些，如果你的站点跑 .aspx 或 .ashx，请求会直接返回 404.2。改法很简单：把 UseAllowExtensions 改成 0 之后，在 [AllowExtensions] 段里加上 .aspx、.ashx、.asmx、.axd。注意 .axd 是 ASP.NET 的 WebResource 请求用的，不加的话页面上的脚本资源全挂。

另一个坑是 [DenyHeaders] 段。默认会拦掉包含 translate: 或 lock-token: 的请求头。有些老式 WebDAV 客户端会发这些头，结果被 urlscan 直接掐断。如果你不确定，先把 DenyHeaders 整段注释掉，观察一周日志再决定要不要加回来。我见过一个案例：某公司的文档管理系统在 Server 2008 上跑，用户上传 Word 文档时偶尔失败，查了三天才发现是 urlscan 拦了 translate 头——那个头是 Office 的 WebDAV 组件自动加的。

日志位置在 C:\Windows\System32\inetsrv\urlscan\Logs\。默认只记录被拦截的请求，不记正常请求。如果你要调试，把 [Options] 里的 Logging=1 改成 Logging=2，这样所有请求都会记。但别长期开 2，日志文件涨得飞快，一天几个 G 很正常。我一般只在排查问题时临时开，搞完立刻改回 1。

还有一个实际经验：urlscan 和 IIS 的请求筛选（Request Filtering）功能有重叠。Server 2008 的 IIS 7 自带请求筛选，能拦 URL 长度、查询字符串长度、高危字符。如果你已经启用了请求筛选，urlscan 的很多规则就是多余的。但 urlscan 有一个请求筛选没有的功能：它可以基于 [DenyQueryStringSequences] 做更细的 SQL 注入特征匹配。比如 ;--、/*、xp_ 这些片段，请求筛选只能靠正则，而 urlscan 是硬编码的字符串匹配，性能更好。所以我的做法是：请求筛选管长度和字符集，urlscan 管注入特征。两者同时开，不冲突。

最后说一个真实故障。某次给一台老 Server 2008 打 urlscan 后，IIS 每隔几小时就自动重启。查事件日志，发现是 urlscan.dll 在 HttpFilterProc 里访问了一个空指针。原因是 urlscan.ini 的 [Options] 段里 UseFastPath=1 和 VerifyNormalization=1 同时开启时，对某些超长 URL 会触发 bug。把 VerifyNormalization 改成 0 就稳定了。这个 bug 在 urlscan 3.1 的 release notes 里没写，但微软论坛上有人提过。如果你也遇到 IIS 无故重启，先查这个。

urlscan 在 Server 2008 上不是即插即用的工具，它需要你手动调 ini、注册筛选器、观察日志、反复试错。但一旦调好，它比后来 IIS 自带的很多安全模块都轻量、直接。我至今还在几台内网老服务器上用它，就图个心里踏实。