由一个案例引出SQL注入防范（WebKnight），补救（数据修复）的思考

写在前面

我写本文的目的，是和各位分享一下内容篡改式攻击的判断方法、SQL注入攻击的防范、以及被攻击后的补救（数据恢复）相关知识，如有谬误，期待您的指正。

前言

2009年9月5日中午1点，历史会记住这个时刻，我们网站被“成功”攻击了，网站一些页面被插入了下载病毒的代码，经查：

• 生产服务器的代码没有任何被改动过的迹象，排除服务器被入侵，代码被篡改的可能；
• 有病毒下载代码的部分，在数据库里真实看到了篡改迹象，可以排除ARP欺骗的可能；
• 同上，能确定网站被SQL注入攻击了，因为数据库被篡改了。

由于是被攻击后马上发现的现象，可以判断攻击此刻应该正在继续（后来检查的结果证明的确是这样），如何能尽快阻止攻击呢？我有2个思路（如果各位有更好的思路，期待您的指点）：

• 马上找到含有SQL注入漏洞的程序，修复之；
• 马上增加一个应用程序防火墙（Application Firewall），从HTTP请求时就阻断攻击。

第一个思路几乎是不可能马上完成的任务，第二个思路还可行，因为前段时间上海天存信息技术有限公司曾提供给我们试用iWall应用防火墙（正式产品是收费的），还记得当时一位朋友提供给我的开源应用程序防火墙WebKnight，我信赖开源，所以我选择了后者。

如何在IIS6中安装WebKnight？

我们的 WebServer 是 IIS6，所以这里只介绍IIS6的安装，我见有些帖子介绍WebKnight的安装时，说只有把IIS调整成IIS5.0隔离模式（IIS5.0 isolation mode）才可以，但实际上WebKnight的官方网站有介绍不需要此操作即可安装的办法，但这需要放弃WebKnight的全局配置特性，相比放弃IIS6.0，我更愿意放弃WebKnight的这个特性：

1. 首先下载一份WebKnight，下载地址：http://aqtronix.com/?PageID=99#Download（注，这不是直接下载地址，点开后需要再点击WebKnight 2.2 (Release date: 2008.09.02)，以防更新后各位朋友还下载旧的版本）
2. 解压后有2个目录Setup、Source，其中Source是源码，我们这里只需要安装，进入Setup
3. 进入Setup后还有2个目录：w32代表32位；x64代表64位；按照您服务器的操作系统来选择即可，我这里选x64（由于WebKnight的32位、64位文件结构完全相同，所以下面的内容完全适用与32位操作系统）
4. 确保自己的每一个网站都运行在独立的应用程序池中；
5. 在WebKnight的配置程序中
   1. 取消选择“Global Filter Capabilities”下的“Is Installed As Global Filter”
   2. 选择“Logging”下的“Per Process Logging”，这样每一个应用程序池的实例都会加载一个单独的WebKnight实例
6. 确保Windows用户NETWORK SERVICE（或您设定的应用程序池的其他用户）有WebKnight文件夹的修改权限
7. 拷贝第3步中x64文件夹中的所有文件到服务器上（如：F:\WebKnight\WebSite1\），注意：每一个网站均需要一个独立完整的WebKnight，不可共用
8. 打开IIS Manager
9. 在需要安装WebKnight的网站上点击右键 > 属性 > ISAPI filters
10. 点击添加 > Filter Name随意，如（WebKnight），Excutable选择WebKnight目录下的WebKnight.dll（注意：要选网站所属的WebKnight目录，不要选错）
11. 点击确定，完成安装
12. 点击WebKnight目录中的Config.exe，具体配置方法见下一节，配置完成后再进行下一步，切记
13. 在以上操作后，重新启动IIS（重启IIS其实可以避免，只需将配置WebKnight的网站的应用程序池停止再启动即可）

如何配置WebKnight

声明：由于WebKnight的配置很多，这里我只写一下推荐配置，个人观点，仅供参考，如果更好的建议，期待您的分享

