几乎所有当前市场上的网络入侵检测系统都是基于一种被动数据收集方式的协议分析，我们可以预见，这种方式在本质上是有缺陷的。
毫无疑问，这样的入侵检测系统会监视整个网络环境中的数据流量，并且总是与一种预定义的可疑行为模式来进行对照，甚至所谓的入侵行为分析技术也只是简单地从单位时间状态事件技术上做了些组合工作，事实上离真正实用的复杂黑客入侵行为的剖析和理解还有很远的距离。
对于这种检测技术的可靠性，我们可以通过自定义的三种可行性很强的攻击方式来验证——插入攻击、逃避攻击和拒绝服务攻击。我们可以看到，当一个入侵者实施了这样的入侵策略以后，所谓的入侵检测系统便妥协了。我们的结论是这种入侵检测系统不是放之四海而皆准的，除非它们从根本上被重新设计过。
真正实用的入侵检测系统的存在价值就是能够察觉黑客的入侵行为并且进行记录和处理，当然，人们也会根据自己的需求提出需要强大的日志记录策略、黑客入侵诱导等等。
不同的入侵检测系统存在不同的入侵分析特征。一个企图检测Web入侵的系统可能只会考虑那些常见的恶意HTTP协议请求；同样道理，一个监视动态路由协议的系统可能只会考虑网络是否存在RIP欺骗攻击等等。目前国内市场上的大部分入侵检测系统使用同一个入侵行为定义库，如著名的SNORT特征库，这说明我们在技术挖掘方面的投入还不够，事实上我国在基础研究设施的投入上也存在严重不足。
入侵检测系统现在已经成为重要的安全组件，它有效地补充和完善了其他安全技术和手段，如近乎快过时的基于协议和端口的_blank">防火墙。入侵检测系统为管理人员提供相应的警告信息、报告可能发生的潜在攻击，从而抵挡了大部分“只是对系统设计好奇”的普通入侵者。
世界上已经开发出了很多种入侵检测系统，我们可以用通用的入侵检测体系结构（CIDF:Common Intrusion Detection Framework）来定义常见的入侵检测系统的功能组件。这些功能组件通常包括事件产生器、分析引擎、存储机制、攻击事件对策。
许多入侵检测系统在设计之时就仅仅被考虑作为警报器。好在多数商业化的入侵检测系统配置了可用的防御性反攻击模块，起码可以切断TCP连接或动态地更改互动_blank">防火墙过滤规则。这样就可以阻止黑客沿着同一路径继续他的攻击行为。一些入侵检测系统还配置了很好的攻击诱骗模块，可以为系统提供进一步的防护，也为进一步深入研究黑客行为提供了依据。
对于比较普遍的两种入侵检测模式--基于网络的入侵检测和基于主机的入侵检测，我们可以这样考虑：基于主机的入侵检测系统对于特定主机给予了定制性的保护，对于发生在本地的、用户级的、特征性比较明显的入侵行为有防范作用。但是，这种模式对于发生在网络传输层的入侵通常是无可奈何的，想让应用级特征比较强的系统同时把系统级和网络底层技术实现得比较完善是不太现实的。虽然我们可以看到在伟大的Linux系统上实现了Lids，毕竟象Solaris，NT这样的系统，我们能够了解的只是皮毛。
基于网络的入侵检测系统需要监视整个网络的流量，匹配可疑行为特征。它的技术实现通常必须从网络和系统的底层入手，而且它同时保护的是网络上的一批主机，无论它们使用的什么系统。基于网络的入侵检测系统显然不会关心某一台主机之上正在进行着什么操作，只要这些操作数据不会扩散到网络上来。因为网络入侵检测系统是以行为模式匹配为基础的，我们可以断定它有匹配失误的可能，有因为不能确定某种行为是入侵而将其放行的可能。那么当一个“聪明”的入侵者骗过了这种系统，顺利地进入一台主机，该系统的厄运开始了。
被动的网络监视器通常利用网络的混杂模式工作，它们直接从网络媒介获得网络中数据包的拷贝，而不考虑这些包本来是不应该被它们接收的。当然，这种被动的网络底层协议分析总是“安静地”存在于网络的某个地方，它只是根据网络媒介提供的这种特征，在其他主机不知不觉的时候将网络数据拷贝一份。同时，需要考虑到，根据引擎端实现平台的不同，各平台实现的网络数据包捕获机制的不同，在混杂模式下丢包的程度是不同的。事实上，对于大多数还需要从内核读取数据的应用级包过滤系统，只能考虑以更快的方式把数据读取到用户空间，进而发送给其它进程。 这样处理的化，要求从技术上增加用户空间的缓冲区尺寸，如在BSD(BPF)的系统上，能够利用BIOCSBLEN ioctl调用来增加缓冲区尺寸。
入侵检测系统地最重要的特征莫过于其检测的“精确性”。因此IDS要对捕获到的数据包进行详细的分析，所以对IDS的攻击就是针对IDS在分析数据时的弱点和漏洞。
网络IDS捕获到网络上传输的数据包并进行分析，以便知道一个对象对另一个对象做了什么。IDS总是通过网络上交换的数据包来对终端系统上发生的信息行为进行判断。假设一个带有错误UDP校验和的IP数据包，大多数操作系统会丢弃这样的数据。某些比较陈旧的系统也可能会接受。IDS需要了解每一个终端系统的具体情况，否则IDS按照自己的方式构造出来的逻辑在终端系统上的应用会有不同。某些操作系统有可能会接受一个明显存在问题的数据包，如允许一个有错误的校验和的IP包。当然，IDS如果不进行分辨，必然会丢掉这些本来终端系统会接受的数据。
就算IDS系统知道网络都有些什么操作系统，它也没有办法通过查看一个包而知道是否一个终端系统会接受这个包。原因很简单，CPU耗尽、内存不足都可能导致系统发生丢包现象。
IDS全部的信息来源就是它捕获到的数据包。但是，IDS应该多了解一些关于终端系统的网络行为，应该了解终端系统如何处理各种网络数据。但是，实际上，这是不可能的。
在处理所谓的拒绝服务攻击时，存在两种常见的情况：某些IDS系统在自己处于停机状态时，可以保持网络正常的信息流通，这种属于“fail-open”型；另一种则是“fail-closed”型，即当IDS系统出现问题时，整个网络也随之瘫痪了。
网络检测系统是被动的。它们不控制网络本身，也不会以任何方式维护网络的连接。如果一个IDS系统是fail-open的，入侵者通过各种手段使IDS资源不可用了，那时IDS就没有任何防范入侵的作用了。正是因为这样，IDS系统加强自身抗拒绝服务攻击的能力显得极为重要。
当然，许多攻击方式讨论的都是针对基于嗅探模式的IDS系统。这些类型的攻击都企图阻止协议分析，阻止特征模式匹配，阻止IDS获得足够信息以得出结论。
针对入侵检测系统弱点的攻击探讨
有时IDS系统会接受终端系统丢弃了的数据包。因为IDS认为终端系统接受并且处理了这些数据，而事实上终端系统由于种种原因丢弃了这些数据包。一个入侵者就可以利用这一点，制造那种他所想要入侵的主机会丢弃而IDS系统将接受并作出判断的数据包，以使IDS与终端系统得到不同的结论。
我们可以把这种攻击称为“插入式”攻击。道理很简单，假设一个入侵者发往终端系统的数据是attack，但是，他通过精心构造在数据流中加入了一个多余的t。对于终端系统而言，这个t是被丢掉不被处理的；而对于IDS系统而言，它得到的最终上下文关系是atttack，这个结论使IDS认为这次行为并没有对终端系统形成攻击而不作处理，事实上，终端系统已经接受了attack数据。
现在让我们来分析一下这种方式的攻击如何阻止特征分析。特征分析通常的方式是根据固定模式判断某个特定的字串是否被存在于一个数据流中，例如，对待一个phf的HTTP攻击，IDS通常检查这个字串的存在与否，“GET /cgi-bin/phf?”, IDS系统判断这种情况很容易，只需要简单的子串搜索功能便可以做到，然而，但是，如果一个入侵者通过插入式攻击的思想在这次HTTP请求中增加了这样的内容，GET /cgi-bin/pleasedontdetectthisforme?,里面同样包含了phf,但是在IDS看来，味道已经不一样了。
插入式攻击的的结果就是IDS系统与终端系统重组数据后得到了不一样的内容。通常，插入式攻击在IDS没有终端系统处理数据那么严格的时候都存在。可能好的解决方法就是让IDS系统在处理网络中需要重组的数据的时候，作出严格的判断和处理，尽可能地与终端系统处理地效果一个样。可是，引来了另外一个问题，这便是另一种攻击方式，相对地叫做“逃避式“攻击模式。
相对的，有些数据包是IDS不会接受的，而终端系统却会对这些数据作出处理。当然，IDS由于不接受某些包，而会导致与这些数据相关的上下文关系无法了解。
问题的现象是因为IDS在对数据包进行审核处理的时候过于严格，使得往往某些数据在终端系统而言，是要进行接受重组处理的，而在IDS本身，仅仅是不作处理，导致许多攻击在这种严格的分析引擎的鼻子地下躲过。
逃避式攻击和插入式攻击都有效地愚弄了模式匹配引擎系统。结果都是入侵者使得IDS与终端系统接受处理了不同的数据流，在逃避式攻击中，终端系统比IDS接受了更多的内容而遭受攻击。
还是上面的phf的例子，入侵者发送了一个HTTP请求，使得原本的GET /cgi-bin/phf？在IDS处理的结论中变成了GET /gin/f，当然，这个结论对于大多数IDS系统来说，几乎没有任何意义。
从技术上来看, 插入式和逃避式这两种对付检测系统的方式也不是这容易就被入侵者所利用，因为实现这种攻击要求入侵具备相当的知识面和实践能力。
现在的许多网络协议是简单的并且容易分析的。比如一个普通的网络分析器就能够容易的判断一个UDP DNS请求的目的。
其它的一些协议则复杂的多，在得出实际传输的内容之前，需要对许多单个的数据包进行考虑。这样的话，网络监视器必须总是监视内容的数据流，跟踪包含在数据流中的信息。例如，为了解析出一个TCP连接中发生了什么，必须重组这次连接中的整个数据流。
象TCP这样的协议，允许在IP最大包尺寸范围内的任意大小的数据被包含于每一个分散的数据包中，数据可以无序地到达目的地，每个数据包都具有一个序列号来表明自己在数据流中的位置。TCP数据流的接受者有责任重新按照序列号进行数据包的重新排序和组合，并解析出数据发送者的意思。这有一套TCP的数据重组机制来完成。
在IP层，IP也定义了一种自己的机制，叫做“碎片“，这种机制允许主机把一个数据包切分为更小的数据分片。每一个片都有一个标记，标记自己原来属于原始数据包的什么相对位置，叫做”偏移值“。IP实现允许接受这样的IP碎片包，并且根据偏移值来重组原始数据包。
插入式攻击通过增加一些数据包到数据流中导致终端系统重组很困难。被插入的数据包能够改变数据流的先后顺序，进而阻止IDS正确地处理紧跟着的正确的数据包。包的插入重叠了老的数据，在IDS系统上重写了数据流。某些情况下，插入数据包，改变了数据流原来的意思。
逃避式攻击则是导致IDS系统在进行流重组的时候错过了其中的部分关键内容，被IDS忽略的数据包可能对于数据流的顺序来说是至关重要的；IDS系统可能在逃避式攻击之后不知道该如何对这些数据下结论了。许多情况下，入侵者产生整个躲避IDS系统检测的数据流是相对简单的。
插入式和逃避式IDS攻击都不是很容易防范的，除非IDS通过了第二信息源的配合，能够对当前监视的网络拓扑结构以及对作为被监视对象的终端系统所能够接收什么样的数据包进行跟踪分析，否则问题依然存在，这是目前必须要提出来的对被检测网络的诠释技术，尽可能通过配合第二信息源的方式，让IDS对它所检测的网络中的终端系统以及网络实际环境有一个成熟的了解.
如果一个攻击能够造成实现插入任意的IP数据包，那么，插入一个UDP或者ICMP也是没有问题的。所以可以看出IDS系统在IP层实现对这两种入侵手段的免疫将是很重要的。
一个最容易的让终端系统丢弃IP数据包的方式是让数据包具有不正确的IP头部信息。如RFC731定义。入侵者所使用的这些头部信息有问题的数据包在现实中可能会遇到问题，除非攻击对象IDS系统处在同一个局域网之内，例如如果version域不是4，而是其他的值，这种数据包实际上是不会被路由的。当然，对于其他的一些域值，比如IP包长度或者IP头长度，一个不规范的长度将阻止IDS系统正确定位IP中的传输层的位置等。
在IP头域信息中，最容易被忽略的是校验值。似乎对于一个IDS系统去校验每一个捕获的IP数据包的校验是没有必要的。然而，一个带有病态的校验值的数据报对于大多数IP实现来说都是不会被处理的。一个IDS系统在设计的时候考虑到有问题的校验了么？如果没有考虑到校验的必要性，那么很难避免“插入式“攻击。
TTL域表示了一个数据包在到达目的系统的过程中需要经过多少路由器。每一次，一个路由器转发一个数据包，数据包所带的TTL信息将会被消耗。TTL消耗尽时，包也被丢弃了。所以，入侵者可以构建一个TTL的值，使得发送的数据包刚好可以到达IDS系统，但是TTL刚好耗尽了，数据本来应该到达的目标却没有到。
相类似的另一个问题与IP头部的DF标志有关。DF标志置位使得转发设备即便是在包超出标准大小尺寸的时候也不要对数据进行IP分片，紧紧通知简单的丢弃掉这些包。
这两个不明确的问题的解决要求IDS系统能够了解它所监视的网络拓扑结构。
IP校验和问题很好解决；一个IDS系统可以假设如果校验和是错误的，那么数据包将会被目标系统所不接受。而IP的选项域的存在又导致一些不同的可能性。
许多操作系统可以配置为自动拒绝源路由数据包。除非IDS了解是否一个源路由数据包的目标主机拒绝这样的数据包，否则不可能正确处理这样情况。
对IP数据包中的源路由项进行检查或许是一个明显的必要。然而，其他的一些选项也是必须应该考虑的。例如，“timestamp“选项要求特定的数据包的接受者在数据包里放置一个时间戳标记。如果这个选项出现问题，处理事件戳选项的代码将强迫丢弃这个包。如果IDS没有如同终端系统那样核实时间戳选项的话，便存在问题。
同一个LAN上的入侵者能够指引链路层的数据帧到IDS系统，不必允许作为IP目标的主机看到这个包。如果一个入侵者知道了IDS的MAC地址，他便能将他的欺骗包发往IDS系统，LAN上的其他系统不会处理这个数据包，但是，如果IDS不检查接受到的数据包的MAC地址，它是不会知道发生了什么情况的。
逃避式攻击则是导致IDS系统在进行流重组的时候错过了其中的部分关键内容，被IDS忽略的数据包可能对于数据流的顺序来说是至关重要的；IDS系统可能在逃避式攻击之后不知道该如何对这些数据下结论了。许多情况下，入侵者产生整个躲避IDS系统检测的数据流是相对简单的。
因为终端系统将重组IP碎片，所以IDS系统能够进行IP碎片重组也是重要的。一个不能正确的重组碎片的IDS系统将是容易受到攻击的，入侵者仅仅通过人工生产碎片的攻击方式便可以愚弄IDS。IP碎片的数据流通常有序到达。但是，协议允许碎片以任何次序到达。一个终端系统必须能够重组无序到达的数据包分片。
一个IDS系统如果不能处理IP碎片无序到达这种情况的话，也是存在问题的；一个入侵者能够故意捣乱他的碎片来逃避IDS检测。而且IDS必须在全部的碎片都被接收到以后才进行碎片重组。当然了，接收到的分片必须被存储下来，直到分片流可以被重组为一个完整的IP数据包。如果一个入侵者利用分片的形式来对网络进行flooding攻击，那么IDS系统通常会资源耗尽。每个终端系统也必须处理这个问题。许多系统根据TTL来丢弃分片，而避免这种由于大量碎片请求造成的内存不足。
许多入侵者能够刻意地通过构造病态的IP分片躲避传统的包过滤器，他们使用的是尽可能小的分片包，因为单个的分片所包含的数据不足以达到过滤规则对应的匹配长度。
另外，出现的问题是重叠的分片处理问题，可能性是这样的，具有不同尺寸的分片先后到达系统，并且分片的数据位置处于重叠状态，既是说，如果一个分片迟于另外一个分片达到系统，两个分片对于重组参数来说是同一个，这时新到的数据可能会覆盖掉已经先到达的老的一些数据。
这便又提出了一个问题，如果一个IDS系统没有能够以它所监视和保护的终端系统处理分片的方式处理分片包的话，可能面对同一个数据分片流，IDS系统将重组出与终端系统得到的玩全不同的数据包。一个了解这种IDS与终端系统之间矛盾的入侵者可能会采用这种入侵方式。
对于重叠分片的取舍是更加复杂的，对于这些有冲突的分片数据是否被采纳往往取决于他们所在的位置，而根据不同的操作系统对IP碎片重叠情况的不同处理也不一样。有些情况，新的数据被承认而有的时候则是旧的数据被承认，系统选择丢弃新的数据。当然，IDS不能正确分析这种情况，将面临“逃脱式”攻击。
就此问题而言，终端系统的IP驱动程序同样会有问题。或许正是因为IP碎片重组的困难和复杂性才使得出现了那么多不正确的处理方式。所以，除非一个IDS系统准确的知道它所监视的系统都是以何种方式来实现IP驱动的，否则要想精确地重组得到每一个终端系统都接受的数据是不可能的。
例如：Windows NT在处理重叠分片时，总是保留最先到达系统并且被接受的数据包。这与BSD4.4刚好相反。
IP包的选项域是应该被考虑到的。当一个IP包被分片时，来自于原始数据包的选项域信息是否应该被携带到全部的分片中去。RFC791声明某些IP选项如（security）将出现在每一个分片里，而其他的一些必须只出现在第一个分片中。
对于严格的IP实现将丢弃那些具有不正确选项的分片。但是事实上许多系统不是这样处理的。如果IDS没能象终端系统那样精确的处理这种情况的话，将也会面临前面提到的两类攻击。
在面向连接的协议中，象TCP这样的连接协议使用了序列号机制，这种机制提供了一种确认方法。可是，对于无连接协议，这种相对严格的确认机制却是没有的；可以看到，一个入侵DNS的破坏者其实可以是来自任何地方，因为就目前的Ipv4协议，可以简单就伪造出源通讯地址。看来，IDS系统的管理者对于IDS系统给出的网络地址的准确性是应该仔细考虑的。
事实上，被IDS检测到的大部分攻击是通过TCP连接的。所以，IDS对TCP会话数据流的重组能力成为关键问题。但是，到目前为止，我们可以肯定，IDS的这种数据重组能力应该与终端系统重组数据包的方式相一致。对于正常的TCP连接，就像一次由远程登录发起的连接，这很容易做到的。
IDS系统为了能够重建TCP连接会话的信息，TCP片段使用的序列号信息是必须知道的。我们可以把这种IDS去判断当前连接的可用序列号的过程叫“同步”。当然，在判断序列号时出现问题，可以叫“失去同步”。
当IDS系统在一次TCP连接中失去序列号同步了，就不能够对这次连接的信息数据进行有效的跟踪和重组了。在许多情况下，IDS系统由此不能够再接着处理这一次连接中的任何数据信息。所以，入侵者通常把让IDS系统“失去同步”作为一个主要攻击目标。
TCP标准定义了一个流控制机制，用来阻止建立连接的一方发送过多的数据到连接的另外一方；IDS追踪TCP连接的每一方的window域的值。TCP也允许数据流中发送所谓的OOB数据（带外数据），它利用了定义的紧急指针选项。
对于网络中的终端系统，与之相关的每次连接的状态信息的收集处理是没有问题的，每种TCP实现必须管理自己的TCB——TCP会话控制块，以便理解那一次建立的连接情况。一个网络IDS系统也必须能够维护它所监视的每一次连接对应的TCB。
任何网络IDS系统都定义了针对所探测到的新的TCP连接而产生TCB的机制，同时也对那些不再有关的连接进行释放和消除工作。
在讨论IDS的TCP问题中，我们独立地分析三个方面，可以看到，在IDS处理这三种情况时可能出现问题。首先是TCB产生，通过它，IDS决定对一个新探测到的TCP连接产生TCB；其次是数据流重组，IDS根据它所维护地TCB信息对数据流进行重组，当然这一步受到上一步地关联；再者是TCB拆卸，IDS通过它撤销一个TCB。
通过分析可以看到，“插入式”攻击的实现将影响到以上提到的几个方面，插入式攻击使得IDS系统分不清到底什么数据事实上到达了终端系统。比如在数据流重组上下文关系中，数据插入式攻击使得一次可靠的TCP会话监视几乎成为不可能的事；所以说IDS能够针对插入式攻击做处理是非常重要的也是很难实现的。
对于IP协议，可以有几种不同的方法可以实现往IDS系统中插入数据包，而对于TCP，问题会复杂一些，但是同样有一些手段能够导致IDS去主动丢弃某些特定的数据包，以达到入侵者的目的，无论如何，如果一个IDS系统不能够以它所监视的终端相同的方式来处理TCP包的话，对待”插入式“将受到威胁。
在一次TCP交互中，如果接收方对应回应了一个信息，那么一个TCP片段就是被认可的，我们进一步可能分析回应的是RST信息还是ACK信息。IDS能够通过对这些认可信息的辨识判断一个片段是否是存在问题的
包含在TCP包里面的数据能够被提取出来进行重组，而不去考虑TCP的头域的某些部分。
这种不严格的处理方式使得 “插入式“攻击手段得以成功，所以，在处理TCP数据的时候，先严格考虑TCP头域的信息可用性显得很重要了。
一个极易被忽略的头域是“CODE“，这个头域决定了TCP片段中发送的信息的类型。这个域是一系列二进制标志位。可以看到，某些标志位的组合是不正常的，通常在网络中导致包被丢弃掉。另外，许多TCP实现就不去接收没有ACK位被设置的TCP片段中的数据信息。
根据TCP的标准定义，TCP应该接受包含在SYN类型片段中的数据信息。而对这种定义的理解却变成了多种味道，导致一些TCP实现没有正确地处理这类信息。如果一个IDS系统没能考虑SYN数据，那么一个随便的“逃避式”攻击就可以对它进行威胁；反之，如果这个IDS系统能够很好地考虑SYN数据了，在针对某些没有正确实现这种定义的终端系统的时候，它显得当不住入侵者刻画的“插入式”攻击。
另外，经常被忽略的TCP输入处理问题是校验和，全部的TCP实现被强制性地要求验证网络校验，许多IDS系统不能做这种检查；所以通过构建有错误校验值的TCP片段就可以简单地插入数据包到IDS系统。
就像处理IP的选项域一样，IDS能够正确的处理TCP的选项域也是十分重要的。可是不幸的是，由于TCP的选项域某些内容被产生和利用的时间还比较短，如timestamp、windows scale这些选项；另外对于何时TCP的选项能够出现在连接的上下文中，TCP标准有专门的规定。某些选项在某些连接状态或许就是不可用或者是非法的。
RFC1323[13]中介绍了两个TCP的选项，这两个选项被设计来增加TCP在高速环境下的可靠性和性能。但是规定这些选项仅仅可以出现在非SYN的分段之中。
因为某些TCP实现会拒绝包含了这些没有见过的选项的非SYN片段，所以IDS也不可盲目的都接受这些有选项的数据包。另外，也有一些终端系统通过忽略这些选项，继续处理这些数据包；所以，可见IDS必须清楚地知道终端系统是如何处理各种数据包的，才能以相对于特定的终端系统正确的处理方式来进行处理而避免如插入和逃避式攻击。
RFC1323 定义了的另外一个叫做PAWS的概念，全称是“protection against wrapped sequence numbers”。使用PAWS的系统将会跟踪分段中的timestamps选项；根据分段中的timestamps响应值判断数据包是否被丢弃，一个入侵者可以很简单的产生一个人工的timestamp值，目的是使得支持PAWS的TCP堆栈不用作出进一步的处理就丢弃这个数据包。
IDS不仅仅需要知道是否终端系统支持PAWS，而且还需要知道终端系统对于timestamps的threshold的值是什么。如果没有这些信息，IDS将会错误地处理不正确地TCP片段，或者对一个片段的合法性作出错误的猜测。
如前面提到的三点，一个IDS系统TCB创造策略决定了IDS如何开始记录一次给定的TCP连接的数据信息，比如象序列号等。这使得IDS可以同步一次需要监视的TCP会话。
然而TCB创造是个麻烦的问题。可以用多种方法可以被利用来判断何时打开一个TCB，但是，这些方法中的每一个似乎证明都是有问题的。TCB创造建立一次连接的初始化状态，包括了连接序列号等信息；通过对IDS的TCB的欺骗行为，入侵者能够破坏那些与这一次被利用的连接具有相同连接参数的将来产生的连接。
作为一个概念，TCB创造对TCP的三次握手是重要的，它其实是一种在主动客户端和被动服务端之间的TCP包的交流。三次握手建立某次连接的初始序列号，还要同时考虑其它的重要的连接参数，如时间戳参数。
通常，在终端系统的TCP实现上，除非三次握手成功，否则TCB建立不起来，也没有必要考虑那么多。没有三次握手，交互的两端没有双方承认的用于继续交换数据的序列号，数据交流是建立不起来的。
但是，在IDS系统中就存在不一样的地方了。IDS或许仅仅通过包含在SYN包中的序列号来判断序列号，或者也可以完全依赖于三次握手给出的信息。当然，如果可能的话，其他方法也可以利用。通常，IDS没有必要在打开一个TCB之前等待完整的TCP三次握手。我们企图概括出一些直接的IDS建立需要的TCB的机制，在一些典型的IDS系统中可以看到。
首先，IDS的设计人员必须作出的决定是是否他的IDS要依赖于完整的三次握手来建立起TCB初始化。一个依赖于三次握手的IDS系统不会记录那些它没有检测到握手信息的数据包的数据。
这有几个较明显的不足，事实上IDS将错失那些它没有发现三次握手的TCP连接。IDS将仅仅能够看到它准备好监视以后产生的连接信息，同样，上面谈到的“逃脱式“攻击将发挥作用，入侵者只要能够让IDS不能发现三次握手就可以绕过IDS检测而入侵终端系统。
为了能够正确的处理TCP的一些扩展特征，例如PAWS，IDS系统必须分析三次握手，三次握手决定了是否某些TCP选项在连接中是合法的。否则，对于IDS要保护某些操作系统如BSD，将会受到“插入式”攻击的威胁。
对于这种要求具备完整的三次握手信息的IDS系统，除非它检测到了并且接受了全部的用于握手的三个数据包，否则它不记录连接数据。当然，我们知道，这三个包当中，有两个来自主动客户端，仅仅有一个来自被动的服务器端，故而，对于对服务器的攻击，攻击的主动权掌握在入侵者手里。使用TCP的术语来说就是，IDS系统直到真正的连接进入了ESTABLISHED状态以后，才开始对连接数据进行记录。
如前所述，由于“逃脱式”入侵技术的存在，这类要求完全建立三次握手的IDS系统是受到威胁的，主要是因为被动造成的IDS丢弃数据包现象使得入侵者的入侵数据逃脱了IDS的监视而到达终端系统。
那种要求至少有部分三次握手信息产生的IDS系统也是需要检测到有某种握手信息后才开始对连接数据进行记录的。三次握手可以使得TCB具有足够的初始化信息，我们也将看到为了同步数据流而盲目地产生TCB而出现的问题，完全地三次握手也使得入侵者哄骗IDS产生失效地TCB的可能性减小了。
然后产生的问题是“三次握手的哪一个部分在IDS产生对应的TCB之前是需要被检测到的？”.一个IDS系统在检测到一个客户端初始连接请求的SYN包时，能够产生一个TCB，或者当IDS检测到服务器返回了一个SYN＋ACK时。在具有一个内外包过滤器作为屏障时，入侵者欺骗服务器的响应是困难的；因此对于一次连接的产生，服务器的SYN+ACK响应是更可靠些的。如果一个入侵者不能欺骗服务器响应，SYN+ACK也包含了正确的连接序列号，IDS将更准确地初始化TCB。
一个IDS系统唯一能够知道一次连接被欺骗的指示是客户端返回给服务器SYN+ACK数据包，这个ACK确认了服务器的初始序列号。如果一个IDS仅仅利用了部分握手信息打开TCB，那么入侵者可以哄骗它为不存在的连接打开TCB。
IDS并不是一个网络连接的积极参与者，通过完整的三次握手而打开TCB可以推断出一次连接的初始状态。当然，IDS完全可以不用考虑三次握手的数据包，对于正常的连接仅仅检测ACK的数据包就可以工作了。
对于一个IDS系统最困难的事应该是对一个TCP连接上被交换的数据流进行精确的重新组合了。当然对于不同的终端系统来说，这些都有精确的定义。
就像对IP碎片重叠的解决，许多操作系统的TCP重组代码中还存在许多不一致的地方，例如，WindowsNT系统往往通过承认重叠数据中老的数据来解决，而4.4BSD系统按照RFC的规定，通常通过承认重叠数据中新的数据来解决。当然，还是一样的，除非IDS系统知道它所监视的网络中的各个系统是如何来处理这些包含了冲突分段的数据流的，否则将不能正确的监视某些类型的终端系统。
这些问题对于大多数连接来说没有表现出些什么问题；正常连接中的大部分TCP分段是顺序地达到，并没有恶意地欺骗性地TCP分段被插入到指定地连接流中企图去捣乱IDS系统。然而，在真实地网络中，一个企图逃避IDS监视地入侵者能够使得IDS在监视TCP流的时候尽可能的困难，他们通常会利用现在协议的种种矛盾和限制来达到目的。
存在于IDS的TCP重组代码中问题可能会仅仅当IDS系统接受了某些病态序列的输入的时候才看得出来。大多数时间，IDS看起来都是正在正确的重组着TCP流的。
IDS系统TCB的拆卸策略决定了何时IDS系统停止记录一次连接的数据。TCB的拆卸是必需的，因为跟踪状态信息是很消耗资源的；一个IDS系统如果没有很好地释放TCB占用的资源的话，一个入侵者将会利用这个弱点轻易耗尽IDS资源，只需要作一些无意义的洪流攻击直到IDS不能再跟踪新的连接。
在TCP中，连接在收到明确的要求关闭请求后关闭。两个TCP的信息(RST和FIN)被明确地利用来中断一次连接。除了连接双方的意外中断以外，TCP连接仅仅通过这些信息来中断。TCP明确提出了这些方式，所以IDS利用这些信息来判断何时关闭一次TCB也是合乎逻辑的。
TCP提供了一种周期性交换信息的机制，用来确认连接的双方依然处于连接状态，但是并没有被普遍地利用，同时也需要付出太长的时间来知道一次处于睡眠状态的连接正在被使用。所以，IDS在处理这些没有被明确中断的连接时，也是容易收到洪流攻击的。
对于基于模式匹配的情况，必然要维护上下文的完整性和相关性，如果IDS系统被欺骗而关闭了一个依然处于连接状态的TCB，对于IDS来说，输入流突然中断。一个入侵者能够导致这种TCB不正常中断，而阻止TCB进一步跟踪他的行为，使得入侵者的进一步的攻击信号通过网络到达终端，而这一次连接的TCB已经失效了，模式匹配引擎已经接收不到入侵的进一步上下文关联信息。
另一方面, 对于一个事实上已经关闭的连接，IDS系统不能够成功地拆卸相对应的TCB的话，也是一个脆弱点；一旦端对端的TCP连接被正常关闭，连接参数就能够被重新利用于新的具有完全不同序列号的连接（技术实现上，系统必须等待一段时间才重用连接参数，但是并不是所有的系统都等待）。如果没有同步恢复技术的话，这将导致IDS对于整个连接都将不可分析。
对于IDS系统，判断何时停止跟踪一次连接的一个可能的方式是：监听TCP的表示连接正在被关闭的控制信息。这样做允许一个IDS系统很快恢复那些用于事实上已经中断了的连接的资源，同时也防止了新连接使用同样的连接参数引来的异步问题。不幸的是，因为某些连接中断请求信息可能被控制在入侵者手里，所以完全信任这些信息也是有风险的。
TCP提供了两个连接拆卸消息，第一个信息考虑“顺序的”连接拆卸，连接的两端承认连接的终止并且确信他们所传输的数据在连接关闭之前已经传输完毕。第二个信息是由于某些错误意外终止连接。
借助于FIN消息，TCP提供了顺序地拆卸连接的方法。一个发送FIN消息的系统表示它已经结束发送数据了，并且准备关闭这次连接。当FIN消息被确认了，连接的每一端发送一个消息来结束连接。
每一次连接直到连接的双方都发送一个FIN消息，并且彼此确认了对方的消息之后被关闭。一个入侵者必须构造看起来是从服务器发出的伪造数据包来欺骗这类FIN的连接关闭机制。
对于IDS系统，仅利用FIN消息来判断中断连接TCB是不足够的。TCP提供了一种方式，利用RST消息来通报连接的另一端连接已经关闭了。RST分段不被通过ACK消息验证；如何知道一个RST消息已经被终端系统接受，唯一的方法是观察是否终端系统继续在此连接上发送数据，而在IDS系统中，这样做的唯一的方法是在观察到一个RST消息之后等待连接超时；然而，这样做意味着一个IDS系统可能潜在地、错误地关闭一个处于睡眠状态的连接。
RST带来的问题由于终端系统的TCP实现bugs而显得更加严重。一个RST消息在技术上来讲，仅仅在具有正确的序列号信息才是可用的，具有错误的序列号的RST消息应该被忽略掉。但是，问题是并不是所有的操作系统都检查RST消息中的序列号信息。
利用TCP连接拆卸消息的另外一个方法是在连接变为睡眠状态一段极限时间规定为超时。这样将阻止IDS被错误的TCP拆卸消息所愚弄，同时也潜在地简单化了IDS的TCP代码。
当然，这也有代价——依赖于超时机制的TCB拆卸的系统是容易被欺骗的，某些攻击者，专门利用了IDS将因为超时而关闭一个TCB的弱点，刻意在一次连接中等待IDS超时。
目前针对IDS种种弱点刻意进行的攻击都不是容易防范的，除非IDS系统通过了第二信息源的配合，能够对当前监视的网络拓扑结构以及对作为被监视对象的终端系统所能够接收和处理什么样的数据包进行跟踪分析，否则问题依然存在
