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
Application Language | TLS Capture Using eBPF | Reason |
---|---|---|
Node.js | Unsupported | USDT probes have been deprecated |
Java | Unsupported | Uses Native TLS Library |
Python | Supported | Uses OpenSSL Dynamic Library |
Go | Supported | Uses OpenSSL Dynamic Library |
Ruby | Supported | Uses OpenSSL Dynamic Library |
C++ | Partially Supported | Developers can statically or dynamically link with any SSL library |
.NET | Partially Supported | Only Linux implementation of .Net uses OpenSSL library |
Proxy Support Matrix
Proxy | TLS Capture Using eBPF | Reason |
---|---|---|
Nginx | Supported | Uses OpenSSL Dynamic Library |
Apache | Supported | Uses OpenSSL Dynamic Library |
Envoy / Istio | Unsupported | Uses Statically Linked BoringSSL Library |
netty-tcnative (Forked Tomcat Native) | Unsupported | Uses Statically Linked BoringSSL Library |
IIS | Unsupported | Non-Linux Environment |
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
The post eBPF for API Security: The Devil’s in the Details appeared first on Cequence Security.
*** This is a Security Bloggers Network syndicated blog from Cequence Security authored by Shreyans Mehta. Read the original post at: https://www.cequence.ai/blog/api-security/ebpf-for-api-security/