在WebKnight目录中（如：F:\WebKnight\WebSite1\），双击Config.exe开始配置，在弹出的Open Configuration对话框中，选择WebKnight.xml

• Scanning Engine 扫描引擎
  • 无需更改默认配置
• Incident Response Handling 已发生攻击的处理
  • 如果您希望有人攻击时看到的页面是WebKnight目录中的denied.htm，选择Response Directly即可；
  • 如果您希望有人攻击时看到的页面是您网站下的某个文件（如：http://www.xxx.com/Error/Denied.htm），选择Response Redirect，并在下面的Response Redirect URL中填写您网站下文件的路径（如：/Error/Denied.htm）
  • 如果您只希望记录攻击，但不希望中断用户的访问，您可以选择Response Log Only
• Logging 日志
  • 如果日志量特别大，请取消选择Enabled，否则很有可能磁盘可用空间不知不觉就没有了，还有可能有比较严重的磁盘I/O性能问题
  • 日志默认是存储在WebKnight目录下的LogFiles文件夹中，如果您想改变该路径，可以修改Log Directory的值
  • WebKnight每天的日志是由不同文件存储的，默认保存28天的数据，您可以在Log Retention中修改该值
• Connection 连接
  • 无需更改默认配置
• Authentication 安全认证
  • 无需更改默认配置
• Request Limits 请求限制
  • 取消选择Limit Content Length（Content-Length是header中的一个值，代表所请求元素的尺寸），我个人觉得这项没有必要选择，因为元素尺寸有可能很大
  • 取消选择Limit URL（即限制URL的长度），原因同上，URL也可能很长
  • 取消选择Limit Query String（即查询字符串的长度），原因同上，查询字符串也可能很长
  • 取消选择Limit HTTP Version（即HTTP版本），我感觉没有必要限制HTTP版本，有可能会造成使用过旧版本浏览器的用户无法访问自己的网站
  • 取消选择Use Max Headers（即限制Headers中各项的最大长度）。我一开始是选择了该项的，但在我的实践中，由于我们用了网站流量统计、广告合作代码等，导致Headers中的一些项超长，阻止了相当多的正常请求，所以我想干脆一劳永逸，取消选择了该项
• URL Scanning 网址扫描
  • 取消选择RFC Compliant URL、RFC Compliant HTTP Url、Deny Url HighBitShellCode，勾选了这三项，很多不太标准的URL格式就会无法访问，比如包含中文的URL
  • 取消选择Deny URL Backslash，因为我们网站中，“\”在URL里面也会用到
  • 在URL Denied Sequences中，描述了拒绝请求的一些URL字符串，如果其中有您网站中正在使用的，可以删除，方法是选中要删除的项目，右键，点击Remove Selected
• Mapped Path 映射目录
  • Use Allowed Paths，这项保持勾选，因为这项可以限制Web程序可以访问的服务器上的物理路径，我们需要做的只是在下面的Allowed Paths中添加上我们自己的网站物理路径，比如F:\WebSite1，添加方法是在任意项上点击右键 > Insert Item > 输入物理路径后，回车即可
• Requested File 被请求的文件
  • 在Denied Files（拒绝请求的文件）中，去掉网站允许请求的文件，如：log.htm、logfiles
  • 在Denied Extensions（拒绝请求的后缀名）中，去掉网站循序请求的后缀名，如：shtm
• Robots 蜘蛛程序
  • 无需更改默认配置
• Headers 头信息
  • Server Header中，可以修改Header中的Server字段的值，我觉得这个也可以改改，挺好玩的
  • 为了防止组织合法的请求，取消勾选RFC Compliant Host Header、Use Denied Headers
• ContentType 内容类型
  • 取消选择Use Allowed Content Types，若选中，则无法上传文件
• Cookie 这个就不需要翻译成中文了吧：）
  • 无需更改默认配置
• User Agent 用户代理/客户端
  • 取消勾选Deny User Agent Empty、Deny User Agent Non RFC，否则有部分合法访问会被拒绝
• Referrer 访问来路
  • 取消选择Use Referrer Scanning，因为我觉得一个访问的来路可能不会有太严重的安全问题，还是为了尽量让合法的请求通过，我选择取消勾选该项
