项目发布: IIS 日志安全分析器
项目发布: IIS 日志安全分析器
近期发现服务器有一些异常，随机手搓了一个 IIS 日志安全分析器，基于不同维度对访问进行分析，并识别可疑的 IP 地址或地址段，便于通过网络策略进行阻拦，以下是其主要特性和功能。
主要特性
- 多维度安全分析：检测SQL注入、XSS攻击、管理面板探测、命令执行尝试等多种安全威胁
- 智能IP地理定位：集成多个IP地理位置API，显示攻击者的地理位置和ISP信息
- 子网攻击分析：识别和分析可疑的子网攻击模式
- 交互式HTML报告：生成带有导航功能的美观HTML报告
- FTP活动监控：分析FTP连接、认证尝试和异常活动
- 实时威胁评估：对危险IP进行深度分析和威胁等级评估
功能概览
Web流量分析
- HTTP状态码分布统计
- 最活跃客户端IP识别
- 热门访问页面分析
- 用户代理(User-Agent)统计
- 错误请求模式分析
安全威胁检测
支持检测以下安全威胁类型：
- 管理面板探测 - 检测对admin、wp-admin等管理界面的扫描
- 命令执行尝试 - 识别代码注入和命令执行攻击
- 环境文件访问 - 检测对.env等敏感配置文件的访问
- phpMyAdmin探测 - 识别对数据库管理工具的扫描
- Shell访问尝试 - 检测Webshell上传和访问尝试
- 目录遍历攻击 - 识别路径遍历攻击模式
- CGI漏洞利用 - 检测CGI脚本相关的攻击
- Git文件访问 - 检测对.git目录的非法访问
IP地理位置分析
- 多API支持 - 集成ip-api.com、ipapi.co、ipinfo.io等多个服务
- ISP信息 - 显示IP所属的ISP和组织信息
- 地理位置 - 精确到城市级别的地理位置信息
- 故障转移 - 多API自动切换确保服务可用性
交互式报告
- 美观界面 - 现代化的HTML报告设计
- 一键导航 - 点击IP或子网快速跳转到详细信息
- 浮动按钮 - 便捷的返回顶部功能
- 响应式设计 - 支持各种屏幕尺寸
这款 IIS 日志安全分析器基于 Python 开发，有需要的网友可自行获取。项目地址：https://github.com/goxia/Tools/tree/main/IISLogAnalyzer
[SBS]解决在 SBS2011 上因压缩模块导致的 HTTP 500.19 故障问题
解决在 SBS2011 上因压缩模块导致的 HTTP 500.19 故障问题
前一篇与大家分享了因开启 32BitApponWin64 后出现的 HTTP 503 故障问题（http://goxia.maytide.net/read.php/1678.htm），而本篇还是与 IIS 和 ASP 有关。接二连三出现问题也并不是 gOxiA 所希望看到的结果，但是之前在调试那个 ASP 程序时确实很不顺利，在 503 故障解决之后紧接着就是 500.19 故障。
大家知道 500.19 是常见故障，导致该问题的出现原因有很多，如果仅是单纯看错误摘要“无法访问请求的页面，因为该页的相关配置数据无效”，是很难确定故障原因的。
所以我们需要将重点放在详细错误信息中，以本案为例，参考下图可看到在详细错误信息中提示“模块 DynamicCompressionModule”出现错误，错误代码为“0x8007007e”。
检查了 Windows Server 2012 Essentials 环境，发现该 ASP 程序所在网站也启用了压缩模块，但访问是正常的。此外在 iis.net 上找到一篇相关的帖子 http://forums.iis.net/t/1149768.aspx/1/10，貌似与 SBS2011 上集成的服务应用有关，尤其是 WSUS，涉及文件“suscomp.dll”，suscomp.dll 是 WSUS 的专用压缩模块。
起初，gOxiA 参考帖子直接将加载的 suscomp.dll 语句注释掉以禁用加载，之后测试 ASP 程序确实就正常了，但这样以来就要牺牲掉 WSUS 的压缩模块。suscomp.dll 属于全局类型的模块，它根据压缩的类型（动态或静态）由 IIS 的 compdyn.dll 和 compstat.dll 进行调用，所以在 IIS 管理器的站点模块管理中也找不到对应的配置信息，所以单独对站点禁用该模块是不可能的。
此外想单纯通过禁用站点的压缩功能也是不行的，因为相关的模块还是被加载了，只要加载就会导致故障的出现。
所以要彻底解决这一故障的唯一办法就是将对应站点中的动态和静态压缩模块全部给删除掉，不予以加载。要直接为单独某个站点删除模块，是不行的！会提示错误“锁定冲突”……
为此，要修改 IIS 服务设置，即在 IIS 管理器里选中当前服务器，通过内容窗体中的“模块”进入其设置，找到对应的模块（如：DynamicCompressionModule），在任务窗体中点击“解除锁定”，之后才能在对应站点中对模块进行删除。
因为涉及到的是全局的 suscomp.dll 模块，所以为了保证 ASP 程序正常访问，除了要删除 动态压缩模块以外，同时还要删除静态压缩模块（StaticCompressionModule）。现在 ASP 程序便可正常访问了，而且也不会影响到 WSUS 服务。（PS：不能再拖了，要尽快完成 SBS2011Std 到 WS2012Ess 的升迁工作！！！）
[SBS]解决因开启 32BitApponWin64 后出现的 HTTP 503 故障问题
解决因开启 32BitApponWin64 后出现的 HTTP 503 故障问题
自从离开 Hosting 行业，好久没有做过 IIS 方面的排错，今天算是遇到了一个，感觉会很常见，所以记录下来以备后用。用户购买了一套 ASP+Access 的小程序（PS：别问为什么还要买这么老旧的架构程序！），配置到用户的 Windows Server 2012 Essentials 环境中运行正常，操作过程并无什么特别，只是为其应用池开启 32位程序支持即可，整个过程非常顺利。
反而在之后配置到 gOxiA 的 Windows Small Business Server 2011 Standard 环境中后一直无法正常运行，IE 访问时提示“Service Unavailable”，经典的 HTTP 503 故障。起初检查 IIS 配置没有发现异常，但是看到对应的应用池会被停掉。于是打开事件查看器查阅日志，发现了很多来源为“IIS-W3SVC-WP”的错误，其内容大致如下：
“由于配置问题，无法加载模块 DLL “C:Program FilesMicrosoftExchange ServerV14ClientAccessOwaauthexppw.dll”。当前配置仅支持加载为 x86 处理器架构构建的映像。……”此外，除了 exppw.dll 文件外还有 kerbauth.dll 也出现错误。
综上分析，应用程序池的 32位应用支持是正常打开了，但是却无法加载 64位的 DLL 文件。而关闭“enable32BitAppOnWin64”后应用程序池恢复正常，但无法访问 ASP 程序。那么原因应该是出在应用程序池和加载模块的问题上。“exppw.dll”和“kerbauth.dll”文件都属于服务器上的 Exchange Server 2010 所有，这两个文件本身肯定是没有问题的。
看来还是要锁定到应用程序池方面，应用程序池本身是64位的，只是开启了32位应用支持，所以应用程序池在设置后是正常运行状态。当触发访问请求时，该应用程序池会启动一个新的32位模式的进程，来接受 ASP 类型的访问请求，此时就会导致 32位应用程序池进程（w3wp.exe）与加载的 64位 DLL 出现系统策略上的冲突，被系统强行终止，最终出现前面所述的故障。
要解决这个故障貌似挺难的，难不成跑了64位应用（Exchange Server 2010）的服务器就不能跑 32位 的 ASP 程序了？！看来只能网上找找是否有相关的资料，这还真的找到了！参考资料：http://blogs.msdn.com/b/rakkimk/archive/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes.aspx
文中末尾提到可以修改“applicationHost.config”文件，为加载的 DLL 指定对应架构模式的 ISAPI Filter 来运行。即，在每个 DLL 加载配置行尾附加“preCondition”参数，如果该 DLL 是 32位那值为“bitness32”，而 64位的则是“bitness64”。修改后的结果可以参考下图：
针对本例，我们需要修改的有两个：“exppw.dll”和“kerbauth.dll”。最后测试一下结果，网站已经能够正常访问，至此故障消失问题得到了解决！同样，有遇到类似故障的都可参考此法解决。
