In today's interconnected digital landscape, Application Programming Interfaces (APIs) serve as the backbone of modern enterprise applications, facilitating communication and data exchange between various software components. As reliance on APIs grows, so does the need for robust API security measures. One emerging technology that has gained attention in the realm of API security is eBPF (extended Berkeley Packet Filter). This article explores the potential of eBPF for enhancing API security, its limitations, and an enhanced approach for comprehensive API protection.

Understanding the API Landscape

Before delving into security measures, it's crucial to understand the current state of API usage in enterprise environments. According to recent studies, NodeJS has emerged as the most popular language for containerized environments, while Java maintains its dominance in non-containerized settings. This diversity in programming languages and deployment environments underscores the need for a versatile API security solution that can adapt to various technological stacks.

Source: https://www.datadoghq.com/container-report/

The Importance of API Discovery and Traffic Inspection

A fundamental aspect of API security is the ability to discover and inspect API traffic. API discovery involves identifying, documenting, and understanding all internal, external, and third-party APIs used within an organization. This process uncovers critical details such as endpoints, supported methods, parameters, and authentication mechanisms. While capturing HTTP traffic is relatively straightforward, decrypting HTTPS traffic presents unique challenges, often requiring interception at the proxy/load balancer level or within the application itself.

Enter eBPF: A Promising Technology for API Security

eBPF, or extended Berkeley Packet Filter, is a powerful and flexible technology integrated into the Linux kernel. It allows programs to run safely within kernel space without modifying the kernel source code or loading kernel modules. This capability makes eBPF an attractive option for efficient monitoring, networking, and security in Linux systems.

One of eBPF’s key advantages in the context of API security is its potential to inspect TLS/HTTPS traffic without decryption. This is achieved by hooking into key functions in TLS libraries using a technique called uprobes (user-space probes). For instance, with OpenSSL, eBPF can attach uprobes to functions like SSL_read and SSL_write to capture plaintext data before encryption or after decryption.

Limitations and Challenges of eBPF in API Security

Despite its potential, eBPF faces several limitations when it comes to API security, particularly in certain application environments:

1. Onboarding Challenges
   1. NodeJS Applications: eBPF currently does NOT work with NodeJS 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.
   2. Java Applications: eBPF does NOT work with Java Virtual Machine (JVM) as it creates an abstraction layer that makes it difficult for eBPF to interact directly with the application. Java's custom TLS implementation and JIT compilation further complicate matters.
   3. Statically Linked Libraries: eBPF does NOT work with applications using statically linked SSL libraries, such as Envoy and Istio, due to the lack of dynamic symbols and predefined attachment points.
   4. Other Language-Specific Challenges: While Python, Go, and Ruby applications generally support eBPF-based TLS capture, C++ and .NET applications present partial support depending on their SSL library implementation.
2. Ongoing Challenges
   1. While eBPF is capable of blocking API attacks, it creates a huge risk of instability, incompatibility, and negative performance affects.
   2. Ongoing maintenance of such hooking techniques requires constant upkeep with new SSL libraries and can break the monitoring function without notice.

Note: Be sure to check with your eBPF vendor if they are capable of blocking in addition to simply monitoring. Many eBPF implementations are passive-only and do not support blocking.

Application and Proxy Support for eBPF

Due to the limitations listed above, we’re left with the following support matrix for inspecting TLS traffic with eBPF.

Application Support Matrix

Proxy Support Matrix

Alternative Approaches to API Security

Given the limitations of eBPF in certain scenarios, organizations need to consider a multi-faceted approach to API security:

RASP-like Agent-based Integration

This method takes an application instrumentation approach to get access to the TLS traffic.

• Pros
  • Integrates into the software development lifecycle (SDLC)
• Cons
  • Must be run on the same device as the application (potentially impacts performance).
  • Limited to protecting individual applications rather than providing broad coverage.
  • Can potentially impact application functionality even in monitoring mode.

WAF-like Agentless Integration

The fastest method for broadest coverage provides integration at the network edge, either as a reverse proxy or integration with the existing API Gateway, Load Balancer or a CDN. It sits in front of applications can facilitate traffic inspection before it reaches the application.

• Pros
  • Provides protection at common chokepoints on the network, blocking known attacks before they reach the application.
  • Can protect an organization's entire suite of applications.
  • Easier to deploy and manage centrally.
• Cons
  • Requires alternate approaches for encrypted traffic.

Conclusion

While eBPF offers some promising capabilities for specific API security edge cases, e.g., Linux environments and with certain programming languages, it is not a one-size-fits-all solution. The diverse landscape of enterprise applications, ranging from NodeJS and Java to statically linked libraries, necessitates a more comprehensive approach to API security.

Organizations should assess their specific technological stack, security requirements, and operational constraints when designing their API security strategy. You need to start with an approach that provides the widest coverage and then start chasing the long tail of unsupported API form factors using alternate approaches. Users should choose a platform that supports all applications, all kinds of traffic (encrypted and unencrypted), and supports all operating systems and environments. This can be rolled out in phases based on the severity and importance of the business application. One such solution is Cequence’s Unified API Protection platform which offers a multi-phased approach to discovery, compliance, governance, and protection.

As the field of API security continues to evolve, staying informed about new developments and regularly updating security technologies with the latest technological enhancements are key to protecting all, rather than some, of your organization’s APIs.

Further Reading

• eBPF Integration Overview
• 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

References

• https://ebpf.io
• https://www.youtube.com/watch?v=sG72GWdo9Hs
• https://www.envoyproxy.io/docs/envoy/latest/faq/build/boringssl
• https://tracingsummit.org/ts/2023/files/Tracing_Summit_2023-Dom_Del_Nano.pdf
• https://github.com/netdata/netdata/issues/12027
• https://learn.microsoft.com/en-us/defender-endpoint/linux-support-ebpf