理解IDS的主动响应机制
    在开发者的团体内，关于“什么是检测***的最有效的方法？”的问题的争论还在激烈的进行着，不过IDS的用户对目前的IDS技术还是感到满意的，为了获得更有优势的竞争，很多的IDS产品提供商，都在其产品中加入了主动响应的功能。这个功能的概念就是说IDS将检测***者的***行为，并组织***者继续进行***。不过，问题是稍有一点TCP/IP知识的***者都可以轻易的直接击败这些响应机制；或者利用这些机制实现阻断网络的功能，管理员将不得不关闭这些功能。对于管理员来说，明白主动响应的局限性将有助于管理员盲目的相信那些产品提供商。绝大多数响应机制是以下两种形式中的一种：
1.阻止会话
2.防火墙联动

一、“阻止会话”机制简介：
阻止会话到目前为止，是最IDS供应商最常用的方式。这种方式之所以流行，是因为它不需要外部设备的支持（如防火墙），而且它易于实现。这一机制非常简单，下面我们将逐步剖析这种机制，并揭示如何绕过它，我希望我的评价不会引起厂商们的反感。
下面我们以IIS的Unicode横向目录遍历***为例子，来讲解这一机制的工作方式。***者发出如下的请求，这个请求共51个字节，将这51个字节变成分段的破碎IP包，每个包长为20个字节，如下所示：

Data: /scripts/..%c0%af../winnt/systme32/cmd.exe/c+dir+foo
+----+----++
Offset: 0 20 40 51
Sec Num: 100 120 140 151

本文中提到的IDS是具有如下功能的产品：
1.有关于“system32/cmd.exe”这个***特征信号
2.能够重组所有的破碎包和流信息
3.能够进行unicode、hexcode（16进制编码）、escape和base64的解码
如果***者仅仅是简单的重复这样的行为，而不做任何变化的化，IDS将捕获到这样的***行为，并生成一个报警信息。一般说来，操作系统在处理时，会对以上所示的IP包在IP堆栈生成一个随机的ISN值，然后将数据用三个数据包发出。（当然，我们都知道简单的通过浏览器是无法实现这个情况的，这里只是一个例子而已）
有些系统的IP堆栈在每发出一个数据包以后，会等待一会儿以便收到来自接受方的确认信息，确认收到发出的那个数据包。而有的系统的IP堆栈会一次发出所有的三个包，然后在重发那些接受方没有确认收到的数据包。尽管不同的操作系统在一个会话建立以后（Established状态）处理IP堆栈的方式不一样，不过这里的关键是说明了堆栈肯定可以同时处理一定数量的数据包。在本例中，我们的IDS将会在收到第三个包的时候报警，因为它已经收到了第1个和第2个数据包，此时它已经可以重组整个会话，并匹配出合适的信号了。这时候，如果IDS具有会话阻断的功能，那么IDS将会向通信的两端各发送一个TCP RESET包，从而实现主动切断连接的目的，此时通信双方的堆栈将会把这个RESET包解释为另一端的回应，然后停止整个通信过程，释放缓冲区并撤销所有TCP状态信息。这个时候，***数据包可能还在目标主机操作系统TCP/IP堆栈缓冲区中，没有被提交给应用程序，由于缓冲区被清空了，所以***不会发生。
对于RESET包来说，IDS发出的RESET包的前提是知道整个会话当前的序列号和确认号，否则这个RESET包将会被忽略。本例中确认号必须为152（比最后的一个序列号大1）如果你发送的RESET包的确认号为142，那么堆栈将会认为这是一个无效的数据包或者被破坏的数据包而将它忽略掉。（嗯，好像问题开始变得明朗了）

