eBPF Observability, Linux Telemetry and Detection Engineering — DedSec Project
eBPF Observability, Linux Telemetry and Detection Engineering eBPF allows constrained programs to observe or influence selected kernel events depending on hook and privilege. For defenders…
eBPF allows constrained programs to observe or influence selected kernel events depending on hook and privilege. For defenders it enables powerful telemetry, but it also introduces governance, performance, and trust questions. This module focuses on safe observability and detection design.
Learning objectives
By the end of this module you should be able to:
- Explain Program and map model and connect it to a concrete trust boundary or security invariant.
- Explain Verifier and privilege and connect it to a concrete trust boundary or security invariant.
- Explain Tracepoints and probes and connect it to a concrete trust boundary or security invariant.
- Explain Network hooks and connect it to a concrete trust boundary or security invariant.
- Explain Telemetry design and connect it to a concrete trust boundary or security invariant.
- Explain Tamper and blind spots and connect it to a concrete trust boundary or security invariant.
Deep concepts
1. Program and map model
eBPF programs run at defined hooks and communicate through maps. Program type, verifier constraints, helpers, and attachment point determine what data is visible and what actions are possible.
2. Verifier and privilege
The verifier reasons about program safety properties such as bounded execution and memory access. Kernel configuration and privilege determine who may load programs; organizations should treat eBPF loading as a privileged administration capability.
3. Tracepoints and probes
Stable tracepoints are preferable when available. Kprobes/uprobes can expose implementation detail but may be more version-sensitive. Choose the least fragile observation point that answers the detection question.
4. Network hooks
XDP and traffic-control hooks can observe packets early in the stack. Security teams should separate passive measurement from enforcement and test performance/failure behavior before production use.
5. Telemetry design
Collect fields that support a hypothesis: process lineage, executable identity, UID, namespace/container, file path, network tuple, capability change, or syscall class. More events are not automatically better detections.
6. Tamper and blind spots
An agent running with high privilege can itself become a sensitive component. Protect loader/configuration paths, record program changes, and understand what happens if telemetry is disabled or overloaded.
7. Performance
High-frequency hooks can generate enormous volume. Use sampling, aggregation, maps, filters, rate limits, and bounded cardinality to protect the host and downstream pipeline.
8. Detection lifecycle
Write the behavioral hypothesis first, validate with controlled activity, measure expected false positives, version the rule, and keep a known-good replay/test fixture.
Authorized exercises
Exercise 1 — Write a detection hypothesis for unexpected interactive shells in a server container and specify which kernel/process fields would prove or refute it—without collecting real user content
Write a detection hypothesis for unexpected interactive shells in a server container and specify which kernel/process fields would prove or refute it—without collecting real user content.
Exercise 2 — Compare audit logs, process accounting, and eBPF telemetry for the same harmless process-start event in a lab
Compare audit logs, process accounting, and eBPF telemetry for the same harmless process-start event in a lab.
Exercise 3 — Design a rollback plan for an observability agent that begins consuming excessive CPU or producing unbounded event volume
Design a rollback plan for an observability agent that begins consuming excessive CPU or producing unbounded event volume.
Knowledge checks
- Explain the most important trust boundary in eBPF Observability, Linux Telemetry and Detection Engineering without naming a security tool.
- Give one example where cryptographic or authentication success still does not imply authorization success.
- Describe one stale-state or replay condition relevant to this module.
- Identify one telemetry source that can support a strong conclusion and one blind spot it still leaves.
- Explain how you would turn a discovered weakness into a regression test rather than a one-time finding.