You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's some interest in knowing the amount of data sent/received per process so I've been working on this lately.
There'll be issues and doubts so let this issue serve as a way to group them together.
How it works:
Data sent or received is intercepted via eBPF and stored in a map by pid.
When a connection is destroyed, the collected data is sent to userspace, accumulated by process, and the partial bytes sent to the GUI (server). The entry is deleted from the eBPF map.
In order not to saturate the daemon, the bytes are accumulated on kernel space. Every 5s the counters are resetted and the collected stats sent to userspace.
Note: This information can also be obtained via netlink, but as we only intercept new connections, we'd need to intercept connections destruction anyway.
On the GUI (server), the data is saved to the DB and displayed on the Applications tab:
New features based on this one:
Allow to apply network quotas by process: Allow connections of a process until a limit, or drop connections when a process exceeds a limit.
The PoC works, but as we only intercept new connections, the rule may be delayed (until a new connection is opened).
TODOs:
Order by bytes numerically instead of alphabetically.
Allow to view the bytes, without grouping them.
Delete entries from the ebpf map that hasn't been deleted in a proper way (like when killing a process that had opened connections). Otherwise if the map becomes full, it won't accept new entries and we will miss statistics.
Review if the hooked functions are the correct ones, or are there others that serve better for the task (tcp_cleanup_rbuf vs tcp_recvmsg?).
Note: bytes are grouped per process, but that is not correct. We must group bytes per connection, to be able to know how many bytes were sent to what port, what IP, domain, etc... and then as we know the connections initiated by a process, we'll be able to display the bytes sent by a process.
The text was updated successfully, but these errors were encountered:
Is there some way I can help with this? I find it so useful.
Maybe some hint or documentation where I can start to see to understand how to extend the ebpf module to intercept that data... Or even a documentation about the general overview about the communication ebpf->deamon
I've got a diagram on how the daemon works, not very detailed.. I need to update it because I just created it for myself and some things have changed. I'll post it once updated.
On the other hand, I've been busy testing the next release v1.6.5, but once released, and I'll publish a branch with all the local changes of this feature.
The main functionality is working, but there's a lot of work still to do: (gui)allow to filter by last day, last 7 days, etc, (gui)delete old traffic stats from the db, (daemon)decide if use tcp_revmsg/sendmsg to get the bytes or use tcp_cleanup_rbuf
Right now the bytes are accumulated by pid, but it would be better to group them by connection, to allow to view on the GUI the bytes sent to IPs, domains, ports, etc...
There's some interest in knowing the amount of data sent/received per process so I've been working on this lately.
There'll be issues and doubts so let this issue serve as a way to group them together.
How it works:
Data sent or received is intercepted via eBPF and stored in a map by pid.
When a connection is destroyed, the collected data is sent to userspace, accumulated by process, and the partial bytes sent to the GUI (server). The entry is deleted from the eBPF map.
In order not to saturate the daemon, the bytes are accumulated on kernel space. Every 5s the counters are resetted and the collected stats sent to userspace.
Note: This information can also be obtained via netlink, but as we only intercept new connections, we'd need to intercept connections destruction anyway.
On the GUI (server), the data is saved to the DB and displayed on the Applications tab:
New features based on this one:
TODOs:
[18/09/2024] the branch with this feature working: https://github.com/evilsocket/opensnitch/tree/send-recv-bytes?tab=readme-ov-file
The text was updated successfully, but these errors were encountered: