如何防止 IP 欺骗攻击

检查投递经过的路线，与决定谁可以进入，是两项不同的工作。源验证和身份验证需要各自的控制措施。

接待台可以检查投递是否经过预期路线。接收者仍需决定谁可以进入建筑。网络也有类似的分工：先验证流量声称来自哪里，再对服务访问进行身份验证。

把第一道检查放在靠近源头的位置

网络运营者知道哪些地址范围应当出现在客户连接上。声称来自无关来源的分组可以在那里被拒绝，不必继续向前传播。这就是 BCP 38 描述的源验证方法。

对于公司网络，既要检查向互联网发出的流量，也要检查从外部进入的流量。同一边界既是一个网络的出口，也是另一个网络的入口。为每条连接定义预期来源，包括合法委派的地址范围，不要在所有地方套用一条一刀切的规则。

范围检查无法识别数据包背后的人。它也可能允许在获准范围内伪造来源。应把它视为有用的边界控制，而不是身份凭证。

让反向路径检查符合真实路由

单播反向路径转发（uRPF）会将数据包的源地址与路由信息比较。在严格模式下，进入接口必须与选定的返回路径相匹配。当路径可预测时，这种方式可以很好地工作。

然而，合法流量可能从一条连接抵达，而最佳返回路由却使用另一条连接。使用非对称路由或多个提供商的网络就会发生这种情况。严格检查可能因此丢弃有效流量。RFC 3704解释了这些权衡。可行路径方法会考虑获准的替代路径；宽松检查通常只询问是否存在一条路由，因此测试较弱。应根据实际拓扑选择并验证模式，包括故障转移路径。

验证服务和用户的身份

保留有用的地址限制，但不要把它作为敏感访问的唯一身份依据。为 Web 服务使用经过正确验证的 TLS，为管理和网络对等端使用适当的身份验证协议。账户身份验证和权限控制仍各自承担不同职责。

TLS 1.3 会验证服务器，也可以验证客户端，并保护应用流量。它不会证明每个 IP 源地址，也不能防止洪泛耗尽链路。加密和源验证保护的是不同对象。

减少被用于反射的机会

如果你运行递归 DNS，应把递归限制在打算服务的客户端范围内。这与权威 DNS 不同，后者可能需要为你的域名向公众提供解析服务。RFC 5358说明了开放递归为何会把服务器变成反射器。

检查其他暴露的服务，确认没有不必要的可达性和过大的响应。在事件发生前规划上游 DDoS 支援：如果流量抵达前就已经使连接饱和，仅靠你自己的服务器过滤无法恢复连接。

IPv6 也需要这些决定

迁移到 IPv6 不会自动开启加密，也不会阻止源地址欺骗。IPsec 需要经过审慎配置并进行密钥管理，并且可以用于两个 IP 版本。IPv6 运行安全指南讨论了实际需要的控制措施。在双栈网络中，应评估并测试两条路径。

验证防护有效，同时不破坏服务

记录预期范围和路由，测试授权流量与故障转移，然后检查丢弃情况和服务健康度。入侵检测系统可以提醒你注意相关模式；真正的阻断需要防御功能或运营者响应。日志应帮助解释发生了什么，而不是把声称的来源变成推定身份。

作为普通互联网用户，应关注更新、经过身份验证的连接和账户安全。如有需要，向提供商询问源过滤；你无法通过浏览器修复上游的数据包验证。有关背景，请阅读伪造源地址如何运作，或阅读每种控制措施应对哪种攻击模式。