• Methods HTTP请求方法
  • 无需更改默认配置
• Querystring 查询字符串
  • 无需更改默认配置
• Global Filter Capabilities 全局过滤功能
  • 取消勾选Is Installed As Global Filter，切记，该项一定要取消选择，否则WebKnight不能正产工作
• SQL Injection SQL 注入
  • 无需更改默认配置
• Web Applications Web应用程序
  • 勾选Allow File Uploads，否则上传文件的功能会失效
  • 勾选Allow Unicode
  • 勾选Allow ASP NET
  • 如果您的网站需要支持ASP，勾选Allow ASP
  • 同理，您的网站需要支持什么，请您自己选择需要勾选的项

修改后，记得通过菜单栏File > Save 来保存配置（或通过快捷键Ctrl+S），保存配置后，就可以重启IIS或应用程序池来启用WebKnight了

提示：您可以通过查看WebKnight的日志，来查看哪些合法请求被阻止了，然后修改相应的配置

如何恢复被篡改的数据

通过安装这个Application Firewall，攻击是被阻止了，但数据库里被篡改的数据，还需要恢复，这里其实包含了2个问题：

1、如何找到被篡改的数据

以彼之道还施彼身。我找到了实施SQL注入的一篇帖子，里面讲到，是“通过游标遍历数据库中的所有表和列并在列中插入代码”，同理，我们也可以写一个程序，遍历数据库中所有表和列，并判断是否存在特征字符串，这个特征字符串即被插入的恶意代码特征。由于此种攻击是将数据库所有行数据修改，所以每个表我们只看一行数据就可以，也不会耗时太久。

2、如何恢复被篡改的数据

我找到了被篡改的表后，其中一些字段是存储的冗余数据，可以通过SQL语句从数据源读取然后更新即可，如：

 UPDATE TableA SET ColumnA = (SELECT TableB.ColumnA FROM TableB WHERE TableB.BID = TableA.BID)

还有比较费劲的就是源数据被改，要修复这样的数据，就必须得有备份了，我们先将备份的数据库还原成一个用户恢复的数据库：

1、执行

 restore filelistonly FROM disk='X:\BackupName.BAK'

获得当前备份文件的逻辑名

2、使用windows账户或者sa登陆执行以下SQL语句：

 restore DATABASE [还原目的数据库] 
2 FROM disk='X:\BackupName.BAK' --备份文件的路径
3 WITH 
4 file=1, --文件的编号
5 move '备份数据文件的逻辑名' TO 'X:\MSSQL\Data\物理文件名_Data.MDF', --数据库逻辑名 to 还原到的物理文件名
6 move '备份日志文件的逻辑名_Log' TO 'X:\MSSQL\Data\物理文件名_Log.LDF' --日志逻辑名 to 还原到的物理文件名

3、当还原成功后，执行下面的语句对数据进行恢复：

 UPDATE [被篡改数据库].[dbo].[表] SET [待恢复字段] = (SELECT 还原的数据库.dbo.表.[待恢复字段] FROM 还原的数据库.dbo.表 WHERE 还原的数据库.dbo.表.主键 = [被篡改数据库].[dbo].[表].主键) WHERE 主键 IN (SELECT 还原的数据库.dbo.表.主键 FROM 还原的数据库.dbo.表)

如何找到有漏洞的程序

应用程序防火墙安装完毕、数据恢复了，接下来我们要找到有SQL注入漏洞的页面，常规的检测方法不再赘述，这里着重说一下如何找到本次攻击被利用的那个漏洞。方法其实很简单，因为被攻击的时间段是已知的，我们只需要把当天的IIS日志中相同时段的内容分析一下，很容易能得出结果，然后修复之。

至此，本次内容篡改式攻击的攻击方法判断，判断出SQL注入攻击后的防范措施，修复数据、修复漏洞的补救措施就全部描述完毕，因为是针对我们网站的例子讲的，普适性可能不够，仅供参考，如有谬误，期待您的指正。