IP地址是否“容易伪造”？

我正在阅读有关Google的新公共DNS服务的一些说明：

• 绩效收益
• 安全利益

我在安全性部分注意到了这一段：

在普遍采用标准的全系统DNS漏洞解决方案（例如DNSSEC2协议）之前，开放DNS解析器需要独立采取一些措施来缓解已知威胁。已经提出了许多技术。有关大多数问题的概述，请参见IETF RFC 4542：使DNS对伪造答案更具弹性的措施。在Google公共DNS中，我们已经实现并建议采用以下方法：

• 过度配置机器资源，以防止对解析程序本身进行直接DoS攻击。由于IP地址对于攻击者来说很容易伪造，因此无法阻止基于IP地址或子网的查询。应对此类攻击的唯一有效方法是简单地吸收负载。

这是一个令人沮丧的认识；即使在堆栈溢出/服务器故障/超级用户中，我们也经常使用IP地址作为各种禁止和阻止的基础。

认为一个“才华横溢”的攻击者可以轻而易举地使用他们想要的任何IP地址，并根据需要合成任意数量的唯一假IP地址，真是太可怕了！

所以我的问题是：

• 攻击者在野外伪造IP地址真的那么容易吗？
• 如果是这样，可以采取哪些缓解措施？

正如许多其他人所述，只要不关心接收响应，IP头就很容易伪造。这就是为什么它在UDP上最常见的原因，因为TCP需要三路握手。一个值得注意的例外是SYN Flood，它使用TCP并试图占用接收主机上的资源。再次，由于答复被丢弃，因此源地址无关紧要。

攻击者欺骗源地址的能力的一个特别讨厌的副作用是反向散射攻击。有一个很好的说明在这里，但简单地说，它是一个传统的DDoS攻击的倒数：

1. 获得对僵尸网络的控制。
2. 配置所有节点以对恶意数据包使用相同的源IP地址。该IP地址将成为您最终的受害者。
3. 将所有受控节点的数据包发送到Internet上的各个地址，以通常未打开的端口为目标，或者连接到声称是现有事务的一部分的有效端口（TCP / 80）。

在（3）中提到的任何一种情况下，许多主机都会以不可达的ICMP或TCP重置为响应，以恶意数据包的源地址为目标。现在，攻击者可能通过使用欺骗性的源IP地址，在网络上成千上万台不受影响的计算机对其选择的受害者进行DDoS攻击。

就缓解而言，这种风险实际上是只有ISP（尤其是提供客户访问权限而不是中转的ISP）可以解决的风险。有两种主要方法：

1. 入口过滤 -确保进入网络的数据包来自存在于传入接口远端的地址范围。许多路由器供应商实现了诸如单播反向路径转发之类的功能，这些功能使用路由器的路由和转发表来验证传入数据包的源地址的下一跳是传入接口。最好在网络的第3层跃点（即默认网关）上执行此操作。

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

这两种技术在“边缘”或“访问”网络（客户端与提供者进行交互）中最有效且最容易实现。由于多路径的复杂性和非对称路由，在接入层上方实施入口/出口过滤变得更加困难。

我已经看到这些技术（特别是入口过滤）在企业网络中发挥了巨大作用。也许具有更多服务提供商经验的人可以更深入地了解在整个Internet上部署入口/出口过滤的挑战。我认为硬件/固件支持将是一个巨大的挑战，并且无法迫使其他国家的上游提供商实施类似的政策...

攻击者在野外伪造IP地址真的那么容易吗？

当然，如果我不关心实际收到任何响应，则可以使用我喜欢的任何源地址轻松发送数据包。由于许多ISP确实没有良好的出口规则，因此我能伪造的任何物品都可以交付。

如果攻击者实际上需要双向通信，它将变得非常困难。如果他们需要双向通信，则简单地使用某种代理通常会更容易。如果您知道自己在做什么，那很容易设置。

通过IP地址禁止用户在SF / SO / SU上有一定的作用，因为该站点使用http / https，这需要双向通信。

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检查，并且发现源有异味，则可能不会将该数据包放出门。

IP地址很容易伪造为单向UDP流量。对于TCP数据包，您只能伪造与SYN数据包的半开放TCP连接。这也是一种DOS攻击的基础。但是您不能使用欺骗的地址建立HTTP连接（例如，如果要过滤会话以使用相同的IP地址）。是的，您可以欺骗数据包中的IP地址，它仅对某些拒绝服务攻击有用。

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。但是，如果您一天要阻止一两次，那应该没问题。

您可能想引入一个稍微复杂一些的方案，在此范围内，但只能进行一段时间，例如一年。如果您的网络能够进行带宽限制或连接限制，那么您也可以考虑使用一种方案，将在您的站点上运行Apache Benchmarks的冲洗袋放入带宽非常有限的笼子中。

由于ISP懒惰，因此IP欺骗将继续。

