Zeek使用与实践探索二
2023-11-23 23:17:0 Author: Desync InfoSec(查看原文) 阅读量:20 收藏

背景

又使用了一段时间的zeek，继续将遇到的问题总结出来，分享给大家。如果文章内容对您有所帮助，请购买一本西野七濑的写真集（❌）点赞转发在看（✔），感谢！

01
日志相关

部署完zeek后，采集日志进行后续分析是使用zeek的必经之路。zeek默认采用tsv文件格式存储所有日志。我们可以修改为更为通用的JSON格式。例如在local.zeek中可以进行如下配置：

root@nta01:/home/zeek/site# vim local.zeekredef LogAscii::use_json = T;

在接收日志进行解析时，我这里用到了thrift，很不巧，conn.log日志中的字段名service与thrift中的关键字冲突了，这时需要对service这个字段名进行重命名，这个需求也可以编辑local.zeek文件，添加以下配置来实现：

root@nta01:/home/zeek/site# vim local.zeekredef Log::default_field_name_map = {        ["service"] = "_service"};

后面发生了更不巧的事情，zeek的日志字段名是以.分隔的，例如字段名id.orig.h。而thrift声明时也不允许字段名包含.符号。因此还需要把分隔符.替换成其他字符。幸运的是zeek的研发早预料到了这种需求。我们依然修改local.zeek文件来实现：

root@nta01:/home/zeek/site# vim local.zeekredef Log::default_scope_sep = "_";

再后来，我们增加了zeek节点，需要区分日志是从哪个zeek节点采集到的，当然，采集工具本身是可以在日志内容中增加agent信息的字段的。但是这会影响原有的JSON结构。例如如果用agent来增加信息，格式如下：

{    "message": {"zeek-log......"},    "hostname": "zeek-01"}

这样做原来的日志外面会嵌套一层数据。这样修改会影响之前的JSON解析逻辑，因此我们选择直接在zeek日志中增加字段。依然是修改local.zeek文件

root@nta01:/home/zeek/site# vim local.zeek@load base/protocols/conn
redef record Conn::Info += {        dev_hostname: string &optional &log;};
event connection_state_remove(c: connection) {    c$conn$dev_hostname = gethostname();}
02
规则相关

zeek自带了一个signature框架用于特征识别。它可以用于识别协议、识别恶意流量等。在zeek运行了一段时间之后，我们发现zeek并不能识别到非标准端口的MySQL通信行为，深挖之后，我们发现zeek识别协议首先会按内置的协议默认端口尝试调用协议解析器进行解析，对于非标准端口，有些协议内置了协议指纹文件，如果TCP数据命中了协议指纹，也会调用协议解析器进行解析。很不巧，zeek没有内置MySQL协议的指纹，因此，非标准端口的MySQL通信就无法识别了

ok，我们自己写一个指纹识别MySQL。那么分析协议特征的过程先略过。文件需要放置在mysql协议脚本的路径下。文件的内容是这样的：

root@nta01:/home/zeek/site# vim /usr/share/zeek/share/zeek/base/protocols/mysql/dpd.sig# MySQL Protocol Signature
signature mysql_client8 {    ip-proto == tcp    payload /\x01\x0f\xa6\x3e.*caching_sha2_password/    tcp-state originator    enable "mysql"}
signature mysql_client5 {    ip-proto == tcp    payload /\x01\x0f\xa6\x3e.*mysql_native_password/    tcp-state originator    enable "mysql"}
signature mariadb_client {    ip-proto == tcp    payload /\x01\x8a\xa7\xbe\x01.*mysql_native_password/    tcp-state originator    enable "mysql"}
signature mysql_server8 {    ip-proto == tcp    payload /\x4a\x00\x00.*caching_sha2_password/    tcp-state responder    enable "mysql"}
signature mysql_server5 {    ip-proto == tcp    payload /\x4a\x00\x00.*mysql_native_password/    tcp-state responder    enable "mysql"}
signature mariadb_server11 {    ip-proto == tcp    payload /\x69\x00\x00.*mysql_native_password/    tcp-state responder    enable "mysql"}

对signature的格式的解释如下：

signature 特征名 {    ip-proto == tcp # ip协议的上层    payload /\xcaching_sha2_password/ #使用正则匹配数据包内容    tcp-state originator    #匹配流方向，originator是client，respender是server    enable "mysql"    # 匹配特征后调用的协议解析器名称}
03
其他流量指纹

https://www.yuque.com/safestplace/ku94do/shozi6ka1kuqfasa


文章来源: http://mp.weixin.qq.com/s?__biz=MzkzMDE3ODc1Mw==&mid=2247487058&idx=1&sn=b9edd35388e25c090cfb4aabb4e5c9b1&chksm=c27f7dfcf508f4ea3c1e9477bed089c894dab1717ad7d2540446a76740c0d83c46a2a6697d83&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh