DEV Community: Mohamed Zrouga

Meet Orion-Belt, Go ZeroTrust Bastion

Mohamed Zrouga — Thu, 01 Jan 2026 20:46:39 +0000

Stop opening Port 22 to the world. 🛑

In the world of infrastructure, we’ve long accepted a "security tax." If you want your servers to be accessible, you either open holes in your firewall, maintain a complex VPN, or pay thousands for enterprise PAM (Privileged Access Management) tools.

I felt there was a massive gap for a lightweight, developer-centric tool that follows Zero Trust principles without the enterprise bloat. That’s why I built Orion-Belt.

Orion-Belt in Action

Seeing is believing. Here is a quick look at osh (the Orion-Belt SSH client) connecting to a machine that has zero inbound ports open, while the gateway handles the heavy lifting of authentication and recording.

The "Security Tax" of Traditional Access

Most teams handle remote server access in one of three ways, and all of them have a "catch":

Static SSH Keys: Great until a laptop is stolen or an employee leaves. Auditing "who did what" is nearly impossible.
The "Jump Box" (Bastion): A single point of failure. If your bastion is compromised, your whole network is exposed.
VPNs: They give "flat" network access. Once a user is on the VPN, they can often see everything, violating the Principle of Least Privilege.

I wanted something that felt like a modern SaaS (like Teleport or Boundary) but remained self-hosted, open-source, and dead simple.

Feature Comparison: Why Orion-Belt?

How does Orion-Belt stack up against the status quo?

Feature	Orion-Belt (Open Source)	Traditional SSH/VPN	Enterprise Gateways
Inbound Firewall Rules	❌ No (Reverse Tunnel)	✅ Yes (Port 22/VPN)	❌ No (Agent/Tunnel)
Session Recording	✅ Yes (Built-in)	❌ No (Hard to config)	✅ Yes (Built-in)
Access Control	ReBAC (Fine-Grained)	Coarse-Grained	RBAC/ABAC
Temporary Access	✅ Yes (JIT Approval)	❌ No	✅ Yes
Protocol Support	SSH, SCP	SSH, SCP (VPN allows more)	SSH, Kubernetes, Databases, HTTP
Cost	Free (Self-Hosted)	Free	$$$ High
Architecture	Lightweight Go Binary	Standard Utilities	Complex Microservices

How it Works (Under the Hood)

Orion-Belt is built on a Reverse SSH Tunnel architecture. Instead of you reaching into your private network, your servers reach out to the Orion-Belt gateway.

The Agent: A small Go binary runs on your target VMs. It creates an outbound connection to your Orion-Belt server.
The Gateway: The "Brain." It handles authentication, ReBAC (Relationship-Based Access Control), and session recording.
The Client (osh / ocp): CLI tools that feel like standard SSH/SCP but verify permissions with the gateway’s API first.

Because the connection is outbound from the server to the gateway, you can keep Port 22 closed. This effectively hides your infrastructure from automated bot scans and 0-day SSH exploits.

Key Features for Modern Teams

1. ReBAC (Relationship-Based Access Control)

Orion-Belt checks the relationship between the user and the resource. This allows for fine-grained permissions that scale as your team grows.

2. Session DVR-Style Replay

Compliance (SOC2/HIPAA) requires seeing what happened during a session. Orion-Belt records every keystroke at the gateway level. You can replay the entire session later to see exactly what commands were run.

3. JIT (Just-In-Time) Temporary Access

Need a developer to debug a production issue for one hour?

osh --request-access prod-db-01 --duration 1h --reason "Investigating latency"

Admins get a notification, approve the request, and the access automatically expires. No "orphaned" keys left behind.

The Architecture

Client (osh/ocp)
      │
      ▼
Orion-Belt Gateway Server (ReBAC + Session Recording)
      │
      ▼ (Reverse SSH Tunnel)
Agent (on your locked-down servers)

Quick Start

1. Build from source:

git clone https://github.com/zrougamed/orion-belt.git
cd orion-belt && make build

2. Start the Server:
The server acts as your central hub. It uses PostgreSQL to store sessions and permissions.

3. Deploy the Agent:
Drop the agent binary on any server behind a firewall. Once it connects to the gateway, that server is accessible via osh.

I need your feedback!

Orion-Belt is currently in Alpha. It’s functional and stable, but I’m looking for early adopters to help shape the roadmap.

Does this architecture fit your current workflow?
What notification plugins would you like to see (Slack, Discord, Email)?

Check out the repo, leave a ⭐ if you like the concept, and let's discuss in the comments!

GitHub: https://github.com/zrougamed/orion-belt

Final Thoughts
Infrastructure access doesn't need to be a choice between "easy" and "secure." By combining Go's performance with a Zero-Trust architecture, Orion-Belt makes high-end security accessible to everyone.

Building a Security Test Lab with QEMU: From Zero to Network Monitoring

Mohamed Zrouga — Fri, 26 Dec 2025 23:47:51 +0000

Why QEMU for Your Test Lab?

As software engineers and security professionals, we constantly need isolated environments to test new tools, experiment with network configurations, or validate security measures before production deployment. While solutions like VirtualBox and VMware are popular, QEMU offers something special: lightweight, scriptable, headless operation perfect for automation and CI/CD pipelines.

In this guide, I'll walk you through building a complete QEMU-based test lab focused on network security and infrastructure testing. By the end, you'll have a reproducible environment for testing firewalls, monitoring tools, and distributed systems.

What We'll Build

We're creating a multi-VM test lab that simulates a realistic network environment:

Gateway VM: Acts as router/firewall
Application VM: Simulates production workloads
Attacker VM: For security testing and validation

This setup mirrors real-world scenarios where you need to test network policies, intrusion detection, or packet filtering.

Prerequisites

Before we start, ensure you have:

A Linux host (Ubuntu/Debian in examples, but adaptable to any distro)
At least 8GB RAM and 20GB free disk space
Basic command-line familiarity
Sudo access for network configuration

Step 1: Installing QEMU

First, let's get QEMU installed with all necessary components:

# Ubuntu/Debian
sudo apt update
sudo apt install qemu-kvm qemu-utils libvirt-daemon-system virtinst bridge-utils

# Verify installation
qemu-system-x86_64 --version

For other distributions:

# Fedora/RHEL
sudo dnf install qemu-kvm qemu-img libvirt virt-install

# Arch
sudo pacman -S qemu libvirt virt-manager

Add your user to necessary groups to avoid constant sudo:

sudo usermod -aG libvirt,kvm $USER
# Log out and back in for changes to take effect

Step 2: Creating Your First VM - The Gateway

Let's start with the gateway VM, which will be our network's control point.

Creating the Disk Image

# Create a working directory
mkdir -p ~/qemu-lab/images
cd ~/qemu-lab

# Create a 20GB disk image (qcow2 format for snapshots)
qemu-img create -f qcow2 images/gateway.qcow2 20G

Why qcow2? It supports snapshots, copy-on-write, and compression - essential for test environments where you'll want to reset frequently.

Download a Minimal OS

For security testing, I recommend Alpine Linux (lightweight) or Debian netinst:

# Alpine Linux (very lightweight, boots in seconds)
wget https://dl-cdn.alpinelinux.org/alpine/v3.23/releases/x86_64/alpine-virt-3.23.0-x86_64.iso \
  -O images/alpine.iso

# Or Debian if you prefer more familiar tools
# wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.2.0-amd64-netinst.iso \
#   -O images/debian.iso

First Boot and Installation

qemu-system-x86_64 \
  -name gateway \
  -m 1024 \
  -smp 2 \
  -hda images/gateway.qcow2 \
  -cdrom images/alpine.iso \
  -boot d \
  -enable-kvm \
  -nic user,model=virtio \
  -nographic

Flag breakdown:

-name gateway: Identifies your VM
-m 1024: 1GB RAM (adjust based on your needs)
-smp 2: 2 CPU cores
-hda: Primary disk
-cdrom: Installation media
-boot d: Boot from CD-ROM first
-enable-kvm: Hardware acceleration (crucial for performance)
-nic user: Simple NAT networking for installation
-nographic: Console mode (no GUI needed)

Quick Alpine Installation:

# Once booted, login as root (no password)
setup-alpine

# Follow prompts:
# - Keyboard: us
# - Hostname: gateway
# - Network: eth0, dhcp
# - Password: (set a strong one)
# - Timezone: your timezone
# - Disk: sda, sys (use entire disk)

After installation completes, power off the VM (type poweroff).

Step 3: Setting Up Advanced Networking

This is where QEMU shines for security testing. We'll create an isolated network that simulates real infrastructure.

Create a Network Configuration Script

# Create scripts directory
mkdir -p ~/qemu-lab/scripts

# Network setup script
cat > ~/qemu-lab/scripts/setup-network.sh << 'EOF'
#!/bin/bash

# Create an isolated bridge for our test lab
sudo ip link add name br-testlab type bridge
sudo ip addr add 10.0.100.1/24 dev br-testlab
sudo ip link set br-testlab up

# Enable IP forwarding (so gateway can route)
sudo sysctl -w net.ipv4.ip_forward=1

# Create TAP interfaces for VMs
for i in 0 1 2; do
  sudo ip tuntap add tap$i mode tap user $USER
  sudo ip link set tap$i master br-testlab
  sudo ip link set tap$i up
done

echo "Test lab network ready: 10.0.100.0/24 on br-testlab"
EOF

chmod +x ~/qemu-lab/scripts/setup-network.sh

