Frao-Guard: The Graduated Response — From Monitoring to Active Defense

Frao-Guard spent its first weeks in observation mode — logging every packet, classifying every probe, scoring every attacker — by design. Once we had a clear picture of the threat landscape, we activated the countermeasures. Here’s what the observation data taught us and what happened when the system stopped logging and started blocking.
Reading time: ~5 minutes

The Observation Period

Frao-Guard has been running in production since early July. By design, the first phase was observation-only: log every packet, classify every probe, score every attacker — but take no action. We wanted a complete picture of who’s out there before telling the system to start blocking.

Over the first 26 days, the system tracked 31,628 unique attacking IPs. That’s distinct hosts, each one actively probing our perimeter.

Where the Attacks Come From

The geographic distribution isn’t subtle. One country dominates in a way that makes the rest look like noise.

Top countries by attacking IPs:

Türkiye alone accounts for three-quarters of all attacking IPs. The top three ASNs are all Turkish providers: Netfactor, SPDNet, and HostLAB. These aren’t individual hackers — they’re compromised infrastructure, residential proxies, and hosting providers that either can’t or won’t clean up their act.

The Baseline

During observation mode, the system used intentionally conservative thresholds — an IP needed a confidence score of 0.95 to register as "critical." The goal wasn’t to block effectively; it was to establish a baseline of who’s out there and what they do.

Note: zero IPs were blocked during observation — that was the point.

The 13 drops shown in earlier Grafana dashboards were pre-existing nftables rules from a prior configuration, not Frao-Guard decisions. During observation mode, the system logged everything and blocked nothing by design.

Activating the Countermeasures

Once the observation period completed, we deployed a coordinated batch of changes across six phases to transition from monitoring to active defense.

1. Operational Thresholds

The scoring thresholds were moved from their conservative observation baselines to operational values:

2. Geo-Blocking Pipeline

A new stage was added to the packet processor — Stage 1b — that runs immediately after GeoIP enrichment and before classification or scoring. If an incoming packet’s country or ASN matches a blocked list, it’s dropped immediately. No scoring overhead. No classification cost. Just: match → drop → continue.

The entire check takes microseconds per packet, happens at line rate, and bypasses the entire detection pipeline for known-bad sources.

3. Geo Aggregator

A background task now aggregates country and ASN distribution data from the SQLite attackers table, refreshed every 60 seconds. This powers a live view of who’s attacking, directly in the Frao-Guard dashboard — no manual SQL queries needed.

4. API + Dashboard

Two new API endpoints — GET /api/geo/countries and GET /api/geo/asns — expose the aggregated data. The settings page now has a searchable multi-select dropdown for selecting which countries and ASNs to block, sorted by attack count. No more comma-separated text fields. Type "Turk" and watch every Turkish ASN appear in real-time.

5. Post-Block Observation

A background task now monitors blocked IPs every 5 minutes, checking whether they’ve persisted or desisted since the block was applied. This feeds into the effectiveness tracking: are blocks actually working, or are attackers just rotating IPs?

The Results

After activating the countermeasures:

The system now actively blocks 4,299 IPs that it was merely logging during observation. The graduated response engages at realistic levels: medium-threat IPs get rate-limited, high-threat IPs get dropped, and critical-threat IPs get the full stack (rate-limit → drop → tarpit).

A note on proportionality: The average dropped IP had 3,183 attacks before being blocked. The most aggressive single IP logged over 10,600 attempts. These are sustained scanning campaigns, not accidental visitors.

The Tax You Didn’t Know You Were Paying

Block Store — the system that records every action taken against every attacker — writes two append-only JSONL files. Before compression, these files consumed 950 MB and were growing at ~1.3 GB per month.

blocks.jsonl     73 MB   →   894 KB   (84× compression)
history.jsonl   877 MB   →   143 MB   (6.1× compression)

The fix: every write is compressed into an independent zstd frame and byte-appended to the file. Old data is never decompressed or rewritten. Zstd’s frame-concatenation feature was designed for append-heavy logs where you can’t recompress history on every write.

What’s Next

The current phase is operational: watching, scoring, blocking, and measuring. The next layer will add:

Honeypot Service — a convincing imitation of common vulnerable services (SSH, HTTP, MySQL) that runs alongside the production stack. Attackers that hit the honeypot identify themselves immediately: we capture their exploits, their toolkits, and their C2 infrastructure — all without any risk to production systems. The honeypot data feeds directly back into the scoring engine: hit the honeypot once, skip the observation period, go straight to blocked.

ASN Reputation Scoring — weighting threat scores based on the historical behavior of each ASN, rather than treating every IP as an independent actor.

Automated Countermeasure Escalation — if a blocked IP persists across multiple block cycles (attempts to reconnect after the block expires), the system automatically escalates from a temporary drop to a permanent null-route with additional tarpit layers.

The data pipeline is in place. The response engine is live. The system watches, scores, and blocks without human intervention — which is the only way to operate at this scale.

— Richard Primera, CEO, Frao Technologies LLC
Last updated: 2026-07-30