基于NAPI的高速网络捕包技术.ppt

基于NAPI的高速网络捕包技术 黎 耀 华中科技大学 yaolee@ 目录 背景 捕包测试及分析 NAPI机制 试验结果分析 小结 背景 IPv6环境下入侵检测系统 （国家网络与信息安全保障持续发展计划资助项目） 背景 IPv6安全性分析 数据包捕获 入侵模式判别 主动阻断 IPv6 Security Enhancements Still Not Everything You Need! 背景－安全问题的原因 Ⅰ设计阶段的缺陷 Ⅱ实现阶段的漏洞和后门 Ⅲ部署管理阶段的漏洞和不合理配置 背景－设计阶段 协议新特征带来的问题 过渡机制的问题 背景－新特征带来的问题 邻居发现 路由头部 扩展头部 背景－过渡机制问题 隧道 双栈 背景－实现阶段 IPv6相关漏洞列表 分析 背景－IPv6相关漏洞列表 数据包捕获 数据包捕获 采用设备轮询机制 NAPI NAPI的核心概念是不采用中断的方式读取数据，而采用首先中断唤醒数据接收的服务程序，然后使用轮询的方法来获取数据 捕包测试及分析 目前现有的网络分析工具及IDS系统 Snort Tcpdump Ethernetreal Libpcap API函数接口 用户层数据包截获 易于移植的应用框架 捕包测试及分析 操作系统：Linux 流量发生器：Smartbit6000 背景流量： 0Mbps 25Mbps 50Mbps 75Mbps 100Mbps 捕包工具：IPgrab（libpcap0.7.2） 捕包测试及分析 测试平台： P4 1.4GHZ 512M 内存 100M 8139网卡 Linux操作系统 背景协议：IPv4－UDP 背景帧长： 1518Byte 512Byte 80Byte 捕包测试及分析 被捕获流量：1000个TCP包 发送速率：1Mbps 试验数据 结果分析 在小流量网络中（0M，25Mb背景流量），或者大包的情况下（1512byte ，75M背景流量）Libpcap表现良好，丢包较少。 在大背景流量，小包的条件下，Libpcap捕获率很低，丢包严重。 数据包帧长对捕获率影响很大。即使在流量不高的情况下（背景流量为25M，帧长80Byte），如果网络上小包较多，也会导致对捕获率大幅下降。 在100M背景流量，帧长为80byte情况下，系统基本处于瘫痪状态，无法响应用户的操作。 结果分析 频繁的网卡中断造成的。 中断是为一些低频率的I/O设备如键盘，磁盘等设计的，通常一秒钟产生几百个中断。 在75M背景流量，包长80字节情况下，网卡每秒钟产生近117000个中断。这将使得操作系统花了大部分时间去处理中断，几乎没有时间做其他的工作。 数据包捕获 Linux系统中包的处理过程 数据包到达产生硬件中断 数据包读入，封装 等待队列backlog，设定软中断标志位 上层处理由软中断来完成 捕包瓶颈分析－硬件问题 当数据传输路径上的瓶颈不能处理数据流时，就会出现数据包丢失。例如： PCI总线 32位/33MHz PCI最大支持1Gb/s：这是无法满足单个千兆网卡工作于全双工模式。 芯片 许多主板上的芯片无法提供高于1Gb/s的网卡支持 目前高端PC的芯片和PCI-x总线已经可以支持到8Gb/s 内核问题 硬件问题不是唯一的限制。 当数据包的接收速率过快时，中断可能无法被内核所调用。 在执行中断处理时，其他中断请求无法得到响应。 缓冲区队列可能被填满 CPU在处理过多NIC中断和队列数据包时将十分繁忙，因此没有足够的资源去处理他们（这就是所谓的中断活锁） CPU可能被其他进程系统调用所使用，因此IP处理进程就必须等待，队列将很快被填满。 阻塞策略 当队列满了以后将会出现大量数据包丢失。 通常当队列满了以后，它会进入阻塞状态，此时任何数据包都无法进入队列直到队列被完全清空 为了防止由于内核过载导致的服务中断以及DoS攻击 Linux网络栈实现方式的改变 为了应对越来越快的网络接口卡，Linux内核的在TCP/IP协议栈的实现方式上做过几次改变。 内核 1.x：bottom halves 中断处理程序进行尽可能少的计算： 通过DMA将数据从NIC buffer拷贝到内核内存中 在backlog队列中插入数据描述符 处理部分推迟到下半部处理 IP进程 阻塞策略：当backlog被完全填满后，中断处理被禁止直到backlog队列被清空 下半部处理严格由CPU串行执行；每次只有一个数据包能进入系统 Linux网络栈实现方式的改变 内核 2.3.43-2.4：softirq 下半部机制已经被软中断所取代 部分代码可以由内核线程按需异步执行 内核 2.4.20- NAPI（new application program interface） 中断缓解技术（中