杂谈入侵检测防御系统

时间：2022-12-04 08:42:33 其他范文收藏本文下载本文

以下是小编帮大家整理的杂谈入侵检测防御系统，本文共6篇，欢迎大家分享。

杂谈入侵检测防御系统

篇1：杂谈入侵检测防御系统

几乎所有当前市场上的网络入侵检测系统都是基于一种被动数据收集方式的协议分析，我们可以预见，这种方式在本质上是有缺陷的，

毫无疑问，这样的入侵检测系统会监视整个网络环境中的数据流量，并且总是与一种预定义的可疑行为模式来进行对照，甚至所谓的入侵行为分析技术也只是简单地从单位时间状态事件技术上做了些组合工作，事实上离真正实用的复杂入侵行为的剖析和理解还有很远的距离。

对于这种检测技术的可靠性，我们可以通过自定义的三种可行性很强的攻击方式来验证――插入攻击、逃避攻击和拒绝服务攻击。我们可以看到，当一个入侵者实施了这样的入侵策略以后，所谓的入侵检测系统便妥协了。我们的结论是这种入侵检测系统不是放之四海而皆准的，除非它们从根本上被重新设计过。

真正实用的入侵检测系统的存在价值就是能够察觉的入侵行为并且进行记录和处理，当然，人们也会根据自己的需求提出需要强大的日志记录策略、入侵诱导等等。

不同的入侵检测系统存在不同的入侵分析特征。一个企图检测Web入侵的系统可能只会考虑那些常见的恶意HTTP协议请求；同样道理，一个监视动态路由协议的系统可能只会考虑网络是否存在RIP欺骗攻击等等。目前国内市场上的大部分入侵检测系统使用同一个入侵行为定义库，如著名的SNORT特征库，这说明我们在技术挖掘方面的投入还不够，事实上我国在基础研究设施的投入上也存在严重不足。

入侵检测系统现在已经成为重要的安全组件，它有效地补充和完善了其他安全技术和手段，如近乎快过时的基于协议和端口的防火墙。入侵检测系统为管理人员提供相应的警告信息、报告可能发生的潜在攻击，从而抵挡了大部分“只是对系统设计好奇”的普通入侵者。

世界上已经开发出了很多种入侵检测系统，我们可以用通用的入侵检测体系结构（CIDF:Common Intrusion Detection Framework）来定义常见的入侵检测系统的功能组件。这些功能组件通常包括事件产生器、分析引擎、存储机制、攻击事件对策。

许多入侵检测系统在设计之时就仅仅被考虑作为警报器。好在多数商业化的入侵检测系统配置了可用的防御性反攻击模块，起码可以切断TCP连接或动态地更改互动防火墙过滤规则。这样就可以阻止沿着同一路径继续他的攻击行为。一些入侵检测系统还配置了很好的攻击诱骗模块，可以为系统提供进一步的防护，也为进一步深入研究行为提供了依据。

对于比较普遍的两种入侵检测模式--基于网络的入侵检测和基于主机的入侵检测，我们可以这样考虑：基于主机的入侵检测系统对于特定主机给予了定制性的保护，对于发生在本地的、用户级的、特征性比较明显的入侵行为有防范作用。但是，这种模式对于发生在网络传输层的入侵通常是无可奈何的，想让应用级特征比较强的系统同时把系统级和网络底层技术实现得比较完善是不太现实的。虽然我们可以看到在伟大的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地址，它是不会知道发生了什么情况的。

因为终端系统将重组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系统通过了第二信息源的配合，能够对当前监视的网络拓扑结构以及对作为被监视对象的终端系统所能够接收和处理什么样的数据包进行跟踪分析，否则问题依然存在

篇2：入侵防御系统ips介绍

侵入保护（阻止）系统（IPS）是新一代的侵入检测系统（IDS），可弥补IDS存在于前摄及假阳性/阴性等性质方面的弱点，IPS能够识别事件的侵入、关联、冲击、方向和适当的分析，然后将合适的信息和命令传送给防火墙、交换机和其它的网络设备以减轻该事件的风险。

