2. 基础知识
在“不可能旅行”（Impossible Travel）异常登录识别中，我们并不是直接去判断“这个人是不是黑客”，而是通过一组可观测的登录事件字段，推断“这次登录在物理上是否可能”。因此，理解登录日志中的核心术语及其数据来源，是后续规则设计、模型训练和告警研判的基础。本节将围绕登录日志、IP地址、地理位置、时间戳、用户代理五个核心概念展开，并说明它们在实际系统中的常见形态与采集方式。
一、核心术语与数据来源
一次典型的登录事件，通常由身份系统、应用系统或网关在认证成功或失败时写入日志。不同系统字段命名不同，但核心信息高度一致。下面这张表列出了 Impossible Travel 识别中最常用的字段、含义与典型来源。
| 字段 | 含义 | 典型来源 | 示例 |
|---|---|---|---|
| user_id / account | 登录账号或用户唯一标识 | IAM、AD、应用数据库 | alice@corp.com |
| login_time | 登录发生的时间戳 | 认证服务、Web 网关 | 2025-03-11T08:22:31Z |
| source_ip | 发起登录的客户端 IP | Nginx、VPN、SSO 日志 | 203.0.113.45 |
| geo_location | IP 解析出的国家、城市、经纬度 | GeoIP 库、第三方 API | 中国, 上海, 31.23, 121.47 |
| user_agent | 客户端浏览器、操作系统、设备标识 | HTTP Header、App SDK | Mozilla/5.0 (Windows NT 10.0) |
| login_result | 成功或失败 | 认证服务 | success / failure |
这些字段中，source_ip 和 login_time 是 Impossible Travel 计算的两个核心输入。没有准确的时间戳和可解析的 IP，后续的地理距离与速度计算就无从谈起。
二、IP 地址与地理位置解析
IP 地址本身只是一串数字，但它背后关联着网络归属和地理信息。IPv4 地址如 203.0.113.45，IPv6 地址如 2001:db8::1。在异常登录识别中，我们通常关注的是公网 IP，因为内网 IP（如 10.x.x.x、192.168.x.x）无法直接映射到真实地理位置。
将 IP 转换为地理位置的过程称为 GeoIP 解析。常见数据来源包括 MaxMind GeoLite2、IP2Location、纯真 IP 库以及云厂商提供的地理位置服务。解析结果通常包含：国家、省份、城市、经纬度、ASN（自治系统号）和时区。需要注意的是，GeoIP 的精度在城市级别通常只能达到 50%～80%，在移动网络和代理场景下误差更大。
提示：如果登录日志中只有内网 IP，可以结合 NAT 网关日志、VPN 登录日志或 X-Forwarded-For 头来还原真实客户端 IP。否则，Impossible Travel 检测将无法进行。
下面是一个使用 Python 和 GeoLite2 进行 IP 地理位置解析的简单示例：
import geoip2.database
reader = geoip2.database.Reader('/path/to/GeoLite2-City.mmdb')
response = reader.city('203.0.113.45')
print(response.country.name) # 国家
print(response.city.name) # 城市
print(response.location.latitude) # 纬度
print(response.location.longitude) # 经度
解析出经纬度后，就可以计算两次登录之间的地理距离。常用公式是 Haversine 公式，它根据两点经纬度计算球面距离。结合时间差，就能得到“旅行速度”，从而判断是否可能。
三、时间戳与用户代理
时间戳是 Impossible Travel 的另一个关键维度。日志中的时间戳必须统一时区，通常建议统一为 UTC。如果一条日志是本地时间，另一条是 UTC，直接相减会得到错误的时间差。常见时间格式包括 ISO 8601（2025-03-11T08:22:31Z）和 Unix 时间戳（1741681351）。
用户代理（User-Agent）虽然不直接参与距离计算，但在研判中非常重要。它可以帮助我们判断两次登录是否来自同一设备、同一浏览器或同一操作系统。例如，一次登录来自 Windows Chrome，另一次来自 Android App，即使地理位置相近，也可能意味着账号被共享或盗用。User-Agent 的典型来源是 HTTP 请求头，格式如下：
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36
在实际分析中，我们通常会将 User-Agent 解析为浏览器、操作系统、设备类型三个维度，便于聚合和对比。
四、方法流程与案例场景
基于上述字段，Impossible Travel 的基本分析流程可以归纳为以下几步：
- 从登录日志中提取 user_id、login_time、source_ip、user_agent 等字段。
- 对 source_ip 进行 GeoIP 解析，得到经纬度。
- 按 user_id 分组，按 login_time 排序。
- 计算相邻两次登录的时间差和地理距离。
- 计算旅行速度 = 距离 / 时间差。
- 若速度超过合理阈值（如 900 km/h，接近民航速度），则标记为可疑。
下面是一个简化的计算示例：
登录1：2025-03-11 08:00:00 UTC，上海（31.23, 121.47）
登录2：2025-03-11 10:00:00 UTC，北京（39.90, 116.40）
时间差 = 2 小时
地理距离 ≈ 1067 公里
旅行速度 ≈ 533.5 km/h
结论：低于 900 km/h，暂不判定为 Impossible Travel。
如果第二次登录发生在 30 分钟后，速度将超过 2000 km/h，明显不可能通过地面交通或普通民航实现，此时应触发告警。
注意：不要仅凭一次高速登录就断定账号被盗。代理服务器、CDN 节点、企业 VPN 出口、移动网络切换都可能导致 IP 地理位置跳变。必须结合用户代理、登录结果、历史行为基线进行综合研判。
五、常见误区与复盘
在真实环境中，初学者容易陷入以下误区：
- 误区一：所有 IP 都能精确定位。实际上，移动网络 IP 可能归属到省会城市，代理 IP 可能显示为数据中心所在地，精度有限。
- 误区二：时间戳不需要统一时区。跨时区日志未归一化，会导致时间差计算错误，进而误报或漏报。
- 误区三：只看 IP 不看用户代理。同一 IP 可能被多人共用，同一用户也可能切换设备，必须结合 User-Agent 判断。
- 误区四：阈值设置过于绝对。900 km/h 只是经验值，实际应根据业务场景调整，例如金融行业可更严格，内部办公系统可适当放宽。
复盘时，建议对每一次告警记录以下信息：两次登录的 IP、解析位置、时间差、计算速度、User-Agent 差异、最终判定结果。长期积累后，可以形成适合自身业务的阈值和白名单策略。
核心要点：登录日志是数据基础，IP 与地理位置是空间维度，时间戳是时间维度，用户代理是设备维度。只有将这四个维度结合起来，才能准确识别 Impossible Travel 异常登录，避免单一字段带来的误判。