Table 1: eBPF flow filtering configuration options
+ +Note: + +- A rule cannot include both `ports` and either `sourcePorts` or `destPorts` simultaneously. +- The number of eBPF flow filter rules is capped at `16` to maintain efficient memory usage when this feature is enabled. +- Validation webhook rejects rules containing duplicate CIDRs. +- Supports both `IPv4` and `IPv6` formats. +- If users wish to match any CIDR, the default `0.0.0.0/0` (Null CIDR) can be used. + +The example below demonstrates various filtering options using multi-rule filters: + +```yaml +agent: + type: eBPF + ebpf: + flowFilter: + enable: true + rules: + - action: Accept + cidr: 10.128.0.0/24 + peerCIDR: 10.129.0.0/24 + ports: '443,6443' + protocol: TCP + sampling: 10 + - action: Accept + cidr: 10.129.0.1/24 + ports: 53 + protocol: UDP + sampling: 20 + - action: Reject + tcpFlags: SYN + cidr: 10.130.0.0/24 + protocol: TCP + sourcePorts: 80-100 + - action: Accept + cidr: 172.30.0.0/16 + protocol: SCTP + pktDrops: true + - action: Reject + cidr: 8.8.8.8/32 + protocol: ICMP + icmpType: 8 // ICMP Echo request packet +``` + +2- Packet Inspection – Extract relevant packet attributes within an eBPF program. + +3- Early Flow Filtering – +Skip or Allow packets based on predefined conditions before doing further ebpf packets processing. +The Following Diagram shows how eBPF filtering is done + +})
+Figure 1: eBPF Flow Filtering Packet Processing
+ +eBPF flow filtering uses a specific map type called `BPF_MAP_TYPE_LPM_TRIE`, which enables prefix-based matching. +For more details on LPM maps, refer to [BPF_MAP_TYPE_LPM_TRIE](https://docs.ebpf.io/linux/map-type/BPF_MAP_TYPE_LPM_TRIE/). + +When a packet traverses the eBPF stack, its `srcIP` undergoes a longest prefix match lookup in the `filter_map`. +If a specific rule matches, the packet is further evaluated against additional fields, +potentially triggering another longest prefix match for `dstIP` +in the `peer_filter_map` only if peer IP filtering is enabled. +Once all matching criteria are met, the corresponding filter rule action is executed—either +allowing the flow or rejecting it—while updating global flow filtering metrics for debugging purposes. + +This process is then repeated with `dstIP` as the primary lookup key in the `filter_map`. If peer IP filtering is enabled, +`srcIP` is checked against the `peer_filter_map`. If a match is found, +the rule’s action is executed, and relevant statistics are updated. + +When the `sampling` configuration is specified in a flow filter rule, +the matching flows will use this sampling rate, overriding the rate +configured in the `flowcollector` object. + +The dual matching approach ensures bidirectional flow tracking, enabling users to correlate and monitor both +directions of a given flow. + +In cases where no matching rules exist, the default behavior is to reject the flow. +However, users can customize the handling of unmatched flows by adding a catch-all entry +`(cidr: 0.0.0.0/0)` and specifying a global action to enforce their preferred policy. + +## Key Use Cases + +🚀 Reducing Observability Overhead – Avoid logging irrelevant flows in high-traffic Kubernetes clusters. + +🔐 Security Filtering – Focus on anomalous or suspicious traffic while ignoring normal flows. + +🌐 Network Performance Monitoring – Capture only high-latency or dropped-packet flows for troubleshooting. + +### Filter EastWest and NorthSouth flows + +Given a cluster with Services subnet on `172.30.0.0/16` and Pods subnet on `10.128.0.0/16` and `10.129.0.0/16`, +we can set specific sampling rates and filters to keep and sample exactly what we want. +For instance, allow traffic to service IP `172.30.100.64:80` with a sampling rate of `10`. +Permit communication between pods in the `10.128.0.0/16` and `10.129.0.0/16` subnets with a sampling rate of `20`. +Also Allow pods within the `10.128.0.0/14` subnet attempt to ping an external IP `8.8.8.8`, +this flow should be allowed with a sampling rate of `30`. +Reject all other traffic `default action` + +```yaml +agent: + type: eBPF + ebpf: + flowFilter: + enable: true + rules: + - action: Accept + cidr: 172.30.0.0/16 + peerCIDR: 10.128.0.0/14 + sampling: 10 + - action: Accept + cidr: 10.128.0.0/14 + peerCIDR: 10.128.0.0/14 + sampling: 20 + - action: Accept + cidr: 8.8.8.8/32 + sampling: 30 + peerCIDR: 10.128.0.0/14 + protocol: ICMP + icmpType: 8 +``` + +})
+Figure 2: eBPF Flow Filtering Kubernetes NorthSouth and EastWest Flows
+ +### Filter flows with packet drops + +Let's filter Kubernetes service flows that include a packet drop and discard all others. +For this use case, the `PacketDrop` feature must be enabled with eBPF in `privileged` mode, +as demonstrated in the configuration below. + +```yaml +agent: + type: eBPF + ebpf: + privileged: true + features: + - PacketDrop + flowFilter: + enable: true + rules: + - action: Accept + cidr: 172.30.0.0/16 + pktDrops: true + - action: Reject + cidr: 0.0.0.0/0 +``` + +})
+Figure 3: eBPF Flow Filtering Kubernetes Services with Packet Drop
+ +### Filter TCP flows using TCP Flags + +Filtering based on TCP flags is an effective method to detect and mitigate TCP SYN flood attacks in a cluster. +A SYN flood is a Denial-of-Service (DoS) attack where an attacker overwhelms a target system by sending a large +number of SYN packets without completing the three-way handshake, +depleting system resources and disrupting legitimate connections. + +```yaml +agent: + type: eBPF + ebpf: + flowFilter: + enable: true + rules: + - action: Accept + cidr: 0.0.0.0/0 + protocol: TCP + tcpFlags: SYN + sampling: 1 +``` + +})
+Figure 4: eBPF Flow Filtering TCP flows using TCP flags
+ +### Filter DNS query over ports 53 and 5353 for both TCP and UDP + +This Use case involves capturing DNS flows over both `TCP` and `UDP`, +with the option to enable the `DNSTracking` feature for enhanced DNS latency insights. + +```yaml +agent: + type: eBPF + ebpf: + features: + - DNSTracking + flowFilter: + enable: true + rules: + - action: Accept + cidr: 0.0.0.0/0 + sourcePorts: '53,5353' + sampling: 1 +``` + +})
+Figure 5: eBPF Flow Filtering DNS flows
+ +## Conclusion + +By filtering flows at the kernel level with eBPF, we maximize efficiency, +ensuring only the most relevant data is processed and stored. +This approach is critical for scalability, cost reduction, and real-time network insights. + +## Feedback + +We hope you liked this article! +Netobserv is an open source project [available on github](https://github.com/netobserv). +Feel free to share your [ideas](https://github.com/netobserv/network-observability-operator/discussions/categories/ideas), [use cases](https://github.com/netobserv/network-observability-operator/discussions/categories/show-and-tell) or [ask the community for help](https://github.com/netobserv/network-observability-operator/discussions/categories/q-a). diff --git a/pom.xml b/pom.xml index 0c3ba6a..5836c77 100644 --- a/pom.xml +++ b/pom.xml @@ -69,7 +69,12 @@