ids分析及其在linux下的实现(编辑修改稿)

ids分析及其在linux下的实现(编辑修改稿)内容摘要：

析 数据分析部分事实上与数据采集部分作为一个进程 (agent)存在 ,主要是为了简化程序设计的复杂性。 在得到数据帧之后， agent 模拟操作系统的 TCP/IP 堆栈对数据进行处理并与已知攻击行为的特征进行比较，从中发现异常行为，并向控制台告警。 在分析的过程中，首先对数据包进行协议分析、过滤，根据协议、端口等信息将数据包送到不同的检测流程（如只有 HTTP 协议的包才进行 CGI 检查），这样使检查的过程尽量缩短，提高了程序的工作效率。 当进入相应的检测流程后，则按照线性的顺序工作。 数据分析部分设计为模拟 TCP/IP 堆栈的流程处理数据包，从中发现异常行为（如分片重合、异常标志等）。 这样主要是为了减少误报与漏报，从攻击的核心特征发现它，而不是象许多其他系统那样，只检查攻击包的表面特征。 waRcher 中毕业设计（论文）：入侵检测系统（ IDS）分析及其在 linux下的实现 第 9 页 共 2 1 页 包括了 IP 分片处理，包括了 TCP 状态转换。 通过这种结构，可以准确的判别诸如teardrop 等碎片攻击的各种变种。 对一些常见攻击手法的描述和处理方法见附录 1。 waRcher 目前可以处理以下攻击： of death routing CGI 攻击 OS detection flood 及其所有变种 数据采集部分与数据分析部分（即 agent 程序）的整体流程图为： 毕业设计（论文）：入侵检测系统（ IDS）分析及其在 linux 下的实现 第 10 页 共 2 1 页 若识别出有异常行为，则向控制台告警（采用类似 IAP的协议）。 WaRcher 此时分出一个单独的进程处理与控制台的交互，而原进程则继续处理新的数据包。 控制台部分分为两个程序， listener 和 console。 listener 绑定 6543 端口（目前似乎没有和其他程序 冲突），接收从分析程序发出的分析结果和其他信息，并根据其类型转化到不同文件存储。 此时的文件为用户可读。 其实 agent 和listener 两者便已经形成了一个完整的 IDS。 console 为一用 GTK+图形库编制的一个窗口程序，目的主要是给用户一个更方便友好的界面来浏览警告信息（下图）。 毕业设计（论文）：入侵检测系统（ IDS）分析及其在 linux 下的实现 第 11 页 共 2 1 页 因为 listener 已经将报警信息以明文格式存储，因此也可以采用将其转换成HTML 文件，用浏览器查看。 当然也可以采用 windows 应用程序。 因 waRcher 不是一个商业软件，对界面的考虑并不多。 WaRcher 的日志采用了 类似 UNIX 系统日志的格式，包括 time（事件发生时间） ,host（被攻击的主机名或 IP） ,agent（发现此攻击的 agent的名字或 IP） ,event（攻击的具体描述）这些项。 各项之间用空格分开，每个记录用一行，每项之中不能有空格，若有，用下划线代替（以上语法约定均是为了方便处理）。 下面是一个例子： Feb_27_20:30:31 agent01 Feb_27_20:31:07 web_server agent02 在设计日志格式时我曾经考虑过许多方案，主要是想分出更多的项，如记录两端的端口信息，加入可信度和计数，这样在以后可以很方便的排序和查找，但最终还是采用了这种简单的格式。 其原因主要是各种不同的事件需要记录的项千差万别，唯一又共性的便是 time,host,agent 这三项，其余之处可都放到 event项中去说明。 我可以举一个例子：攻击的源地址似乎应该单列出来，但是现在假冒源地址进行的攻击实在太普遍了， land 攻击（具体描述见附录）便将源地址设为与被攻击者相同，此时记 录源地址没有任何意义； syn flood 往往随机的生成源地址，如果因源地址不同而单列出一个记录的话，只会使日志迅速膨胀，而其记录的内容与只简单记录发生了 syn flood 没有多大区别。 设计日志时还有一大问题便是连续不断的相同攻击会产生大量相同的日志，waRcher 对此采取的办法也与 UNIX 的 syslogd 相同：设立一专门的计数器 count，每当有新的事件出现的时候先比较是否与上一事件重名，若不重名则马上记录（保证报警的迅速），否则对计数器加一，直到有不重名的事件发生才真正写日志，此时记录的 event 项的 内容为： The_last_messages_repeated_$count_times 除生成日志告警外，系统不采取任何其他行动，是否采取相应的措施由系统管理员自行决定。 毕业设计（论文）：入侵检测系统（ IDS）分析及其在 linux 下的实现 第 12 页 共 2 1 页 未完成部分 此章所描述的功能与最终理想的程序有所出入（主要是由于时间关系有些部分尚未完成），具体差别有： （ 1）无法灵活的升级：所有的入侵检测部分都以编译后的程序的形式提供（可以高效处理 ,但同时失去了灵活性）用户必须完全或部分更新原有程序才能实现升级。 以后应该采用类似脚本语言的办法。 （ 2）所处理的攻击数还需有很大的提高。 （ 3）控制台程序尚没有加入对采集分析程序的控制，也没有加入对分析结果作进一步处理的功能（如排序、过滤、查找等）。 （ 4）磁盘定额：对日志过大以后的情况尚没有人为规定，不过目前可以用 linux自身的 quato 功能实现（写满一定磁盘定额后覆盖）。 （ 5）集中控制 :控制台应该加入配置 agent 的功能（如暂停其某项检测）。 （ 6）无法动态的载入和卸载检测规则。 （很快会加入） （ 7）未采用 IAP：现在 agent 与 listener 的通信仍采用明文传输，这种局面急需改变。 但 IAP 设计的过于复杂，且是否会成为标准尚不明朗，所以 暂时可能先设计一个简单点的协议来实现加密和验证。 性能参考 IDS 系统面临的一个矛盾便是性能与功能的折衷。 对数据进行全面复杂的检验，对实时性的要求构成了很大的挑战。 对 waRcher 而言，其可能影响性能的有三个地方：内核到应用层的转换（涉及数据拷贝）；数据分析（大量的数据匹配操作）；记录日志（ IO 操作）。 IDS 的测试还没有客观的标准。 由于内部流程不同，不同的测试数据会产生不同的效果（假设以丢包率， CPU 利用率为标准）。 且由于程序一直处于开发阶段，尚还没有对 waRcher 的某一稳定版本进行性能测试。 但根据以前防火墙测试的经验，性能的瓶颈往往在日志的记录上（大量磁盘读写），所以应通过尽量减少日志数量的办法来提高 IDS 的性能。 第四章 存在的问题 尽管有众多的商业产品出现，与诸如防火墙等技术高度成熟的产品相比，入侵检测系统还存在相当多的问题。 这一章我们便要讨论一下对其进行威胁的主要因素，值得注意的是，这些问题大多是目前入侵检测系统的结构所难以克服的（包括 waRcher），而且这些矛盾可能越来越尖锐。 以下便是对入侵检测产品提出挑战的主要因素 [3]： ，日趋成熟多样自动化工具，以 及越来越复杂细致的攻击手法。 下图是 CERT 每年处理的安全事件（纵坐标）的统计： 毕业设计（论文）：入侵检测系统（ IDS）分析及其在 linux 下的实现 第 13 页 共 2 1 页 不难看出，安全问题正日渐突出，尤其是 2020 年初出现了对诸如 Yahoo， ebay等著名 ICP 的攻击事件。 IDS 必须不断跟踪最新的安全技术，才能不致被攻击者远远超越。 网络入侵检测系统通过匹配网络数据包发现攻击行为， IDS 往往假设攻击信息是通过明文传输的，因此对信息的稍加改变便可能骗过 IDS 的检测。 TFN 现在便已经通过加密的方法传输控制信息。 还有许多系统通过 VPN（虚拟专用网）进行网络之间 的互联，如果 IDS 不了解其所用的隧道机制，会出现大量的误报和漏报。 、适应多样性的环境中的不同的安全策略。 网络及其中的设备越来越多样化，即存在关键资源如邮件服务器、企业数据库，也存在众多相对不是很重要的 PC 机。 不同企业之间这种情况也往往不尽相同。 IDS要能有所定制以更适应多样的环境要求。 用户往往要求 IDS 尽可能快的报警，因此需要对获得的数据进行实时的分析，这导致对所在系统的要求越来。