IPS的关键技术成份包括所合并的全球和本地主机访问控制、IDS、全球和本地安全策略、风险管理软件和支持全球访问并用于管理IPS的控制台。如同IDS中一样，IPS中也需要降低假阳性或假阴性，它通常使用更为先进的侵入检测技术，如试探式扫描、内容检查、状态和行为分析，同时还结合常规的侵入检测技术如基于签名的检测和异常检测。

同侵入检测系统（IDS）一样，IPS系统分为基于主机和网络两种类型，

基于主机IPS

基于主机的IPS依靠在被保护的系统中所直接安装的代理。它与操作系统内核和服务紧密地捆绑在一起，监视并截取对内核或API的系统调用，以便达到阻止并记录攻击的作用。它也可以监视数据流和特定应用的环境（如网页服务器的文件位置和注册条目），以便能够保护该应用程序使之能够避免那些还不存在签名的、普通的攻击。

基于网络的IPS

基于网络的IPS综合了标准IDS的功能，IDS是IPS与防火墙的混合体，并可被称为嵌入式IDS或网关IDS（GIDS）。基于网络的IPS设备只能阻止通过该设备的恶意信息流。为了提高IPS设备的使用效率，必须采用强迫信息流通过该设备的方式。更为具体的来说，受保护的信息流必须代表着向联网计算机系统或从中发出的数据，且在其中：

指定的网络领域中，需要高度的安全和保护和/或

该网络领域中存在极可能发生的内部爆发

配置地址能够有效地将网络划分成最小的保护区域，并能够提供最大范围的有效覆盖率。

IPS：侵入保护（阻止）系统

篇3：入侵检测与入侵防御将长期共存

近日，“IDS/IPS应用与发展趋势”研讨会在京召开，业内很多安全专家及行业用户代表参加，从市场的实际应用出发，探讨IDS（入侵检测系统）与IPS（入侵防御系统）的产品价值和部署目标。

自从IPS面市之日起，围绕IPS和IDS之间关系的讨论就不断升温，成为安全业界的一大热点。一派认为“IPS将取代IDS”，一派认为“IDS会和IPS共存”，直至IDC年度安全市场报告明确指出IDS和IPS是两个独立的市场，这场讨论才趋于平淡。

来自中国人民银行的专家表示，从用户角度来讲，目前已经基本认同IDS和IPS是两类产品，并不存在IPS要替代IDS的可能，但在选择产品和具体部署时，有相当一部分的用户还是存在疑惑。“在实际应用中应如何选择和区分两类产品”成为广大用户关心的话题。

“IDS入侵检测系统注重全面检测、有效呈现；IPS则更擅长深层防御、精确阻断。”国内入侵检测领袖企业启明星辰这样描述IDS与IPS的区别，

从实际应用来说，IPS既非IDS的替代品，更非IDS的延伸者，而是术业有专攻，侧重不同的方面，是为了满足企业风险管理需求的两种不同解决方案。启明星辰从长时间的用户调查和实际应用状况中，总结出了IDS和IPS的应用条件。如果一个企业属于低风险的类别，他们往往只关注风险控制，不关注检测与监控，风险管理要求不高，选择IPS产品即可；高风险行业如金融、电信等，不仅关注风险控制，而且关注风险管理，这样的企业既需要IDS，也需要IPS；对于一些监管机构/部门来说，往往更关注风险管理的检测与监控，监督风险控制的改进状况，因此IDS是比较合适的产品。

启明星辰产品管理中心总工万卿说：“IDS和IPS将继续共存，这已经是一个不争的事实。这个观点是从客户的实际应用中得来的。启明星辰目前拥有完善的IDS和IPS产品线，将根据客户的不同需求，为客户设计不同的解决方案组合，达到风险管理和风险控制并举的目的。”

与会专家表示，由于各行业客户不同的应用环境和实际需求，IDS和IPS 在国内都呈现出繁荣发展的前景，因此二者之间的关系并非简单的升级和替代，长期来看，IDS和IPS将出现共同发展、和平共存的局面。