you will end up with this network topology

10.0.100.1/24 Network
       |
   [Bridge](br-testlab)
    /   |    \
  TAP0 TAP1 TAP2
  VM1  VM2   VM3

Characteristics:

VMs are on SAME subnet as host
VMs are "visible" to external network

Network Teardown Script

cat > ~/qemu-lab/scripts/teardown-network.sh << 'EOF'
#!/bin/bash

# Remove TAP interfaces
for i in 0 1 2; do
  sudo ip link set tap$i down 2>/dev/null
  sudo ip link delete tap$i 2>/dev/null
done

# Remove bridge
sudo ip link set br-testlab down 2>/dev/null
sudo ip link delete br-testlab 2>/dev/null

echo "Test lab network removed"
EOF

chmod +x ~/qemu-lab/scripts/teardown-network.sh

Run the setup:

~/qemu-lab/scripts/setup-network.sh

Step 4: Creating VM Launch Scripts

Rather than typing long QEMU commands, let's create reusable launch scripts.

Gateway VM Script

cat > ~/qemu-lab/scripts/run-gateway.sh << 'EOF'
#!/bin/bash

qemu-system-x86_64 \
  -name gateway \
  -m 1024 \
  -smp 2 \
  -hda ~/qemu-lab/images/gateway.qcow2 \
  -enable-kvm \
  -netdev tap,id=net0,ifname=tap0,script=no,downscript=no \
  -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:00 \
  -netdev user,id=net1 \
  -device virtio-net-pci,netdev=net1,mac=52:54:00:12:34:01 \
  -nographic \
  -serial mon:stdio
EOF

chmod +x ~/qemu-lab/scripts/run-gateway.sh

This gateway has TWO network interfaces:

net0: Connected to internal test network (10.0.100.0/24)
net1: NAT to internet for updates

Quick Clone Function for Additional VMs

# Create application VM from gateway template
qemu-img create -f qcow2 -b images/gateway.qcow2 -F qcow2 images/app.qcow2

# Create attacker VM
qemu-img create -f qcow2 -b images/gateway.qcow2 -F qcow2 images/attacker.qcow2

These are backing images - they only store differences from the base, saving massive disk space.

Application VM Script

cat > ~/qemu-lab/scripts/run-app.sh << 'EOF'
#!/bin/bash

qemu-system-x86_64 \
  -name app-server \
  -m 2048 \
  -smp 2 \
  -hda ~/qemu-lab/images/app.qcow2 \
  -enable-kvm \
  -netdev tap,id=net0,ifname=tap1,script=no,downscript=no \
  -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:10 \
  -nographic \
  -serial mon:stdio
EOF

chmod +x ~/qemu-lab/scripts/run-app.sh

Attacker VM Script

cat > ~/qemu-lab/scripts/run-attacker.sh << 'EOF'
#!/bin/bash

qemu-system-x86_64 \
  -name attacker \
  -m 1024 \
  -smp 2 \
  -hda ~/qemu-lab/images/attacker.qcow2 \
  -enable-kvm \
  -netdev tap,id=net0,ifname=tap2,script=no,downscript=no \
  -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:20 \
  -nographic \
  -serial mon:stdio
EOF

chmod +x ~/qemu-lab/scripts/run-attacker.sh

Step 5: Network Configuration Inside VMs

Start each VM and configure networking:

Gateway VM (10.0.100.1)

# Start gateway
~/qemu-lab/scripts/run-gateway.sh

# Inside VM - configure interfaces
# For Alpine Linux:
cat > /etc/network/interfaces << 'EOF'
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.0.100.1
    netmask 255.255.255.0

auto eth1
iface eth1 inet dhcp
EOF

# Restart networking
rc-service networking restart

# Enable forwarding permanently
echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
sysctl -p

# Setup basic NAT (so internal VMs can reach internet via gateway)
apk add iptables
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Save iptables rules
rc-update add iptables
/etc/init.d/iptables save

Application VM (10.0.100.10)

# Configure static IP
cat > /etc/network/interfaces << 'EOF'
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.0.100.10
    netmask 255.255.255.0
    gateway 10.0.100.1
    dns-nameservers 8.8.8.8
EOF

rc-service networking restart

Attacker VM (10.0.100.20)

# Configure static IP
cat > /etc/network/interfaces << 'EOF'
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.0.100.20
    netmask 255.255.255.0
    gateway 10.0.100.1
    dns-nameservers 8.8.8.8
EOF

rc-service networking restart

# Install security testing tools
apk add nmap tcpdump hping3 netcat-openbsd

Step 6: Snapshots for Quick Resets

One of QEMU's killer features - instant rollback:

# Create a "clean state" snapshot for each VM
qemu-img snapshot -c clean-install images/gateway.qcow2
qemu-img snapshot -c clean-install images/app.qcow2
qemu-img snapshot -c clean-install images/attacker.qcow2

# After testing, rollback to clean state
qemu-img snapshot -a clean-install images/gateway.qcow2

# List all snapshots
qemu-img snapshot -l images/gateway.qcow2

Step 7: Practical Use Cases

Now your lab is ready! Here are some real-world scenarios:

Testing Network Monitoring Tools

On the gateway VM, install your monitoring solution:

# Example: tcpdump for packet analysis
apk add tcpdump

# Capture traffic between app and attacker
tcpdump -i eth0 -w /tmp/capture.pcap

# Or install eBPF-based tools for advanced monitoring
# (Great for testing tools like Cilium, Falco, or custom eBPF monitors like Cerberus)

Simulating Attack Scenarios

From attacker VM:

# Port scan the application
nmap -sV 10.0.100.10

# Test firewall rules
hping3 -S -p 80 10.0.100.10

# Monitor on gateway to see what's blocked

Testing Firewall Rules

On gateway, add restrictive rules:

# Block all traffic from attacker to app
iptables -I FORWARD -s 10.0.100.20 -d 10.0.100.10 -j DROP

# Allow only SSH
iptables -I FORWARD -s 10.0.100.20 -d 10.0.100.10 -p tcp --dport 22 -j ACCEPT

Container Testing

Install Docker on the app VM to test container networking and security policies in isolation.

Step 8: Automation and Management

Create a master control script:

cat > ~/qemu-lab/manage-lab.sh << 'EOF'
#!/bin/bash

case "$1" in
  start)
    ./scripts/setup-network.sh
    echo "Starting VMs in tmux sessions..."
    tmux new-session -d -s gateway './scripts/run-gateway.sh'
    tmux new-session -d -s app './scripts/run-app.sh'
    tmux new-session -d -s attacker './scripts/run-attacker.sh'
    echo "Lab started. Attach with: tmux attach -t <gateway|app|attacker>"
    ;;
  stop)
    echo "Stopping all VMs..."
    tmux kill-session -t gateway 2>/dev/null
    tmux kill-session -t app 2>/dev/null
    tmux kill-session -t attacker 2>/dev/null
    ./scripts/teardown-network.sh
    ;;
  reset)
    echo "Resetting all VMs to clean snapshot..."
    qemu-img snapshot -a clean-install images/gateway.qcow2
    qemu-img snapshot -a clean-install images/app.qcow2
    qemu-img snapshot -a clean-install images/attacker.qcow2
    echo "Reset complete"
    ;;
  *)
    echo "Usage: $0 {start|stop|reset}"
    exit 1
    ;;
esac
EOF

chmod +x ~/qemu-lab/manage-lab.sh

Usage:

# Start entire lab
./manage-lab.sh start

# Access any VM
tmux attach -t gateway

# Reset everything to clean state
./manage-lab.sh reset

# Shut down cleanly
./manage-lab.sh stop

Performance Tips

Always use KVM acceleration (-enable-kvm) - it's 10-20x faster than emulation
Allocate appropriate resources - Don't over-provision RAM
Use virtio drivers - Much faster than emulated hardware
qcow2 for flexibility, raw for performance - Use raw images if speed is critical
CPU pinning for consistency:

   -smp 2,sockets=1,cores=2,threads=1

Troubleshooting Common Issues

VM won't start with KVM error:

# Check if KVM is available
lsmod | grep kvm
# If not, enable in BIOS (Intel VT-x or AMD-V)

Network not working:

# Verify TAP interfaces are up
ip link show | grep tap

# Check bridge configuration
bridge link show br-testlab

Cannot connect to VMs:

# From host, ping the bridge IP
ping 10.0.100.1

# Check iptables isn't blocking
sudo iptables -L -n

Performance is slow:

# Verify KVM is actually being used
ps aux | grep qemu | grep -i kvm

Next Steps and Advanced Topics

Your test lab is now ready for serious work! Consider exploring:

Ansible automation - Provision VMs automatically
Cloud-init integration - Pre-configure VMs on first boot
PXE boot testing - Network installation scenarios
Multi-host clustering - Test Kubernetes or Docker Swarm
VPN testing - Simulate site-to-site connections
VLAN tagging - Complex network segmentation

Conclusion

QEMU provides a powerful, scriptable foundation for testing network security tools and infrastructure. Unlike heavyweight alternatives, it integrates seamlessly into CI/CD pipelines, supports headless operation, and gives you complete control over the network topology.

The lab we built mirrors production environments while remaining completely isolated and reproducible. Use it to validate security tools, test infrastructure changes, or experiment with new technologies risk-free.

All scripts and configurations from this guide are available in my GitHub https://github.com/zrougamed/blog .

What will you test first in your new lab? Drop a comment below!

About the author: I'm a Senior Software Engineer at Deltaflare, where we work on the Phoenix Platform protecting Critical National Infrastructure across energy, water, and transport sectors. I use QEMU extensively for testing security tools and validating infrastructure changes before production deployment in CNI environments. You can find me at https://zrouga.email or check out my open-source work on GitHub.

Building a Real-Time Network Monitor with eBPF: Lessons from Cerberus

Mohamed Zrouga — Sat, 20 Dec 2025 18:09:12 +0000

As a platform engineer working with critical infrastructure, I needed deep visibility into network behavior without the overhead of traditional packet capture tools. The result? Cerberus - an eBPF-based network monitor that processes packets at the kernel level with near-zero overhead.

This post walks through the architecture, challenges, and lessons learned from building a production-grade network monitoring tool using eBPF and Go.

Why eBPF for Network Monitoring?

Traditional network monitoring tools like tcpdump and Wireshark are powerful but come with drawbacks:

Context switches: Every packet copies data from kernel to user space
Performance overhead: Processing in user space is slower
Security: Full packet capture requires elevated privileges everywhere
Scalability: High-traffic networks can overwhelm traditional tools

eBPF (Extended Berkeley Packet Filter) solves these by running sandboxed programs directly in the Linux kernel, allowing you to:

Filter and process packets at line rate
Extract only the data you need (no full packet copies)
Aggregate statistics in kernel space
Minimize context switches with ring buffers

Architecture Overview

Cerberus uses a two-layer architecture:

The eBPF Program: Kernel-Space Magic

The heart of Cerberus is a TC (Traffic Control) classifier written in C that attaches to network interfaces. Here's what it does:

1. Packet Parsing at Line Rate

struct network_event {
    __u8 event_type;       // Event classification
    __u8 src_mac[6];       // Source MAC
    __u8 dst_mac[6];       // Destination MAC
    __u32 src_ip;          // Source IP
    __u32 dst_ip;          // Destination IP
    __u16 src_port;        // Source port
    __u16 dst_port;        // Destination port
    __u8 protocol;         // IP protocol
    __u8 tcp_flags;        // TCP flags
    __u16 arp_op;          // ARP operation
    __u8 icmp_type;        // ICMP type
    __u8 l7_payload[32];   // Layer 7 inspection data
} __attribute__((packed));

Key Design Decision: We only capture 75 bytes per event. This is enough for classification and L7 inspection without the overhead of full packet capture.

2. Multi-Protocol Detection

The eBPF program identifies 7 different protocol types:

// Simplified version of the protocol detection logic
SEC("tc")
int monitor_ingress(struct __sk_buff *skb) {
    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return TC_ACT_OK;

    // ARP detection
    if (eth->h_proto == bpf_htons(ETH_P_ARP)) {
        return handle_arp(skb, eth, data_end);
    }

    // IP packet processing
    if (eth->h_proto == bpf_htons(ETH_P_IP)) {
        struct iphdr *ip = (void *)(eth + 1);
        if ((void *)(ip + 1) > data_end)
            return TC_ACT_OK;

        switch (ip->protocol) {
            case IPPROTO_TCP:
                return handle_tcp(skb, eth, ip, data_end);
            case IPPROTO_UDP:
                return handle_udp(skb, eth, ip, data_end);
            case IPPROTO_ICMP:
                return handle_icmp(skb, eth, ip, data_end);
        }
    }

    return TC_ACT_OK;
}

3. Layer 7 Inspection

Here's where it gets interesting. We extract application-layer data for DNS, HTTP, and TLS:

// DNS query extraction
static __always_inline int handle_dns(struct __sk_buff *skb, 
                                       struct udphdr *udp,
                                       void *data_end) {
    void *dns_data = (void *)(udp + 1);

    // Copy up to 32 bytes of DNS payload
    if (dns_data + 32 <= data_end) {
        bpf_probe_read(&event.l7_payload, 32, dns_data);
        event.event_type = EVENT_DNS;
    }

    bpf_ringbuf_submit(&event, 0);
    return TC_ACT_OK;
}

// HTTP detection (simplified)
static __always_inline int handle_http(struct __sk_buff *skb,
                                        struct tcphdr *tcp,
                                        void *data_end) {
    void *http_data = (void *)(tcp + 1);

    // Check for HTTP methods
    if (http_data + 4 <= data_end) {
        char method[4];
        bpf_probe_read(&method, 4, http_data);

        if (method[0] == 'G' && method[1] == 'E' && 
            method[2] == 'T' && method[3] == ' ') {
            event.event_type = EVENT_HTTP;
            bpf_probe_read(&event.l7_payload, 32, http_data);
        }
    }

    return TC_ACT_OK;
}

