Frao-Guard: Network Defense at Kernel Speed — and What 10,000 Attackers Reveal

The internet is not a friendly place. Every second, packets arrive at our gateway from hosts that have no business talking to us — automated scanners, brute-force bots, and orchestrated attack campaigns. We built Frao-Guard to see every single one of them, understand their patterns, and respond at line rate. Here’s what we built, how it works, and what the attackers have taught us.
Reading time: ~5 minutes

The Reality of Running a Public Gateway

Every machine connected to the internet is under constant probing. Not occasionally. Not during "attack windows." Constantly. The moment you expose a public IP, automated scanners from around the world begin testing it — looking for open ports, responding services, and ultimately, footholds.

Before we built Frao-Guard, our gateway had a conventional firewall. It worked in the sense that packets were being dropped. But it had no visibility into who was knocking, how they were probing, or what patterns they followed. It was a wall with no windows — you knew you were being hit, but you had no idea by whom or how badly.

A firewall without telemetry is a door with no peephole. You assume it’s working. You hope it’s enough. You don’t actually know.

What Frao-Guard Is

Frao-Guard is an intelligent, adaptive network defense system. It sits on the Frao internet gateway and processes every incoming packet — not through a conventional firewall chain, but through a multi-stage analysis pipeline running at the kernel level and backed by real-time telemetry.

Four stages. Every packet passes through all of them. The entire loop — from kernel intercept to dashboard update — completes before the next packet arrives on a typical connection.

The Architecture: eBPF Meets Rust

The foundation is eBPF (Extended Berkeley Packet Filter) with the XDP (eXpress Data Path) hook — a kernel technology that lets us run sandboxed programs at the network interface level, before the packet even reaches the kernel’s networking stack.

eBPF/XDP (kernel space)                  Rust Daemon (userspace)
┌─────────────────────┐                 ┌──────────────────────────┐
│  xdp_filter.bpf.c   │── ring buffer──▶│  PacketProcessor         │
│  rate_limiter.bpf.c  │                 │  ├── Parser (protocols)  │
│  flow_tracker.bpf.c  │  BPF maps      │  ├── Classifier (18 det.)│
│  packet_rewriter.bpf │ ◀────────────── │  ├── GeoIP (MaxMind)     │
└──────────────────────┘                 │  ├── Scorer (0.0–1.0)   │
         │                               │  └── ActionEngine (21)  │
         │ XDP_PASS / DROP / TX          │                          │
         ▼                               │  AttackerTable · BlockSt.│
┌──────────────┐                        │  SSE Broadcaster · API   │
│  Network I/F  │                        └──────────────────────────┘
└──────────────┘                                      │
                                                      ▼
                                              ┌──────────────┐
                                              │  Dashboard    │
                                              │  (HTMX + SSE) │
                                              └──────────────┘

The architecture splits the work across two domains:

Kernel space (eBPF/XDP): The hot path. Every packet is inspected at line rate by a small, kernel-verified C program. The program can pass the packet through, drop it immediately, or redirect it — all without ever leaving kernel context. No context switch, no copies, no overhead.

Userspace (Rust): The deep analysis path. Raw packets flow from kernel ring buffers into an actix-web-powered Rust daemon that runs them through a 5-stage pipeline — parsing protocol headers, classifying attack patterns, looking up geolocation, computing threat scores, and executing countermeasures.

The key design choice: do the minimum in kernel space, do the thinking in userspace. The eBPF program is deliberately small — capture, classify at a basic level, and forward. All heavy analysis happens in Rust, where we have the full standard library, MaxMind GeoIP databases, pattern matchers, and the ability to persist state.

Detection Pipeline: 18 Patterns and Counting

The classifier detects 18 attack patterns, each with custom heuristics and scoring:

Each detection feeds into the Scorer, which maintains a per-IP threat score from 0.0 to 1.0. Scores decay over time (0.95x per 10 seconds), so an IP that stops attacking is forgotten within about two hours. This prevents permanent blacklisting from transient scans — a critical design choice, because most scanners are automated and don’t represent persistent threats.

Countermeasures: 21 Actions, From Gentle to Aggressive

When the score crosses thresholds, the ActionEngine kicks in. Frao-Guard implements 21 action types across a graduated response spectrum:

