//:LOG→BAN · SYSTEM ONLINE
nginx access log → WAF/CRS → kernel ban · single chain · self-hosted
Turkey's measurable-proof, single-chain self-hosted security stack — rivals are piecemeal; we ship one integrated chain.
~26ms
kernel ban
recall
89
auto tests
1 chain
log→CRS→kernel
Single chain from nginx access log line to ipset ban: parser, OWASP CRS/WAF evaluation and ~26 ms kernel ban. Rivals offer piecemeal architecture — we merge in one chain with measured, reproducible PDF/JSON proof. Built in Turkey, MIT open source, fully self-hosted.
Security researcher? Not WooCommerce or a shop API — verification matrix at /testler · security.txt
$ git clone https://github.com/kurtulusutkucenik/Linux-Log-Guardian.git
$ cd Linux-Log-Guardian
$ make -j$(nproc)
$ sudo bash install.sh
[OK] log-guardian.service active
[OK] daemon IPC: OK
[OK] API fail-closed (tokensiz 403)
FAIL: 0 WARN: 0
//:About
An open-source (MIT) self-hosted security product built in Turkey. Reads nginx access logs in real time, evaluates with OWASP CRS/WAF and bans attacker IPs at kernel level via ipset in ~26 ms — single chain, no third-party cloud.
Fail2ban only bans, ModSecurity WAF is a separate module, CrowdSec needs a piecemeal stack. Log Guardian merges them: log line → parser → CRS/WAF (PCRE2 JIT) → ban pipeline policy + tenant → ipset/XDP kernel → Prometheus metrics and dashboard SOC timeline.
Results are measurable and reproducible: 100% recall on real attack corpus, 100% OWASP CRS parity, 0.2% false positive, ~26 ms median ban latency and 0 errors over 863 samples in 72h VPS soak.
This site is a public landing and download page — static content. The software runs on your Linux server; your data stays with you.
Single chain
log → WAF → kernel ban, one tool
~26 ms
median latency log line to ipset ban
100% recall
real attack corpus + CRS parity
0.2% FP
1 alarm in 500 benign lines
72h soak
863 samples, 0 errors (VPS)
MIT · TR
open source, Turkish docs, self-hosted
//:Sectors
Not an e-commerce or WooCommerce shop — measured protection for hosting, API, and SOC operators behind nginx.
Multi-tenant nginx with Turkish paths and anonymized customer corpus (API/JWT/path traversal) recall proof.
customer-corpus · tr-hosting · 89/89 gate
BOLA/schema abuse, JWT abuse, OAuth redirect_uri/PKCE and path traversal variants — log→WAF→ban.
openapi-strict · ban-profile e2e
Ban/ack/lineage in one stream, webhook batch and operator undo — SOC visibility beyond Fail2ban logs.
telegram-soc · dashboard :8443
//:3Paket
single chain · measured proof · CrowdSec optional
nginx log → OWASP CRS in the same C process → named skip or ban → XDP or ipset. CrowdSec LAPI is an optional complement.
Instead of a separate WAF + ban stack → one log-guardian process
Fail2ban + iptables scripts
No separate Fail2ban. Log line to ipset/XDP kernel ban ~26 ms — policy, tenant, FP trust in one pipeline.
Instead of a separate WAF + ban stack → one log-guardian process
ModSecurity + separate nginx integration
No separate ModSecurity module. OWASP CRS 121 rules, PCRE2 JIT — single pass from nginx log line.
Instead of a separate WAF + ban stack → one log-guardian process
CrowdSec bouncer + separate console + manual proof
CrowdSec is complementary, not a replacement — optional LAPI signal into the ban API. Prometheus, SOC timeline, 89 tests, 14 evidence files, Telegram ops — one panel.
nginx log → WAF/CRS → kernel ban
Full story → /paketler//:Numbers
Source: competitive-proof.json · bench-ban-latency.json · bench-vs-modsec.json · fp-report.json · soak-report.json
Median ban latency (n=5)
Laptop target (PASS)
Prod target
Real attack recall
OWASP CRS parity
CRS rule count
False positive rate
Benign test lines
Bench corpus lines
WAF/CRS @rx (LG)
CRS @rx replay
LG / CRS @rx ratio
Bench worker count
Automated tests
VPS soak duration
VPS soak samples
Soak errors
Evidence files
JA3 cluster test
Core setup time
Prometheus port
Dashboard port (prod)
//:Pipeline
~26 ms from an nginx access log line to ipset ban — rivals have piecemeal architecture.
writable access log, log_guardian format
URI, method, XFF, body — one schema
OWASP CRS, PCRE2 JIT, schema/BOLA
policy + tenant + FP trust decision
~26 ms kernel ban
Prometheus tenant + SOC timeline
writable access log, log_guardian format
URI, method, XFF, body — one schema
OWASP CRS, PCRE2 JIT, schema/BOLA
Prometheus tenant + SOC timeline
~26 ms kernel ban
policy + tenant + FP trust decision
XDR, Wasm marketplace and LLM Copilot are long-term optional layers — Core is production-ready on its own.
//:Pipeline · Step by step
The chain overview is above — below, what each step does, its advantages and how we compare to rivals.
writable access log, log_guardian format
What is it?
Reads the nginx access log file you already write, in real time. No extra reverse proxy, sidecar or cloud agent — the log line on your server is the start of a single chain.
89 automated tests · install gate PASS
Advantages
Compared with rivals
Log Guardian
One binary reads nginx logs — no separate Fail2ban/CrowdSec agent install.
Fail2ban · CrowdSec · ModSec
CrowdSec needs a separate agent plus central API. Fail2ban reads logs but never reaches a WAF layer — piecemeal architecture.
URI, method, XFF, body — one schema
What is it?
Turns each log line into one normalized schema: URI, HTTP method, X-Forwarded-For, User-Agent and optional body. WAF, ban and metrics layers all share the same structure.
114,003 EPS · 6.63× CRS @rx (bench-vs-modsec.json)
Advantages
Compared with rivals
Log Guardian
Log → normalize → WAF in one process; no intermediate format or ETL.
Fail2ban · CrowdSec · ModSec
ModSecurity runs inline in nginx but log-based banning needs separate Fail2ban integration. CrowdSec uses a different parser plus signal network.
OWASP CRS, PCRE2 JIT, schema/BOLA
What is it?
Evaluates attack patterns with 121 OWASP CRS rules, PCRE2 JIT compilation and OpenAPI/schema + BOLA validation. Measured 100% parity with ModSecurity on the same corpus.
CRS parity 100% · recall 100% · FP 0.2%
Advantages
Compared with rivals
Log Guardian
WAF + CRS in one product — no separate ModSecurity module. 6.63× vs CRS @rx replay on the same 121 rules — not nginx inline ModSec.
Fail2ban · CrowdSec · ModSec
ModSecurity + CRS is a separate module bolted onto nginx — blocks the first request inline but has no log→ban chain. Fail2ban does not run WAF evaluation.
policy + tenant + FP trust decision
What is it?
After a WAF match, tenant policy, ban threshold, false-positive trust score and operator ack merge in one decision path. Wrong-ban risk is bounded by measured gates.
~26 ms median ban · n=5 (bench-ban-latency.json)
Advantages
Compared with rivals
Log Guardian
~26 ms median from log line to ban decision; policy, tenant and FP trust share one code path.
Fail2ban · CrowdSec · ModSec
Fail2ban only fires regex/jail bans; FP trust and tenant live in other systems. CrowdSec needs central decision plus distributed agents.
~26 ms kernel ban
What is it?
Applies the ban at kernel level via ipset and optional XDP/eBPF the moment the decision is made. The userspace→kernel hop completes in a measured ~26 ms median.
72h soak · 863 samples (VPS) · 0 errors
Advantages
Compared with rivals
Log Guardian
Log → kernel ban in one chain, ~26 ms. Fail2ban/CrowdSec stay in seconds–minutes.
Fail2ban · CrowdSec · ModSec
Fail2ban ban latency is seconds to minutes. CrowdSec depends on its signal network; kernel ban is another integration. ModSecurity blocks inline but has no persistent ipset ban pipeline.
Prometheus tenant + SOC timeline
What is it?
Every step writes tenant-tagged Prometheus metrics, Grafana dashboards and the :8443 SOC dashboard timeline. Operators manage Telegram alerts and one-click ack from the same panel.
89 tests · competitive-proof.json · dashboard /tests
Advantages
Compared with rivals
Log Guardian
Metrics + dashboard + proof in one product — no CrowdSec SaaS console or piecemeal Grafana stack.
Fail2ban · CrowdSec · ModSec
Fail2ban has limited metrics/export. CrowdSec wants managed SaaS or self-hosted piecemeal setup. ModSecurity emits logs but no SOC timeline or automatic proof pack.
//:Selected
Core · Pro · Proof — measurable results in a single chain.
Single chain: nginx log → OWASP CRS → ~26 ms kernel ban. Production in ~15 minutes.
//:Why
nginx log → OWASP CRS in the same C process → named skip/ban → XDP or ipset. Fail2ban has no WAF. ModSecurity has no kernel ban pipeline. CrowdSec is not this log-tail CRS binary.
OWASP CRS in the same C process, then a named skip-or-ban, then kernel XDP (else ipset). Fail2ban has no WAF. ModSecurity has no kernel ban pipeline. CrowdSec AppSec + bouncer is not this log-tail CRS binary.
competitive-proof PDF, 89 tests, 72h soak — missing or fragmented in rivals.
Open source, Turkish docs, self-hosted — no vendor lock-in.
ModSec blocks the first request inline; we're reactive. CDN absorbs L3/L4. Throughput is 114,003 vs 17,193 CRS @rx replay — not nginx inline ModSec.
nginx log → CRS → skip/ban → kernel. CrowdSec LAPI is optional complement, not a replacement.
~26 ms median ban — Fail2ban/CrowdSec in seconds–minutes; n=5.
JA3 cluster 100% recall — 80 IP live test; per-IP ban + cluster detection.
Telegram alert + one-click ack, SOC timeline, tenant metrics — :8443 after install.
89
Automated tests
72h
Soak PASS
~26ms
Kernel ban
114,003
EPS
//:Vs
Measured proof — Fail2ban / CrowdSec / ModSecurity architecture notes. The winner in each row is marked red.
Fail2ban bans from logs and has no WAF. ModSecurity is a WAF with no kernel ban pipeline. CrowdSec AppSec + bouncer is a multi-component stack. Log Guardian: log → CRS in the same C process → named skip/ban → XDP or ipset.
One install, one chain
nginx log → OWASP CRS in the same C process → named skip or ban → XDP (else ipset). CrowdSec LAPI is optional complement. ~15 min setup.
~26 ms kernel ban
Median 26.17 ms from log line to ipset/XDP ban (n=5). Fail2ban/CrowdSec stay in seconds–minutes.
114,003 EPS · 6.63× CRS @rx
Same 121 OWASP CRS patterns, PCRE2 JIT, regex replay: 114,003 vs 17,193 EPS (6.63×). Not a nginx inline ModSec speed claim (bench-vs-modsec.json).
100% recall + 100% CRS parity
121 OWASP CRS rules, 100% real-attack recall on a 1500-line corpus and full parity with ModSec — at 0.2% false positive.
Distributed attack coverage
JA3 cluster detection + per-IP ban — 100% on an 80-IP live test. Fail2ban is single-IP; CrowdSec needs a separate signal network.
Transparent, reproducible proof
89 automated tests + a 14-file PDF/JSON evidence pack + 72h VPS soak (863 samples, 0 errors). Rivals have no automatic proof or it's fragmented.
Self-hosted · MIT · made in Turkey
Your data stays with you, no vendor lock-in, fully open source. SOC timeline, Prometheus metrics and Telegram ops in one panel (:8443).
| Metric | Log Guardian | Fail2ban | CrowdSeccomplementary | ModSec + CRS |
|---|---|---|---|---|
| Strengths (measured) | ||||
| Log → WAF → kernel ban | Single chain | Ban only | Piecemeal | WAF separate |
| WAF/CRS throughput (same corpus) | 114,003 EPS (6.63×) | — | — | 17,193 EPS |
| OWASP CRS parity | 100% (121 rules) | — | — | Reference (100%) |
| Real attack recall | 100% (23 cat, 1K+10K) | — | — | 100% |
| Distributed / JA3 cluster ban | 100% (80 IP) | — | Signal-based | — |
| nginx inline consult | PASS | — | — | Separate module |
| L7 application protection | WAF + consult + eBPF | — | — | CRS inline |
| Kernel / eBPF (XDP) ban | ipset + XDP | iptables | iptables/nft | — |
| False positive | 0.2% (measured) | High | Medium | CRS-dependent |
| Ban latency | ~26 ms | sec–min | sec | Separate integration |
| Short stability (5 min) | PASS (0 fail) | — | — | — |
| 72h soak | PASS (863/0 · VPS) | — | — | — |
| Evidence pack PDF+JSON | Automatic (14 files) | None | Partial | Module by module |
| Automated test matrix | 89 tests | — | Partial | — |
| SOC timeline / dashboard | Yes (:8443) | — | Console | — |
| Telegram ops + ack | Yes (one-click) | — | Partial | — |
| Setup time | ~15 min | minutes | minutes | hours (tuning) |
| Honest limits | ||||
| Block the first request instantly | Reactive (log line) | Reactive | Partly | Inline (instant) |
| Volumetric L3/L4 scrub | None — CDN recommended | None | None | None |
| Community signal network | Self-hosted | — | Yes (global) | — |
| Edge / Cloud WAF | Origin layer | — | Bouncer | Proxy mode |
| Managed cloud / SaaS | None (self-hosted) | None | Yes (console) | — |
Honest limit: in some areas rivals are clearly better (red cells). ModSec + CRS blocks the first request inline instantly (we're reactive — the first request may pass until the log line drops); CrowdSec is strong in its distributed community signal network and managed SaaS console. Throughput: 114,003 vs 17,193 EPS on the same 121 CRS @rx replay — not nginx inline ModSec (bench-vs-modsec.json).
//:Charts
Derived from measured proof (competitive-proof.json, bench-vs-modsec.json, fp-report.json, bench-ban-latency.json). Our line is phosphor turquoise.
Higher = better · 0–100 normalized · Throughput: bench-vs-modsec.json EPS ratio (114k vs 17k @rx) — LG not scored 100
Lower = better · n=5 (bench-ban-latency.json) · median 26.17 ms · target 75 ms
Higher = better · 863 samples · 0 errors (VPS)
Lower = better · % · LG measured, rivals architectural note
Higher = better · bench-vs-modsec.json · same 121 CRS patterns, PCRE2 JIT · 6.63× CRS @rx
Higher = better · corpus · %
//:Honest
//:Layers
Core
log → WAF → ipset ban (~15 min)
Pro
eBPF daemon, dashboard, metrics, fleet
Pro Plus
K8s/Helm proof (kind), fleet showcase, optional Wasm/mesh (XDR/Copilot roadmap)
Pro and Pro Plus do not change the protection level; they only add visibility and integration proof. XDR, Wasm and LLM Copilot are Pro Plus's long-term optional roadmap — Core is production-ready on its own.
//:Proof · Measured evidence
Not slides, reproducible proof. OWASP CRS parity, false-positive gates, ban-latency benchmarks, corpus recall and a 72-hour soak — all measured, automated and visible in a public test matrix. Dashboard /tests exactly the same matrix.
89
Total tests
89
Passed
72h
Soak PASS
~26ms
Ban pipeline E2E
//:Editions
Same C core, three packagings. Pick the layer you need — not an all-in-one 'mega platform'.
log → WAF → kernel ban. Enough on its own in production.
RAM
~110 MB
Disk
~4 MB (clean) · ~55 MB (events.db full)
Chain
C binary → log → WAF → ban
Includes
Core + SOC dashboard, Grafana, Prometheus, Caddy TLS, fleet.
RAM
~730 MB (laptop) · ~400 MB (VM)
Disk
~5.3 GB (VM, mostly Docker images)
Chain
Core + Dashboard + Grafana + Caddy + Prometheus
Includes
Pro + K8s/Helm proof (kind), fleet showcase, optional Wasm/mesh.
RAM
~1.9 GB (laptop, all on)
Disk
Pro disk + ~2–3 GB (kind volume)
Chain
Pro + K8s/Helm proof (kind) + fleet + Wasm/mesh
Includes
The protection level is identical across all three editions. Pro and Pro Plus only add visibility and integration proof.
The RAM and disk that grow with higher editions do not come from the Log Guardian C core. The Core binary stays at ~515 KB and ~110 MB RAM. The extra footprint is the third-party tools you chose for SOC and demos (Docker, Grafana, kind, etc.) — shut them down or run Core only and the cost drops.
| Layer | Log Guardian's responsibility | Third-party (outside us) |
|---|---|---|
| Core | log-guardian + daemon + config/DB (~110 MB RAM, ~4–55 MB disk) | — |
| Pro | Same Core binary; no extra protection | Docker images, Node.js dashboard, Grafana, Prometheus, Caddy |
| Pro Plus | Still the same Core; no extra protection | kind/K8s node, Helm chart pods, operator, optional Wasm/mesh |
//:Setup
Pick your tab; each guide is self-contained — you don't need to read Core for Pro, or Pro/Core for Pro Plus.
This guide completes end to end on its own. Ubuntu 22.04/24.04 or Debian 12 (amd64), root/sudo.
Install Debian/Ubuntu package dependencies and nginx (if missing).
sudo apt-get update sudo apt-get install -y ipset libbpf1 libcurl4 libpcre2-8-0 \ libsqlite3-0 libssl3 libelf1 liburing2 nginx
Setting up ipset ... Setting up nginx ...
Clone the repo, build with all cores and install systemd units + rules via install.sh.
git clone https://github.com/kurtulusutkucenik/Linux-Log-Guardian.git cd Linux-Log-Guardian make -j$(nproc) sudo bash install.sh
cc -O2 ... -o log-guardian cc -O2 ... -o log-guardian-daemon [install] systemd unit'leri kuruldu
Starts services, prepares the fail-closed API token and verifies the setup gate (expect FAIL: 0).
sudo bash scripts/install_first_run.sh sudo bash scripts/ensure_api_security.sh bash scripts/post_install_verify.sh
[OK] servisler aktif [OK] API fail-closed (tokensiz 403) FAIL: 0 WARN: 0
Apply the log_guardian format so the WAF can read body + X-Forwarded-For, then reload nginx.
STRICT=1 bash scripts/check_nginx_log_format.sh sudo nginx -t && sudo systemctl reload nginx
[check] access_log log_guardian aktif nginx: configuration file test is successful
Check daemon IPC, Prometheus metrics and the ipset ban list. Core is now in production.
sudo log-guardian --health curl -s http://127.0.0.1:9091/metrics | grep loganalyzer_ sudo ipset list log-guardian-ban | head
[HEALTH] daemon IPC: OK
loganalyzer_ban_success_total{tenant_id="default"} 8
Members:
203.0.113.250//:Evidence
One command: STABILITY=1 bash scripts/full_proof_pack.sh → PDF + release-pack.zip + data-room.zip
# Tek komut — rakiplerde yok
STABILITY=1 bash scripts/full_proof_pack.sh
# 3 dk demo
SKIP_WEBHOOK=1 bash scripts/demo_3min.sh
Update: STABILITY=1 bash scripts/full_proof_pack.sh
//:Contact
Write for questions, collaboration or contributions. Bug reports and pull requests are welcome in the open-source spirit.
kurtulusutkucenikcontact@gmail.com