Jef*_*ood 68 security domain-name-system ip-address spoofing
我正在阅读有关Google 新公共 DNS 服务的一些说明：
我在安全部分注意到这一段：
在普遍实施针对 DNS 漏洞的标准全系统解决方案（例如 DNSSEC2 协议）之前，开放式 DNS 解析器需要独立采取一些措施来缓解已知威胁。已经提出了许多技术；请参阅IETF RFC 4542：使 DNS 更能抵御伪造答案的措施，以了解其中大部分内容的概述。在 Google 公共 DNS 中，我们已实施并推荐以下方法：
- 过度配置机器资源以防止对解析器本身的直接 DoS 攻击。由于 IP 地址对于攻击者来说是微不足道的，因此无法阻止基于 IP 地址或子网的查询；处理此类攻击的唯一有效方法是简单地吸收负载。
这是一个令人沮丧的认识；即使在堆栈溢出/服务器故障/超级用户上，我们也经常使用 IP 地址作为各种禁止和阻止的基础。
认为一个“有才华”的攻击者可以随便使用他们想要的任何IP地址，并合成尽可能多的唯一假IP地址，真是太可怕了！
所以我的问题：
Mur*_*iar 51
正如许多其他人所说，只要不关心接收响应，IP 报头就很容易伪造。这就是为什么它主要与 UDP 一起出现的原因，因为 TCP 需要 3 次握手。一个值得注意的例外是SYN flood，它使用 TCP 并试图占用接收主机上的资源；同样，由于回复被丢弃，源地址无关紧要。
攻击者欺骗源地址的能力的一个特别令人讨厌的副作用是反向散射攻击。有一个很好的说明在这里，但简单地说，它是一个传统的DDoS攻击的倒数：
在 (3) 中提到的任何一种情况下，许多主机都会响应 ICMP 不可达或 TCP 重置，针对恶意数据包的源地址。攻击者现在可能在网络上有数千台未受攻击的机器对其选择的受害者执行 DDoS 攻击，所有这些都是通过使用欺骗性的源 IP 地址进行的。
在缓解方面，这种风险实际上只有 ISP（尤其是提供客户访问而不是传输的 ISP）才能解决。有两种主要方法可以做到这一点：
入口过滤- 确保进入您网络的数据包来自位于传入接口远端的地址范围。许多路由器供应商都实现了单播反向路径转发等功能，它使用路由器的路由和转发表来验证传入数据包源地址的下一跳是传入接口。这最好在网络中的第一个第 3 层跃点（即您的默认网关）执行。
出口过滤- 确保离开您网络的数据包仅来自您拥有的地址范围。这是对入口过滤的自然补充，本质上是成为“好邻居”的一部分；确保即使您的网络受到恶意流量的破坏，该流量也不会转发到您与之对等的网络。
当在“边缘”或“接入”网络中这样做时，这两种技术都是最有效和最容易实现的，在这些网络中，客户端与提供商进行交互。由于多路径和非对称路由的复杂性，在接入层之上实施入口/出口过滤变得更加困难。
我已经看到这些技术（特别是入口过滤）在企业网络中发挥了巨大的作用。也许拥有更多服务提供商经验的人可以更深入地了解在互联网上部署入口/出口过滤的挑战。我想硬件/固件支持是一个很大的挑战，而且无法强迫其他国家的上游供应商实施类似的政策......
Zor*_*che 47
攻击者在野外伪造 IP 地址真的那么容易吗？
当然，如果我不关心实际收到任何响应，我可以很容易地使用我喜欢的任何源地址发送数据包。由于许多 ISP 并没有真正好的出口规则，因此我伪造的任何东西通常都会被交付。
如果攻击者实际上需要双向通信，这将变得非常困难。如果他们需要双向通信，那么简单地使用某种代理往往会更容易。如果您知道自己在做什么，这很容易设置。
由于该站点使用需要双向通信的 http/https，因此通过 IP 地址禁止人员在 SF/SO/SU 上较为有效。
Kyl*_*ndt 23
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 检查并发现源闻起来很糟糕，他们可能不会让该数据包出门。
小智 13
单向UDP流量的IP 地址很容易伪造。对于TCP数据包，只能用SYN数据包伪造一个半开的TCP连接。这也是一种 DOS 攻击的基础。但是您不能使用欺骗地址伪造 HTTP 连接（例如，如果您要过滤会话以使用相同的 IP 地址）。虽然是的，您可以在数据包中欺骗 IP 地址，但它仅对某些类型的拒绝服务攻击有用。
JD *_*ong 10
GOOG 文章明确讨论了 DNS。DNS 使用 UDP 和 TCP 数据包。UDP 可以伪造，但 TCP 不能。TCP 需要3 次握手。如果 TCP 数据包的 IP 地址是伪造的，那么伪造的计算机将不会收到响应并且连接将失败。正如其他答案中提到的，UDP 是“即发即忘”，不需要响应通信。出于这个原因，DoS 攻击几乎完全以 UDP 数据包的形式出现。
在 Stack Overflow 和家庭站点的上下文中，Takaun Daikon 提出的问题非常有效。有很多方法可以从一个人的 ISP 获得一个新的 IP 地址。更改 MAC 地址显然是最简单的，并且适用于许多 ISP。此外，许多愚蠢的人可能正在使用公共代理或 TOR。显然，阻止这些数据包的原始 IP 只会阻止代理或 TOR 终止节点。
那么阻止 IP 地址有效吗？地狱是的。但是你最终会出错。您将阻止一些实际上不是问题根源的 IP（即代理），并且您还将让人们通过更改 IP 来避免您的阻止。之后不幸获得被禁止 IP 的人将无法访问 SO 系列站点。但是错误率应该很小。除非您阻止了大量 IP。但是如果你每天阻塞一两个，你应该没问题。
您可能想引入一个稍微复杂一些的方案来阻止，但仅限于一段时间，例如一年。如果您的网络能够进行带宽节流或连接限制，您还可以考虑这样一种方案，即在您的站点上运行 Apache Benchmarks 的冲洗袋只是被放在带宽非常有限的笼子里。
Mic*_*aff 10
IP 欺骗将继续存在，因为 ISP 很懒惰。
我该死的 ISP 知道我在一个特定的地址，或者至少是我所在的子网。但是我可以使用任何源地址。这是为什么？简单来说，成本。
如果我在这里和那里伪造一些地址，我的 ISP 不会花费任何费用。如果我的 ISP 的每个用户都在 1:00 到 2:00 之间伪造了一个数据包，这仍然不会是雷达上的一个昙花一现。但是，当僵尸网络从许多 ISP 上的许多主机发送许多欺骗性数据包时，目标机器或网络就会发生故障。
财务现实是，除非您是被攻击者，否则欺骗不会产生任何成本。在客户附近实施过滤需要花钱，而花钱的人除了知道自己是优秀的网络公民之外，获得的回报很少。
UDP 和 ICMP 最容易伪造，但 TCP 也是可能的。它需要一个不安全的远程操作系统，它使用可预测的序列号来利用。有时是负载平衡机改变序列号并使它们可预测。所以，TCP 是可能的——但更难。
DNS 反欺骗主要侧重于防止某人向递归解析器提交错误答案的安全方面。UDP 的泛洪方面不是特定于 DNS 的，除了单个小查询（例如，对于 '.'）将导致相当大的响应。因此，它是一个很好的扩增载体。还有许多其他 UDP 协议可以工作，但 DNS 无处不在，而且很容易找到用于放大攻击的机器。
DNSSEC 使情况变得更糟，UDP 数据包的大小可以达到 4k。
就基于 DNS 的 (D)DOS 攻击而言，IP 地址很容易伪造，因为它们通常是一种即发即忘的 UDP 数据包。对于 HTTP 流量，情况并非如此，因此您需要与 Web 服务器位于同一本地网络（当然，这完全有可能，具体取决于您的站点所在的位置），或者控制中间路由器。
你可以给任何人寄一封信，如果你没有在信封上写上回信地址（或者写错了），他们可以雇佣世界上所有的垃圾邮件过滤器，不打开就过滤掉你的邮件（处理） 它。
但是，如果发送方想要响应，返回地址最好是正确的，否则必须有一个应用层机制来获取正确的地址。所以我可以让你认为你正在打开一封来自 Nana 的信，但即使我用信件的内容愚弄了你，你也不会向 Nana 寄一张支票，以现金形式寄往尼日利亚的某个地址（除非 Nana 是尼日利亚人） ）。因此，只要您不是中间人，挑战/响应就是一种有效的防御。
虽然这确实是一个需要处理的现实，但潜在的问题实际上是非技术性的：怀有恶意的人试图做恶意的事情。因此，真正的解决方案也必须是非技术性的。
我认为 Stackoverflow 所做的正是处理第二道防线的正确解决方案：在达到某种程度的“可信度”之前，通过限制潜在垃圾邮件用户与平台交互能力的不同方式来限制潜在垃圾邮件用户的技术。
这些技术不仅有助于提高网站的整体质量，而且实际上会激励用户更多地参与并提供更可信/可靠的答案。
从技术的角度来看，最好的做法是按照谷歌的建议去做：高效地吸收/处理额外的负载。
干得好，不断改进！
| 归档时间： |
|
| 查看次数： |
14760 次 |
| 最近记录： |