IP 地址是否“很容易伪造”?

IP 地址是否“很容易伪造”?

我正在阅读一些关于Google 的新公共 DNS 服务

我注意到安全部分中有这样一段话:

在 DNS 漏洞的标准系统解决方案(例如 DNSSEC2 协议)普遍实施之前,开放 DNS 解析器需要独立采取一些措施来缓解已知威胁。目前已提出了许多技术;请参阅IETF RFC 4542:使 DNS 更能抵御伪造答案的措施了解其中大部分内容。在 Google Public DNS 中,我们已实施并推荐以下方法:

  • 过度配置机器资源以防止针对解析器本身的直接 DoS 攻击。由于攻击者可以轻易伪造 IP 地址,因此不可能阻止基于 IP 地址或子网的查询;处理此类攻击的唯一有效方法就是吸收负载。

这是一个令人沮丧的认识;即使在 Stack Overflow / Server Fault / Super User 上,我们也经常使用 IP 地址作为各种禁令和阻止的基础。

想想看,一个“有才华的”攻击者可以轻易地使用他们想要的任何 IP 地址,并合成任意数量的唯一虚假 IP 地址,这真是太可怕了!

我的问题是:

  • 是不是真的攻击者在野外伪造 IP 地址是否容易?
  • 如果是的话,可以采取哪些缓解措施?

答案1

正如许多人所说,只要不关心收到响应,IP 标头很容易伪造。这就是为什么它主要出现在 UDP 中,因为 TCP 需要三次握手。一个值得注意的例外是SYN洪水,它使用 TCP 并尝试绑定接收主机上的资源;同样,由于回复被丢弃,因此源地址并不重要。

攻击者伪造源地址的一个特别严重的副作用是背向散射攻击。有一个很好的描述这里,简单来说,它是传统 DDoS 攻击的逆过程:

  1. 获得对僵尸网络的控制权。
  2. 配置所有节点以使用相同的源 IP 地址查找恶意数据包。该 IP 地址将成为您的最终受害者。
  3. 将数据包从所有受控节点发送到互联网上的各个地址,瞄准通常未开放的端口,或连接到有效端口(TCP / 80),声称是已经存在的交易的一部分。

在 (3) 中提到的任何一种情况下,许多主机都会以 ICMP 不可达或 TCP 重置进行响应,针对的是恶意数据包的源地址. 攻击者现在可能拥有网络上数千台未受感染的机器,通过使用欺骗的源 IP 地址对他/她选择的受害者执行 DDoS 攻击。

从缓解措施方面来看,这种风险实际上只有 ISP(尤其是提供客户访问而非传输的 ISP)才能解决。主要有两种方法可以解决此问题:

  1. 入口过滤- 确保进入网络的数据包来自位于传入接口远端的地址范围。许多路由器供应商都实现了以下功能单播逆向路径转发,使用路由器的路由和转发表来验证传入数据包的源地址的下一跳是否为传入接口。此操作最好在网络中的第一个第 3 层跳(即您的默认网关)处执行。

  2. 出口过滤- 确保离开您网络的数据包仅来自您拥有的地址范围。这是入口过滤的自然补充,本质上是成为“好邻居”的一部分;确保即使您的网络受到恶意流量的攻击,该流量也不会转发到与您同行的网络。

这两种技术在“边缘”或“接入”网络中最为有效且易于实施,因为客户端与提供商交互。由于多路径和非对称路由的复杂性,在接入层之上实施入口/出口过滤变得更加困难。

我已经看到这些技术(特别是入口过滤)在企业网络中得到了很好的应用。也许有更多服务提供商经验的人可以更深入地了解在整个互联网上部署入口/出口过滤的挑战。我认为硬件/固件支持是一个巨大的挑战,而且无法迫使其他国家的上游提供商实施类似的政策……

答案2

对于攻击者来说,在野外伪造 IP 地址真的那么容易吗?

当然,如果我不在乎是否真的收到任何响应,我可以轻松使用我喜欢的任何源地址发送数据包。由于许多 ISP 并没有很好的出口规则,因此我伪造的任何内容通常都会被传递。

如果攻击者确实需要双向通信,那么就会变得非常困难。如果他们需要双向通信,那么使用某种代理往往更容易。如果你知道自己在做什么,那么设置起来非常容易。

由于网站使用需要双向通信的 http/https,因此通过 IP 地址禁止人们在 SF/SO/SU 上具有中等效果。

答案3

Zordeche 的答案的小概念证明(使用 ubuntu):

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

然后在另一个控制台中:

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

是的,这很简单,但是您无法获得前面提到的回复,除非您可以访问 11.10.10.20,或者在 www.google.com 和 11.10.10.20 之间有嗅探器(并且它必须位于两端的正前方,因为您无法预测数据包的路由)。此外,如果欺骗者的网关 (ISP) 正在进行某种 IP 检查并发现源有问题,则可能不会让该数据包出门。

答案4

GOOG 文章明确讨论了 DNS。DNS 使用 UDP 和 TCP 数据包。UDP 数据包可以伪造,但 TCP 数据包不能。TCP 需要三次握手。如果 TCP 数据包的 IP 地址是伪造的,那么伪造的计算机将不会收到响应,连接将失败。正如其他答案中提到的,UDP 是“发射后不管”的,不需要响应通信。出于这个原因,DoS 攻击几乎完全以 UDP 数据包的形式出现。

在 Stack Overflow 和同类网站的背景下,Takaun Daikon 提出的问题非常有效。有很多方法可以从 ISP 获取新 IP 地址。更改 MAC 地址显然是最简单的方法,并且适用于许多 ISP。此外,许多想出这种愚蠢主意的人可能正在使用公共代理或 TOR。显然,阻止这些数据包的原始 IP 只会阻止代理或 TOR 终止节点。

那么,封锁 IP 地址是否有效?当然有效。但最终还是会出现错误。你会封锁一些实际上不是问题根源的 IP(即代理),也会有人通过更改 IP 来避开你的封锁。不幸被封禁 IP 的人以后将无法访问 SO 系列网站。但错误速度应该很小。除非你封锁了大量 IP。但如果你每天封锁一两个 IP,那就没问题了。

您可能想要引入一个稍微复杂一点的方案,即封锁一段时间,比如一年。如果您的网络能够限制带宽或连接数,您可能还会考虑一个方案,即在您的站点上运行 Apache Benchmarks 的混蛋会被关进带宽非常有限的笼子里。

相关内容