风险IP定位实战：从日志分析到威胁情报与自动化封禁

上个月我处理一起异常流量的时候客户把一堆日志导出给我让我看看到底是谁在打他的接口。日志长什么样几千条恶意请求几十个IP密密麻麻的4xx、5xx还有几个触发了WAF规则。我知道很多人这时候的操作是打开一个网页版的IP查询工具一个一个粘贴进去看看归属地然后手动去封禁。但这种做法在真正的网络安防场景里效率低到可怕而且极容易漏掉关键信息。更麻烦的是当你遇到一些特殊IP时很多常见网页工具根本给不出有效结果你只能看到一个“未知”或者一个笼统的“境外IP”没什么用。后来我把整套流程沉淀成了一个相对固定的链路日志提取、批量归属查询、威胁情报交叉验证、风险评分、自动化处置。这篇文章就是把这条链路拆开来讲包括我用过的好用工具、踩过的坑以及为什么有些IP在网页工具里查不到、该怎么绕过去。不管你是刚接手服务器运维的新人还是已经有一套防御体系的工程师应该都能从里面找到一点能直接用的东西。1. 先从一次真实攻击日志说起定位风险IP的三种核心场景1.1 攻击日志里的“看不懂”IP先看一个最常见的场景。Nginx或者Apache的访问日志里往往混着大量正常请求和恶意请求。你要做的第一件事不是去查IP而是先把日志里“真正的异常”筛出来。怎么筛我一般按三个维度来判断频率异常单个IP在极短时间内产生大量请求远超正常用户行为。路径异常请求的URL集中在/api/、/admin/、/.env、/wp-login.php等敏感路径上。状态码异常大量401、403、502响应尤其是401未认证频繁出现多半是在暴力破解或撞库。去年处理过一个案例某站点日志里有个IP在10分钟内请求了3.4万次全部指向一个登录接口。这类IP你不用犹豫基本就是风险IP不管它是来自IDC机房还是住宅带宽行为已经足够说明问题。但还有个场景容易被忽略。有些恶意流量不会一次性爆发而是很缓慢地试探比如每天只来几十个请求持续一周。这种低频慢速攻击光靠看日志很难发现。你需要把过去一段时间比如7天的IP汇总按累计请求次数、错误率、触发WAF规则的次数做一个排序才能把那些“安静的风险IP”捞出来。1.2 实时流量里的风险流量识别另一种场景是你在防火墙或云端安全组里看到实时告警。一般云服务商的安全中心会推送类似“某IP尝试登录您的服务器”的消息。这时候你面对的不是一堆日志而是一个具体的IP需要快速判断要不要处理。这个场景的特点是非常急。你不能像分析日志那样慢慢研究必须快速回答几个问题这个IP是什么类型的是IDC机房的独立IP还是云厂商的弹性IP还是家庭宽带的动态IP它有没有历史恶意行为在威胁情报平台里能不能查到记录它的归属地和你的业务是否相关一个从未访问过你业务的地区突然出现本身就是一个危险信号。我第一次遇到这种情况是很多年前当时看到一台香港云主机不断扫描我的SSH端口。我用网页工具查了一下看到归属地是香港心里还在想“这是不是同行误扫”结果一查威胁情报发现这个IP已经被标记为挖矿木马的控制端这才当机立断把它封掉。从那以后我养成一个习惯遇到可疑IP先查情报库不要凭感觉判断。1.3 把“查IP”当成防御体系的一部分有一类观点认为查IP是“事后补救”意义不大。我不太同意。IP定位在整个网络安防里的价值不在于它能不能阻止攻击而在于它帮你建立一张攻击者的画像。攻击者的画像有什么用举个例子。你的服务器今天收到来自IP-A的扫描明天又收到来自IP-B的登录尝试。单独看这两个IP没什么关联但如果你把每天的恶意IP做成一个列表按ASN自治系统号或者C段聚合一下就能发现它们可能都来自同一个IDC机房甚至同一个网段。这就是攻击源头的趋势信息能帮你提前把整个C段封掉也可以帮你预测下一步可能会有哪些IP来试探。所以我的建议是把“IP查询”从一个孤立的动作升级成一个持续运行的流程。每次发现风险IP不仅做单点查询还要把它沉淀到自己的威胁情报库哪怕只是一个文本文件或数据库表这样随着时间推移你对“哪些IP会盯上你”会越来越有感觉防御也会越来越有针对性。2. 工具选型网页工具体验好但批量场景远不够用2.1 网页工具快速判断的入口聊到IP查询工具大部分人第一反应就是各种“站长工具”或者“IP归属地查询”网页。这类工具的优点很明显不需要装任何东西打开浏览器、输入IP、回车立刻就能看到归属地、运营商、经纬度等基础信息。对于偶尔查一两个IP的场景这类工具完全够用。但它的瓶颈也很明显没有批量的概念。如果想查几十个IP就得手动复制粘贴几十次非常折磨人。数据来源不透明。很多网页工具的数据库更新频率并不高尤其是一些新兴的IDC网段或云厂商的新增IP段经常查不到或者显示成过时的归属地。没有威胁情报字段。归属地只是非常基础的维度。一个IP是“美国洛杉矶”还是“中国广东”并不能直接告诉你它是不是恶意的。真正有价值的“是否被举报过”“是否关联到恶意软件”“风险评分多少”大多网页工具不提供。所以我把网页工具定位为“快速判断的入口”而不是正经的安防工具。适合在群里帮人看一眼“这个IP是哪里的”不适合做严肃的风险研判。2.2 API和命令行工具批量查询的正确姿势当你需要一次性处理几十个甚至上百个IP时正确的选择是API接口或命令行工具。我常用的有这几类ip-api.com免费额度很良心支持批量查询一次最多100个IP返回JSON/XML/CSV格式速度也快。缺点是免费版不支持HTTPS如果对传输安全有要求可以用它的付费版或者自己在服务端做转发。ipinfo.io信息维度很丰富除了归属地还有ASN、组织名、托管商标记等字段。免费版每月有配额个人运维完全够用。它有一个好处是能识别“这个IP是不是托管机房hosting的”这对安防判断极其有用。whois命令行当你需要看一个IP的注册信息、ASN号时本地执行一下whois 8.8.8.8是最直接的。虽然输出格式有点乱但信息最原始、最完整而且不依赖任何第三方平台。离线库GeoLite2等MaxMind的GeoLite2提供了免费的ASN和City库可以下载到本地配合命令行工具如mmdblookup或各种语言的SDK如python-geoip2使用。好处是速度快、无网络依赖、没配额限制坏处是库文件需要定期更新而且它只解决“归属地和ASN”这类地理信息不提供风险标记。2.3 威胁情报平台判断“恶意”的关键信息源IP归属地只是第一步真正用来判断“这个IP是不是风险IP”的是威胁情报平台。这类平台会把全球多个渠道收集到的恶意行为数据汇总比如垃圾邮件发送、暴力破解、漏洞扫描、恶意软件传播等然后打上标签给一个风险评分。我平时查得比较多的几个平台主要用途备注VirusTotal多引擎检测看IP是否关联恶意软件/钓鱼信息丰富但需要克制使用免费配额AbuseIPDB看IP被举报的历史记录、投诉类别有风险评分运维圈用得多IPinfo含威胁数据归属地ASN托管标记威胁标签一体付费版才有完整威胁数据阿里云/腾讯云威胁情报对国内场景更贴近有中文报告云厂商用户用起来方便DNSBL/Spamhaus邮件源IP的黑名单查询主要面向邮件场景在安防处置里我很少只看一个平台就做决定。通常的做法是归属地用离线库或API快速获取风险情报在VirusTotal和AbuseIPDB上交叉验证。如果一个IP在AbuseIPDB上被标记了多次暴力破解同时VirusTotal上有引擎检出恶意行为那这个IP基本可以确定是风险IP直接进封禁名单没问题。3. 精准定位的实操链路从日志到风险研判的五步流程3.1 日志提取先把“嫌疑IP”准确捞出来所有判断的前提是“嫌疑IP得是准确的”。如果你的日志分析有误后面再精准的工具也白搭。我在处理Nginx日志时常用的命令是这样# 统计过去一天里访问次数最多、且非200状态码的前20个IP awk {print $1} /var/log/nginx/access.log \ | sort \ | uniq -c \ | sort -rn \ | head -20但这只是非常粗糙的统计。更精细的做法是筛选特定路径上的请求比如只看/login和/api/相关路径# 统计登录接口相关的IP请求次数 grep POST /login /var/log/nginx/access.log \ | awk {print $1} \ | sort \ | uniq -c \ | sort -rn \ | head -20如果你用的不是Nginx而是CDN或云负载均衡导出的日志字段可能不同但思路一样先按时间和路径维度缩小范围再按IP做聚合。另外建议顺手记录一下每个IP对应的User-Agent。如果一个IP虽然只来了一次但UA明显是Curl或者Python脚本它的可疑程度也不低。注意这里提到的“24小时内”是一个经验值。如果你处理的是慢速攻击建议把时间跨度拉长到7天甚至30天否则会漏掉低频的试探请求。3.2 批量归属地查询脚本化示例捞出来嫌疑IP列表后下一步是批量查询。不建议一个个粘贴到网页里写个简单脚本就行。下面是我经常用的一段Python脚本用ip-api.com的批量接口import requests import json # 假设 ips.txt 每行一个IP with open(ips.txt, r) as f: ips [line.strip() for line in f.readlines() if line.strip()] # ip-api.com 批量接口每次最多100个 for i in range(0, len(ips), 100): batch ips[i:i100] resp requests.post( http://ip-api.com/batch, datajson.dumps(batch), headers{Content-Type: application/json}, timeout10 ) results resp.json() for item in results: status item.get(status, fail) if status success: print(f{item.get(query):20s} {item.get(country):12s} {item.get(city):12s} {item.get(isp):30s} {item.get(as)}) else: print(f{item.get(query, unknown):20s} 查询失败)运行起来几秒钟就能把100个IP的归属地、ISP、ASN全部拉出来。这个脚本的输出可以保存成CSV方便后续分析。如果你希望完全离线也可以下载GeoLite2库用python-geoip2做同样的批量处理import geoip2.database reader geoip2.database.Reader(./GeoLite2-ASN.mmdb) with open(ips.txt, r) as f: for line in f: ip line.strip() try: response reader.asn(ip) print(f{ip:20s} ASN: {response.autonomous_system_number} 组织: {response.autonomous_system_organization}) except Exception as e: print(f{ip:20s} 未查到: {e})3.3 威胁情报交叉验证别被归属地误导归属地查完很多新手会陷入一个误区觉得“来自某些地方的IP一定是恶意的其他地方的就是安全的”。这是大忌。IP归属地和攻击者所在地并不等价因为攻击者可以使用代理、跳板、或直接控制远端的肉鸡来发起攻击。正确的做法是用威胁情报平台做交叉验证。拿AbuseIPDB举例它的API支持按IP查询举报记录、使用类别和置信度评分。下面是一个示例curl -s https://api.abuseipdb.com/api/v2/check?ipAddress示例IPmaxAgeInDays90 \ -H Key: 你的API_Key \ -H Accept: application/json | python3 -m json.tool返回结果里重点看几个字段totalReports总举报次数。如果大于0说明这个IP已经被其他人标记过风险行为。numDistinctUsers有过多少个不同的举报者。数值越大可信度越高排除单点误报。abuseConfidenceScore滥用置信度0-100。高于50的一般可以谨慎处理高于80的可以直接拉黑。lastReportedAt最近一次举报时间。如果近期有举报说明该IP正在活跃地做坏事。我个人的判断逻辑是这样的如果归属地显示是IDC机房/云主机 abuseConfidenceScore高于50 触发过WAF规则那么封禁是合理选择如果归属地是家庭宽带 abuseConfidenceScore很高 举报类别是恶意软件那更要警惕因为这可能是被攻陷的个人电脑不仅会影响你也会继续感染别人。3.4 风险综合评分把“感觉”变成可执行的决策我习惯在调查结束时给每个IP做一个综合评分然后根据分数决定处置方式。评分维度如下维度分数范围说明归属地类型0-25家庭宽带0IDC机房15云厂商弹性IP10Tor出口25威胁情报记录0-40无记录0少量举报20大量举报40行为异常程度0-35频率异常15敏感路径20暴力破解特征35触发WAF规则的次数0-20超过10次直接给20分总分超过60分基本可以判定为风险IP直接封禁30-60分之间限速或告警观察低于30分暂时标记等以后再看。这个评分标准不是行业标准是我自己的经验值你完全可以按业务场景调整权重。核心思路就是把模糊的“可疑程度”量化这样团队协作时也好沟通不会出现“我觉得它危险”这种说不清的争论。4. 那些网页工具“查不到”的IP以GitHub相关IP为例的排查复盘4.1 问题现象为什么有些IP在网页工具里搜不到前段时间有朋友问我“为什么我用站长工具去查Github的某个IP返回结果居然显示什么都没有或者显示的地区和实际完全对不上是不是工具出问题了”坦率地说这不算工具出错而是互联网基础设施的复杂度问题。就拿Github来说它的服务分布在全球多个数据中心和CDN节点上。你访问一个Github页面时看到的IP可能并不属于Github自己的ASN而是某个CDN服务商提供的边缘节点IP。这类IP有几个特点更新频繁CDN的边缘节点IP是动态调度的今天的IP可能明天就切换了网页工具里的数据库如果更新不及时拿到旧数据就会显示不准确。数据归属模糊某些CDN节点IP被多个客户共用你在whois里看到的注册信息是某某云服务商的而不是Github的。如果你只按“whois里的组织名”来判断就会得出“这个IP和Github无关”的错误结论。网页工具收录不完整不少网页工具的IP库只覆盖主流运营商和IDC对新兴CDN厂商、海外云厂商的小网段收录不全所以直接显示“未知”。我自己排查这类问题时的经验是网页工具查不到不代表这个IP没有信息只是说明这个工具的库太“死”了。真正的IP定位实践不应该依赖单一来源。4.2 排查链路换数据源、看ASN、回溯历史记录当你遇到网页工具查不到的IP不要急着下结论。按下面几步走通常能查个八九不离十第一步换一个数据更新更快的API或离线库。比如用ipinfo.io的API看ASN字段。示例curl -s https://ipinfo.io/你的IP地址?token你的Token返回的JSON里会包含as: AS36459 GITHUB, US这样的字段。即使你查的是Github的IP只要你看到ASN归属是Github的AS号那基本可以确认这就是Github的官方IP段。ASN信息比归属地城市层面的判断可靠得多因为它指向的是IP地址段的注册所有者而不是用户的物理位置。第二步用whois看分配信息。对具体IP执行whois找到NetName、Organization、CIDR等字段。比如whois 140.82.112.8输出里如果出现类似GITHUB、GitHub, Inc.这样的字段说明这个IP确实是Github分配给自己使用的。即便一些网页工具没收录whois服务器里的原始注册数据依然是完整的——只要你的系统能发出whois查询请求就能拿到这些信息。第三步看历史情报记录。在VirusTotal等平台上搜索这个IP看它是否被其他安全研究者标记过。比如某些IP如果是Github的Webhook回调源IP可能被标记为“关联到Webhook服务”如果某个IP同时存在可疑下载行为则可能有恶意软件相关标签。这里的“历史”很重要它帮你判断这个IP在网络上长期扮演的角色而不是一时一地的使用场景。第四步用IP反查去确认服务类型。如果你怀疑某个IP是Github Pages的托管节点可以访问https://api.github.com/meta查看Github官方公布的IP列表。Github官方会公开它用于Web、API、Git等服务的所有IP段你拿可疑IP去比对一下CIDR段基本一查一个准。4.3 为什么要“认ASN而不是认城市”这起排错最后给我的最大启发是定位风险IP时“ASN组织名”比“国家/城市”更有决策价值。原因很简单城市级别的IP归属库只能告诉你“这个IP所在的机房/运营商注册地在哪”但云主机和CDN节点的实际位置经常和注册地不一致。组织名则直接告诉你“这个IP段归谁管理”。如果归攻击者常用的某个IDC管理那它的可疑程度远高于普通家庭宽带。ASN还能帮你做关联分析。一个攻击者可能换了很多个IP但这些IP如果都在同一个ASN下基本可以判断是同一家服务商的资源封禁时可以直接把该ASN下的风险子网也考虑进去。简单来说城市信息是“给人类看的”ASN和组织名是“给机器决策看的”。安防系统判断风险时应当依靠后者。5. 从“手工查询”到“自动封禁”把IP定位变成防御动作5.1 脚本化定时获取情报并更新威胁名单每次手动查完、判断完然后手动在防火墙里封IP这种方式不仅效率低而且容易出现遗漏。更合理的方式是把流程固化成一个定时任务。我的做法是写一个shell脚本每天凌晨从WAF/防火墙日志里拉取昨天的风险IP列表通过API批量查询归属地和威胁情报然后把风险评分超过60分的IP追加进一个封禁名单文件。脚本逻辑大概是#!/bin/bash # daily_risk_ip_check.sh # 1. 从Nginx日志中提取昨天的风险IP grep $(date -d yesterday %d/%b/%Y) /var/log/nginx/access.log \ | grep -E 401|403|404|500 \ | awk {print $1} \ | sort -u /tmp/yesterday_risk_ips.txt # 2. 调用AbuseIPDB API 批量获取风险评分 # 这里需要根据API限制做分批处理 while read ip; do score$(curl -s https://api.abuseipdb.com/api/v2/check?ipAddress$ip \ -H Key: $ABUSEIPDB_KEY | jq .data.abuseConfidenceScore) if [ ${score:-0} -ge 50 ]; then echo $ip /etc/blacklist_ip.txt fi done /tmp/yesterday_risk_ips.txt # 3. 去重并重新加载防火墙规则 sort -u /etc/blacklist_ip.txt -o /etc/blacklist_ip.txt # 省略具体防火墙reload逻辑因系统而异这只是示例实际部署时需要结合你的防火墙类型和云服务商接口来调整。但核心思路不变把人工判断里的关键指标如威胁情报评分、请求异常度写成规则让机器每天自动执行。5.2 联动云安全组和WAF封禁自动化如果你用的是公有云服务器除了操作系统层级的iptables/firewalld还可以利用云安全组和WAF的黑名单功能。大多数云厂商都提供了API可以动态往安全组里加入来源IP。这样封禁的IP不仅针对某一台服务器而是对整个安全组下的所有机器生效。举个简单例子AWS的安全组API可以通过CLI动态更新入站规则。阿里云、腾讯云也都提供了类似的接口。用脚本定时调用接口把封禁名单同步过去就能实现“日志分析 → 风险研判 → 自动封禁”的闭环。这样即便你夜里在睡觉服务器被扫描了第二天起来发现它已经把攻击者挡在门外了体验真的不错。5.3 误封与解封不能只封不禁任何自动化封禁系统都存在误封的风险。比如有些云服务商的共享IP可能被多个用户共用其中一个用户行为异常导致整个IP被封可能会误伤无辜用户。或者你的某个合作方使用了动态IP今天进来时触发规则被封了明天可能还会影响正常的业务。所以我会建议在封禁名单上加一个“有效期”概念。比如IP进入封禁名单后默认冻结24小时24小时后自动从防火墙移除除非它在这期间继续有恶意行为。这个设计能避免“封IP一时爽第二天业务报警”的尴尬。具体的实现方式可以为封禁名单增加时间戳字段每次防火墙同步时只加载“当前还在有效期内”的IP。过期IP则进入一个“待观察名单”如果之后几天再次出现恶意行为直接加入长期封禁名单。6. 实战心得别迷信单个工具IP定位只是拼图的一块文章最后分享几个我在实际运维里反复体会到的经验。第一别迷信单个工具或单一数据源。我之前见过同事只用某一个网页工具查IP发现查不到就认定“这个IP查不到没风险”结果后来发现那是个活跃的攻击源。“查不到”更可能意味着“这个工具的数据覆盖不足”或“该IP属于某个动态调度的云平台”而不是“安全”。遇到这种情况跨平台交叉验证是正确的做法。第二IP定位信息永远是辅助判断的一部分不是全部。我在做风险评估时会把日志行为、请求内容、威胁情报、归属地信息综合在一起看。比如一个IP即使归属地看起来正常但如果它同时触发了WAF的SQL注入规则并且User-Agent是Python爬虫那么无论归属地在哪里都应该高度重视。相反一个IP即使归属地在高风险地区如果它只是访问了一个公开页面且频率正常也没有必要过度反应。第三记录和复盘比“封掉一个IP”重要得多。我会把每次调查的风险IP列表、判断依据、处置结果都存下来定期回看。这个习惯让我们在面对攻击者换了一波新IP时能更快地识别出攻击者的“套路”。比如某个攻击者喜欢用同一个ISP的IP段或者总是通过同样的HTTP头来访问你记录得多了慢慢就能发现这些规律。最后如果你还是团队协战建议把上面的流程写成文档或脚本团队内部分享。风险IP定位不是个人英雄主义的活一套可复现的标准流程比什么都强。遇到类似事件时大家按同一个流程走效率会高很多。