去年接了一个智能电表项目，帮客户做安全加固。客户提了一个需求：能不能根据IP地址自动识别恶意设备，发现一个封一个？
听起来很合理，对吧？但我们没敢直接这么干。先拿了一周的日志试了一下，结果发现：几百个电表的上报IP，查出来全是"数据中心"属性、风险评分也不低------按规则全该封。可这些电表明明在正常上报数据，没有任何异常行为。
后来用IP数据云详细查了一下这批IP的net_type和asn，才发现它们来自某运营商的CGNAT段，本来就是千家万户共享的出口。如果一个IP上挂了几百个正常设备，你因为"IP属性像机房"就一把封掉，那误杀的就是整个小区。
这件事让我意识到：物联网里评估IP安全性，不能只看归属地和风险分。核心是先区分IP对象（设备出口/网关/运维/回调），再结合漂移速度、ASN/宿主类型、代理匿名性、场景标签五类信号分级，最后绑定动作（放行/限流/隔离）。
一、四种IP对象，风险目标和误伤代价完全不同
同一IP在不同业务场景下，含义天差地别。建议日志里增加字段 ip_object_type：
| IP对象 | 典型来源 | 主要风险 | 误封代价 |
|---|---|---|---|
| 设备出口 | 蜂窝、家宽、CGNAT | 冒用设备身份、批量伪造上报 | 极高：一死死一片 |
| 网关公网 | 站点固定出口、专线 | 网关被劫持、横向渗透 | 高：影响站点级业务 |
| 运维登录 | 办公网、堡垒机 | 撞库盗号、权限接管 | 中高：影响应急响应 |
| 第三方回调 | CDN、供应商机房 | 伪造回调、接口被刷 | 中：可用白名单兜底 |
经验：设备出口的"漂移、共用IP"常有网络机制导致，需结合设备鉴权；运维与回调的"漂移、匿名性"更接近入侵线索。
二、五类硬信号：IP查询工具真正要查什么
IP数据云等工具可返回以下字段，每类信号解决一个实际问题：
| 信号类别 | 关键字段 | 解决什么问题 |
|---|---|---|
| 归属地漂移 | country/city变更次数、ASN变更次数 | 判断是否异常跳变 |
| ASN/宿主/网络类型 | asn、org、net_type（hosting/residential/mobile/enterprise） | 区分机房、家宽、移动、企业网 |
| 代理匿名性 | proxy_type、is_tor | 识别代理、匿名网络 |
| 场景标签 | scene_tags（CDN/数据中心/爬虫等） | 判断IP的"正常用途"，辅助白名单 |
| 风险画像 | risk_score、threat_tags | 概率信号，用于分流，不是铁证 |
代码示例：批量获取IP画像（每天离线跑一次）
python
import requests, redis, json
r = redis.Redis(decode_responses=True)
def batch_enrich(ip_list):
url = "https://api.ipdatacloud.com/v2/batch"
params = {'ips': ','.join(ip_list), 'key': 'YOUR_API_KEY', 'lang': 'zh-CN'}
resp = requests.get(url, params=params, timeout=5)
if resp.status_code == 200 and resp.json().get('code') == 0:
return resp.json()['data']
return []
new_ips = ['45.33.22.11', '203.0.113.5']
results = batch_enrich(new_ips)
for info in results:
ttl = 86400 if info.get('risk_score', 0) < 30 else 3600
r.setex(f"ip:{info['ip']}", ttl, json.dumps(info))
三、漂移怎么判？直接可用的默认阈值
以下阈值是我们的实战起点（先灰度，再用历史数据回放校准）：
| IP对象 | 窗口 | 异常条件 | 动作 |
|---|---|---|---|
| 运维登录 | 24h | 跨国家（country_changes>=1） |
高风险 → 强制MFA + 限速 |
| 运维登录 | 24h | asn_changes>=2 或 network_type 从 residential 变 hosting |
高风险 → 强校验+复核 |
| 第三方回调 | 7d | asn_changes>=1 且不在白名单 |
默认拒绝，配合签名校验 |
| 网关公网 | 24h | 国家/ASN变更且无工单记录 | 隔离到影子通道 + 工单 |
| 设备出口 | 24h | 漂移本身不加分，仅弱信号 | 只有"机房IP + 鉴权失败 + 频次暴涨"才升级 |
四、简单评分卡：让一线同事能看懂为什么拦
我们没用机器学习，就一个加分卡，分数对应动作：
| 加分项 | 分值 | 适用对象 |
|---|---|---|
| 漂移超阈值 | +40~+70 | 运维/回调/网关 |
| hosting且非白名单 | +20~+50 | 所有 |
| 高匿名代理/Tor | +50~+80 | 运维/回调 |
| 场景不匹配（设备却显示数据中心） | +20~+60 | 设备 |
| 风险分>80 | +10~+40 | 所有 |
分数→动作：
- <40：放行，只记录画像快照
- 40--69：限流 + 挑战（验证码/MFA），告警聚合（不刷屏）
- ≥70 ：
- 运维/回调：拒绝或强制MFA + 工单
- 网关：隔离到观察通道 + 工单
- 设备：隔离上报通道；必须加上行为异常（如鉴权失败）才拉黑
拉黑前置条件（必须同时满足）：
- 评分 ≥70 且 明确行为异常（登录失败爆发、撞库特征、签名校验失败、异常指令）
五、工程落地：两条腿走路，别把实时查塞进设备上报
- 离线批量：每小时/每天从日志提取新IP，调用IP数据云批量接口查画像，存入Redis/本地缓存，TTL 6-24小时。
- 在线实时 ：只在关键链路（运维登录、回调验签失败、被刷时）同步查询。设备上报不要实时查第三方，否则QPS一上来必崩。
- 缓存降级：API超时/失败时，默认降级为"限流+告警"，不阻断关键业务。
- 日志留够字段：event_type、ip_object_type、source_ip、account_id/device_id、鉴权结果、失败原因。
六、总结
回到开头那个电表项目。我们后来把规则改成了：设备出口只看"机房IP + 鉴权失败 + 频次异常"的组合条件，不再因为IP属性像机房就乱封。误报率从预估的15%降到了2%左右。
物联网里评估IP安全性，IP查询工具提供的是信号，不是判决书。信号怎么用，取决于你的业务上下文。做好四件事：分对象、查五类信号、打分分级、工程兜底，就能把"拍到"变成"判准"。IP数据云的离线库支持日更、批量查询和私有化部署，正好能撑起这套评估体系。