Feature Request - CommunityID

[defensivedepth]

Look into generating a Community ID as a new column for socket_events

https://blog.zeek.org/2019/07/an-update-on-community-id.html

https://github.com/corelight/community-id-spec

[zwass]

Just a heads up that I am working on adding this as a function in osquery core. That may render it unnecessary if you are able to just use the function when selecting results from osquery.

[Wajihulhassan]

I have a question on adding CommunityID column in the socket_events table. Currently, zeek-agent uses auditd and openbsm to collect socket events on Linux and macOS, respectively. In both cases, we miss some information when we extract socket information. For example, for connect event we only have the destination IP address and port, and we miss source IP address and port. However, to generate CommunityID we need complete information, i.e. both source and destination IP address/port. Is there a way to solve this problem in zeek-agent? My goal is to correlate host logs (zeek-agent) with network logs (zeek) and CommunityID seems to be a straightforward way to achieve this goal. However, if zeek-agent cannot produce CommunityID then the question is, are there any other ways to derive such correlations? @alessandrogario @rsmmr

[alessandrogario]

The easiest way to implement it is to add new tracers for the bind(), accept() and accept4() system calls and use the gathered data to complete the table output. It is still possible however to end up not having the required data for correlation if the process being traced was started before the Zeek Agent.

[Wajihulhassan]

Not sure if I follow. By "new tracers" you mean something other than Linux auditd such as custom Linux kernel module to intercept those syscalls. Because for example accept call can be traced by auditd; however, my understanding is that we can only extract remote IP address and port from passed sockaddr to accept using auditd alone. right?

[alessandrogario]

You are right! The accept/accept4 syscalls will only return the remote address. Servers however will call bind() first, which can be used to obtain the local address.

Clients are not as nice though, and it's not uncommon for them to just call connect() without using bind() on the socket. A workaround could be to use procfs and attempt to get the missing data from /proc/net/{tcp,udp,tcp6,udp6} by using the inode field, but this introduces race conditions.