mattereppe
commented
2 years ago Adding the process ID and name would require to add a hook to the kernel functions for initiating and receiving connections. This is not implemented in this tool (and likely it won't) because it is conceived to inspect forwarded traffic, which is not initiated nor terminated on the node. This is the reason why the tool parses packet headers, which would not be necessary in case the flows are terminated on the node where it is running, because in this case the same information could be more efficiently retrieved by hook on kernel functions. If you are looking for a tool that associates your network flows with process ID and name, you consider libebpfflow, which works this way.
Thank you to point out the OpenSnitch project. I'll certainly consider it in my future work.
Excellent work on your project! And your white paper on this topic was an excellent read. Out of curiosity, how hard would it be to add the process ID and name information for each flow? I know BCC has an example in their networking section for a basic flow, but their script does not have all the flow statistics that yours does. With the easiest way to implement this be to use a second eBPF like BCC's and then combine the process ID and name with the detailed flow data during the merge procedure?
One other project you might be interested in that was not listed in your white paper is OpenSnitch. It is an application firewall for Linux which leverages eBPF to associate flows with applications then uses an NF tables queue to German whether traffic should be accepted or denied. They've been running the project for 3 years but it has matured to a very usable and fairly polished tool.