[*] 关于 SimulatedUbuntu 的问题

[ChinaBluecat]

这里日志是用sysdig采集的，但我们对数据进行简单统计分析后，发现一些问题：

1. 日志应该不是直接由 sysdig -j 导出，最后的 is_warn 字段似乎是添加上的。这个标注的依据是什么？
2. 日志中的 evt.type 类型被限定了，以下是日志内出现的各类 syscall 的统计结果。

# anomaly.json: {'read': 1580869, 'fstat': 2050523, 'write': 176712, 'clone': 5922, 'execve': 2901, 'fcntl': 4031, 'writev': 2521, 'rename': 2611, 'sendto': 531, 'recvmsg': 2790, 'recvfrom': 1278, 'sendmsg': 1348, 'accept': 136, 'chmod': 73, 'rmdir': 96}
# benign.json: {'fstat': 3080932, 'read': 11253196, 'write': 891898, 'fcntl': 13167, 'clone': 12529, 'execve': 6408, 'writev': 20962, 'rename': 21294, 'sendto': 4047, 'recvfrom': 11538, 'recvmsg': 17019, 'sendmsg': 7565, 'accept': 833, 'chmod': 266, 'rmdir': 441}

我想知道选定这些 syscall 的依据是什么，出于何种考虑，这些调用是否足够完善用于溯源图构建，还有是否存在某个未公开的过滤脚本。
比如像是 bind 的调用在日志中并未出现？还是过滤了？并且在日志中存在的 fstat 调用在实际的处理脚本中并未使用(config.py中)。

[0xllssFF]

1. is_warn is labeled manually after collection according to the document of each attack.
2. Yes, we only consider the events that we list in the paper as previous work has done. I think it is enough for reconstructing the provenance graph of the attacks in our experiment. We didn't collect the 'bind' syscall, and you can configure the type of event if you think it is necessary.

[ChinaBluecat]

感谢解答 :D，我想适当加入别的 syscall 记录能使得图更丰富，并可能补充某些遗漏。

---

我们初步对预处理过程走了一遍，还有一个问题:
以下是一条 evt.type 为 read 类型的日志，按照脚本的处理逻辑，该日志的 fd.name 对象会被标记为 FILE 类别。但是这个看起来更像是 NET 类别

{"evt.args": "fd=19(<4t>127.0.0.1:57570->127.0.0.1:39905) size=65536 ", "evt.num": 1278, "evt.time": 1648471346299700795, "evt.type": "read", "fd.name": "127.0.0.1:57570->127.0.0.1:39905", "proc.cmdline": "node /root/.vscode-server/bin/ccbaa2d27e38e5afa3e5c21c1c7bef4657064247/out/bootstrap-fork --type=extensionHost --uriTransformerPath=/root/.vscode-server/bin/ccbaa2d27e38e5afa3e5c21c1c7bef4657064247/out/vs/server/uriTransformer.js", "proc.name": "node", "proc.pcmdline": "node /root/.vscode-server/bin/ccbaa2d27e38e5afa3e5c21c1c7bef4657064247/out/vs/server/main.js --start-server --host=127.0.0.1 --enable-remote-auto-shutdown --port=0 --connection-secret /root/.vscode-server/.ccbaa2d27e38e5afa3e5c21c1c7bef4657064247.token", "proc.pname": "node", "is_warn": false}

以下是一条 sendmsg 类别日志

{'evt.args': 'fd=12(<4u>127.0.0.1:53512->127.0.0.53:53) size=90 tuple=127.0.0.53:53->127.0.0.1:53512 ', 'evt.num': 1555090, 'evt.time': 1648196482171884136, 'evt.type': 'sendmsg', 'fd.name': '127.0.0.1:53512->127.0.0.53:53', 'proc.cmdline': 'systemd-resolve', 'proc.name': 'systemd-resolve', 'proc.pcmdline': 'systemd nospectre_v2 nopti noibrs noibpb', 'proc.pname': 'systemd'}

这个在处理过程中有区分吗？又或者说，这个节点类型会产生影响吗？

[0xllssFF]

感谢解答 :D，我想适当加入别的 syscall 记录能使得图更丰富，并可能补充某些遗漏。

我们初步对预处理过程走了一遍，还有一个问题: 以下是一条 evt.type 为 read 类型的日志，按照脚本的处理逻辑，该日志的 fd.name 对象会被标记为 FILE 类别。但是这个看起来更像是 NET 类别

{"evt.args": "fd=19(<4t>127.0.0.1:57570->127.0.0.1:39905) size=65536 ", "evt.num": 1278, "evt.time": 1648471346299700795, "evt.type": "read", "fd.name": "127.0.0.1:57570->127.0.0.1:39905", "proc.cmdline": "node /root/.vscode-server/bin/ccbaa2d27e38e5afa3e5c21c1c7bef4657064247/out/bootstrap-fork --type=extensionHost --uriTransformerPath=/root/.vscode-server/bin/ccbaa2d27e38e5afa3e5c21c1c7bef4657064247/out/vs/server/uriTransformer.js", "proc.name": "node", "proc.pcmdline": "node /root/.vscode-server/bin/ccbaa2d27e38e5afa3e5c21c1c7bef4657064247/out/vs/server/main.js --start-server --host=127.0.0.1 --enable-remote-auto-shutdown --port=0 --connection-secret /root/.vscode-server/.ccbaa2d27e38e5afa3e5c21c1c7bef4657064247.token", "proc.pname": "node", "is_warn": false}

以下是一条 sendmsg 类别日志

{'evt.args': 'fd=12(<4u>127.0.0.1:53512->127.0.0.53:53) size=90 tuple=127.0.0.53:53->127.0.0.1:53512 ', 'evt.num': 1555090, 'evt.time': 1648196482171884136, 'evt.type': 'sendmsg', 'fd.name': '127.0.0.1:53512->127.0.0.53:53', 'proc.cmdline': 'systemd-resolve', 'proc.name': 'systemd-resolve', 'proc.pcmdline': 'systemd nospectre_v2 nopti noibrs noibpb', 'proc.pname': 'systemd'}

这个在处理过程中有区分吗？又或者说，这个节点类型会产生影响吗？

It has little effect. Because the embedding operation of the network and file has no difference.