IBSR - Inline Block Simulation Report
IBSR is a kernel-level shadow-mode security validation system for network traffic.
It runs at the XDP/eBPF layer and observes live TCP traffic, collecting metrics that would inform inline enforcement decisions - without enforcing anything.
IBSR exists to generate evidence that inline enforcement could be safe before it is allowed to act.
What IBSR Does
- Attaches an XDP/eBPF program to a network interface
- Observes TCP packets at the earliest possible point in the kernel
- Aggregates per-source-IP metrics (SYN, ACK, RST, packets, bytes)
- Writes structured snapshots to disk for offline analysis
- Passes traffic on - business as usual
What IBSR Is Not
| Not This | Why |
|---|---|
| Firewall | No packet drops, no enforcement |
| IPS | No signatures, no blocking |
| Real-time dashboard | Batch snapshots, offline analysis |
| Threat intelligence consumer | No external feeds, pure observation |
IBSR does not protect systems. It validates whether protection could be safely applied.
Why IBSR Exists
Inline enforcement is powerful but dangerous without proof.
Most security systems operate reactively and enforce policies without demonstrating mechanical correctness or measuring blast radius.
IBSR answers one question:
“What would have happened if conservative inline rules were enforced?”
By running in shadow mode on production traffic, IBSR generates evidence for:
- False positive surface - legitimate traffic that would be blocked
- Candidate block rules - sources exhibiting abusive patterns
- Counterfactual impact - percentage of traffic affected
Status & Maturity
IBSR is early-stage software.
It is currently used in:
- controlled pilots
- evaluation environments
- safety and feasibility testing
IBSR is intentionally limited in scope and functionality.
Interfaces, outputs, and tooling may change as the system evolves.
It is not a general-purpose security product and should not be relied on for protection.
Intended Use Cases
| Use Case | Description |
|---|---|
| Pilot deployments | Observe traffic patterns before considering enforcement |
| Validator infrastructure | Collect RPC endpoint traffic data for analysis |
| Edge/ingress systems | Shadow-mode observation on load balancers |
| Baseline establishment | Generate evidence for future enforcement decisions |
Pilot Workflow
In pilot deployments, the workflow is:
- Collect: IBSR runs on your infrastructure, collecting traffic snapshots
- Upload: Scheduled uploads send snapshots to your S3 bucket using
ibsr-export - Report: NullRabbit generates reports from uploaded data
- Review: You receive finished reports - no analysis required on your end
The collector runs unattended once configured. There are no dashboards to watch and no logs to tail.
Architecture Overview
+-----------------------------------------------------------------+
| Target Host |
| |
| +-------------+ +--------------+ +------------------+ |
| | Network |--->| XDP/eBPF |--->| ibsr collect | |
| | Interface | | (XDP_PASS) | | (userspace) | |
| +-------------+ +--------------+ +--------+---------+ |
| | | |
| Counter updates Snapshots |
| | | |
| +------v------+ +----v----+ |
| | BPF LRU Map | | Disk | |
| | (per-IP) | | JSONL | |
| +-------------+ +----+----+ |
+-------------------------------------------------|---------------+
|
+-------------------+
v
+--------------------+
| ibsr-export s3 |
| (scheduled upload) |
+---------+----------+
|
v
+--------------------+
| Customer S3 Bucket |
| (snapshots) |
+---------+----------+
|
v
+--------------------+
| NullRabbit |
| (report generation)|
+---------+----------+
|
v
+--------------------+
| Customer receives |
| final reports |
+--------------------+
Documentation
| Document | Description |
|---|---|
| Installation | System requirements and installation methods |
| S3 Upload | Upload snapshots using ibsr-export |
| Reporting | Offline reporting workflow |
| How It Works | Technical deep dive |
| Safety Model | Safety guarantees and risk profile |
| FAQ | Frequently asked questions |
Design Principles
Shadow-only: IBSR never drops, redirects, or modifies packets. All packets return XDP_PASS.
Fail-open: If the collector crashes or the XDP program detaches, traffic continues unaffected.
Bounded resources: LRU map with configurable size ensures memory usage is predictable.
Offline analysis: All decision-making happens offline. No real-time enforcement logic.
Conservative by default: Thresholds and rules err on the side of false negatives over false positives.