如何防止 IP 欺骗攻击

前台可以查一件快递是不是从正常的收货通道送来的，但谁有权进楼，仍要另行验证。网络防护也有这样的分工：先检查流量声称的来源，再验证谁有权使用服务。

尽量在靠近源头的地方检查

网络运营者知道，某个客户的线路应该使用哪些地址范围。如果数据包冒用了不相关的来源，就可以在这里拦下，避免继续向外传播。BCP 38讲的就是这类源地址验证。

企业网络既要检查外面进来的流量，也要检查自己发往互联网的流量。同一条边界，对一侧是出口，对另一侧是入口。应当按连接明确合理的来源，包括合法分配给下游的地址范围，而不是到处套用同一条规则。

范围检查仍然不能证明是谁发了包，也未必能阻止在允许范围内部冒用别人的地址。它是一道有价值的边界检查，不是一张身份证明。

反向路径检查，要适合真实的路由

单播反向路径转发，简称 uRPF，会拿数据包的源地址与路由信息做比较。严格模式要求：流量进来的接口，与所选回程路由的接口一致。路径比较固定时，这种方式很有用。

但正常流量也可能从一条线路进来，回复却从另一条线路出去。非对称路由、接入多个运营商的网络，都可能遇到这种情况。此时一味启用严格检查，反而会误伤正常通信。RFC 3704说明了这些取舍。可行路径方法会考虑允许的备选路径；宽松检查通常只看有没有回程路由，验证力度较弱。选择之前应核对实际拓扑，也要测试线路切换后的情况。

服务和用户，还要验证身份

地址限制有用的地方可以保留，但敏感访问不应只凭 IP 放行。网站应正确验证 TLS，管理连接和网络对等方也应使用合适的认证协议。账户登录与权限管理，仍然各有自己的职责。

TLS 1.3可以验证服务端，也可按配置验证客户端，并保护应用数据。它不会为每个 IP 包的来源背书，也不能阻止大量流量把线路挤满。加密与源地址验证保护的是不同环节。

别让自己的服务变成反射器

如果你运行递归 DNS，应把递归查询限制在真正需要服务的客户端范围内。这里要与权威 DNS 区分：为你的域名提供权威回答的服务器，可能本来就需要面向公众。RFC 5358解释了开放递归为何会被用于反射攻击。

其他对外服务也应检查是否有不必要的开放，以及是否会产生过大的回复。提前安排上游 DDoS 防护同样重要：如果流量到达服务器之前就已经挤满线路，只在服务器上过滤，无法恢复这段线路的容量。

换成 IPv6，也不会自动安全

启用 IPv6 不会自动开启加密，更不会自动消除源地址伪造。IPsec 需要配置和密钥管理，IPv4、IPv6 都可以使用。IPv6 运行安全指南讨论的是需要实际部署的控制措施。双栈网络要把两套路径都检查到。

既要挡住异常，也要让正常业务继续

记录预期的地址范围和路径，测试正常流量与故障切换，再结合丢包记录和服务状态判断效果。入侵检测系统可以报警，真正阻断还需要防御功能或运维响应。日志应帮助解释发生了什么，不能把一个自报地址直接当成某个人的身份。

如果你只是使用互联网，重点仍是更新软件、使用经过身份验证的连接、保护好账户。需要时可以向运营商了解源地址过滤；浏览器里的设置无法替上游完成这项工作。想回看原理，可以读源地址如何被伪造，或看各种防护分别应对什么攻击。