IDS及其Linux下的实现(5) Feb_27_20:30:31 172.18.172.18 watcher01 Port_Scan_From_evil.com Feb_27_20:31:07 web_server watcher02 OS_fingerprint_from_12.18.1.1 在设计日志格式时我曾经考虑过许多方案，主要是想分出更多的项，如记录两端的端口信息，加入可信度和计数，这样在以后可以很方便的排序和查找，但最终还是采用了这种简单的格式。其原因主要是各种不同的事件需要记录的项千差万别，唯一又共性的便是time,host,watcher这三项，其余之处可都放到event项中去说明。我可以举一个例子：攻击的源地址似乎应该单列出来，但是现在假冒源地址进行的攻击实在太普遍了，land攻击便将源地址设为与被攻击者相同，此时记录源地址没有任何意义；syn flood往往随机的生成源地址，如果因源地址不同而单列出一个记录的话，只会使日志迅速膨胀，而其记录的内容与只简单记录发生了syn flood没有多大区别。 设计日志时还有一大问题便是连续不断的相同攻击会产生大量相同的日志，HereLine对此采取的办法也与UNIX的syslogd相同：设立一专门的计数器count，每当有新的事件出现的时候先比较是否与上一事件重名，若不重名则马上记录（保证报警的迅速），否则对计数器加一，直到有不重名的事件发生才真正写日志，此时记录的event项的内容为： The_last_messages_repeated_$count_times 除生成日志告警外，系统不采取任何其他行动，是否采取相应的措施由系统管理员自行决定。 由于时间关系，程序完成的不是很完善，有很多跟理想的有一些差别： （1）无法灵活的升级：所有的入侵检测部分都以编译后的程序的形式提供（可以高效处理,但同时失去了灵活性）用户必须完全或部分更新原有程序才能实现升级。以后应该采用类似脚本语言的办法。 （2）所处理的攻击数还需有很大的提高。 （3）控制台程序尚没有加入对采集分析程序的控制，也没有加入对分析结果作进一步处理的功能（如排序、过滤、查找等）。 （4）磁盘定额：对日志过大以后的情况尚没有人为规定，不过目前可以用Linux自身的quato功能实现（写满一定磁盘定额后覆盖）。 （5）集中控制:控制台应该加入配置watcher的功能（如暂停其某项检测）。 （6）无法动态的载入和卸载检测规则。（很快会加入） （7）未采用IAP：现在watcher与listener的通信仍采用明文传输，这种局面急需改变。但IAP设计的过于复杂，且是否会成为标准尚不明朗，所以暂时可能先设计一个简单点的协议来实现加密和验证。 IDS系统面临的一个矛盾便是性能与功能的折衷。对数据进行全面复杂的检验，对实时性的要求构成了很大的挑战。 由于仅仅进行了开发，没有对HereLine进行性能测试，对HereLine而言，其可能影响性能的有三个地方：内核到应用层的转换（涉及数据拷贝）；数据分析（大量的数据匹配操作）；记录日志（IO操作）。
