我谈入侵检测的方向 --转自水木 rilson (开心辞典) (推荐)
来源：互联网 发布：快递单打印软件破解 编辑：程序博客网 时间：2024/04/30 04:48
基本上是转自,我个人调了下顺序.
最近看了一些入侵检测的文章，对未来的研究方向有自己的一些想法：如下
1）传统入侵检测方法研究：包括主机检测和网络检测,包括融合异常检测和特征检测。
2）入侵特征库的整理以及新的入侵特征的发现。
3）分布式入侵检测研究：主要研究分布式攻击的检测办法
4）智能化的入侵检测：可以提出类似神经网络、免疫系统、专家系统的检测方法
5）应用层的入侵检测：研究应用层的抓包技术与检测算法
6）基于主机的入侵检测：针对不同日志如何进行检测，可以用到数据挖掘技术
7）高速网络的入侵检测：研究1000Mbps以太网情况下的入侵检测
8）入侵检测系统的标准化研究：可以建立新的检测模型，使不同的IDS产品可以协同工作
9）IDS自身系统的安全研究：可以采取一些安全的技术，如IP隐藏技术、认证、SSL的使用
10）研究如何使IDS与防病毒工具、防火墙、VPN等其他安全产品协同工作，形成一套安全网管体系
11）研究入侵检测系统的评估准则
以下是关于对入侵检测的讨论:
1.个人觉得这些东西许多都紧密联系。
例如对高速网络的入侵检测，我觉得在目前的条件下，还是使用分布式，使得大流量数据由众多的节点分摊，基于主机的和基于网络的入侵检测应该协调起来，共享数据。
因为对于重要主机服务器需要使用基于主机的入侵检测。
还有就是节点之间连动，一个检测节点检测到可能的攻击行为后应该把信息和其他节点分享，使整个系统对该种攻击（例如ip地址）具有预见性。
不过总的来说最重要的工作应该是在建立完整的特征库上面。
现在许多系统的检全率和检准率不高，我想没有一个很好的特征库，没有合理地分类是一个很大的原因。
2.分布式DIDS确实是未来的发展趋势，目前国内一些IDS产品如TL-DIDS就是采用
“分布探针－集中控制”的方式，探针可以负责一定的安全区域，这样可以解决
高速网络的问题。
另外，对于高速网络必须采用协议分析的方法，落后的模式匹配方法是不能
胜任的。对于节点的信息共享确实也是一个非常值得研究的领域。这方面AAFID做的比较早。
98年就已经开始设计了。不过他依然采用分散管理的模式，有待改进。
对于特征检测，特征库确实是个关键问题，由于攻击特征五花八门，新的攻击方法层出不穷，现在很难对攻击特征很好的分类，国外的标准组织的进展缓慢，CVE的特征库也比较乱。
3.不是的，
特征库就像是病毒库，
你的诺顿或者毒霸，都是必须经常更新的，
所以 建立维护一个权威的标准的库也是做IDS的一个重要方面，
当然不一定每一个作IDS的人都要做了。
我们中心想做一个这个东西，
主要标准就是全，准，细，新。
完整准确细致最新
4.最初的时候
我觉得规则检测，其实就是一种杀毒软件：）
但是我觉得，似乎这种依靠规则检测的方式
就需要对管理者，或者是软件开发商有较高的要求
如果我们的规则库没有进行升级
那么我们所依赖的检测也就没有任何安全性了
所以我觉得单纯的依靠规则检测，恐怕是不够安全的
不过，对于统一一个规则库
我不是很乐观
恐怕难以作到全，准
:P
个人看法
5.你说的很有道理。
所以才需要在全国，乃至全球方位内成立
cert,FIRST等组织啊。
目的实际上就是汇总各地的信息，共享信息。
入侵检测永远是防御的一方，它必然比攻击慢半拍。
所以只能减少损失，无法避免
:)
一家之言哦。呵呵
6.: 个人觉得这些东西许多都紧密联系。
: 例如对高速网络的入侵检测，我觉得在目前的条件下，还是对于高速网络，我们是从两个方面来解决：
1. 提高捕包效率，现在来说就是修改内核了，以及直接使用千兆网卡。
2. 使用集群的方法，一台不行就加一台，进行分流，降低节点机速度要求。
: 使用分布式，使得大流量数据由众多的节点分摊，
: 基于主机的合基于网络的入侵检测应该协调起来，共享数据。
: 因为对于重要主机服务器需要使用基于主机的入侵检测。
: 还有就是节点之间连动，一个检测节点检测到可能的攻击行为后
: 应该把信息和其他节点分享，使整个系统对该中攻击（例如ip地址）具有预见性。
: 不过总的来说最重要的工作应该是在建立完整的特征库上面。
: 现在许多系统的检全率和检准率不高，我想没有一个很好的特征库，
: 没有合理地分类是一个很大的原因。
HIDS与NIDS协调是必然的，因为他们各有优缺点，尤其在加密环境中NIDS显得
无从下手，HIDS弥补了这一点。
7.我觉得就目前的商用软件就是这样的
因为目前特征检测的技术是最可靠的
而且对于商用软件而言，这个技术也是比较的成熟
不过我觉得
特征检测的对于特征库的高要求是一个致命的难点
8.: 对于高速网络，我们是从两个方面来解决：
: 1. 提高捕包效率，现在来说就是修改内核了，以及直接使用千兆网卡。
直接使用网络处理器来处理高速流量, 修理现有的操作系统内河很难
达到 G 级别的处理水平.
: 2. 使用集群的方法，一台不行就加一台，进行分流，降低节点机速度要求。
: HIDS与NIDS协调是必然的，因为他们各有优缺点，尤其在加密环境中NIDS显得
: 无从下手，HIDS弥补了这一�
是个好主意, 但是集群之间的协调, 报文的重组等是很很大的问题.
9. 没错，说入侵检测总是处于防御的一方，我想主要是就Misuse ID而言吧，像AbnormalID
就可以建立一套正常行为的统计规律来防御未知的入侵，虽然这种防御方式也有其自身
的不足，比如统计规律不够精确，人为因素过重之类的，不过现在有一种将特征检测和
误用检测结合的所谓混和检测方法，但我始终对其最后的仲裁抱有怀疑态度，因为对同
一个事件进行两种检测必然设计最后的决策
10. 呵呵，我对CIDF的模型的最初理解就是把它当成一个特征检测的模型，不是吗？
不过商用软件中使用特征检测和误用检测都有吧，主要的使用可能还是特征检测。我
所知道的REALSECURE，Cybercop多数都使用的特征检测。
11.听说南京大学已经把入侵检测和硬件相互关连了
不知道有人知道详细情况嘛？
我觉得只有把检测的大部分工作交给
硬件，对付高速网络才有希望
似乎软件的瓶颈太厉害了
12.最后两种检测的决定比例
不知道如何算
反正我觉得二者单独使用都是没有什么
太大的安全系数的
未来的方向应该是多种合并检测
13.: 事实上真正高速的网络原始数据包的采集都是通过硬件实现的，软件只是实现一个
: 显示的作用，比如显示流量数据或者分析曲线，像上海的国际出口局的国际出口流量
: 采集都是通过硬件来实现的，因为软件在千兆之上的丢包率会很高。
高速网络数据的采集，的确应该是以硬件为主，但是就入侵检测的功能而言肯定要使用
软件来处理，如何在高速的硬件和低速的软件间建立有效的联系呢？我们的方案是使用
硬件进行分流，将大流量合理的分割成一定数量的软件平台能够承受的小流量，然后进
行处理，这种方案既保持了硬件的速度，能够处理高速网络，又具有软件的灵活，能够
快捷的进行模块升级，处理最新的安全事件。
14. 修改现有的操作系统的内核的确不是很容易，使用网络处理器的确是
一个比较好的办法。
我想可以在分流数据包的时候就做一些基本的判断来解决一些问题，
也就是说做Banlance的机器要比较"smart"一些，它知道什么数据包该给
后面的哪台机器，这样就能解决报文重组等问题了。比如我们可以按照协
议类型分类的测率进行Banlance，把TCP的数据发送到A，把UDP的数据发
宋到B，把ICMP的数据发送到C等等，当然还可以有其他的方式。
反正不管怎么说，比较重要的是先是些协议的解析，在解析过的协议
上做很多尽一步的处理都是比较方便，并且效率很高的。
至于协调什么的问题，可以交给一台控制器来做，它负责收集和整理
来自不同的sensor的信息，然后处理他们之间的相关性，同时把一些必要
的策略修改信息下发到需要的sensor上去，也就是说sensor之间不发生直
的信息交换，一切都通过manager来实现，这样就能够使系统结构简单一些。
15.: 修改现有的操作系统的内核的确不是很容易，使用网络处理器的确是
: 一个比较好的办法。
不知道你这儿是什么意思，修改OS内核在困难也比设计一个ASIC容易，
只不过能够提高的带宽有极限而已，但这实际上也受限于机器的体系结构，
比如总线速度，网卡效能。
: 我想可以在分流数据包的时候就做一些基本的判断来解决一些问题，
: 也就是说做Banlance的机器要比较"smart"一些，它知道什么数据包该给
: 后面的哪台机器，这样就能解决报文重组等问题了。比如我们可以按照协
: 议类型分类的测率进行Banlance，把TCP的数据发送到A，把UDP的数据发
: 宋到B，把ICMP的数据发送到C等等，当然还可以有其他的方式。
你举的这个平衡例子显然很不好，大家都知道TCP数据比UDP多很多，按
协议划分会很不均衡。当然这个问题可以由增加A类节点的数量来解决，但是
这又必然会引入相关或者要增加别的划分方案。
一般而言，可以有以下负载平衡方法：
1. 按IP段静态划分，这种方法比较简单，基本上就是起到在总体范围内分
流，降速的作用，但是不能处理流量在IP段之间的不均衡以及在时间上的变化。
2. 按IP静态划分，实现复杂一些，但是可以将即使是在同一网段的IP的流
量也均匀的分配到不同机器，可以在一定程度上解决1中的峰值问题。
3. 按连接的动态负载平衡，实现复杂，但是能够很好的进行负载平衡，而
且能够降低后端处理节点间的相关性，是分流器设计的最终形态。
我们进行过其中1的方案，现在正在进行其中3。
16: 不知道你这儿是什么意思，修改OS内核在困难也比设计一个ASIC容易，
: 只不过能够提高的带宽有极限而已，但这实际上也受限于机器的体系结构，
: 比如总线速度，网卡效能。
: 你举的这个平衡例子显然很不好，大家都知道TCP数据比UDP多很多，按
: 协议划分会很不均衡。当然这个问题可以由增加A类节点的数量来解决，但是
: 这又必然会引入相关或者要增加别的划分方案。
: 一般而言，可以有以下负载平衡方法：
: 1. 按IP段静态划分，这种方法比较简单，基本上就是起到在总体范围内分
: 流，降速的作用，但是不能处理流量在IP段之间的不均衡以及在时间上的变化。
: 2. 按IP静态划分，实现复杂一些，但是可以将即使是在同一网段的IP的流
: 量也均匀的分配到不同机器，可以在一定程度上解决1中的峰值问题。
: ...................
集群的问题可以参见 LVS , IDS 的集群不仅仅要分出去, 还要合起来,
另外, 节点的处理性能也是一个问题.
其实,更重要的问题是如何来减少误报率..这个是个大问题, snort就不用说,
cisco 的netrange , 你放在网络中看看, 大多数都是误报..所以, 现在
高层协议的分析是一个 IDS 的新方向.
LVS www.linuxvirtualserver.org 对负载均衡有很好的实现方式..可以参见.
17.: 集群的问题可以参见 LVS , IDS 的集群不仅仅要分出去, 还要合起来,
: 另外, 节点的处理性能也是一个问题.
新一代的IDS基本都实现了协议栈的还原，甚至包括应用层协议的还原解码。
: LVS www.linuxvirtualserver.org 对负载均衡有很好的实现方式..可以参见.
没太仔细看，但是好象它很难能够解决超过1G的流量问题，应用方向不太一样。
18.: 新一代的IDS基本都实现了协议栈的还原，甚至包括应用层协议的还原解码。
: 没太仔细看，但是好象它很难能够解决超过1G的流量问题，应用方向不太一样。
刚才又看了一下LVS www.linuxvirtualserver.org，发现它是做服务集群的，
其中负载平衡有3种技术：基于NAT，基于IP Tunneling，基于直接路由，呵呵，
其中我们用过后2种。因为：
1. NAT要修改IP层数据，当然不能为NIDS所用。
2. 而IP隧道是在数据采集点与数据分析点跨网段的时候采用的，这个方法
比较弱智，非常浪费带宽，不过当时测试的时候我们不可能在出口放一堆机器啦，
幸好那时候出口带宽很小，速度还跟得上，:-)
3. 直接路由就是集群必然要采用的方法，负载平衡机收到包后，根据算法
选择目标节点机(的MAC)，然后填到目的地址，就OK了，硬件软件都很容易实现，
效率也都很高。
19. 关于你反驳我举的例子不好的问题，我想向你做进一步的解释。
我的例子可能举的比较粗，但是我的想法是基于完全协议解析的IDS系统的，
对于一个完全协议解析的系统来说，它的设计从逻辑上来看是分层的，也就是说
不同的层负责的功能是不同的，比如说，IP层只做IP的解码，解码后的数据包可
能是TCP/UDP/ICMP，那么它就可以把这些数据包发送给这几个协议层的处理子系
统，而在TCP这一层呢，他可以根据端口号来进一步的判断高层协议是什么，比如
对于端口号是80的连接，它就可以将数据包发送给HTTP的处理子系统了，而对于
HTTP的子系统来说，它就可以按照HTTP协议的规范去进行必要的解码和解释了，
在此基础上就可以很好地实现一个HTTP协议数据包的检测。
其实对于我所描述的这个模型来说，因为能够通过完全的协议解析把系统分
成各个彼此独立的层次，所以就可以在程序设计上将不同的层次写成单独的进程
或者线程，各个进程/线程之间可以按照一定的私有协议进行通讯。如果是多进程
的话，将不同的进程运行在不同的系统上，就形成了一个很好的分布模型，这个
分布是基于协议的，也是非常好管理和控制的。
对于你提到的UDP数据少的问题，实际上我们可以把UDP的数据给发送到一台
比较差一些的机器上去，这样怎么能够浪费资源呢？
再说修改内核，我不明白你说的意思。现有的内核结构就是这个样子，再怎
么修改也不能提高多少的性能了，而这些所作的修改也基本上属于定制型的，就
是把其他部分的功能给弱化一些以换取与IDS相关部分的性能，试问这样的方式又
能提高多少的性能呢？
20. 可以在系统内配置一台中心控制主机来处理来自不同sensor的数据，进而
在此基础上得出一些结论，同时也可以动态的调整系统策略并下发到相应的
sensor。
高层协议解析的确不错，BlackICE和NFR都是这样的产品。
21. NAT其实是可以被NIDS使用的，我们知道，对于一个NAT来说，它可能只改变
某个方向的地址，也可能两个方向的地址都改，对于两个方向的地址都修改的NAT，
我们的确没有办法使用，但是对于那些只改变目标地址的NAT，我们是可以使用的，
因为保证了源地址，所以能够保证报警的正确。
22.: 关于你反驳我举的例子不好的问题，我想向你做进一步的解释。
: 我的例子可能举的比较粗，但是我的想法是基于完全协议解析的IDS系统的，
: 对于一个完全协议解析的系统来说，它的设计从逻辑上来看是分层的，也就是说
: 不同的层负责的功能是不同的，比如说，IP层只做IP的解码，解码后的数据包可
: 能是TCP/UDP/ICMP，那么它就可以把这些数据包发送给这几个协议层的处理子系
: 统，而在TCP这一层呢，他可以根据端口号来进一步的判断高层协议是什么，比如
: 对于端口号是80的连接，它就可以将数据包发送给HTTP的处理子系统了，而对于
: HTTP的子系统来说，它就可以按照HTTP协议的规范去进行必要的解码和解释了，
: 在此基础上就可以很好地实现一个HTTP协议数据包的检测。
你上面描述的工作模型我们已经实现过2个，现在正在做平台化工作，都是使用
回调插件方式组织，应用层处理插件也做了不少，所以对这种工作方式可以说是很
有发言权的。:-)
值得一提的是，单单依靠端口来判断应用层协议是一种极不可靠的方法。为此，
在我们的NIDS平台框架中专门作了协议识别的引擎来快速识别协议，并进行协议分发。
: 其实对于我所描述的这个模型来说，因为能够通过完全的协议解析把系统分
: 成各个彼此独立的层次，所以就可以在程序设计上将不同的层次写成单独的进程
: 或者线程，各个进程/线程之间可以按照一定的私有协议进行通讯。如果是多进程
: 的话，将不同的进程运行在不同的系统上，就形成了一个很好的分布模型，这个
: 分布是基于协议的，也是非常好管理和控制的。
: 对于你提到的UDP数据少的问题，实际上我们可以把UDP的数据给发送到一台
: 比较差一些的机器上去，这样怎么能够浪费资源呢？
问题是对于高速网络，数据量大的TCP，或者更细分一点的HTTP(80端口)协议，
一台再好的机器也不可能进行有效处理。
: 再说修改内核，我不明白你说的意思。现有的内核结构就是这个样子，再怎
: 么修改也不能提高多少的性能了，而这些所作的修改也基本上属于定制型的，就
我们的工作主要是减少甚至消除用户空间访问内核时的系统调用数，要知道系
统调用是非常影响性能的，我师弟那儿有有关测试，具体数字不记得了，大约就是
一次调用相当于内存比较2000次(?)吧。
: 是把其他部分的功能给弱化一些以换取与IDS相关部分的性能，试问这样的方式又
: 能提高多少的性能呢？
作为一个专用的NIDS节点机器，除了相关的功能需要保留之外，别的功能当然是
越少越好，功能越少越安全嘛。:-)
23. 回调方式从根本上说，还是一个串行的方式，也就是属于你的那个进程不做完回调
这件事情，它是不会去做其他的事情的（我说的是你的进程中的），那么这样就会因为
某个回调处理函数的效率低下造成问题，比如丢包等等，其实说来说去，回调的方式还
是一个大循环来工作的。
而我比较倾向于一个一个小循环的方式来实现，也就是说，IP层处理完了之后，它
直接把数据写入TCP/UDP/ICMP的缓冲区里，写成功后，IP的这个处理流程结束，进入下
circle，这样的方式是一层一些向上服务的，也就是小循环的方式，这样的方式的好处
应该是比较明显的，TCP/IP协议栈在BSD系统上的实现就是这样的。其实这样的小循环
的方式可以在任何的层次上进行任意的修改和扩充而不与其上、其下的层次发生关系，
从而减小耦合度，进而能为系统的分布带来方便。
24.基于端口的来区分协议似乎并不可靠吧？
为什么不首先解码，然后再分到不同的协议规范去判断是否是入侵行为
不过解码似乎是对性能要求最高的部分吧？
再分一层，在TCP这一层先判断使用的协议，然后再去做高层协议的处理
数据->ip层解码->TCP/UDP/ICMP协议的解码判断出是什么高层协议
->对高层协议作处理
这样不好吗？
在判断高层协议的时候可以考虑到端口的问题，但是如果只根据端口来判断协议
似乎不太合适。
记得以前写过一个scanner,对操作系统的识别和对相应服务的识别都是通过相关
协议以及服务器软件的特征来识别的,并不是用端口识别。和这个应该是类似的吧？
判断高层协议和对高层协议的处理这2个部分都可以放在分布式的系统上来进行
25. NIDS实际上分为两部分，捕包和分析：
1. 捕包实际上是由网卡DMA来完成的，不占CPU时间，只有当内核提供给网卡的
缓冲区不够的时候才会出现丢包现象，因此要降低丢包率，除了提高分析速度之外，
还有一个办法就是给网卡提供足够多的缓冲区，使得网络流量出现（高）峰值或者
处理速度出现（低）峰值的时候不会出现丢包。
2. 分析主要是由用户空间的还原/检测程序实现的，从网卡DMA区一直到分析处
理完成，常规的处理方法常常会经过一系列的系统调用，耗费大量的CPU时间，因此，
修改内核，使得分析部分的处理速度能够在总体上跟上网卡捕包的速度，显得尤为
重要。
这样，捕包和分析实际上自然而然的就是处在两个不同的“循环”上的，他们
的交互界面就是网卡DMA区，而所有的回调都是在分析里面做的，只要提高了分析的
总体速度，而DMA区有足够大的话，分析本身的串行，以及分析的某一个处理峰值，
都不会影响捕包的效率。
而插件的工作方式，既提高效率，又提高平台灵活性。
大家都知道ISO建议的OSI7层模型和TCP/IP的4层结构，为什么作为“标准参考
模型”的7层模型无人采纳，而TCP/IP却统一网络呢？其中一个很重要的原因就是
OSI模型分层太多，要知道在协议栈中每增加一层就会增加一层协议访问点，也就
意味着数据传递的时间和空间的增加，因此，看起来“完美”的OSI模型效率低下，
最终为各位网络OS厂家所抛弃。
而这里yjs提到的一个一个“小循环”，实际上也就是沿袭了OSI的老思路，只
不过是重新运用到了TCP/IP协议还原中来了而已，依靠增加缓冲区的办法来对网络
数据机械的“分层处理”，会增加多少访存时间呀！
在网络上，简单就是美，只有简单了，CPU的速度才能够跑得过光纤的速度。
26. 其实对于我所描述的这个模型来说，因为能够通过完全的协议解析把系统分
成各个彼此独立的层次，所以就可以在程序设计上将不同的层次写成单独的进程
或者线程，各个进程/线程之间可以按照一定的私有协议进行通讯。如果是多进程
的话，将不同的进程运行在不同的系统上，就形成了一个很好的分布模型，这个
分布是基于协议的，也是非常好管理和控制的。
对于你提到的UDP数据少的问题，实际上我们可以把UDP的数据给发送到一台
比较差一些的机器上去，这样怎么能够浪费资源呢？
这样不成了人为的分布式了吗？发挥不了分布式的优势了
我觉得不一定非要基于协议来做发送到不同的机器处理
网络中传送的数据时刻都会变化的，可能某一时刻UDP数据会很多
不如学学LVS那样做个集群样的东西，自己去做负载的均衡
再说修改内核，我不明白你说的意思。现有的内核结构就是这个样子，再怎
么修改也不能提高多少的性能了，而这些所作的修改也基本上属于定制型的，就
是把其他部分的功能给弱化一些以换取与IDS相关部分的性能，试问这样的方式又
能提高多少的性能呢？
27.: NIDS实际上分为两部分，捕包和分析：
: 1. 捕包实际上是由网卡DMA来完成的，不占CPU时间，只有当内核提供给网卡的
: 缓冲区不够的时候才会出现丢包现象，因此要降低丢包率，除了提高分析速度之外，
: 还有一个办法就是给网卡提供足够多的缓冲区，使得网络流量出现（高）峰值或者
: 处理速度出现（低）峰值的时候不会出现丢包。
使用 0 copy 的技术来提高访问内存的次数,
尽量让更多的操作在内核中进行.
使用高效率的实时操作系统...
: 2. 分析主要是由用户空间的还原/检测程序实现的，从网卡DMA区一直到分析处
: 理完成，常规的处理方法常常会经过一系列的系统调用，耗费大量的CPU时间，因此，
: 修改内核，使得分析部分的处理速度能够在总体上跟上网卡捕包的速度，显得尤为
: 重要。
: 这样，捕包和分析实际上自然而然的就是处在两个不同的“循环”上的，他们
: 的交互界面就是网卡DMA区，而所有的回调都是在分析里面做的，只要提高了分析的
: ...................
另外, 还需要处理在不能够跟上网络流量时的处理机制..
如果所有的插件, 回调都在内河中进行..效率可观..;-).但难度就大了.
28.看了几天, 一直没说话. 看到vertex都跑出来灌水, 我就也说两句:)
首先, 在网络层面上:
基于PC结构的IDS的抓包能力和处理能力上都有瓶颈.这个是大家都公认了.
目前最好的解决方法就是用NP, ysj他们就在用这个方法, 将TCP/IP协议解析
放在NP里面作,其实是解放了tcip/ip协议栈的工作. 大大减少了CPU的负担,
比起修改内核的方法要先进, 可靠的多.效率的提高也大的多.目前市面上还没有
见到一个用NP的IDS, 但是已经有用NP的内容过滤型防火墙.
cucme他们声称自己作了OS的内核优化, 这个努力可能会有效,但是是否像你声称
的那么有效, 我保留怀疑. 因为我不知道
你说的这个消除用户空间访问内核的系统调用数是那个阶段的, 如果你不是用NP,
0 copy的话, 我基本上认为不可能.
对于单机IDS来说, 使用了NP还是不够的. 先不说string match的优化,
因为CPU还是支持不了后续的那么多的连接计算, 就是一个简单的TCP stream维护
都玩不起. 所以还是需要负载分担.
至于负荷分担的方法, 已经是硬件IDS里面一个起码的技术了.
因为这个是NP里面就可以支持的. 某些NP的相应主板上就
支持, 另外国外有芯片可以直接作, 你如果用软件在X86上来作的话, 是不行的.
我绝对不相信你的一个PC可以作双工Gbit的负载均衡.
其次是分析层面:
协议分析是大势所趋了, 协议分析的基础是协议识别. ysj说他们是用port,
这个是枚错的, 不过只是这些是不够的. liue他们都指出了. 不过我估计ysj
肯定是知道这些问题的, 可能当时说的简单了点, 我来把这个问题详细说一下.
port识别之后, 你的协议分析引擎是要作进一步的确定的, 避免错误的确定了协议.
还有一个技术是作协议猜测,
这个技术是必须的, 否则你就没法准确的查backdoor, RPC,TNS等等协议的攻击.
对于那些well known的端口, 还是直接port定位, 然后加容错性检查就可以了,
否则你处理不了那么多连接的.
接下来的string match, 在协议分析和signature里面都有, 现在基本上是考虑用
string match芯片来解决问题. 最优的软件上的计算量是O(m的n次方),
期中m是data的length,n是要匹配的字符串的数目. 软件上是根本承受不起的.
这种脏活还是给芯片作吧.
另外我对cucme他们的原型设计有一些疑问. 首先你们用软件作负载均衡就是
很值得商榷的, 就算是能达到你们声称的能力, 那么现在网络处理能力部分
你们已经通过负载均衡的方法解决了, 就是说, 你们在负载均衡之后, 可以简单的
增加PC机来将降低对sensor的能力要求,sensor已经没有必要在网络处理能力上
担心网络处理瓶颈了,你们为什么还要在IDS sensor上
为什么还要修改内核,还要求做到0系统调用这么不现实的目标?
29.说起网卡..
3com的一种网卡内置防火墙的功能..可能以后就可以有 IDS 在网卡上了.
如果网卡能作 protocol parsing 那这个世界就完美了..;-)
30.
: 看了几天, 一直没说话. 看到vertex都跑出来灌水, 我就也说两句:)
:
: 首先, 在网络层面上:
: 基于PC结构的IDS的抓包能力和处理能力上都有瓶颈.这个是大家都公认了.
: 目前最好的解决方法就是用NP, ysj他们就在用这个方法, 将TCP/IP协议解析
: 放在NP里面作,其实是解放了tcip/ip协议栈的工作. 大大减少了CPU的负担,
: 比起修改内核的方法要先进, 可靠的多.效率的提高也大的多.目前市面上还没有
: 见到一个用NP的IDS, 但是已经有用NP的内容过滤型防火墙.
专用的协议栈硬件固然先进，可靠，效率也高，但是开发难度，造价也高呀，
这就是为什么还没见到NP的IDS的一个原因吧？
: cucme他们声称自己作了OS的内核优化, 这个努力可能会有效,但是是否像你声称
: 的那么有效, 我保留怀疑. 因为我不知道
: 你说的这个消除用户空间访问内核的系统调用数是那个阶段的, 如果你不是用NP,
: 0 copy的话, 我基本上认为不可能.
我承认，我们采用过多种方式提高捕包性能（具体内容就不足为外人道了，
sorry），现在zero copy，测试效果可以完全消除你的怀疑。
: 对于单机IDS来说, 使用了NP还是不够的. 先不说string match的优化,
: 因为CPU还是支持不了后续的那么多的连接计算, 就是一个简单的TCP stream维护
: 都玩不起. 所以还是需要负载分担.
:
: 至于负荷分担的方法, 已经是硬件IDS里面一个起码的技术了.
: 因为这个是NP里面就可以支持的. 某些NP的相应主板上就
: 支持, 另外国外有芯片可以直接作, 你如果用软件在X86上来作的话, 是不行的.
: 我绝对不相信你的一个PC可以作双工Gbit的负载均衡.
我们一直都是用硬件做分流。
: 其次是分析层面:
:
: 协议分析是大势所趋了, 协议分析的基础是协议识别. ysj说他们是用port,
: 这个是枚错的, 不过只是这些是不够的. liue他们都指出了. 不过我估计ysj
: 肯定是知道这些问题的, 可能当时说的简单了点, 我来把这个问题详细说一下.
: port识别之后, 你的协议分析引擎是要作进一步的确定的, 避免错误的确定了协议.
: 还有一个技术是作协议猜测,
: 这个技术是必须的, 否则你就没法准确的查backdoor, RPC,TNS等等协议的攻击.
: 对于那些well known的端口, 还是直接port定位, 然后加容错性检查就可以了,
: 否则你处理不了那么多连接的.
nod，这是共识了，呵呵
: 接下来的string match, 在协议分析和signature里面都有, 现在基本上是考虑用
: string match芯片来解决问题. 最优的软件上的计算量是O(m的n次方),
: 期中m是data的length,n是要匹配的字符串的数目. 软件上是根本承受不起的.
: 这种脏活还是给芯片作吧.
不是吧？你给的O(n^m)是最差情况呀，即使是对多模，O(n)是很easy的事情呀？
只不过内存大点，:( 简直是内存杀手，哈哈，还好，现在内存不太贵。
而且硬件比较器也不是那么容易做的吧？
:
: 另外我对cucme他们的原型设计有一些疑问. 首先你们用软件作负载均衡就是
: 很值得商榷的, 就算是能达到你们声称的能力, 那么现在网络处理能力部分
: 你们已经通过负载均衡的方法解决了, 就是说, 你们在负载均衡之后, 可以简单的
: 增加PC机来将降低对sensor的能力要求,sensor已经没有必要在网络处理能力上
: 担心网络处理瓶颈了,你们为什么还要在IDS sensor上
: 为什么还要修改内核,还要求做到0系统调用这么不现实的目标?
由于我们一直就坚持在协议还原上作检测，而且开始的时候技术很滥呀，
so, 一直都是采用的狼群战术，使用几十台机器作分析，前面一直都是用硬件作
分流，而且在分析逐渐进化的同时，分流器也逐渐进化。
0系统调用是完全可以实现的呀，难道大家觉得一个GB NIDS系统就有几十台机器
是一件很壮观的事情吗？另外100M级的出口也是NIDS大量应用的地方，难道还要去跑
个价值昂贵的分流器，后面挂上三两个分析机？
31. 我认为随着端对端加密的普及，HIDS，尤其是集成到应用程序的IDS会重新
占有主要地位，当然这些都是在分布式的大框架下的。
【 在 growrry (少一点浮躁) 的大作中提到: 】
: 大家的讨论基本上都是围绕采用特征检测的NIDS的，请高手也谈一谈对
: Host－based和Application-Integrated类型的IDS的观点。
最近看了一些入侵检测的文章，对未来的研究方向有自己的一些想法：如下
1）传统入侵检测方法研究：包括主机检测和网络检测,包括融合异常检测和特征检测。
2）入侵特征库的整理以及新的入侵特征的发现。
3）分布式入侵检测研究：主要研究分布式攻击的检测办法
4）智能化的入侵检测：可以提出类似神经网络、免疫系统、专家系统的检测方法
5）应用层的入侵检测：研究应用层的抓包技术与检测算法
6）基于主机的入侵检测：针对不同日志如何进行检测，可以用到数据挖掘技术
7）高速网络的入侵检测：研究1000Mbps以太网情况下的入侵检测
8）入侵检测系统的标准化研究：可以建立新的检测模型，使不同的IDS产品可以协同工作
9）IDS自身系统的安全研究：可以采取一些安全的技术，如IP隐藏技术、认证、SSL的使用
10）研究如何使IDS与防病毒工具、防火墙、VPN等其他安全产品协同工作，形成一套安全网管体系
11）研究入侵检测系统的评估准则
以下是关于对入侵检测的讨论:
1.个人觉得这些东西许多都紧密联系。
例如对高速网络的入侵检测，我觉得在目前的条件下，还是使用分布式，使得大流量数据由众多的节点分摊，基于主机的和基于网络的入侵检测应该协调起来，共享数据。
因为对于重要主机服务器需要使用基于主机的入侵检测。
还有就是节点之间连动，一个检测节点检测到可能的攻击行为后应该把信息和其他节点分享，使整个系统对该种攻击（例如ip地址）具有预见性。
不过总的来说最重要的工作应该是在建立完整的特征库上面。
现在许多系统的检全率和检准率不高，我想没有一个很好的特征库，没有合理地分类是一个很大的原因。
2.分布式DIDS确实是未来的发展趋势，目前国内一些IDS产品如TL-DIDS就是采用
“分布探针－集中控制”的方式，探针可以负责一定的安全区域，这样可以解决
高速网络的问题。
另外，对于高速网络必须采用协议分析的方法，落后的模式匹配方法是不能
胜任的。对于节点的信息共享确实也是一个非常值得研究的领域。这方面AAFID做的比较早。
98年就已经开始设计了。不过他依然采用分散管理的模式，有待改进。
对于特征检测，特征库确实是个关键问题，由于攻击特征五花八门，新的攻击方法层出不穷，现在很难对攻击特征很好的分类，国外的标准组织的进展缓慢，CVE的特征库也比较乱。
3.不是的，
特征库就像是病毒库，
你的诺顿或者毒霸，都是必须经常更新的，
所以 建立维护一个权威的标准的库也是做IDS的一个重要方面，
当然不一定每一个作IDS的人都要做了。
我们中心想做一个这个东西，
主要标准就是全，准，细，新。
完整准确细致最新
4.最初的时候
我觉得规则检测，其实就是一种杀毒软件：）
但是我觉得，似乎这种依靠规则检测的方式
就需要对管理者，或者是软件开发商有较高的要求
如果我们的规则库没有进行升级
那么我们所依赖的检测也就没有任何安全性了
所以我觉得单纯的依靠规则检测，恐怕是不够安全的
不过，对于统一一个规则库
我不是很乐观
恐怕难以作到全，准
:P
个人看法
5.你说的很有道理。
所以才需要在全国，乃至全球方位内成立
cert,FIRST等组织啊。
目的实际上就是汇总各地的信息，共享信息。
入侵检测永远是防御的一方，它必然比攻击慢半拍。
所以只能减少损失，无法避免
:)
一家之言哦。呵呵
6.: 个人觉得这些东西许多都紧密联系。
: 例如对高速网络的入侵检测，我觉得在目前的条件下，还是对于高速网络，我们是从两个方面来解决：
1. 提高捕包效率，现在来说就是修改内核了，以及直接使用千兆网卡。
2. 使用集群的方法，一台不行就加一台，进行分流，降低节点机速度要求。
: 使用分布式，使得大流量数据由众多的节点分摊，
: 基于主机的合基于网络的入侵检测应该协调起来，共享数据。
: 因为对于重要主机服务器需要使用基于主机的入侵检测。
: 还有就是节点之间连动，一个检测节点检测到可能的攻击行为后
: 应该把信息和其他节点分享，使整个系统对该中攻击（例如ip地址）具有预见性。
: 不过总的来说最重要的工作应该是在建立完整的特征库上面。
: 现在许多系统的检全率和检准率不高，我想没有一个很好的特征库，
: 没有合理地分类是一个很大的原因。
HIDS与NIDS协调是必然的，因为他们各有优缺点，尤其在加密环境中NIDS显得
无从下手，HIDS弥补了这一点。
7.我觉得就目前的商用软件就是这样的
因为目前特征检测的技术是最可靠的
而且对于商用软件而言，这个技术也是比较的成熟
不过我觉得
特征检测的对于特征库的高要求是一个致命的难点
8.: 对于高速网络，我们是从两个方面来解决：
: 1. 提高捕包效率，现在来说就是修改内核了，以及直接使用千兆网卡。
直接使用网络处理器来处理高速流量, 修理现有的操作系统内河很难
达到 G 级别的处理水平.
: 2. 使用集群的方法，一台不行就加一台，进行分流，降低节点机速度要求。
: HIDS与NIDS协调是必然的，因为他们各有优缺点，尤其在加密环境中NIDS显得
: 无从下手，HIDS弥补了这一�
是个好主意, 但是集群之间的协调, 报文的重组等是很很大的问题.
9. 没错，说入侵检测总是处于防御的一方，我想主要是就Misuse ID而言吧，像AbnormalID
就可以建立一套正常行为的统计规律来防御未知的入侵，虽然这种防御方式也有其自身
的不足，比如统计规律不够精确，人为因素过重之类的，不过现在有一种将特征检测和
误用检测结合的所谓混和检测方法，但我始终对其最后的仲裁抱有怀疑态度，因为对同
一个事件进行两种检测必然设计最后的决策
10. 呵呵，我对CIDF的模型的最初理解就是把它当成一个特征检测的模型，不是吗？
不过商用软件中使用特征检测和误用检测都有吧，主要的使用可能还是特征检测。我
所知道的REALSECURE，Cybercop多数都使用的特征检测。
11.听说南京大学已经把入侵检测和硬件相互关连了
不知道有人知道详细情况嘛？
我觉得只有把检测的大部分工作交给
硬件，对付高速网络才有希望
似乎软件的瓶颈太厉害了
12.最后两种检测的决定比例
不知道如何算
反正我觉得二者单独使用都是没有什么
太大的安全系数的
未来的方向应该是多种合并检测
13.: 事实上真正高速的网络原始数据包的采集都是通过硬件实现的，软件只是实现一个
: 显示的作用，比如显示流量数据或者分析曲线，像上海的国际出口局的国际出口流量
: 采集都是通过硬件来实现的，因为软件在千兆之上的丢包率会很高。
高速网络数据的采集，的确应该是以硬件为主，但是就入侵检测的功能而言肯定要使用
软件来处理，如何在高速的硬件和低速的软件间建立有效的联系呢？我们的方案是使用
硬件进行分流，将大流量合理的分割成一定数量的软件平台能够承受的小流量，然后进
行处理，这种方案既保持了硬件的速度，能够处理高速网络，又具有软件的灵活，能够
快捷的进行模块升级，处理最新的安全事件。
14. 修改现有的操作系统的内核的确不是很容易，使用网络处理器的确是
一个比较好的办法。
我想可以在分流数据包的时候就做一些基本的判断来解决一些问题，
也就是说做Banlance的机器要比较"smart"一些，它知道什么数据包该给
后面的哪台机器，这样就能解决报文重组等问题了。比如我们可以按照协
议类型分类的测率进行Banlance，把TCP的数据发送到A，把UDP的数据发
宋到B，把ICMP的数据发送到C等等，当然还可以有其他的方式。
反正不管怎么说，比较重要的是先是些协议的解析，在解析过的协议
上做很多尽一步的处理都是比较方便，并且效率很高的。
至于协调什么的问题，可以交给一台控制器来做，它负责收集和整理
来自不同的sensor的信息，然后处理他们之间的相关性，同时把一些必要
的策略修改信息下发到需要的sensor上去，也就是说sensor之间不发生直
的信息交换，一切都通过manager来实现，这样就能够使系统结构简单一些。
15.: 修改现有的操作系统的内核的确不是很容易，使用网络处理器的确是
: 一个比较好的办法。
不知道你这儿是什么意思，修改OS内核在困难也比设计一个ASIC容易，
只不过能够提高的带宽有极限而已，但这实际上也受限于机器的体系结构，
比如总线速度，网卡效能。
: 我想可以在分流数据包的时候就做一些基本的判断来解决一些问题，
: 也就是说做Banlance的机器要比较"smart"一些，它知道什么数据包该给
: 后面的哪台机器，这样就能解决报文重组等问题了。比如我们可以按照协
: 议类型分类的测率进行Banlance，把TCP的数据发送到A，把UDP的数据发
: 宋到B，把ICMP的数据发送到C等等，当然还可以有其他的方式。
你举的这个平衡例子显然很不好，大家都知道TCP数据比UDP多很多，按
协议划分会很不均衡。当然这个问题可以由增加A类节点的数量来解决，但是
这又必然会引入相关或者要增加别的划分方案。
一般而言，可以有以下负载平衡方法：
1. 按IP段静态划分，这种方法比较简单，基本上就是起到在总体范围内分
流，降速的作用，但是不能处理流量在IP段之间的不均衡以及在时间上的变化。
2. 按IP静态划分，实现复杂一些，但是可以将即使是在同一网段的IP的流
量也均匀的分配到不同机器，可以在一定程度上解决1中的峰值问题。
3. 按连接的动态负载平衡，实现复杂，但是能够很好的进行负载平衡，而
且能够降低后端处理节点间的相关性，是分流器设计的最终形态。
我们进行过其中1的方案，现在正在进行其中3。
16: 不知道你这儿是什么意思，修改OS内核在困难也比设计一个ASIC容易，
: 只不过能够提高的带宽有极限而已，但这实际上也受限于机器的体系结构，
: 比如总线速度，网卡效能。
: 你举的这个平衡例子显然很不好，大家都知道TCP数据比UDP多很多，按
: 协议划分会很不均衡。当然这个问题可以由增加A类节点的数量来解决，但是
: 这又必然会引入相关或者要增加别的划分方案。
: 一般而言，可以有以下负载平衡方法：
: 1. 按IP段静态划分，这种方法比较简单，基本上就是起到在总体范围内分
: 流，降速的作用，但是不能处理流量在IP段之间的不均衡以及在时间上的变化。
: 2. 按IP静态划分，实现复杂一些，但是可以将即使是在同一网段的IP的流
: 量也均匀的分配到不同机器，可以在一定程度上解决1中的峰值问题。
: ...................
集群的问题可以参见 LVS , IDS 的集群不仅仅要分出去, 还要合起来,
另外, 节点的处理性能也是一个问题.
其实,更重要的问题是如何来减少误报率..这个是个大问题, snort就不用说,
cisco 的netrange , 你放在网络中看看, 大多数都是误报..所以, 现在
高层协议的分析是一个 IDS 的新方向.
LVS www.linuxvirtualserver.org 对负载均衡有很好的实现方式..可以参见.
17.: 集群的问题可以参见 LVS , IDS 的集群不仅仅要分出去, 还要合起来,
: 另外, 节点的处理性能也是一个问题.
新一代的IDS基本都实现了协议栈的还原，甚至包括应用层协议的还原解码。
: LVS www.linuxvirtualserver.org 对负载均衡有很好的实现方式..可以参见.
没太仔细看，但是好象它很难能够解决超过1G的流量问题，应用方向不太一样。
18.: 新一代的IDS基本都实现了协议栈的还原，甚至包括应用层协议的还原解码。
: 没太仔细看，但是好象它很难能够解决超过1G的流量问题，应用方向不太一样。
刚才又看了一下LVS www.linuxvirtualserver.org，发现它是做服务集群的，
其中负载平衡有3种技术：基于NAT，基于IP Tunneling，基于直接路由，呵呵，
其中我们用过后2种。因为：
1. NAT要修改IP层数据，当然不能为NIDS所用。
2. 而IP隧道是在数据采集点与数据分析点跨网段的时候采用的，这个方法
比较弱智，非常浪费带宽，不过当时测试的时候我们不可能在出口放一堆机器啦，
幸好那时候出口带宽很小，速度还跟得上，:-)
3. 直接路由就是集群必然要采用的方法，负载平衡机收到包后，根据算法
选择目标节点机(的MAC)，然后填到目的地址，就OK了，硬件软件都很容易实现，
效率也都很高。
19. 关于你反驳我举的例子不好的问题，我想向你做进一步的解释。
我的例子可能举的比较粗，但是我的想法是基于完全协议解析的IDS系统的，
对于一个完全协议解析的系统来说，它的设计从逻辑上来看是分层的，也就是说
不同的层负责的功能是不同的，比如说，IP层只做IP的解码，解码后的数据包可
能是TCP/UDP/ICMP，那么它就可以把这些数据包发送给这几个协议层的处理子系
统，而在TCP这一层呢，他可以根据端口号来进一步的判断高层协议是什么，比如
对于端口号是80的连接，它就可以将数据包发送给HTTP的处理子系统了，而对于
HTTP的子系统来说，它就可以按照HTTP协议的规范去进行必要的解码和解释了，
在此基础上就可以很好地实现一个HTTP协议数据包的检测。
其实对于我所描述的这个模型来说，因为能够通过完全的协议解析把系统分
成各个彼此独立的层次，所以就可以在程序设计上将不同的层次写成单独的进程
或者线程，各个进程/线程之间可以按照一定的私有协议进行通讯。如果是多进程
的话，将不同的进程运行在不同的系统上，就形成了一个很好的分布模型，这个
分布是基于协议的，也是非常好管理和控制的。
对于你提到的UDP数据少的问题，实际上我们可以把UDP的数据给发送到一台
比较差一些的机器上去，这样怎么能够浪费资源呢？
再说修改内核，我不明白你说的意思。现有的内核结构就是这个样子，再怎
么修改也不能提高多少的性能了，而这些所作的修改也基本上属于定制型的，就
是把其他部分的功能给弱化一些以换取与IDS相关部分的性能，试问这样的方式又
能提高多少的性能呢？
20. 可以在系统内配置一台中心控制主机来处理来自不同sensor的数据，进而
在此基础上得出一些结论，同时也可以动态的调整系统策略并下发到相应的
sensor。
高层协议解析的确不错，BlackICE和NFR都是这样的产品。
21. NAT其实是可以被NIDS使用的，我们知道，对于一个NAT来说，它可能只改变
某个方向的地址，也可能两个方向的地址都改，对于两个方向的地址都修改的NAT，
我们的确没有办法使用，但是对于那些只改变目标地址的NAT，我们是可以使用的，
因为保证了源地址，所以能够保证报警的正确。
22.: 关于你反驳我举的例子不好的问题，我想向你做进一步的解释。
: 我的例子可能举的比较粗，但是我的想法是基于完全协议解析的IDS系统的，
: 对于一个完全协议解析的系统来说，它的设计从逻辑上来看是分层的，也就是说
: 不同的层负责的功能是不同的，比如说，IP层只做IP的解码，解码后的数据包可
: 能是TCP/UDP/ICMP，那么它就可以把这些数据包发送给这几个协议层的处理子系
: 统，而在TCP这一层呢，他可以根据端口号来进一步的判断高层协议是什么，比如
: 对于端口号是80的连接，它就可以将数据包发送给HTTP的处理子系统了，而对于
: HTTP的子系统来说，它就可以按照HTTP协议的规范去进行必要的解码和解释了，
: 在此基础上就可以很好地实现一个HTTP协议数据包的检测。
你上面描述的工作模型我们已经实现过2个，现在正在做平台化工作，都是使用
回调插件方式组织，应用层处理插件也做了不少，所以对这种工作方式可以说是很
有发言权的。:-)
值得一提的是，单单依靠端口来判断应用层协议是一种极不可靠的方法。为此，
在我们的NIDS平台框架中专门作了协议识别的引擎来快速识别协议，并进行协议分发。
: 其实对于我所描述的这个模型来说，因为能够通过完全的协议解析把系统分
: 成各个彼此独立的层次，所以就可以在程序设计上将不同的层次写成单独的进程
: 或者线程，各个进程/线程之间可以按照一定的私有协议进行通讯。如果是多进程
: 的话，将不同的进程运行在不同的系统上，就形成了一个很好的分布模型，这个
: 分布是基于协议的，也是非常好管理和控制的。
: 对于你提到的UDP数据少的问题，实际上我们可以把UDP的数据给发送到一台
: 比较差一些的机器上去，这样怎么能够浪费资源呢？
问题是对于高速网络，数据量大的TCP，或者更细分一点的HTTP(80端口)协议，
一台再好的机器也不可能进行有效处理。
: 再说修改内核，我不明白你说的意思。现有的内核结构就是这个样子，再怎
: 么修改也不能提高多少的性能了，而这些所作的修改也基本上属于定制型的，就
我们的工作主要是减少甚至消除用户空间访问内核时的系统调用数，要知道系
统调用是非常影响性能的，我师弟那儿有有关测试，具体数字不记得了，大约就是
一次调用相当于内存比较2000次(?)吧。
: 是把其他部分的功能给弱化一些以换取与IDS相关部分的性能，试问这样的方式又
: 能提高多少的性能呢？
作为一个专用的NIDS节点机器，除了相关的功能需要保留之外，别的功能当然是
越少越好，功能越少越安全嘛。:-)
23. 回调方式从根本上说，还是一个串行的方式，也就是属于你的那个进程不做完回调
这件事情，它是不会去做其他的事情的（我说的是你的进程中的），那么这样就会因为
某个回调处理函数的效率低下造成问题，比如丢包等等，其实说来说去，回调的方式还
是一个大循环来工作的。
而我比较倾向于一个一个小循环的方式来实现，也就是说，IP层处理完了之后，它
直接把数据写入TCP/UDP/ICMP的缓冲区里，写成功后，IP的这个处理流程结束，进入下
circle，这样的方式是一层一些向上服务的，也就是小循环的方式，这样的方式的好处
应该是比较明显的，TCP/IP协议栈在BSD系统上的实现就是这样的。其实这样的小循环
的方式可以在任何的层次上进行任意的修改和扩充而不与其上、其下的层次发生关系，
从而减小耦合度，进而能为系统的分布带来方便。
24.基于端口的来区分协议似乎并不可靠吧？
为什么不首先解码，然后再分到不同的协议规范去判断是否是入侵行为
不过解码似乎是对性能要求最高的部分吧？
再分一层，在TCP这一层先判断使用的协议，然后再去做高层协议的处理
数据->ip层解码->TCP/UDP/ICMP协议的解码判断出是什么高层协议
->对高层协议作处理
这样不好吗？
在判断高层协议的时候可以考虑到端口的问题，但是如果只根据端口来判断协议
似乎不太合适。
记得以前写过一个scanner,对操作系统的识别和对相应服务的识别都是通过相关
协议以及服务器软件的特征来识别的,并不是用端口识别。和这个应该是类似的吧？
判断高层协议和对高层协议的处理这2个部分都可以放在分布式的系统上来进行
25. NIDS实际上分为两部分，捕包和分析：
1. 捕包实际上是由网卡DMA来完成的，不占CPU时间，只有当内核提供给网卡的
缓冲区不够的时候才会出现丢包现象，因此要降低丢包率，除了提高分析速度之外，
还有一个办法就是给网卡提供足够多的缓冲区，使得网络流量出现（高）峰值或者
处理速度出现（低）峰值的时候不会出现丢包。
2. 分析主要是由用户空间的还原/检测程序实现的，从网卡DMA区一直到分析处
理完成，常规的处理方法常常会经过一系列的系统调用，耗费大量的CPU时间，因此，
修改内核，使得分析部分的处理速度能够在总体上跟上网卡捕包的速度，显得尤为
重要。
这样，捕包和分析实际上自然而然的就是处在两个不同的“循环”上的，他们
的交互界面就是网卡DMA区，而所有的回调都是在分析里面做的，只要提高了分析的
总体速度，而DMA区有足够大的话，分析本身的串行，以及分析的某一个处理峰值，
都不会影响捕包的效率。
而插件的工作方式，既提高效率，又提高平台灵活性。
大家都知道ISO建议的OSI7层模型和TCP/IP的4层结构，为什么作为“标准参考
模型”的7层模型无人采纳，而TCP/IP却统一网络呢？其中一个很重要的原因就是
OSI模型分层太多，要知道在协议栈中每增加一层就会增加一层协议访问点，也就
意味着数据传递的时间和空间的增加，因此，看起来“完美”的OSI模型效率低下，
最终为各位网络OS厂家所抛弃。
而这里yjs提到的一个一个“小循环”，实际上也就是沿袭了OSI的老思路，只
不过是重新运用到了TCP/IP协议还原中来了而已，依靠增加缓冲区的办法来对网络
数据机械的“分层处理”，会增加多少访存时间呀！
在网络上，简单就是美，只有简单了，CPU的速度才能够跑得过光纤的速度。
26. 其实对于我所描述的这个模型来说，因为能够通过完全的协议解析把系统分
成各个彼此独立的层次，所以就可以在程序设计上将不同的层次写成单独的进程
或者线程，各个进程/线程之间可以按照一定的私有协议进行通讯。如果是多进程
的话，将不同的进程运行在不同的系统上，就形成了一个很好的分布模型，这个
分布是基于协议的，也是非常好管理和控制的。
对于你提到的UDP数据少的问题，实际上我们可以把UDP的数据给发送到一台
比较差一些的机器上去，这样怎么能够浪费资源呢？
这样不成了人为的分布式了吗？发挥不了分布式的优势了
我觉得不一定非要基于协议来做发送到不同的机器处理
网络中传送的数据时刻都会变化的，可能某一时刻UDP数据会很多
不如学学LVS那样做个集群样的东西，自己去做负载的均衡
再说修改内核，我不明白你说的意思。现有的内核结构就是这个样子，再怎
么修改也不能提高多少的性能了，而这些所作的修改也基本上属于定制型的，就
是把其他部分的功能给弱化一些以换取与IDS相关部分的性能，试问这样的方式又
能提高多少的性能呢？
27.: NIDS实际上分为两部分，捕包和分析：
: 1. 捕包实际上是由网卡DMA来完成的，不占CPU时间，只有当内核提供给网卡的
: 缓冲区不够的时候才会出现丢包现象，因此要降低丢包率，除了提高分析速度之外，
: 还有一个办法就是给网卡提供足够多的缓冲区，使得网络流量出现（高）峰值或者
: 处理速度出现（低）峰值的时候不会出现丢包。
使用 0 copy 的技术来提高访问内存的次数,
尽量让更多的操作在内核中进行.
使用高效率的实时操作系统...
: 2. 分析主要是由用户空间的还原/检测程序实现的，从网卡DMA区一直到分析处
: 理完成，常规的处理方法常常会经过一系列的系统调用，耗费大量的CPU时间，因此，
: 修改内核，使得分析部分的处理速度能够在总体上跟上网卡捕包的速度，显得尤为
: 重要。
: 这样，捕包和分析实际上自然而然的就是处在两个不同的“循环”上的，他们
: 的交互界面就是网卡DMA区，而所有的回调都是在分析里面做的，只要提高了分析的
: ...................
另外, 还需要处理在不能够跟上网络流量时的处理机制..
如果所有的插件, 回调都在内河中进行..效率可观..;-).但难度就大了.
28.看了几天, 一直没说话. 看到vertex都跑出来灌水, 我就也说两句:)
首先, 在网络层面上:
基于PC结构的IDS的抓包能力和处理能力上都有瓶颈.这个是大家都公认了.
目前最好的解决方法就是用NP, ysj他们就在用这个方法, 将TCP/IP协议解析
放在NP里面作,其实是解放了tcip/ip协议栈的工作. 大大减少了CPU的负担,
比起修改内核的方法要先进, 可靠的多.效率的提高也大的多.目前市面上还没有
见到一个用NP的IDS, 但是已经有用NP的内容过滤型防火墙.
cucme他们声称自己作了OS的内核优化, 这个努力可能会有效,但是是否像你声称
的那么有效, 我保留怀疑. 因为我不知道
你说的这个消除用户空间访问内核的系统调用数是那个阶段的, 如果你不是用NP,
0 copy的话, 我基本上认为不可能.
对于单机IDS来说, 使用了NP还是不够的. 先不说string match的优化,
因为CPU还是支持不了后续的那么多的连接计算, 就是一个简单的TCP stream维护
都玩不起. 所以还是需要负载分担.
至于负荷分担的方法, 已经是硬件IDS里面一个起码的技术了.
因为这个是NP里面就可以支持的. 某些NP的相应主板上就
支持, 另外国外有芯片可以直接作, 你如果用软件在X86上来作的话, 是不行的.
我绝对不相信你的一个PC可以作双工Gbit的负载均衡.
其次是分析层面:
协议分析是大势所趋了, 协议分析的基础是协议识别. ysj说他们是用port,
这个是枚错的, 不过只是这些是不够的. liue他们都指出了. 不过我估计ysj
肯定是知道这些问题的, 可能当时说的简单了点, 我来把这个问题详细说一下.
port识别之后, 你的协议分析引擎是要作进一步的确定的, 避免错误的确定了协议.
还有一个技术是作协议猜测,
这个技术是必须的, 否则你就没法准确的查backdoor, RPC,TNS等等协议的攻击.
对于那些well known的端口, 还是直接port定位, 然后加容错性检查就可以了,
否则你处理不了那么多连接的.
接下来的string match, 在协议分析和signature里面都有, 现在基本上是考虑用
string match芯片来解决问题. 最优的软件上的计算量是O(m的n次方),
期中m是data的length,n是要匹配的字符串的数目. 软件上是根本承受不起的.
这种脏活还是给芯片作吧.
另外我对cucme他们的原型设计有一些疑问. 首先你们用软件作负载均衡就是
很值得商榷的, 就算是能达到你们声称的能力, 那么现在网络处理能力部分
你们已经通过负载均衡的方法解决了, 就是说, 你们在负载均衡之后, 可以简单的
增加PC机来将降低对sensor的能力要求,sensor已经没有必要在网络处理能力上
担心网络处理瓶颈了,你们为什么还要在IDS sensor上
为什么还要修改内核,还要求做到0系统调用这么不现实的目标?
29.说起网卡..
3com的一种网卡内置防火墙的功能..可能以后就可以有 IDS 在网卡上了.
如果网卡能作 protocol parsing 那这个世界就完美了..;-)
30.
: 看了几天, 一直没说话. 看到vertex都跑出来灌水, 我就也说两句:)
:
: 首先, 在网络层面上:
: 基于PC结构的IDS的抓包能力和处理能力上都有瓶颈.这个是大家都公认了.
: 目前最好的解决方法就是用NP, ysj他们就在用这个方法, 将TCP/IP协议解析
: 放在NP里面作,其实是解放了tcip/ip协议栈的工作. 大大减少了CPU的负担,
: 比起修改内核的方法要先进, 可靠的多.效率的提高也大的多.目前市面上还没有
: 见到一个用NP的IDS, 但是已经有用NP的内容过滤型防火墙.
专用的协议栈硬件固然先进，可靠，效率也高，但是开发难度，造价也高呀，
这就是为什么还没见到NP的IDS的一个原因吧？
: cucme他们声称自己作了OS的内核优化, 这个努力可能会有效,但是是否像你声称
: 的那么有效, 我保留怀疑. 因为我不知道
: 你说的这个消除用户空间访问内核的系统调用数是那个阶段的, 如果你不是用NP,
: 0 copy的话, 我基本上认为不可能.
我承认，我们采用过多种方式提高捕包性能（具体内容就不足为外人道了，
sorry），现在zero copy，测试效果可以完全消除你的怀疑。
: 对于单机IDS来说, 使用了NP还是不够的. 先不说string match的优化,
: 因为CPU还是支持不了后续的那么多的连接计算, 就是一个简单的TCP stream维护
: 都玩不起. 所以还是需要负载分担.
:
: 至于负荷分担的方法, 已经是硬件IDS里面一个起码的技术了.
: 因为这个是NP里面就可以支持的. 某些NP的相应主板上就
: 支持, 另外国外有芯片可以直接作, 你如果用软件在X86上来作的话, 是不行的.
: 我绝对不相信你的一个PC可以作双工Gbit的负载均衡.
我们一直都是用硬件做分流。
: 其次是分析层面:
:
: 协议分析是大势所趋了, 协议分析的基础是协议识别. ysj说他们是用port,
: 这个是枚错的, 不过只是这些是不够的. liue他们都指出了. 不过我估计ysj
: 肯定是知道这些问题的, 可能当时说的简单了点, 我来把这个问题详细说一下.
: port识别之后, 你的协议分析引擎是要作进一步的确定的, 避免错误的确定了协议.
: 还有一个技术是作协议猜测,
: 这个技术是必须的, 否则你就没法准确的查backdoor, RPC,TNS等等协议的攻击.
: 对于那些well known的端口, 还是直接port定位, 然后加容错性检查就可以了,
: 否则你处理不了那么多连接的.
nod，这是共识了，呵呵
: 接下来的string match, 在协议分析和signature里面都有, 现在基本上是考虑用
: string match芯片来解决问题. 最优的软件上的计算量是O(m的n次方),
: 期中m是data的length,n是要匹配的字符串的数目. 软件上是根本承受不起的.
: 这种脏活还是给芯片作吧.
不是吧？你给的O(n^m)是最差情况呀，即使是对多模，O(n)是很easy的事情呀？
只不过内存大点，:( 简直是内存杀手，哈哈，还好，现在内存不太贵。
而且硬件比较器也不是那么容易做的吧？
:
: 另外我对cucme他们的原型设计有一些疑问. 首先你们用软件作负载均衡就是
: 很值得商榷的, 就算是能达到你们声称的能力, 那么现在网络处理能力部分
: 你们已经通过负载均衡的方法解决了, 就是说, 你们在负载均衡之后, 可以简单的
: 增加PC机来将降低对sensor的能力要求,sensor已经没有必要在网络处理能力上
: 担心网络处理瓶颈了,你们为什么还要在IDS sensor上
: 为什么还要修改内核,还要求做到0系统调用这么不现实的目标?
由于我们一直就坚持在协议还原上作检测，而且开始的时候技术很滥呀，
so, 一直都是采用的狼群战术，使用几十台机器作分析，前面一直都是用硬件作
分流，而且在分析逐渐进化的同时，分流器也逐渐进化。
0系统调用是完全可以实现的呀，难道大家觉得一个GB NIDS系统就有几十台机器
是一件很壮观的事情吗？另外100M级的出口也是NIDS大量应用的地方，难道还要去跑
个价值昂贵的分流器，后面挂上三两个分析机？
31. 我认为随着端对端加密的普及，HIDS，尤其是集成到应用程序的IDS会重新
占有主要地位，当然这些都是在分布式的大框架下的。
【 在 growrry (少一点浮躁) 的大作中提到: 】
: 大家的讨论基本上都是围绕采用特征检测的NIDS的，请高手也谈一谈对
: Host－based和Application-Integrated类型的IDS的观点。
- 我谈入侵检测的方向 --转自水木 rilson (开心辞典) (推荐)
- 开心辞典
- 开心辞典
- 入侵检测产品的发展趋势
- 一次完整的入侵检测
- 入侵检测系统的部署
- 入侵检测技术的实现
- 入侵检测系统的不足
- 入侵检测初学习--常见的入侵检测系统
- 谈入侵检测系统探究
- 经济类图书推荐--转自水木
- --- 入侵检测 ---
- --- 入侵检测 ---
- 入侵检测
- 入侵检测
- 入侵检测
- 入侵检测
- 入侵检测系统和入侵防护系统的区别
- 分治与递归策略_hanio塔问题
- 自定义控件中使用枚举类型的属性（原创）
- 分治与递归策略_整数划分问题
- 为把(...大学)建设成为社会主义大学而奋斗
- 十一放假到家
- 我谈入侵检测的方向 --转自水木 rilson (开心辞典) (推荐)
- 分治与递归策略_二分搜索法
- 我见过的最有水平的英语笑话
- ----->武安河《windows2000/XP WDM设备驱动程序开发》讨论专区<-----
- 《黄手帕》主题曲，很好听
- 《决战恶意代码〉赞
- DCLP不是线程安全的？
- 吉大的声誉和名气- -(转载)
- 给空间换一个名字
