Windows服务器运维中，IIS日志是排查异常请求最直接的数据来源。通过分析IIS日志文件（默认位于C:\inetpub\logs\LogFiles\W3SVC1\），你可以快速识别出SQL注入攻击、CC攻击、目录遍历、异常爬虫抓取等多种恶意行为模式。核心方法是利用Log Parser工具或者PowerShell脚本对日志进行批量统计分析，重点关注请求频率异常、状态码分布异常、URL路径异常、User-Agent异常这四个维度。下面我会把每一步操作和判断标准都讲清楚，你照着做就能上手。
一、IIS日志文件结构与关键字段解读
IIS默认使用W3C扩展日志格式，每一行代表一次HTTP请求。关键字段包括：date（日期）、time（时间）、s-ip（服务器IP）、cs-method（请求方法如GET/POST）、cs-uri-stem（请求路径）、cs-uri-query（查询参数）、s-port（端口）、cs-username（用户名）、c-ip（客户端IP）、cs(User-Agent)（浏览器标识）、sc-status（HTTP状态码）、sc-substatus（子状态码）、sc-win32-status（Windows状态码）、time-taken（响应时间，单位毫秒）。运维人员必须熟悉这些字段，因为异常模式的识别全部建立在对这些字段的组合分析之上。
二、使用Log Parser工具批量分析日志
Log Parser是微软官方提供的免费命令行工具，支持SQL-like语法查询日志文件。下载安装后，打开命令行窗口，进入日志目录执行分析。以下是几个最实用的查询命令：
LogParser "SELECT cs-uri-stem, COUNT(*) AS cnt FROM *.log WHERE sc-status=404 GROUP BY cs-uri-stem ORDER BY cnt DESC" -i:W3C -o:CSV
这条命令统计404错误最多的路径，如果某个路径被大量请求404，大概率是目录遍历扫描或者路径探测攻击。再比如统计某个IP的请求总数：
LogParser "SELECT c-ip, COUNT(*) AS cnt FROM *.log GROUP BY c-ip ORDER BY cnt DESC" -i:W3C -o:CSV
如果单个IP在短时间内产生数千甚至上万次请求，基本可以判定为CC攻击或者恶意爬虫。Log Parser的优势在于处理速度快，几百万条日志几秒钟就能出结果，非常适合日常运维巡检。
三、PowerShell脚本实现自动化分析
对于需要定期执行的分析任务，PowerShell脚本更加灵活。以下是一个识别高频请求IP的脚本示例：
$logPath = "C:\inetpub\logs\LogFiles\W3SVC1\*.log"
$threshold = 500
Get-ChildItem $logPath | ForEach-Object {
Get-Content $_.FullName | Where-Object { $_ -notmatch "^#" } | ForEach-Object {
$fields = $_ -split "\s+"
$ip = $fields[10]
$status = $fields[11]
[PSCustomObject]@{IP=$ip; Status=$status}
}
} | Group-Object IP | Where-Object { $_.Count -gt $threshold } | Sort-Object Count -Descending | Format-Table -AutoSize
这个脚本会读取指定目录下所有IIS日志，跳过注释行，提取客户端IP和状态码，然后按IP分组统计，只输出超过阈值（这里设为500次）的IP。你可以根据实际情况调整阈值，一般生产环境建议设为200到500之间。
四、四大异常请求模式的识别方法
模式一：高频单一IP请求（CC攻击特征）
正常用户访问网站，同一IP在一分钟内通常不会超过30次请求。如果某个IP在一分钟内发出超过100次请求，且请求的URL路径高度集中（比如反复请求首页或者某个动态页面），这就是典型的CC攻击。识别方法：按IP和分钟粒度统计请求数，用PowerShell或者Log Parser都能实现。应对措施包括在IIS中配置IP限制（IP Restrictions模块）、使用Web应用防火墙（WAF）或者在前端部署CDN进行流量清洗。
模式二：大量404/403状态码（路径探测与目录遍历）
攻击者会尝试访问常见的后台路径，比如/admin、/wp-admin、/phpmyadmin、/.git/config、/web.config等。如果日志中出现大量对这些路径的404请求，说明服务器正在被扫描。更危险的是目录遍历攻击，特征是URL中包含../../../等路径跳转符，比如/page?id=../../../windows/system32/drivers/etc/hosts。你需要在日志中搜索包含".."的请求路径，同时关注403状态码的集中出现，这通常意味着攻击者在尝试访问受保护资源。
LogParser "SELECT cs-uri-stem, COUNT(*) AS cnt FROM *.log WHERE cs-uri-stem LIKE '%..%' GROUP BY cs-uri-stem ORDER BY cnt DESC" -i:W3C
模式三：异常User-Agent（恶意爬虫与扫描工具）
正常浏览器的User-Agent都有明确的标识，比如Chrome、Firefox、Edge等。如果日志中出现大量空User-Agent、或者包含"sqlmap"、"nikto"、"Nmap"、"scanner"等关键词的请求，基本可以判定为自动化攻击工具。还有一种情况是User-Agent伪装成正常浏览器但行为异常，比如请求频率极高、只访问特定接口，这需要结合其他字段综合判断。
模式四：异常查询参数（SQL注入与XSS攻击）
SQL注入攻击通常在URL查询参数中包含SQL关键字，比如' OR 1=1--、UNION SELECT、DROP TABLE等。XSS攻击则包含<script>、javascript:等内容。你可以用Log Parser搜索包含这些关键词的请求：
LogParser "SELECT cs-uri-query, c-ip, cs(User-Agent) FROM *.log WHERE cs-uri-query LIKE '%SELECT%' OR cs-uri-query LIKE '%UNION%' OR cs-uri-query LIKE '%script%'" -i:W3C
需要注意的是，合法用户偶尔也可能在搜索框中输入类似内容，所以不能仅凭单一关键词就封禁IP，建议结合请求频率和来源IP信誉综合判断。
五、响应时间异常的分析价值
IIS日志中的time-taken字段记录了每次请求的处理时间（毫秒）。如果某个时间段内大量请求的响应时间超过5秒甚至更长，可能意味着服务器正在遭受慢速攻击（Slowloris）或者数据库查询被恶意拖慢。慢速攻击的特征是每个连接都保持很长时间但数据量很小，日志中表现为time-taken值很高但sc-bytes（发送字节数）很低。运维人员应该定期监控time-taken的平均值和P99值，一旦出现异常波动就要立即排查。
六、建立日常日志分析机制
单次分析只能解决眼前问题，长期运维需要建立自动化机制。建议做到以下几点：第一，配置IIS日志按天滚动存储，保留至少30天日志用于回溯分析；第二，编写定时任务脚本，每天凌晨自动执行一次高频IP统计和异常路径统计，结果输出到指定文件或者发送邮件告警；第三，将IIS日志接入集中式日志平台（如ELK Stack或者Splunk），实现可视化监控和实时告警；第四，定期更新异常模式规则库，因为攻击者的手法在不断变化，你的检测规则也要跟着迭代。
七、常见误区与注意事项
很多运维人员只关注状态码，忽略了请求路径和User-Agent的组合分析，这是最大的误区。比如一个IP大量请求200状态码并不代表正常，如果它在短时间内遍历了上千个不同路径，那就是扫描行为。另外，不要轻易封禁IP，尤其是公网IP可能是NAT共享地址，误封会影响正常用户。正确做法是先标记、再观察、确认恶意后再封禁。还有一点，IIS日志本身不记录请求体（POST数据），如果需要分析POST请求中的恶意内容，需要借助WAF或者应用层日志。
八、总结与实操建议
Windows服务器IIS日志分析是运维安全的基本功，核心思路就是"从数据中找规律"。掌握Log Parser和PowerShell两个工具，围绕IP频率、状态码分布、URL路径、User-Agent、响应时间五个维度建立分析体系，你就能在攻击发生的早期阶段发现端倪。建议从今天开始，先跑一遍你服务器上最近7天的日志，用本文提供的命令看看有没有异常，这比任何理论都来得实在。安全运维不是等出了事再救火，而是把日志分析变成日常习惯，把异常识别变成肌肉记忆。
