上个月我处理一起异常流量的时候，客户把一堆日志导出给我，让我看看到底是谁在打他的接口。日志长什么样？几千条恶意请求，几十个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:i+100] resp = requests.post( 'http://ip-api.com/batch', data=json.dumps(batch), headers={'Content-Type': 'application/json'}, timeout=10 ) 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=示例IP&maxAgeInDays=90" \ -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 | 家庭宽带0，IDC机房15，云厂商弹性IP10，Tor出口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定位不是个人英雄主义的活，一套可复现的标准流程比什么都强。遇到类似事件时，大家按同一个流程走，效率会高很多。