我的ISP非常知道我位于特定地址，或者至少位于我所在的子网中。但是我可以使用任何源地址。这是为什么？简单来说，就是成本。

如果我在这里和那里伪造了一些地址，那么我的ISP不会花费任何费用。如果我的ISP的每个用户都在1:00和2:00之间伪造了一个数据包，那么这几乎不会是一时的事。但是，当僵尸网络从许多ISP上的许多主机发送许多欺骗性数据包时，目标计算机或网络将崩溃。

财务现实是，除非您是被攻击者，否则欺骗不会花费任何代价。在客户附近实施过滤需要花费金钱，而花钱的人除了知道他们是良好的网络公民以外，几乎没有回报。

UDP和ICMP最容易伪造，但TCP也是可能的。它需要一个不安全的远程OS，该OS使用可预测的序列号来进行利用。有时，负载平衡机器会更改序列号并使它们可预测。因此，TCP是可能的-但难度更大。

DNS反欺骗主要集中在安全方面，以防止某人向递归解析器提交错误答案。UDP的泛滥方面不是特定于DNS的，而是单个小的查询（例如，“。”）将导致相当大的响应。因此，它是一个很好的扩增载体。还有许多其他的UDP协议可以使用，但是DNS随处可见，并且很容易找到用于放大攻击的计算机。

DNSSEC使UDP数据包的大小达到4k时，情况变得更糟。

就基于DNS的（D）DOS攻击而言，IP地址很难伪造，因为它们通常是即发即弃的UDP数据包。对于HTTP通信，不是这种情况，因此您需要与Web服务器位于同一本地网络上（当然，完全有可能，这取决于您的站点托管的位置），或者控制中间路由器。

您可以向任何人发送一封信，如果您没有在信封上放回信地址（或放错了回信地址），他们可以雇用世界上所有的垃圾邮件过滤器，并且在不打开邮件的情况下不过滤您的邮件（处理）。

但是，如果发送者想要响应，则返回地址最好是正确的，否则就必须有一个应用程序层机制来获取正确的地址。因此，我可以使您认为您正在打开娜娜的一封信，但是即使我用信中的内容欺骗了您，也不会将纳什的支票寄给CASH到尼日利亚的某个地址（除非娜娜是尼日利亚人）。因此，只要您不是中间人，挑战/回应就是一种有效的防御措施。

我可以在数据报中设置所需的任何源IP地址。
我的ISP是否会让这样的数据包泛滥，这是另一个问题。

尽管这确实是必须解决的现实，但潜在的问题实际上是非技术性的：具有恶意意图的人试图做恶意的事情。因此，真正的解决方案也必须是非技术性的。

我认为Stackoverflow所做的完全是处理第二道防线的正确解决方案：通过在达到一定程度的“可信度”之前通过限制用户与平台交互能力的不同方式来限制潜在垃圾邮件用户的技术。

这些技术不仅有助于提高网站的整体质量，而且实际上可以激励用户更多地参与其中并提供更可信/可靠的答案。

从技术的角度来看，最好的办法就是按照Google的建议去做：只是有效地吸收/处理额外的负载。

做得好，并不断改进！

UDP是为什么这是很容易的主体部分-事实上，Skype和Slingbox的利用在UDP容易伪造IP地址的能力“ 冲通过NAT”，并允许便于对等网络。

TCP较难，因为它需要一个完整的SYN / ACK周期，但是您仍然可以用挂起的SYN数据包淹没服务器，该数据包会跳到距离很多跳的IP地址，并在此过程中实际上占用了大量路由器。

如上所述，使用代理是微不足道的，并且有大量可用的开放式匿名代理。

即使不使用代理，我也可以将防火墙上的MAC地址设置为任何新的任意值，重置电缆调制解调器，然后ISP将为我分配一个全新的闪亮IP地址。

那只是初学者。还有许多其他方法可以解决IP禁令。

如果是这样，可以采取哪些缓解措施？

在接收端您无能为力。

伪造者的ISP应该过滤其出站流量，以便其客户不能欺骗来自不同网络的IP。

路由器配置中只有几行，因此没有一个很好的借口。

有一种方法可以跟踪攻击者，但是需要上游供应商的配合：http ://www.cymru.com/Documents/dos-and-vip.html

正如其他人指出的那样，UDP非常容易伪造，TCP则不那么容易。

首选防御机制是出口过滤器，但不幸的是，这种防御方式并未普遍部署。

对于运行DSL等服务的ISP，应该为每个虚拟线路配置ip verify unicast reverse-path（或与之等效的非Cisco），该虚拟线路会阻止其源IP地址不在已知沿该线路路由的范围内的任何数据包。

我记得在90年代末使用Visual Basic进行套接字编程，我们可以在连接上设置源IP。我模糊地记得在尝试时，netstat -an显示了实际的源IP，但是Apache日志显示了欺骗的IP。而且我认为Apache还将欺骗的IP交给了perl模块等等。