// TLS handshake detection
static __always_inline int handle_tls(struct __sk_buff *skb,
                                       struct tcphdr *tcp,
                                       void *data_end) {
    void *tls_data = (void *)(tcp + 1);

    if (tls_data + 5 <= data_end) {
        __u8 content_type;
        bpf_probe_read(&content_type, 1, tls_data);

        // 0x16 = Handshake
        if (content_type == 0x16) {
            event.event_type = EVENT_TLS;
            bpf_probe_read(&event.l7_payload, 32, tls_data);
        }
    }

    return TC_ACT_OK;
}

Challenge #1: The Verifier

The eBPF verifier is strict. Every memory access must be bounds-checked:

// This will fail verification:
char *data = packet + offset;
*data = value;  // ❌ No bounds check

// This passes:
if ((void *)(packet + offset + 1) <= data_end) {
    char *data = packet + offset;
    *data = value;  // ✅ Verified safe
}

User-Space Processing: Go Application

The Go application reads events from the ring buffer and performs higher-level analysis:

1. Ring Buffer Polling

func (m *NetworkMonitor) pollEvents(ctx context.Context) {
    rb, err := m.module.InitRingBuf("events", m.eventsChannel)
    if err != nil {
        log.Fatal(err)
    }
    defer rb.Close()

    rb.Poll(300) // 300ms timeout

    for {
        select {
        case <-ctx.Done():
            return
        case record := <-m.eventsChannel:
            m.processEvent(record)
        }
    }
}

2. Smart Deduplication with LRU Cache

To avoid alert fatigue, we only show new traffic patterns:

type NetworkMonitor struct {
    deviceCache  *lru.Cache        // Device tracking
    patternCache *lru.Cache        // Unique communication patterns
    db           *buntdb.DB        // Persistent storage
}

func (m *NetworkMonitor) processEvent(data []byte) {
    event := parseNetworkEvent(data)

    // Track device
    deviceKey := event.SrcMAC.String()
    if !m.deviceCache.Contains(deviceKey) {
        m.announceNewDevice(event)
        m.deviceCache.Add(deviceKey, true)
    }

    // Track pattern (first occurrence only)
    patternKey := fmt.Sprintf("%s:%s:%d:%s",
        event.SrcMAC, event.DstIP, event.DstPort, event.EventType)

    if !m.patternCache.Contains(patternKey) {
        m.printTrafficPattern(event)
        m.patternCache.Add(patternKey, true)
    }

    // Update statistics
    m.updateStats(event)
}

3. Layer 7 Parsing in User Space

func parseL7Payload(event *NetworkEvent) string {
    switch event.EventType {
    case EVENT_DNS:
        return parseDNSQuery(event.L7Payload)
    case EVENT_HTTP:
        return parseHTTPRequest(event.L7Payload)
    case EVENT_TLS:
        return "TLS"
    default:
        return ""
    }
}

func parseDNSQuery(payload []byte) string {
    // Skip DNS header (12 bytes)
    offset := 12

    var domain []byte
    for offset < len(payload) {
        length := int(payload[offset])
        if length == 0 {
            break
        }

        if len(domain) > 0 {
            domain = append(domain, '.')
        }

        offset++
        if offset+length > len(payload) {
            break
        }

        domain = append(domain, payload[offset:offset+length]...)
        offset += length
    }

    return string(domain)
}

Performance Optimizations

1. Zero-Copy with Ring Buffers

Ring buffers allow the kernel to write directly to memory shared with user space:

// No data copying - just reading shared memory
rb.Poll(300)

2. Batch Database Writes

Instead of writing every event to disk, we batch them:

func (m *NetworkMonitor) persistStats() {
    ticker := time.NewTicker(30 * time.Second)
    defer ticker.Stop()

    for range ticker.C {
        m.db.Update(func(tx *buntdb.Tx) error {
            for mac, stats := range m.deviceStats {
                data, _ := json.Marshal(stats)
                tx.Set(mac, string(data), nil)
            }
            return nil
        })
    }
}

3. LRU Cache Tuning

// Balance memory vs. accuracy
deviceCache, _ := lru.New(1000)   // Track 1000 devices
patternCache, _ := lru.New(10000) // Track 10k patterns

Real-World Output

Here's what you see when running Cerberus:

NEW DEVICE DETECTED!
   MAC:     dc:62:79:2f:39:28
   IP:      192.168.0.108
   Vendor:  Apple
   First Seen: 2024-12-06 16:51:12

[DNS] 192.168.0.100 (aa:bb:cc:dd:ee:ff) [Apple] → 8.8.8.8:53 [google.com]
[HTTP] 192.168.0.100 (aa:bb:cc:dd:ee:ff) [Apple] → 93.184.216.34:80 [GET /api/v1/users]
[TLS] 192.168.0.100 (aa:bb:cc:dd:ee:ff) [Apple] → 142.250.185.46:443 [TLS]
[TCP] 192.168.0.50 (11:22:33:44:55:66) [Raspberry Pi] → 192.168.0.200:22 (SSH)

