eBPF
To enable seamless auditing capabilities for Linux endpoints and containers, Uptycs has implemented Extended Berkeley Packet Filter (eBPF) based auditing techniques. eBPF is a powerful auditing system to monitor suspicious activities by tracing networks, sockets, and process activities from hosts or containers running on those hosts.
What's the problem trying to solve?
In order to detect suspicious or malicious events, we need to gather a lot of telemetry from a running system. We use this telemetry to understand the ongoing system calls, active processes, and how the system is behaving. There are different approaches we can use for gathering this information on a Linux system, however they are not all created equal.
The ideal place to gather information on events are directly inside the kernel. This can be done with mainly two methods: the Linux Auditing subsystem and the alternative method to gather this telemetry is with eBPF, which excels at high-performance kernel instrumentation and improved observability.
What is eBPF and why is it useful?
Berkeley Packet Filter is a Linux kernel subsystem that allows a user to run a limited set of instructions on a virtual machine running in the kernel. It is divided between classic BPF (cBPF) and extended BPF (eBPF, or simply BPF). The older cBPF was limited to observing packet information, while the newer eBPF is much more powerful, allowing a user to do things such as modify packets, change syscall arguments, modify userspace applications, and more.
Supported Platforms and kernels for Uptycs-eBPF
To use Uptycs-eBPF based auditing techniques, ensure that your Linux endpoints are updated to the osquery version 4.2.xx.xx and above.
The supported kernel versions are:
Please refer the help document for the recent product update and version we support : https://protectcs.uptycs.io/help/docs/contents/osquery/ebpf/#supported-platforms-and-kernels-for-uptycs-ebpf
Deployments using linux audit subsystem as source of events for Uptycs osquery
For those who does not use eBPF or using linux audit system, the suggestions are:
- Stop the auditd service
- Configure the 'audit' feature in (configuration->flags) in osquery to perform those auditd related things.
When running Uptycs osquery on an endpoint with the event collection capability enabled the auditd service must be stopped. Also, auditd service is stopped before launching the osqueryd service. When Uptycs osquery is deployed, osquery pushes a set of audit rules to the audit subsystem. The rules pushed monitor process, socket, file and user activity. The volume of telemetry is very high and can overwhelm Auditd service if enabled. If Auditd is also enabled the events that match the rule pushed by osquery get sent to the Auditd service. The Auditd service then writes these to a file. The high volume of telemetry delivered to the Auditd subsystem can cause a significant spike in CPU usage and disk IO. The high disk IO can starve the other services of disk access. This could make the endpoint unresponsive.
Note: This applies to deployments where the linux audit subsystem is the source of events for Uptycs osquery. This note does not apply to deployments where Uptycs osquery is configured to use the eBPF subsystem and the Linux kernel on the endpoint supports eBPF.
What is the supported kernel version for CentOS to use Uptycs-eBPF?
- Supported kernel version for CentOS is from kernel 3.10 and above (CentOS 7 and above). CentOS 7 is the same as RHEL 7
- RHEL 7 doesn't support eBPF fully, however eBPF is enabled only for tracing purposes in Rhel 7, which allows attaching eBPF programs to probes, tracepoints and perf events. Other use cases such as eBPF socket filters or eXpress DataPath (XDP) are not enabled.
- Since we are using eBPF only for tracing purposes, for RHEL 7 and above we recommended using eBPF as it is more efficient and it support FIM with auditd.