Mikel
转载：http://www.linwan.net.cn/archives/2699.html
近期在朋友的服务器上发现了一些问题；前段日子他就说，有两个站占用cpu很大，把此两站独立各自的应用程序池中，发现确实占用很大，发现此两站一 个是asp网站程序，是站长自己写的，并且用的mdb数据库已经有将近100M；另一个是discuz论坛，安装有“虚拟股市”等插件。大概一看，心里有 了些打算。
分析：一般自写的asp程序，在对access数据的操作上面，操控不是很完善；虽然这些站可能在本地调试很高效，但在大流量访 问读写的情况下，情况就完全不同了，因此，针对此站，告诉朋友，让这个站的站长，下载iis日志，分析读写日志，优化代码和数据库结构，并且，竭力建议该 站长转向SQLServer数据库结构。
discuz的论坛，应该稳定性是相当好的，其性能，自我感觉，还是比不上phpwind的，只是 phpwind6走到现在，也把以前的高效，有些丢弃，但既是丢弃，我感觉，还是要比discuz6要快上许多，确实对discuz有很大的矛盾心理。 discuz论坛上，有很多说明，占用iiscpu过大以及对mySQL占用内存大的很多相关问题，这些，大家有意的可以到discuz论坛搜索一 下，iis、mySQL、cpu、内存等关键词，就知道，问题的普遍性了。查的这个站，在httperr中，发现了很多有关论坛插件“虚拟股市”的日志， 如下简示（只是一部分代码）：
2008-02-03 10:46:19 124.78.190.55 61297 服务器ip 80 HTTP/1.1 GET /plugin.php?identifier=stock&module=stock – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
2008-02-03 10:46:19 124.78.190.55 61300 服务器ip 80 HTTP/1.1 GET /plugin.php?identifier=stock&module=stock – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
2008-02-03 10:46:19 124.78.190.55 61303 服务器ip 80 HTTP/1.1 GET /plugin.php?identifier=stock&module=stock – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
2008-02-03 10:46:19 59.56.45.157 7287 服务器ip 80 HTTP/1.1 GET /post.php?action=newthread&fid=3&extra=page%3D1 – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
2008-02-03 10:46:19 124.78.190.55 61307 服务器ip 80 HTTP/1.1 GET /plugin.php?identifier=stock&module=stock&action=chat – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
2008-02-03 10:46:19 124.78.190.55 61309 服务器ip 80 HTTP/1.1 GET /plugin.php?identifier=stock&module=stock – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
2008-02-03 10:46:19 124.78.190.55 61316 服务器ip 80 HTTP/1.1 GET /plugin.php?identifier=stock&module=stock – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
2008-02-03 10:46:19 124.78.190.55 61322 服务器ip 80 HTTP/1.1 GET /plugin.php?identifier=stock&module=stock – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
2008-02-03 10:46:19 124.115.4.198 48964 服务器ip 80 HTTP/1.1 GET /thread-73509-1-22.html – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
2008-02-03 10:46:19 124.78.190.55 61329 服务器ip 80 HTTP/1.1 GET /plugin.php?identifier=stock&module=stock – 7633 Connection_Abandoned_By_AppPool DefaultAppPool
就此看来，这个“虚拟论坛”插件，还是有些问题。因此，建议朋友告诉那位站长，要么要求插件制作方优化插件性能，要么取消这个插件的应用，尽量找官方推荐的认可的比较稳定的插件来使用；
另外，在看httperr日志的时候，同时也发现了Timer_MinBytesPerSecond 错误或 Timer_ConnectionIdle 错误 ，并且，这些错误出的时候，也是很连贯的，非常多，因此，这也属不正常现象；
C:\Windows\system32\LogFiles\HTTPERR\httperr*.log 中看到 Timer_MinBytesPerSecond 错误或 Timer_ConnectionIdle 错误。 这些是由IIS 默认设置, 定义用于连接到保持活动小通信流速率和最大空闲时间之前连接中断允许。
1) 从 IIS 管理器右键单击 Internet Information Server (IIS) 管理器级别根目录上并转到属性。 选中要启用直接编辑元数据库框。 单击确定。
2) 在 记事本中打开 C:\Windows\system32\inetsrv\MetaBase.xml 文件，搜索有关 " MinFileBytesPerSec "。 将用于 MinFileBytesPerSec 设置从 240 更改为 0。 执行其他搜索, 该时间将 600 " ConnectionTimeout "。 保存更改并退出。
3） 重新启动 IISAdmin 服务以更改生效。
另外，在谁是黑客(1): 关于IIS LOG的MinFileBytesPerSec和Timer_ConnectionIdle错误也发现了一些不错的言论，很独到，在理论上，他分析得还是很有见地的，只是很遗憾，没有下文。
以下内容引用：
前 些天发现自己的网站无法访问，询问机房这边，说是机器最近常死机，我就把网站迁移到一个朋友的主机上， 结果没过几天机器又挂了，问朋友的机房那边说是硬件防火墙被攻击了而死掉了，详细情况不知。看来不是硬件问题，多半是被SYN FLOOD或者CC攻击了。恰好原来的机房说最近购买了新的防火墙，我又放了回去。
既然不是硬件问题而可能是攻击，我就开始检查 IIS log了，发现 IIS 里面很多Timer_ConnectionIdle和Timer_MinBytesPerSecond的错误，到网络上google了一下，常见说法是说 错误是因为IIS的设置不当引起的，是因为连接超时时间设置太小，解决方法是设置连接超时为600秒，把MinFileBytesPerSec的设置从 240修改到0（相当于关掉该设置)。觉得这些解决方法都有问题，假如车辆防盗警报经常响，正确的解决方法是看看有谁常来打你车子的主意，或者把车子放在 更安全的地方，而绝对不是关掉警报。
因为HTTP服务需要占用TCP连接，而TCP连接时是需要占用系统资源的，而且IIS为每个连 接也需要分配相应的资源。目前的主机能够处理上万的连接就可以说是软硬件设计都很不错了(可以参见C10K )。假如恶意人员通过一台或者多台机器发起大量的连接，而不请求内容(这样不需要消耗多少攻击机器的带宽)，就可以大量消耗服务器资源而达到拒绝服务的目 的。
所以 IIS 需要关闭长时间非活动的连接，这个就是Timer_ConnectionIdle 的错误由来。
既 然盾牌改进了，当然矛也要发展一下，攻击者可以给服务器故意缓慢的发送和接收内容而消耗服务器的资源，这样可以避免服务器对于 Timer_ConnectionIdle 的保护，相应的IIS的防范就是 MinFileBytesPerSec 设置，MinFileBytesPerSec 属性通过以最小的数据量保持连接，来禁止恶意的或软件工作不正常的客户端消耗资源。如果吞吐量低于 MinFileBytesPerSec 设置的值，则终止连接。LOG里面就会显示Timer_MinBytesPerSecond错误（一些Timer_MinBytesPerSecond错 误是因为 windows 2003 的http.sys错误引起的，解决方式是打上最新 ServicePack ： http://support.microsoft.com/kb/919797 http://support.microsoft.com/kb/919797/en-us ）
所 以说这些设置都是用来保护IIS服务器的，可以一定程度上抵御一些恶意的行为消耗服务器的资源，所以我反而将IIS连接超时从原来的600秒改到了30 秒，就让攻击来得更加猛烈些吧！！不过我还是很纳闷: 网站不大，所以我不可能去财消灾。无怨无仇的，谁这么无聊啊？！
不得了，分析服务器，可真不是一件简单的事，复杂的问题，复杂的表现，综述出一大串复杂的原因，并且还要不断调整，然后再观察。呵，明天再看看httperr效果再说。