篇4：网络入侵检测系统实现

互联网也同时带给我们无数的宝贵资源，只等我们去开发、利用，开放源代码软件(Open Source Software)便是其中之一，免费可得的软件发布形式，使其具有广大的用户群;众多志愿者的协同开发模式使其具有卓越的兼容性;大量的网上社区弥补了缺少商业服务的不足。本文试图论述利

用互联网上免费可得的开放源代码软件实现一个完整的网络入侵检测系统的过程。

系统概述

本系统采用三层分布式体系结构：网络入侵探测器、入侵事件数据库和基于Web的分析控制台。为了避免不必要的网络流量，本例将网络入侵探测器和入侵事件数据库整合在一台主机中，用标准浏览器异地访问主机上的Web服务器作为分析控制台，两者之间的通信采用HTTPS安全加密协议传输。

由于实现本系统所需的软件较多，有必要在此进行简要的说明：

Snort

功能简述：网络入侵探测器;

正式网址：www.snort.org/

软件版本：1.8.6

Libpcap

功能简述：Snort所依赖的网络抓包库;

正式网址：www.tcpdump.org/

软件版本：0.7.1

MySQL

功能简述：入侵事件数据库;

正式网址：www.mysql.org/

软件版本：3.23.49

Apache

功能简述：Web服务器;

正式网址：www.apache.org/

软件版本：1.3.24

Mod_ssl

功能简述：为Apache提供SSL加密功能的模块;

正式网址：www.modssl.org/

软件版本：2.8.8

OpenSSL

功能简述：开放源代码的SSL加密库，为mod_ssl所依赖;

正式网址：www.openssl.org/

软件版本：0.9.6d

功能简述：为Apache的模块提供共享内存服务;

正式网址：www.engelschall.com/sw/mm/

软件版本：1.1.3

PHP

功能简述：ACID的实现语言;

正式网址：www.php.net/

软件版本：4.0.6

功能简述：被PHP用来即时生成PNG和JPG图像的库;

正式网址：www.boutell.com/gd/

软件版本：1.8.4

ACID

功能简述：基于Web的入侵事件数据库分析控制台;

正式网址：www.cert.org/kb/aircert/

软件版本：0.9.6b21

ADODB

功能简述：为ACID提供便捷的数据库接口;

正式网址：php.weblogs.com/ADODB

软件版本：2.00

PHPlot

功能简述：ACID所依赖的制图库;

正式网址：www.phplot.com/

软件版本：4.4.6

上述软件都是开源软件，可以直接登录相应软件的正式网站，下载源代码，

此外，需要特别说明的一点是虽然本例中网络入侵检测系统所采用的系统平台是Solaris 8 for Intel Platform，但是在其它种类的系统平台上，如Linux 、OpenBSD以及Windows 等，其具体的实现步骤大同小异，因此就不在另行说明了。

三、安装及配置

在正式进行软件安装之前，请检查系统，确保拥有符合ANSI标准的C/C++编译器等软件开发工具。

1、安装MySQL

首先，以超级用户的身份登录系统，创建mysql 用户和mysql用户组;

然后，以mysql身份登录，执行下列命令：

$gzip -d -c mysql-3.23.49.tar.gz | tar xvf -

$cd mysql-3.23.49

$./configure

$make

$make install

这样，就按照缺省配置将MySQL安装在/usr/local目录下。然后将源代码树中的缺省配置文件my.cnf拷贝到/etc目录下。接下来，以超级用户身份执行源码树中scripts目录下的可执行脚本文件mysql_install_db来创建初始数据库。用/etc/init.d/mysql.server命令启动数据库服务器后，使用/usr/local/bin/mysqladmin程序来改变数据库管理员的口令。

[1] [2] 下一页

篇5：建新手入门入侵检测系统

根据CIDF规范，我们从功能上将入侵检测系统划分为四个基本部分：数据采集子系统、数据分析子系统、控制台子系统、数据库管理子系统，