二、绕过“会话阻止”
会话阻止的机制可以被***者所绕过，绕过这一机制的很多方法都是依靠时间选择方式。
如果***不需要一个交互式的会话过程，则***者可以通过简单设置TCP/IP数据包的PUSH堆栈来实现时间选择。TCP/IP堆栈一般不会立即将收到的大块数据送给应用程序处理。绝大多数时候，这样将造成应用程序花费比较高的系统中断调用和内容交换的代价来提高对小数据包的处理能力，堆栈将所有数据放在一个缓冲区中，当缓冲区满了以后，堆栈才将堆栈中所有的数据一次性提交给应用层的程序。在上面的例子中，所有的51字节的数据全部收到以后才会被一次性提交给应用层。
某些应用程序希望尽可能快的获得数据，因此这些程序将会付出额外的开销以便尽可能获得较高的处理速度。PUSH标志的设置实际上是通知TCP/IP堆栈收到数据以后，立即提交给应用层。但是如果你需要获得一个目录列表，就不能采用这种设置PUSH标志位的方式，因为当数据被传递给应用程序以后，这个会话就立即终止了。你无法得到一个交互式的过程，不过若你只是想copy一个文件到web服务器路径下面，以便通过浏览器下载这个文件的话，你就可以采用这种方法，因为整个过程无需任何交互，你就可以完成你的操作。（比如复制SAM文件到Web路径下）。
如果你需要一个会话能够保持，以便你获得一个交互式的过程，本文将介绍一组技术来实现这一目标，这里的窍门就是让目标主机忽略RESET数据包。此时让IDS以为它已经终止了会话，实际上***者依然工作得很好。
首先的有利条件是所有的IDS在响应***时都有延迟时间，因为IDS从抓取数据包，监测***，产生RESET包，到最后发出RESET整个过程都要消耗一定的时间。很多的IDS使用libpcap库来抓包，大部分IDS构建在类BSD的系统上，BSD系统下是利用BPF（Berkeley Packet Filters）进行抓包，BPF默认将会开一个很大的缓冲区，在一个典型的网络中，IDS发出RESET包的过程大约会延迟半秒。在Linux和Solaris平台上，性能要稍微好一点，但是肯定也有延迟时间。
要使得IDS发送的RESET失效，我们必须能够保证一个会话中出现***特征以后，其后续的包比RESET包先到达目的主机。下面我们将通过TCP工作机制来简要介绍如何实现让目标主机忽略IDS的RESET数据包。
在TCP中，大家都知道有一个Window窗的概念。系统接受到的数据中，有的已经被提交给应用程序，有的则存储在缓冲区中，等待被提交给应用程序，同时系统中还留有一个空的空间以便接受新到达的数据。如下所示：

+---+--- ---+-+
　 已交给应用的数据 　 未处理的数据 　 空 区 　
+---+--+-+
^

当前指针(CP)

　<----窗体---->　

所有在缓冲区中的数据和空区就构成了TCP中的窗，只有在窗体中的数据才可执行send或者receive或者reset操作，在窗体之前的数据（也就是上面说得已经提交给应用层的数据）是被处理过的数据，窗体之后的数据将被忽略。如上图所示，TCP堆栈同时还用一个当前指针CP来定位目前的空区的起始位置。CP指针指向下一个要收到的数据包的起始位置，其值等于确认值。比如当前的堆栈获得了76字节的数据，则确认值为77。如果下一个数据包到达，则CP指针将会移动到下一个数据包的结束位置＋1的地方。
由于TCP中不一定所有的数据包都要按照顺序到达，因此，有可能后面的数据包比前面的数据包先到，比如从90字节开始的数据包可能比从77字节开始的数据包先到。所有到达的数据包都会进入缓冲区，不过CP指针将停留在77的位置直到从77字节开始的数据包到达，当从77字节开始的数据包到达以后，CP指针此时将会一次性的移动到所收的数据包末尾，如下图所示：
+---+--+ +--+---+
　 已交给应用的数据 　 未处理的数据 　 空 区 　先到的位置靠后的数据 　 空 区 　
+---+--+-+--+---+
^

当前指针(CP)

无序的数据包到达情况

　 已交给应用的数据 　 未处理的数据 　后到的位置靠前的数据　先到的位置靠后的数据 　 空 区 　

^
当前指针(CP)

数据包到达后CP指针一次性移动

在绝大数TCP实现中，RESET包必须与CP指针相符合，否则RESET包将会被抛弃。好了，一切彻底明朗了，只要我们能够构造一串连续的数据包，修改当前的CP。比如在上面我们的例子中，我们在第三个包之后构造第四个包，比如包含一个空格或者别的什么，只要不影响***的效果。我们以非常快的速度连续发出这两个包，则当IDS抓到第三个包的时候，它会产生RESET包，不过此时第四个包已经到达了目标主机，修改
了CP指针。当IDS发出的RESET包到达目标主机时，这个RESET包就被忽略了。（我们前面说过IDS都是有延迟的）。同时我们可以有一个更好的办法，我们在构造数据包的时候，先发送第四个数据包，再发送第3个数据包，则第四个数据包先到达，它进入到缓冲区中，不过此时的CP并没有改变，当第3个包到达时，CP将移动到第4个数据包之后，这样一来无论IDS产生的RESET能够以多快的速度发出，此RESET的确认序列总是
根据第3个包产生的，则它肯定被忽略。因为CP指针早就改变了。

三、结论
本文主要讲述了RESET包阻止TCP会话的IDS主动响应机制，至于防火墙联动的机制，我们其实可以通过欺骗，跳转（如FTP跳转等，请参看phrack 51）等方式，造成防火墙错误的拒绝某些重要的地址，比如网关路由的地址，DNS地址等等，这样也可以给使用者带来很大的干扰，同时一般来说防火墙联动机制会有1至2秒的延迟，这个时间完全够***者给目标主机安插一个后门，如此以来，什么样的防御都可能很轻松的突破了。通过本文的讲述，我们可以看到IDS提供了一种主动响应的机制，这比单纯的报警而没有响应好了很多，也很吸引用户，甚至这一点成了很多厂商的宣传武器，让很多消费者以为这时非常高超的技术，其实一个稍据TCP/IP知识的***者，就可以让这种响应机制失效