防范IP欺骗的实用方法

你需要做的第一件事是了解你想防范的攻击types。 我认为任何事情都不能让你更好地理解攻击，而不是写代码来执行攻击。

我知道的有关IP欺骗的三类攻击是 ：

• 服务器上的资源消耗
• 反思攻击
• 对问责制的攻击

我会更详细地描述它们中的每一个。 资源消耗类的攻击意味着服务器将接收大量的数据包，其中大部分具有欺骗性的源IP。 由于欺骗性的IP地址可以有攻击者select的任何分布，所以没有合法的数据包被欺骗的数据包。 服务器只有资源来处理这些数据包的数量，攻击者发送的数据包越多，合法数据包的一小部分就能被服务器处理。

这个典型的攻击是几十年前的SYN洪水。 它在服务器上消耗的资源主要是内存来保持每个TCP连接的状态。

SYN Cookie旨在保护完全免受这种攻击。 他们把cookie的概念挤进TCP握手。 Cookie是服务器发送给客户端的唯一目的的简短值，即客户端可以将其发送回服务器。 这certificate客户端收到了cookie。 通常的欺骗场景只允许攻击者从伪装的IP发送数据包，不接收服务器发送给这个IP的数据包。

SYN cookies确实从TCP丢失了一点function。 这是因为需要与现有的TCP客户端兼容，同时在客户端驴通过返回cookiecertificateIP地址之前不使用服务器上的内存。

在上面提到的两个devise目标中，端口碰撞失败。 这对客户来说并不完全透明。 此外，即使在第一个（敲入）数据包已经发送到服务器之后，它也要求存储状态。 端口敲击根本不是为了减轻IP欺骗而devise的，它是为完全不同的目的而devise的。 如果您确实希望有效的防范IP欺骗，并且您愿意在客户端上进行软件更新，那么有更有效的方法。

reflection攻击旨在消耗networking带宽，而不是服务器本身的资源。 这种攻击将受害者的IP置于源IP中，并将目标IP中的任何合适的服务器。 一旦服务器收到请求，它将回复欺骗性的来源，回复可能比请求要大得多。 这使攻击者能够以比本身发送更多的stream量来淹没受害者。

这个类别的攻击可以使用多个基于UDP的服务。 DNS和NTP是众所周知的服务，当收到一个小的请求可能会发送一个大的答复。

防止reflection攻击的最有效的方法是服务器永远不会发送多个数据包，以响应来自IP地址的请求，而先前没有被certificate是正确的，并且该响应不得包含比请求多的字节。 TCP通常被认为是免疫reflection攻击，但基于UDP的服务可能是脆弱的。

第三类攻击是在整个通信过程中使用一个欺骗性IP在服务器上完成一个完整的事务。 服务器上的所有日志都会指出这个事务是由欺骗IP执行的。 这通常被认为是纯理论上的攻击。

通常情况下，通信是通过TCP完成的。 攻击者必须猜测一个32位的序列号才能build立连接。 攻击者也可能需要猜测服务器每次回复的大小。 而且如果使用encryption，攻击者甚至可能不得不猜测部分内容。 另外，攻击者必须在主机被欺骗之前完成事务，才有时间向服务器发送错误消息，从而closures连接。

如何testing攻击

build立一个小型的机器networking，欺骗互联网上的任何主机的IP并不难，从这个IP发送数据包到你自己的服务器。 与此同时，您可以安排路由表将回复路由到互联网。 有了这个设置，你就有一个真实的networking来testingIP欺骗。 请记住只欺骗IP地址，这是不允许通过BGP宣布的，这样您就不会为有reflection数据包的人造成问题。

准备就绪后，普通的TCP或DNS客户端就足以向服务器发送欺骗性数据包。 实际的洪水需要更多的努力设置，但并不难。

如何保护DNS免受欺骗

首先，如果你有一个DNS服务器，你可以检测到它正在用于reflection攻击。 在服务器向欺骗IP发送回复之后，reflection攻击将导致ICMP错误到达。

你可以做些什么来减轻攻击？ 首先，您可以跟踪经过validation的客户端IP地址和欺骗性IP地址。 显然大部分的IP地址都会在不知道的范畴。 当您收到一个响应DNS答复的ICMP错误时，IP地址将被放入欺骗IP地址的类别中。 知识产权进入时，必须实施缓解措施。

为了减轻攻击，DNS服务器发送一个只包含请求但不包含实际回复的回复。 此外，必须设置截断位。 这将告诉客户端使用TCP重试请求。 通过TCP的成功请求将certificateIP是实际客户端的IP地址，并将IP地址移到一组经过validation的IP地址。

如果一组已知的欺骗性IP地址变得比你想追踪的大，你只需停止追踪它，即使在IP地址（假冒状态未知）的地方也可以使用缓解措施。

如何保护所有协议免受欺骗

为在UDP上运行的每个服务编写服务特定代码似乎不是防止欺骗的正确方法。 应该有一个服务独立的方式来防止欺骗。

我不认为你可以以完全向后兼容的方式来做到这一点。 但是让我们假设我们可以在IP层和传输层之间添加一些新的function来防范欺骗，假设考虑欺骗性的问题来部署这样的保护，那么这样的保护是什么样的呢？

我有一个基于IPv6扩展头的想法来实现这一点。 几个月前，我草拟了更多的细节。 如果您要完成在开源IPv6协议栈中实现的任务，那么我很乐意将我的草稿翻译成英文。