1. 从“爱扫站”到“黑名单”一个运维的日常防御战最近在整理服务器日志时又看到了那些熟悉的、高频出现的IP地址它们像不知疲倦的工蜂一遍又一遍地尝试访问那些根本不存在的管理后台路径、API接口甚至是早已废弃的旧版应用入口。这些IP背后就是大家常说的“爱扫站”的脚本小子或自动化扫描器。他们未必有明确的攻击目标更像是开着拖拉机在互联网上“犁地”哪块地松了哪个站有漏洞就停下来挖一挖。作为站点的守护者我们的任务就是让这片地变得足够“硬”让这些无意义的扫描流量消耗降到最低同时保护真正的业务不受干扰。今天我想分享的就是如何从海量日志中提炼出一份属于你自己的、动态有效的“IP黑名单”这不仅是技术活更是经验和策略的结合。这份黑名单的核心价值不在于封禁一两个IP而在于建立一套自动化的威胁感知与响应机制。它能让你的服务器从被动挨打转向主动防御把宝贵的计算资源和带宽留给真实的用户。无论是个人博客、企业官网还是带有用户交互的Web应用这套思路都具有普适性。接下来我会从日志分析、策略制定、到自动化封禁与维护完整地走一遍这个流程并重点分享几个我踩过坑才明白的关键细节。2. 日志分析从噪声中识别“扫描指纹”构建黑名单的第一步也是最重要的一步就是看懂日志。Nginx或Apache的访问日志是主要的信息源。一个盲目的扫描行为会在日志中留下非常明显的“指纹”。我们需要的不是人工每天去看而是教会机器如何识别这些指纹。2.1 识别典型的扫描特征扫描行为通常不具备正常用户的访问逻辑。以下是我总结的几个关键特征你可以根据这些特征来编写筛选规则高频访问不存在404的敏感路径这是最显著的标志。扫描器会内置一个字典包含诸如/admin/wp-admin/phpMyAdmin/config.json/api/v1/users等成千上万的常见管理后台、配置文件和API端点。一个IP在短时间内如1分钟对大量这类路径返回404状态码其扫描意图就非常明显了。例如一个IP连续请求了/admin.php/admin//administrator/ 且你的站点根本没有这些目录这几乎可以断定是扫描行为。非常规User-Agent很多扫描工具会使用特征明显的User-Agent比如包含“Scanner” “Nmap” “Acunetix” “Nikto” “dirb”等关键字。但高明的扫描器会伪装成普通浏览器。因此User-Agent可以作为辅助判断但不能作为唯一依据。更值得警惕的是那些使用老旧、不常见或明显伪造的User-Agent的请求。攻击载荷试探扫描器在发现可能存在漏洞的端点后会尝试注入攻击载荷。例如在URL参数中携带SQL注入片段如 OR 11、XSS脚本如scriptalert(1)/script、或路径遍历序列如../../../etc/passwd。在日志中看到这类参数无论请求是否成功该IP都应被立即拉黑。低频但恶意的探测有些高级扫描器会降低频率避免触发基于速率的规则。但它们可能会针对一个特定的、真实的漏洞进行深度探测。例如持续对同一个登录接口用不同的用户名密码组合进行尝试撞库或者对同一个API端点发送格式畸形、旨在触发程序异常的数据包。这类行为需要结合业务逻辑和返回状态码如大量401、403或500来判断。2.2 使用命令行工具进行初步分析在构建自动化脚本前我们可以先用Linux下的命令行工具对日志进行手动分析这有助于我们验证判断逻辑。假设我们的Nginx访问日志文件是/var/log/nginx/access.log。找出短时间内访问404页面最多的IP# 分析过去一小时内返回状态码为404的请求按IP分组计数取前10名 awk $9404 {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10这个命令会输出类似“150 203.0.113.45”的结果表示IP203.0.113.45在过去一小时的日志中产生了150次404错误。这个数字如果远高于正常用户正常用户偶尔输错URL产生一两次404是合理的就值得怀疑。结合特定路径模式进行筛选# 查找访问过“admin”相关路径的IP并统计次数 grep -E (admin|login|wp-admin|phpmyadmin) /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -20识别携带攻击载荷的请求# 查找URL中包含常见SQL注入或XSS关键词的请求注意此命令仅为示例实际关键词列表要长得多 grep -E (\|\%27).*(OR|AND).*(\|\%3D)|(\script\|alert\(|onerror) /var/log/nginx/access.log | awk {print $1, $7} | head -20注意在生产环境中直接grep日志文件可能效率不高且正则表达式需要精心设计以避免误伤正常请求例如一些正常的搜索查询可能包含单引号。这步操作主要用于验证和调试规则。通过以上手动分析你就能对当前面临的扫描态势有一个直观感受并为下一步的自动化规则制定提供数据支撑。3. 策略制定如何科学地“拉黑”一个IP确定了哪些IP可疑之后下一个问题就是封多久怎么封全部封禁会不会误伤这里涉及到黑名单策略的制定它直接决定了防御效果和运维成本。3.1 黑名单的等级与时效性我通常将黑名单分为三个等级对应不同的处置方式和封禁时间等级触发条件封禁动作封禁时长备注临时黑名单高频扫描如1分钟内20次404加入防火墙规则如iptables或Web应用防火墙WAF临时黑名单1小时 - 24小时应对无差别扫描自动过期释放避免列表膨胀。持久黑名单检测到明确的攻击载荷如SQL注入、路径遍历加入持久化黑名单数据库或文件30天 - 永久针对有明确恶意的行为者。需要定期审查可手动移除。紧急黑名单正在进行的暴力破解、CC攻击等立即封禁并可能升级到上游网络或云服务商进行封堵直至攻击停止 额外时间需要实时监控和快速响应通常与监控告警联动。为什么需要分级全部永久封禁是最简单的但不够优雅。互联网上有大量被木马控制的“肉鸡”IP它们本身也是受害者其控制者可能随时更换。永久封禁这些IP可能导致某个地区的普通用户无法访问如果该“肉鸡”恰好位于某个企业或学校的NAT网关后。分级策略能在有效阻断当前威胁的同时保持一定的灵活性减少对正常网络的“误伤”。3.2 封禁层面的选择网络层 vs 应用层在哪里执行封禁也是一个关键决策。网络层封禁如iptables, firewalld, 云安全组优点效率极高数据包在进入系统协议栈之前就被丢弃对服务器资源零消耗。缺点规则数量庞大时管理复杂可能影响防火墙性能。且一旦封禁该IP的所有访问包括可能正常的流量都被阻断。适用场景针对高流量攻击IP、明确恶意的持久性黑名单IP。应用层封禁如Nginx deny, WAF规则优点更灵活可以基于域名、URL路径等条件进行封禁。可以返回自定义的错误页面如403 Forbidden。缺点请求仍需到达Web服务进程会消耗一定的连接和计算资源。适用场景临时黑名单或者仅需封禁对特定站点或路径的访问。我的常用策略是结合使用对于持久黑名单和紧急黑名单中的IP使用网络层封禁一劳永逸。对于临时黑名单使用Nginx的deny指令或者通过WAF的动态规则功能方便自动过期。下面给出一个Nginx的配置片段示例# 在 http 或 server 块中定义一个黑名单文件路径 geo $blocked_ip { default 0; include /etc/nginx/conf.d/ip_blacklist.conf; # 1表示封禁 } server { listen 80; server_name yoursite.com; if ($blocked_ip) { return 403; # 对于黑名单IP直接返回403禁止访问 # 也可以 rewrite 到一个特定的错误页面 # rewrite ^ /403.html; } ... # 其他配置 }/etc/nginx/conf.d/ip_blacklist.conf文件内容格式如下可以由自动化脚本动态更新203.0.113.45 1; 198.51.100.22 1;更新后需要执行nginx -s reload重载配置。注意频繁重载Nginx会影响性能因此更适合更新不那么频繁的持久黑名单。4. 自动化实战构建一个简单的黑名单管理系统手动分析和管理黑名单是不可持续的。我们需要自动化。这里我设计一个基于Linux shell脚本和iptables的简易自动化系统框架。这个框架包含日志监控、规则判定、封禁执行和定期清理四个部分。4.1 核心监控与判定脚本假设我们主要针对“高频访问404”这一特征进行临时封禁。创建一个脚本/usr/local/bin/ip_blocker.sh#!/bin/bash # 配置参数 LOG_FILE/var/log/nginx/access.log TEMP_BLACKLIST/etc/iptables/temp_blacklist.txt THRESHOLD30 # 1分钟内404次数阈值 TIME_WINDOW60 # 时间窗口秒 BLOCK_DURATION3600 # 封禁时长秒 # 分析过去 TIME_WINDOW 秒的日志 # 使用 awk 提取时间戳和IP这里假设日志格式为 combined且时间戳在 $4 # 这是一个简化示例生产环境需要更精确的时间过滤 awk -v now$(date %s) -v window$TIME_WINDOW # 解析日志时间需要根据你的日志时间格式调整这里是个复杂点 function parse_time(time_str) { # 简化处理此函数需要根据你的日志日期格式实现将日志时间转换为epoch时间戳 # 例如使用 date -d $time_str %s但需注意格式匹配 # 此处仅为示意实际应用建议使用logtail或更专业的工具追踪增量日志 return now - 30; # 假设所有日志都在时间窗口内 } { if ($9 404) { ip $1; # 调用 parse_time($4) 获取请求时间 req_time parse_time($4); if ((now - req_time) window) { count[ip]; } } } END { for (ip in count) { if (count[ip] $THRESHOLD) { print ip; } } } $LOG_FILE /tmp/suspicious_ips.txt # 封禁新发现的IP while read IP; do # 检查是否已在临时黑名单文件中 if ! grep -q ^$IP$ $TEMP_BLACKLIST 2/dev/null; then # 使用iptables封禁 iptables -A INPUT -s $IP -j DROP # 记录封禁时间和IP echo $IP $(date %s) $TEMP_BLACKLIST logger [IP-Blocker] Blocked IP: $IP due to excessive 404s. fi done /tmp/suspicious_ips.txt # 清理过期的封禁可选另一种方式是用iptables的--seconds参数 current_time$(date %s) if [ -f $TEMP_BLACKLIST ]; then while read line; do ip$(echo $line | awk {print $1}) block_time$(echo $line | awk {print $2}) if [ -n $block_time ] [ $((current_time - block_time)) -gt $BLOCK_DURATION ]; then iptables -D INPUT -s $ip -j DROP 2/dev/null # 从文件中删除记录这里用临时文件再写回的方式更安全 sed -i /^$ip /d $TEMP_BLACKLIST logger [IP-Blocker] Unblocked IP: $IP after $BLOCK_DURATION seconds. fi done $TEMP_BLACKLIST fi重要提示上述脚本中的时间解析部分 (parse_time函数) 是最大的难点和易错点。Nginx日志时间格式通常是[07/May/2024:15:30:01 0800]在shell中精确解析并计算时间差比较繁琐。生产环境强烈建议使用更成熟的工具如Fail2ban 专为日志分析自动封禁而设计内置大量过滤器jail支持Nginx、Apache、SSH等多种服务配置灵活是大多数场景下的首选。Logwatch/Swatch 日志监控工具可以配置触发动作。使用编程语言Python/Go编写 对于复杂逻辑用Python等语言处理日志解析和日期计算会更稳健。4.2 使用Fail2ban实现生产级管理Fail2ban完美实现了我们上面想做的所有事情监控日志、匹配模式、执行封禁动作、超时释放。配置起来比从头写脚本更规范。以下是一个针对Nginx 404扫描的Fail2ban配置示例创建过滤器/etc/fail2ban/filter.d/nginx-404-scan.conf[Definition] failregex ^HOST -.*\(GET|POST|HEAD).*\ 404 .*$ ignoreregex 这个正则匹配所有返回404状态的请求并提取IPHOST。你可以根据需要细化比如匹配包含特定路径的404。创建监狱Jail配置在/etc/fail2ban/jail.local中添加[nginx-404-scan] enabled true port http,https filter nginx-404-scan logpath /var/log/nginx/access.log maxretry 30 # 最大重试次数即阈值 findtime 60 # 在多少秒内查找时间窗口 bantime 3600 # 封禁时间秒 action iptables[nameHTTP, porthttp, protocoltcp] sendmail[namenginx-404, destyour-emailexample.com, senderfail2banyourserver.com] # 可选邮件通知这表示在60秒内如果同一个IP触发了30次nginx-404-scan过滤器匹配的规则即30次404则封禁该IP 3600秒并发送邮件通知。重启Fail2bansudo systemctl restart fail2ban查看状态sudo fail2ban-client status nginx-404-scanFail2ban会自动管理iptables规则的添加和删除大大简化了运维工作。你还可以为SSH密码爆破、Web应用攻击等配置不同的监狱。5. 维护与进阶让黑名单更智能、更有效自动化封禁系统建立后并非一劳永逸。日常维护和策略调优同样重要否则可能会遇到问题。5.1 避免误封白名单与误判处理最大的风险是误封正常用户或关键服务如搜索引擎爬虫、支付网关回调IP、CDN节点等。建立核心白名单将你自己的办公IP、公司网络IP段、重要的第三方服务IP如Google Search Console、Bing Webmaster Tools公布的爬虫IP段、支付接口IP等加入防火墙或Fail2ban的白名单ignoreip配置项。谨慎设置阈值maxretry和findtime的配置需要根据实际流量调整。对于一个流量不大的博客1分钟30次404可能已经很高了但对于一个大型论坛用户发帖包含错误链接也可能触发阈值就需要调高。监控封禁日志定期检查Fail2ban或自研脚本的封禁日志/var/log/fail2ban.log或自定义的logger看看有没有误封的情况。如果发现及时手动解封并分析原因调整过滤规则。5.2 应对高级威胁与动态IP简单的频率规则容易被绕过。高级攻击者会使用IP池、降低扫描频率、或模仿正常用户行为。复合规则不要只依赖404状态码。结合User-Agent异常、攻击载荷特征、访问路径的深度是否遍历目录等多维度进行判断。Fail2ban允许你使用多个failregex并可以配置复杂的ignoreregex来排除误报。关注慢速攻击对于登录接口可以设置一个更长的时间窗口如1小时和较小的尝试次数如5次来防御慢速的密码爆破。使用信誉库可以考虑集成公开的恶意IP信誉库如AbuseIPDB的API将已知的恶意IP直接加入持久黑名单。但要注意API调用频率限制和误报。云服务商WAF如果业务在云上直接使用云服务商提供的Web应用防火墙如AWS WAF Cloudflare WAF是更省心的选择。它们通常具备基于信誉的IP列表、自定义规则和更强大的DDoS缓解能力虽然需要额外成本但能抵挡更复杂的攻击。5.3 黑名单的持久化与共享对于持久黑名单你需要一个地方来存储它并确保服务器重启后规则不丢失。iptables规则持久化使用iptables-save /etc/iptables/rules.v4保存规则并在系统启动时自动加载具体方法取决于发行版如使用iptables-persistent包。使用ipset管理大批量IP当需要封禁的IP段或IP数量很大时直接添加iptables规则会影响性能。ipset工具可以将大量IP地址集合成一个命名的集合然后iptables只需一条规则引用这个集合即可极大提升效率。# 创建一个名为blacklist的ipset哈希集合 ipset create blacklist hash:ip timeout 86400 # 支持超时单位秒 # 向集合中添加IP ipset add blacklist 203.0.113.45 # 在iptables中引用这个集合 iptables -I INPUT -m set --match-set blacklist src -j DROP多服务器同步如果你有多台前端服务器需要确保黑名单在所有节点生效。可以通过共享一个数据库如Redis、定期同步文件或者使用像CrowdSec这样的现代、分布式的安全解决方案它采用社区共享威胁情报的模式。构建和维护IP黑名单是一个持续的过程是安全运营中“基础但重要”的一环。它不能解决所有安全问题但能有效过滤掉绝大部分噪音和低层次攻击让你的安全监控系统能更专注于发现真正的、高级的威胁。从分析日志特征开始到制定合理的策略再到利用Fail2ban等工具实现自动化最后通过维护和调优来减少误伤这套组合拳打下来你的服务器在面对“爱扫站的黑客”时将从一块任人试探的“软土地”变成一块难啃的“硬骨头”。