Security with Extended Berkeley Packet Filter and PAM

March 12, 2020 Corey O'Connor

eBPF and Privileged Access Management (PAM)

Extended Berkeley Packet Filter (ePBF) has been circulating the developer arena for quite some time.  The original BPF was developed nearly three decades ago by US national laboratory research scientists as an architecture for Unix operating systems designed to monitor packet filtering on the host.

Companies like Amazon, Google, Facebook and Netflix are leveraging the Linux kernel extension (eBPF) for various network security and monitoring processes. Why? In short, because it’s super easy to implement and it provides a more secure and restricted environment for the development team.

This technology allows for monitoring within the kernel – you can run user-defined code at the kernel level, safely and without ever having to go deep down the stack and write a kernel module.  It’s a tiny virtual machine that exists inside Linux, supporting various monitoring functions within the kernel. The fact that developers are leveraging this is a great thing from a security perspective.  It’s like the dev team writing an open letter:

Dear Security, Ops and the Business, we care about writing secure and attestable code, we just need your backing and tools that enable it.

One common use case example of this is tcpdump, which displays the packets (TCP/IP) that are traversing through the network of that given Linux instance.  Executing tcpdump requires root or “sudo” access, primarily due to the Linux capabilities involved as part of this process.  However, the sudo command can provide a false sense of security.  In theory, sudo is designed to improve the security around root access, but, in reality, there are many drawbacks to sudo that bring its security capabilities into question.

In many organizations, the individual who requires root access is the same person who configures sudo policies, so there is no separation of duties.  Even if separation of duties is in place, the sudoers file is still stored locally, which presents a significant security risk.  Users can easily escalate to root to access the sudoers file and change policies to grant additional permissions, delete logs to cover their tracks and cause significant damage to the business.  The end result: no integrity to the data that sudo is collecting.

eBPF in Containerized Environments

Nowadays the use of LXC (Linux Containers) is essentially universal.  By simple definition, LXC are abstractions of physical hardware within the Linux kernel.  Leveraging Linux kernel structures such as namespaces and control groups (cgroups), Docker and other container runtimes allows you to achieve isolation and abstraction – similar to what you get with virtual machines.  This logical isolation layer is a good thing for application delivery.

If you’re reading this blog, chances are you understand that containers are ephemeral in nature.  They can be deployed and decommissioned in hours or even minutes, which makes both management and security quite challenging.

The fact that all LXC running on the same physical hardware share a single kernel makes the use of eBPF for monitoring and securing applications an extremely useful approach to securing containerized environments.  Installing a secure computing mode (seccomp) filter for eBPF is a best practice that folds in the principle of least privilege to minimize what’s exposed at the kernel level, limiting what system calls can be made.

CyberArk understands the importance of ensuring that consistent security policies are enforced, which is why we enable our customers to customize their seccomp files to fit their security preferences, allowing them to import these settings directly into containers themselves via Docker Compose (see Figure 1).  Doing this prevents any pre-defined security policies from being changed, which in turn mitigates the risk of a larger-scale attack by limiting an attacker’s ability to make system calls from the container layer.

Figure 1. This is a demonstration of a project which allows CyberArk users to customize their seccomp.

Technology like eBPF is a great impetus for stability, visibility and security and having a defense in depth approach is a requirement for proactive protection against advanced attacks.  Developers who use eBPF benefit from performance monitoring and load balancing as well as network traffic information and the laundry list of application-specific data that’s generated.

Security teams benefit from basic user-level actions performed within the shell, which is provided out-of-the-box, and can get even greater security by leveraging CyberArk Core Privileged Access Security for more granular controls in both Unix and Linux systems.

Using eBPF for system monitoring provides great visibility and minimizes the need for remote privileged access, but if that access is required, it should be managed and controlled.  Combining the use of eBPF with CyberArk privilege access management (PAM) solutions provides deep privileged user control and accountability across all of Unix/Linux instances both in the cloud or on-premises.  Contact us to see a technical demonstration of how the CyberArk solution can help enable your business.

Previous Article
A Message from Our CEO: Working Together in Unprecedented Times
A Message from Our CEO: Working Together in Unprecedented Times

The CyberArk Response to COVID-19 We are living in an unprecedented time as the world quickly adjusts to th...

Next Article
A Brief History of Securing the Hybrid Cloud
A Brief History of Securing the Hybrid Cloud

More and more organizations are getting on board with infrastructure as a service and the hybrid cloud and ...