具体实现起来，一般都将数据采集子系统(又称探测器)和数据分析子系统在Linux或Unix平台上实现，我们称之为数据采集分析中心;将控制台子系统在Windows NT或2000上实现，数据库管理子系统基于Access或其他功能更强大的数据库，多跟控制台子系统结合在一起，我们称之为控制管理中心。本文以Linux和Windows NT平台为例介绍数据采集分析中心和控制管理中心的实现。

第一步获取Libpcap和Tcpdump

审计踪迹是IDS的数据来源，而数据采集机制是实现IDS的基础，否则，巧妇难为无米之炊，入侵检测就无从谈起。数据采集子系统位于IDS的最底层，其主要目的是从网络环境中获取事件，并向其他部分提供事件。目前比较流行的做法是：使用Libpcap和Tcpdump，将网卡置于“混杂”模式，捕获某个网段上所有的数据流。

Libpcap是Unix或Linux从内核捕获网络数据包的必备工具，它是独立于系统的API接口，为底层网络监控提供了一个可移植的框架，可用于网络统计收集、安全监控、网络调试等应用。

Tcpdump是用于网络监控的工具，可能是Unix上最著名的Sniffer了，它的实现基于Libpcap接口，通过应用布尔表达式打印数据包首部，具体执行过滤转换、包获取和包显示等功能。Tcpdump可以帮助我们描述系统的正常行为，并最终识别出那些不正常的行为，当然，它只是有益于收集关于某网段上的数据流(网络流类型、连接等)信息，至于分析网络活动是否正常，那是程序员和管理员所要做的工作。Libpcap和Tcpdump在网上广为流传，开发者可以到相关网站下载。

第二步构建并配置探测器，实现数据采集功能

1. 应根据自己网络的具体情况，选用合适的软件及硬件设备，如果你的网络数据流量很小，用一般的PC机安装Linux即可，如果所监控的网络流量非常大，则需要用一台性能较高的机器。

2. 在Linux服务器上开出一个日志分区，用于采集数据的存储。

3. 创建Libpcap库。从网上下载的通常都是Libpcap.tar.z的压缩包，所以，应先将其解压缩、解包，然后执行配置脚本，创建适合于自己系统环境的Makefile，再用Make命令创建Libpcap库。Libpcap安装完毕之后，将生成一个Libpcap库、三个include文件和一个Man页面(即用户手册)。

4. 创建Tcpdump。与创建Libpcap的过程一样，先将压缩包解压缩、解包到与Libpcap相同的父目录下，然后配置、安装Tcpdump。

如果配置、创建、安装等操作一切正常的话，到这里，系统已经能够收集到网络数据流了。至于如何使用Libpcap和Tcpdump，还需要参考相关的用户手册。

第三步建立数据分析模块

网上有一些开放源代码的数据分析软件包，这给我们构建数据分析模块提供了一定的便利条件，但这些“免费的午餐”一般都有很大的局限性，要开发一个真正功能强大、实用的IDS，通常都需要开发者自己动手动脑设计数据分析模块，而这往往也是整个IDS的工作重点。

数据分析模块相当于IDS的大脑，它必须具备高度的“智慧”和“判断能力”。所以，在设计此模块之前，开发者需要对各种网络协议、系统漏洞、攻击手法、可疑行为等有一个很清晰、深入的研究，然后制订相应的安全规则库和安全策略，再分别建立滥用检测模型和异常检测模型，让机器模拟自己的分析过程，识别确知特征的攻击和异常行为，最后将分析结果形成报警消息，发送给控制管理中心，

设计数据分析模块的工作量浩大，并且，考虑到“道高一尺，魔高一丈”的手法日益翻新，所以，这注定是一个没有终点的过程，需要不断地更新、升级、完善。在这里需要特别注意三个问题：

① 应优化检测模型和算法的设计，确保系统的执行效率;

② 安全规则的制订要充分考虑包容性和可扩展性，以提高系统的伸缩性;

③ 报警消息要遵循特定的标准格式，增强其共享与互操作能力，切忌随意制订消息格式的不规范做法。

第四步构建控制台子系统

