eBPF for API Security: The Devil’s in the Details

Application Programming Interfaces (APIs) facilitate seamless communication and data exchange between various software components, forming the connective tissue between modern enterprise applications. With the increasing dependence on applications and APIs, robust security measures are essential. The extended Berkeley Packet Filter (eBPF) is a promising technology for API security and traffic inspection. This blog explores how eBPF enhances API security, its limitations, and how to achieve comprehensive API protection.

The Current Application and API Landscape

Recent studies indicate that Node.js is the most popular language for containerized environments, while Java continues to dominate non-containerized settings. Of course, Python, Go, Ruby, C++, and .NET are still in common use. An API security solution suitable for the current diversity in programming languages and deployment environments necessarily must be adaptable to the heterogeneous technology stacks in use in enterprise environments.

API Discovery and Traffic Analysis in API Security

A successful API security program relies on a solution with the ability to discover and inspect API traffic. API discovery involves identifying, understanding, and building a continuous inventory of all APIs – internal, external, and third-party – within an organization, including details such as endpoints, supported methods, parameters, and authentication mechanisms. Capturing HTTP traffic is straightforward, but decrypting HTTPS traffic presents additional challenges in order to maintain security and low latency. Decrypting HTTPS traffic often requires interception at the proxy/load balancer level or within the application itself.

Introducing eBPF for API Security

eBPF, or extended Berkeley Packet Filter, is a powerful technology integrated into the Linux kernel that allows programs to execute safely within kernel space without modifying the kernel source code or loading kernel modules. This makes it a highly attractive option for efficient monitoring, networking, and security in Linux systems. One significant advantage of eBPF with regard to API security is its ability to inspect TLS/HTTPS traffic without terminating the TLS connection.

Challenges and Potential Problems with eBPF in API Security

Despite its potential, eBPF is severely limited in the environments in which it can operate and what applications it can protect. As with many things, the devil’s in the details:

1. Implementation Restrictions

• Node.js Applications: eBPF is incompatible with Node.js due to the removal of USDT (User Statically Defined Tracing) probes, challenges posed by JIT compilation, and a lack of active maintainers for eBPF support.
• Java Applications: eBPF cannot work with the Java Virtual Machine (JVM) because it creates an abstraction layer that hinders eBPF’s interaction with the application. Java’s custom TLS implementation and JIT compilation further complicate the situation.
• Statically Linked Libraries: eBPF is ineffective with applications using statically linked SSL libraries, such as Envoy and Istio, due to the absence of dynamic symbols and predefined attachment points.
• Other Language-Specific Challenges: While Python, Go, and Ruby applications generally support eBPF-based TLS capture, C++ and .NET applications offer only partial support depending on their specific SSL library implementation.

2. Operational Limitations

• Use of eBPF for blocking API attacks poses risks of instability, incompatibility, and negative performance.
• The maintenance of hooking techniques requires ongoing updates with new SSL libraries, and monitoring functions can break without notice. This problem increases in scope as the API footprint grows.

Application and Proxy Support for eBPF

Given the limitations outlined above, the following is a support matrix for inspecting TLS traffic with eBPF:

Application Support Matrix

Proxy Support Matrix

Beyond Edge Cases – More Comprehensive Approaches to API Security

While eBPF is a promising technology, considering the limitations outlined above, organizations should adopt a multidimensional approach to API security:

Agent-based Integration

This method involves instrumenting applications in order to access TLS traffic.

• Pros:
  • Can be integrated into the software development lifecycle (SDLC).
• Cons:
  • Can impact performance as it must be run on the same device as the application.
  • Only protects individually-instrumented applications; broad coverage requires significant development effort.
  • Application functionality can be impacted, even in monitoring mode.

Network-based Agentless Integration

Similar to a WAF in operation, this method offers the broadest API and application coverage. Integration at the network edge, either as a reverse proxy or integration with the existing API gateway, load balancer, or CDN, enables comprehensive inspection of traffic before it reaches the application.

• Pros:
  • Stops attacks before they reach the application.
  • Broad coverage protects an organization’s entire suite of applications.
  • Easy to deploy and manage centrally.
• Cons:
  • Requires alternate approaches to inspect encrypted traffic.

Use the Right Tool for the Job

eBPF offers promising capabilities for highly-specific API security edge cases, particularly in Linux environments and with certain programming languages. eBPF is clearly not a “hammer” to pound every “nail.” The heterogeneous nature of enterprise application environments demands a multifaceted approach to API security to maximize comprehensive API and application coverage.

Organizations should evaluate their specific technological stack, infrastructure, security requirements, and operational constraints when designing their API security program. A network-based agentless approach provides the broadest coverage and enables organizations to address the vast majority of API security needs. It provides near-complete freedom with regard to operating systems, programming languages, and architectures, enabling organizations to quickly and easily reach their API security goals.

Platforms such as Cequence’s Unified API Protection offer a multi-phased approach to discovery, compliance, governance, and protection, supporting all applications, traffic types (encrypted and unencrypted), operating systems, and environments.

Additional Resources

Please see the following Cequence Knowledge Base articles for additional details.

• eBPF Integration Overview
• Leveraging eBPF for API Security in Enterprise Applications: Challenges and Solutions
• Configuring eBPF with Cequence TLS Sensor Package
• eBPF Sensor installed as a DaemonSet
• Configuring eBPF with Gigamon Precryption
• eBPF Sensor installed as a Linux package