╔════════════════════════════════════════════════════╗
║         NETWORK STATISTICS SUMMARY                 ║
╠════════════════════════════════════════════════════╣
║ Total Devices: 15                                  ║
║ Total Packets: 45821                               ║
║   - TCP:  38456                                    ║
║   - UDP:  6120                                     ║
║   - DNS:  892                                      ║
║   - HTTP: 156                                      ║
║   - TLS:  1834                                     ║
╚════════════════════════════════════════════════════╝

Challenges and Solutions

Challenge #1: eBPF Complexity Limit

eBPF programs are limited to ~1 million instructions. Solution: Keep parsing logic simple and move complex analysis to user space.

Challenge #2: Payload Size Tradeoff

More payload = better L7 inspection, but higher overhead. Solution: 32 bytes is enough for DNS queries, HTTP methods, and TLS detection.

Challenge #3: TC vs XDP

Initially considered XDP (eXpress Data Path) but TC offered better compatibility and easier development. XDP is faster but more restrictive.

Challenge #4: Cross-Kernel Compatibility

Different kernel versions support different eBPF features. Solution: Use CO-RE (Compile Once, Run Everywhere) via libbpf.

Lessons Learned

Start simple: Basic packet capture first, then add L7 inspection
Trust the verifier: If it rejects your code, there's probably a real bug
Test incrementally: Use bpftool to inspect maps and programs
Memory matters: Every byte in your event structure adds overhead
User space is your friend: Don't try to do everything in eBPF

Production Considerations

For critical infrastructure monitoring (my day job), I've learned:

Alert fatigue is real: Smart deduplication is essential
Performance monitoring: Track your own overhead
Graceful degradation: Handle packet loss at high traffic volumes
Security: Limit L7 payload capture to metadata only

What's Next?

The roadmap for Cerberus includes:

Redis backend for distributed deployments
Prometheus metrics export
Anomaly detection using pattern baselines
IPv6 support
Extended L7 inspection (128-256 byte payloads)
Web dashboard for visualization

Try It Yourself

git clone https://github.com/zrougamed/cerberus.git
cd cerberus
make
sudo ./build/cerberus

Requirements:

Linux kernel 4.18+
Go 1.24+
Root privileges

Contributing

Cerberus is open source and looking for contributors! Whether you're interested in:

eBPF kernel programming
Go application development
Network protocol analysis
Performance optimization
Documentation

Check out the GitHub repository and open an issue or PR.

Resources

Conclusion

Building Cerberus taught me that eBPF isn't just about performance - it's about rethinking how we approach observability. By moving intelligence into the kernel, we can monitor networks at scale without sacrificing visibility.

The combination of eBPF's efficiency and Go's expressiveness creates a powerful platform for building modern monitoring tools. Whether you're securing critical infrastructure or just curious about network traffic, eBPF opens up possibilities that weren't feasible before.

What would you build with eBPF? Let me know in the comments!

Mohamed Zrouga is a Senior Platform Engineer at Deltaflare, specializing in critical infrastructure protection and DevSecOps. Connect on GitHub or visit zrouga.email

Build a Secure Multi-Tenant SSO System with Keycloak, Go & React: Step-by-Step Guide

Mohamed Zrouga — Sat, 07 Jun 2025 19:55:54 +0000

Managing authentication across multiple tenants can be a nightmare—different domains, identity providers, and security models all add complexity. In this guide, you’ll learn how to build a production-ready multi-tenant SSO system using Keycloak, React, and Go, enabling your users to log in with Google, GitHub, or Microsoft accounts, while keeping each tenant securely isolated.

Stack Overview

Layer	Tech	Purpose
Identity	Keycloak	Central identity provider (OAuth2, JWT, social login, multi-tenancy)
Frontend	React	User and admin interfaces
Backend	Go	Stateless API with JWT validation and business logic
Data	PostgreSQL	Stores tenants, users, and metadata
DevOps	Docker Compose	Container orchestration for local setup

Architecture: A Layered Security Model

The solution follows a cleanly separated, layered architecture:

Identity Providers Layer: Social login via Google, Microsoft, and GitHub
Frontend Layer:
- React user interface (http://localhost:3000)
- Admin dashboard (http://localhost:3001)
Authentication Layer:
- Keycloak (http://localhost:8080) handles all identity and access flows
Backend Layer:
- Go API (http://localhost:8081) that verifies JWTs and executes tenant-aware logic
Data Layer:
- PostgreSQL database for user, tenant, and relationship data

Why This Stack?

Keycloak

Open-source IAM platform with OAuth2, OpenID Connect, social login, and multi-tenancy.
Saves you from writing brittle auth code.
Highly customizable with realms, clients, and mappers.

React

Modern, component-driven framework.
Perfect separation of user frontend and admin interface.
Great developer experience and large ecosystem.

Go

Lightweight and performant.
Excellent standard library for JWT handling and HTTP.
Strong concurrency model for scalable APIs.

Authentication Flow

Here’s how the secure OAuth2-based login works:

User starts login from the React frontend.
Keycloak redirects to the selected identity provider.
User authenticates, and the OAuth callback returns to Keycloak.
Keycloak issues a JWT with user and tenant context.
Frontend includes the JWT in API requests.
Go backend validates the token and extracts tenant info.
Tenant-isolated operations run based on JWT claims.

This setup ensures centralized auth with stateless APIs and strong tenant isolation.

Multi-Tenancy: Key Considerations

Concern	Solution
Tenant Isolation	Users and data are scoped to their own organization.
Flexible Auth	Each tenant chooses which social login providers to enable.
Self-Service Admin	Admin panel allows tenant admins to manage users without overlap.
Scalable Infrastructure	Each component is containerized and independently scalable.

Security Best Practices

JWT Validation: Go backend checks tokens against Keycloak’s JWKS endpoint.
CORS Configuration: Proper headers configured in both Keycloak and backend.
Environment Variables: All sensitive values are managed via .env files.
Isolated Networks: Docker containers communicate over private networks.

Getting Started

Clone and boot the system using Docker Compose:

# Clone and navigate to the repo
git clone https://github.com/zrougamed/multitenant-sso
cd multitenant-sso

# Start all services
docker-compose up -d

Access services at:

Configuring OAuth Providers

Google

Go to Google Cloud Console
Create OAuth credentials
Set redirect URI: http://localhost:8080/realms/{realm}/broker/google/endpoint

GitHub

Go to GitHub Developer Settings
Set callback URI: http://localhost:8080/realms/{realm}/broker/github/endpoint

Microsoft

Register an app via Azure App Registrations
Set redirect URI: http://localhost:8080/realms/{realm}/broker/azure/endpoint

Common Challenges and Solutions

Problem	Solution
Port Conflicts	Modify `docker-compose.yml` or Keycloak config.
CORS Errors	Ensure correct CORS settings in backend and Keycloak.
JWT Validation Fails	Double-check audience (`aud`), issuer (`iss`), and realm configuration.

Extending the System

Add more identity providers: Twitter, Facebook, etc.
Add Role-Based Access Control (RBAC) via Keycloak groups and roles.
Implement API rate limiting in Go middleware.
Add monitoring with Prometheus, Grafana, or ELK.

Production Considerations

High Availability: Cluster Keycloak and PostgreSQL with redundancy.
SSL/TLS: Use reverse proxy like NGINX or Traefik for HTTPS.
Backups: Regular backups for Keycloak and PostgreSQL.
Monitoring: Alerting on auth failures, performance, and token expiry issues.

Conclusion

Building a secure, scalable, multi-tenant SSO system doesn’t have to be painful. By using Keycloak for identity management, React for the frontend, and Go for the API, you get a powerful and maintainable architecture that scales with your needs.

The system supports:

Multi-tenant user isolation
Social logins via OAuth
Stateless APIs with secure JWTs
Admin management for each tenant

Source Code

👉 GitHub Repository – multitenant-sso

Questions or feedback?

Open an issue on GitHub or connect with me on LinkedIn

🚀 Open Source Notification Scheduler in Go! 🌟 [Looking for Contributors]

Mohamed Zrouga — Mon, 16 Dec 2024 02:37:43 +0000

Hi Dev! 👋

I’m excited to share my latest open-source project, Dynamic Notification System! 🎉

This is a Go-based extensible notification scheduler that supports multiple channels, including:

📨 Slack
🔔 Discord
📩 Telegram
📧 SMTP
🖥️ Webhooks
And many more!
With dynamic plugin support, the system allows you to add new notification channels effortlessly. It’s designed for cross-platform compatibility (Linux, macOS, Windows) and supports Go 1.23+.

Why Contribute?
✅ Learn and improve your skills in Go and dynamic plugin systems.
✅ Work on cross-platform builds for Linux, macOS, and Windows.
✅ Be part of a growing open-source project and build your portfolio.
✅ Help the community by adding new features and optimizing existing ones.

How You Can Help
👨‍💻 We’re looking for contributors to:

Add new notification channels like Twilio, Signal, etc.
Improve documentation and examples.
Fix bugs and optimize builds.
No matter your experience level, we’d love your input! 🚀

Links
🔗 GitHub Repository: Dynamic Notification System

Feel free to check out the project, try it, and let us know your thoughts! Contributions, feedback, and stars 🌟 are all greatly appreciated. Let’s build something amazing together! 💪