控制台子系统负责向网络管理员汇报各种网络违规行为，并由管理员对一些恶意行为采取行动(如阻断、跟踪等)。由于Linux或Unix平台在支持界面操作方面远不如常用的Windows产品流行，所以，为了把IDS做成一个通用、易用的系统，笔者建议将控制台子系统在Windows系列平台上实现。

控制台子系统的主要任务有两个：

① 管理数据采集分析中心，以友好、便于查询的方式显示数据采集分析中心发送过来的警报消息;

② 根据安全策略进行一系列的响应动作，以阻止非法行为，确保网络的安全。

控制台子系统的设计重点是：警报信息查询、探测器管理、规则管理及用户管理。

1.警报信息查询：网络管理员可以使用单一条件或复合条件进行查询，当警报信息数量庞大、来源广泛的时候，系统需要对警报信息按照危险等级进行分类，从而突出显示网络管理员需要的最重要信息。

2.探测器管理：控制台可以一次管理多个探测器(包括启动、停止、配置、查看运行状态等)，查询各个网段的安全状况，针对不同情况制订相应的安全规则。

3.规则库管理功能：为用户提供一个根据不同网段具体情况灵活配置安全策略的工具，如一次定制可应用于多个探测器、默认安全规则等。

4.用户管理：对用户权限进行严格的定义，提供口令修改、添加用户、删除用户、用户权限配置等功能，有效保护系统使用的安全性。

第五步构建数据库管理子系统

一个好的入侵检测系统不仅仅应当为管理员提供实时、丰富的警报信息，还应详细地记录现场数据，以便于日后需要取证时重建某些网络事件。

数据库管理子系统的前端程序通常与控制台子系统集成在一起，用Access或其他数据库存储警报信息和其他数据。该模块的数据来源有两个：

① 数据分析子系统发来的报警信息及其他重要信息;

② 管理员经过条件查询后对查询结果处理所得的数据，如生成的本地文件、格式报表等。

第六步联调，一个基本的IDS搭建完毕

以上几步完成之后，一个IDS的最基本框架已被实现。但要使这个IDS顺利地运转起来，还需要保持各个部分之间安全、顺畅地通信和交互，这就是联调工作所要解决的问题。

首先，要实现数据采集分析中心和控制管理中心之间的通信，二者之间是双向的通信。控制管理中心显示、整理数据采集分析中心发送过来的分析结果及其他信息，数据采集分析中心接收控制管理中心发来的配置、管理等命令。注意确保这二者之间通信的安全性，最好对通信数据流进行加密操作，以防止被或篡改。同时，控制管理中心的控制台子系统和数据库子系统之间也有大量的交互操作，如警报信息查询、网络事件重建等。

联调通过之后，一个基本的IDS就搭建完毕。后面要做的就是不断完善各部分功能，尤其是提高系统的检测能力。

篇6：SNORT入侵检测系统2

10.安装 Snort2.4.4 10.1建立snort配置文件和日志目录 #mkdir /etc/snort #mkdir /var/log/snort #tar -zxvf snort-2.4.4.tar.gz #cd snort-2.4.4 #./configure --with-mysql=/usr/local/mysql

10.安装 Snort2.4.4

10.1建立snort配置文件和日志目录

#mkdir /etc/snort

#mkdir /var/log/snort

#tar -zxvf snort-2.4.4.tar.gz

#cd snort-2.4.4

#./configure --with-mysql=/usr/local/mysql

#make

#make install

注意，我在编译snort时出现“ERROR! Libpcre header not found, go get it from”的错误，这是因为少安装了一个lib的库，如果谁出现了这样的问题，就到ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ 下载最新的pcre库进行安装。

方法： #tar -zxvf pcre-6.7.tar.gz

#./configure

#make

#make check

#make install

10.2安装规则和配置文件

#cd /etc/snort/

#tar ?zxvf /ruanjian/snortrules-snapshot-2.4.tar.gz

#cd /etc/snort/rules (在snort安装目录下)

#cp *.conf /etc/snort/.

#cp *.config /etc/snort/.

#cp *.map /etc/snort/.