The philosophy is proportional response. A single port scan from a new IP gets monitored and logged — it’s probably Shodan or Censys. That same IP returning with a SYN flood six hours later gets rate-limited. If it escalates to a full beacon pattern with C2 characteristics, it gets dropped at the kernel level and redirected to the honeypot.

The Dashboard: Seeing the Battlefield

Frao-Guard ships with an HTMX-driven real-time dashboard — the same pattern used across all Frao engineering tools. It shows:

• Live packet flow — Packets per second, active flows, parse errors
• Attacker table — Every tracked IP with geo, ASN, threat score, and attack pattern timeline
• Block history — Which IPs have been actioned, what actions were taken, and whether they persisted or desisted
• Geographic distribution — Country-level heatmap of attacker origins
• Configuration panel — Runtime settings for capture interfaces, thresholds, and whitelist management
• Honeypot logs — Real-time stream of attacker interactions with the fake SSH and HTTP services

The dashboard updates via Server-Sent Events (SSE) — no polling, no WebSockets, just a persistent HTTP connection that pushes updates as they happen. Every action the system takes is visible within seconds.

Honest State of the System

Frao-Guard has been built iteratively over the past several weeks. Here’s a transparent assessment of where it stands:

What works today:

• Real packet capture at the XDP/eBPF level — every packet is seen
• 18 detection patterns with scoring and decay
• Graduated response engine (rate limit → drop → countermeasure)
• Block history recording and effectiveness tracking
• Full REST API and SSE-driven real-time dashboard
• nftables-backed kernel-level enforcement with whitelist protection
• Honeypot service for attacker engagement
• Config persistence across restarts (SQLite-backed)

What we’re actively improving:

• The detection pipeline was initially designed with all components as library modules but the main loop connecting them was wired incrementally — Phases 1 through 4 closed these gaps systematically
• 14 of the 21 action types (protocol confusion, infinite tunnel, honeytoken flood, etc.) have implementations that need hardening for unsupervised production use
• A production incident on July 12 taught us a hard lesson about duplicate nftables rules and the importance of kernel-level whitelist enforcement — both were fixed in subsequent phases
• Score decay, garbage collection, and config persistence were production-graded in Phases 1 and 4

The honest version: Frao-Guard is operational and catching real attacks, but it’s a young system. Each phase makes it more robust. The foundation — eBPF capture, Rust pipeline, graduated actions, real-time telemetry — is solid and proven.

What the Attackers Taught Us

Frao-Guard has been tracking attackers since its deployment. As of late July 2026, the numbers tell a revealing story about the state of the internet.

Scale

Geography

The geographic distribution is striking and consistent:

The overwhelming source is Türkiye — 70.5% of all tracked attackers originate from Turkish ASNs. Specifically, the top three ASNs are all Turkish hosting providers: SPDNet (5,656 attackers), Netfactor (2,476 attackers), and HostLAB Bilisim (1,518 attackers). These are not residential IPs — they’re datacenter ranges, which means the attacks are originating from servers, likely compromised machines or commoditized VPS instances used for scanning.

Attack Types

The attackers use a narrow but effective playbook:

Slowloris and SYN floods dominate because they’re cheap to execute and hard to stop without application-level awareness. A conventional firewall sees these as legitimate connections. Frao-Guard’s behavioral analysis catches them by recognizing the pattern — not just the packet signature.

Defending the Internet

Running a public-facing infrastructure means accepting that you will always be probed, scanned, and tested. The internet’s attacker economy is automated, persistent, and globally distributed. The only defense is visibility — understanding the patterns, recognizing the tools, and responding at the speed of the network.

Frao-Guard is our answer to that reality. It’s not a set-it-and-forget-it firewall. It’s an active defense system that watches, learns, and responds. It has already recorded over 364,000 attack events from over 16,000 unique IPs in its short lifetime. And every one of those events is data — data that makes the system smarter, our infrastructure safer, and our understanding of the threat landscape deeper.

The road ahead:

• Hardening the remaining countermeasure implementations for unsupervised production use
• ML-based anomaly detection to catch zero-day patterns
• Automated threat intelligence sharing with partner ASNs
• Geographic and ASN-based policy zones (block entire regions per service)

Frao-Guard is one piece of Frao Technologies’ commitment to building infrastructure that is not just functional, but defensible by design.

— Richard Primera, CEO & CTO, Frao Technologies
Frao-Guard is open for review by partners and prospective clients. Contact us for a live dashboard demonstration.
Last updated: 2026-07-29