入侵检测规则基础知识
规则的基础知识
网络入侵检测系统规则是指我们在网络通讯中需要寻找的一种模式。为了让你对各种不同类型的规则有一个基本的概念，让我们来看一些可以用于鉴别的实例和方法。
从某一固定IP发送的连接请求。这可以通过IP头文件中的原地址区域很容易地鉴别出来。
带有非法TCP标记包的集合。这可以通过已知的合法与非法的标记集合与TCP头文件中的标记进行比较而得出结论。
包含特殊病毒的电子邮件。 IDS可以通过将邮件的标题或附件的名称与已知的病毒邮件相关的标题做比较得出结论。
包含在队列有效载荷中的DNS缓冲区溢出尝试。可以通过分析DNS域和检查每个队列的长度，从而使IDS能够辨别出在DNS域中是否存在缓冲区溢出的尝试。或者另外一种方式，就是在有效荷载队列中寻找是否存在溢出程序。
通过提交上千次相同命令来实施对ＰＯＰ３服务器的拒绝服务攻击。对付这种攻击的办法就是设定命令提交的次数，一旦超过设定的次数系统将会发出警报。
通过提交文件或目录试图跳过先前的登陆过程来对ＦＴＰ服务器进行文件存取攻击。可以开发一种跟踪系统，用来监控成功登陆的ＦＴＰ通讯，如果发现有人试图在经过系统认证前进入，则将发出警报。
正如你从上面所看到的，规则的范围非常广泛，从最简单的检查头文件到高度复杂的，例如真正跟踪连接状态或进行广泛的协议分析等。在本文中，我们将着眼于一些简单的规则，并讨论它们在开发中的复杂性。请注意，规则的能力在不同的ＩＤＳ中会有所变化，所以本文中所描述的技术可能在你使用的防火墙中未必适用。例如，一些网络ＩＤＳ产品提供给客户自己写规则或配置现有规则的能力很弱，而有一些产品几乎可以让你自定义所有现有的规则且将你能想到的所有规则定义进系统中。另外需要考虑的一个重要因素是一些ＩＤＳ产品只能检查特定的头文件有效载荷属性，而有些产品可以给出任何包中任何部分的数据。
规则为哪些功能服务
入侵检测规则的目的究竟何在呢？答案是，不同的规则其目的也不相同。我们所需要的结果就是当入侵发生时，系统发出警报。但让我们再想想，为什么我们需要自己定制或者修改规则呢？可能你看见网络上存在一些单一的通讯，而你希望在下次此类通讯出现时给出警报。你可能已经注意到，它具有特殊的头文件标志，你希望自己定义一个规则来匹配这种已知的标志；或许，你希望自己配置ＩＤＳ来检测那些不正常或可疑的通讯，而非光是检测攻击和探测。一些规则可以告诉你哪种特定的攻击正在进行，或攻击者试图尝试针对哪种漏洞的攻击，而另一些规则只是指出有不正常的行为存在，而非指出是特定的哪种攻击。前者势必花费更多时间和资源，但却能给你更多的信息，例如为什么你会被攻击或者攻击者的目的是什么。
头文件属性
我们已经快速讲述了规则的类型，接着让我们着眼于一个简单的规则特性：头文件属性。一些头文件属性很明显不正常，所以我们要在规则中制定很多选项。这一规则的经典例子是带有ＳＹＮ和ＦＩＮ标志的ＴＣＰ包设置。在ＲＦＣ７９３（用来定义ＴＣＰ标准）中存在一个漏洞，使得很多工具都试图通过这一漏洞来尝试绕过防火墙，路由器和入侵检测系统。很多攻击程序包括头文件属性其目的在于违背ＲＦＣｓ，因为很多操作系统和应用程序是基于遵守ＲＦＣｓ假定上写成的，且对在此基础上的通讯中的错误不进行纠正。也有很多工具包含错误或不完整的代码，于是由这些工具制成的包其中包含了违背ＲＦＣｓ的头文件属性。那些写得很糟糕的工具和各种入侵技术提供了用于写规则的可辨别属性。
这听上去不错，但请注意，并不是所有的操作系统和应用程序都是完全继承ＲＦＣｓ的。事实上，很多系统或程序都至少在一方面是违背ＲＦＣ的。所以，随着时间的流逝，协议可能被赋予不包含在ＲＦＣ中的新属性，然后新的标准出现了，将以前不合法的标准变为现在合法的。ＲＦＣ３１６８就是一个很好的例子。所以，ＩＤＳ的规则完全依赖于ＲＦＣ可能会导致很多积极的错误产生。当然，ＲＦＣ仍然在规则开发中占很重要的地位，因为很多恶意的攻击都是针对ＲＦＣｓ而来的。由于ＲＦＣ的升级和其他因素（这些我们将在以后讨论），所以需要阶段性地回顾和升级现有的规则。
虽然非法的头文件属性是规则的基础组成部分，合法但可疑的头文件属性也很重要。例如，对于连接可疑端口如３１３３７或２７３７４（这些经常是与木马有关的端口），若对这些连接发出警告，可以快速识别木马的行动。不幸的是，一些正常良性的通讯也可能使用相同的端口。如果没有使用更详细的规则来定义通讯中的其他特征，你将很难确定通讯的真正属性。可疑但合法的属性，如一些端口号，最好与其他属性综合考虑。
识别可能的规则成分
基于头文件属性来开发规则的最好办法就是通过实例。Sｙｎｓｃａｎ是一种应用广泛的扫描和探测系统工具。在２００１年初的互连网上，它频繁活动，因为它的代码经常被用于制造Ｒａｍｅｎ蠕虫的第一阶段。这一活动提供了很好的实例，因为它的包中含有大量的可识别特征。这里有一些在蠕虫传播初期存在于Ｒａｍｅｎ蠕虫包中的ＩＰ和ＴＣＰ头文件属性。（请注意，我的ＩＤＳ被配置为默认取消未被请求的通讯，所以我只能看见每个尝试的最初的包）
１ 各种不同的源ＩＰ地址
２ ＴＣＰ源端口２１，目标端口２１
３ 服务类型为０
４ ＩＰ识别号３９４２６
５ ＳＹＮ和ＦＩＮ标记设置
６ 各种序列号码设置
７ 各种确认号码设置
８ ＴＣＰ ｗｉｎｄｏｗｓ大小为１０２８
现在我们知道了Synscan包的头文件含有哪些特征了，我们可以开始考虑怎么制定一个好的规则。让我们来找找那些非法的、不正常的、可疑的属性，在很多事件中，这些特征都有相对应的攻击者试图利用的漏洞或者对应于攻击者使用的一种特殊技术。虽然正常的包属性中经常包括对于一些通讯的限制，但这种限制并不能成为好的规则特征。例如，我们将协议中正常的ＩＰ协议属性定义为６，这样一来我们就只能查看ＴＣＰ包。但另外一些完全正常的特征，例如将服务类型设置为０，对于规则的开发是非常不利的。
Synscan包的某些不正常的特征可以使用以下规则识别：
１ 仅有ＳＹＮ和ＦＩＮ标记设置是恶意行为的明显标志。
２ 另一种特征是，这些包的确认号有各种不同的属性但ＡＣＫ标志未设置。如果没有设置ＡＣＫ标志的话，确认号码应该设为０。
３ 还有一种可疑的特征是，源端口和目标端口都被设为２１，这是一种不正常的ＦＴＰ服务器关联。如果这两者端口号相同，我们称之为反身。除了某些特殊的通讯（如特定的ＮｅｔＢＩＯＳ通讯），通常都不应该存在这样的情况。反身端口不违背ＴＣＰ标准，但在大多数的事件中是不正常的。在正常的ＦＴＰ通讯中，我们会看见一个高端口（大于１０２３）作为源端口，而目标端口为２１。
这样，我们就找出了三条可以用来制定规则的特征：ＳＹＮ和ＦＩＮ标记设置，确认号码不为０且没有设置ＡＣＫ标记，以及反身端口设置为２１。这里还有两点需要注意：ＴＣＰ ｗｉｎｄｏｗｓ大小经常设为１０２８，ＩＰ识别号设置所有的包为３９４２６。通常，我们所预期的ＴＣＰ ｗｉｎｄｏｗｓ大小要大于１０２８，虽然这一值并不是很不正常，但也应该引起注意。同样，ＩＰ ＲＦＣ定义ＩＰ识别号在不同的包中应该具有不同的值，所以固定的值是非常值得怀疑的。
选择一种规则
由于我们已经找到了五种可以成为规则的元素，所以我们有了很多不同的选项来开发基于头文件的规则，而一个好的规则应该包括超过一个的特征。如果只想设置最简单的规则，那么可以用包的SYN和FIN标记来设置。虽然这是一种对恶性行为比较好的识别办法，但无法给出为什么这种行为会发生。请记住，ＳＹＮ和ＦＩＮ通常用来绕过防火墙和其他设备，所以他们可以起到扫描器的作用，信息收集或攻击的实施。所以，一个仅有ＳＹＮ和ＦＩＮ的规则对于我们的目的来说实在是太简单了。
然而，如果一条规则中包括了以上所有五条可疑特征，虽然可以提供更详细的信息，但相对于仅检测一条属性的规则来说，实用性还是差很多。规则开发总是在实用性和精确性两者之间权衡。在很多事件中，较简单的规则比复杂的更容易识别积极错误，因为较简单的规则一般来说适合总体概念。而复杂的规则比简单的规则更容易识别被动的错误，因为一些工具和算法的特征会随着时间的推移而改变。
我们假设，一条规则的目的在于确定使用的是哪种工具。除了ＳＹＮ和ＦＩＮ标记以外，还有哪些属性是最适合的？让我们来看看，反身端口非常可疑，但由于很多工具都具有这种特征甚至连一些合法的通讯也会存在这种特征，所以它无法提供足够详细的资料来制定规则。ＡＣＫ值设置但没有ＡＣＫ标记，这一点很明显是非法的，它可以和ＳＹＮ，ＦＩＮ一起用来制定规则。Wｉｎｄｏｗｓ的１０２８尺寸，有一点可疑但也可以算在正常范围内。而ＩＰ识别号３９４２６呢？我们可以通过将以上属性结合，开发不同的几种规则。但仍然无法确定哪种是最好的，因为最好的规则是应该随着时间和环境的变化随时调整的。
小结
在下一期中，我们会确定在SYNSCAN规则中使用哪些属性，以及估量规则对于更多的SYNSCAN通讯的有效性。我们将进一步研究总体规则相对于具体规则的优点。我们也将继续着重于讨论ＩＰ协议头文件属性在规则开发中所扮演的角色。
