//:LOG→BAN · SYSTEM ONLINE

Linux Log GuardianTürk bayrağı

Linux Log Guardian

  • ~20 ms kernel ban
  • 89 automated tests
  • 72h soak PASS

nginx access log → WAF/CRS → kernel ban · single chain · self-hosted

open source · MIT72h soak PASS

3.65k+ visits · 56 countries · proof PDF

Turkey's measurable-proof, single-chain self-hosted security stack — rivals are piecemeal; we ship one integrated chain.

~20ms

kernel ban

100%

recall

89

auto tests

3→1

tool merge

  • ~20 ms median ban — measured 21 samples vs Fail2ban's hours-long iptables path
  • 100% real attack recall + 100% OWASP CRS parity — 121 rules, 1500-line corpus
  • 0.2% false positive — 1 alarm in 500 benign lines; rivals higher/medium
  • 72h VPS soak — 863 samples, 0 errors; no automatic proof in rivals
  • 89 automated tests + 14-file evidence pack — PDF/JSON, reproducible
  • Fail2ban + ModSecurity + CrowdSec in one chain — ~15 min setup

Fail2ban + ModSecurity + CrowdSec separately? One product, one proof, one install.

Single chain from nginx access log line to ipset ban: parser, OWASP CRS/WAF evaluation and ~20 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

root@prod-node — bash

$ 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

nginx log → WAF → kernel ban89 automated tests72h soak PASS~20 ms kernel banfalse positive 0.2%real attack recall 100%OWASP CRS parity 100%MIT · Turkeyself-hosted · no vendor lock-innginx log → WAF → kernel ban89 automated tests72h soak PASS~20 ms kernel banfalse positive 0.2%real attack recall 100%OWASP CRS parity 100%MIT · Turkeyself-hosted · no vendor lock-in

//:About

What is Linux Log Guardian?

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 ~20 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, ~20 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

~20 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

Who is it for?

Not an e-commerce or WooCommerce shop — measured protection for hosting, API, and SOC operators behind nginx.

TR hosting

Shared / VPS hosting

Multi-tenant nginx with Turkish paths and anonymized customer corpus (API/JWT/path traversal) recall proof.

customer-corpus · tr-hosting · 89/89 gate

API / B2B

OpenAPI & JWT-backed API

BOLA/schema abuse, JWT abuse, OAuth redirect_uri/PKCE and path traversal variants — log→WAF→ban.

openapi-strict · ban-profile e2e

SOC

Telegram operator & timeline

Ban/ack/lineage in one stream, webhook batch and operator undo — SOC visibility beyond Fail2ban logs.

telegram-soc · dashboard :8443

//:3Paket

3-in-1 — no separate installs

Three rival tools · one chain · measured proof

Instead of installing Fail2ban, ModSecurity and CrowdSec separately, Log Guardian merges all three in one self-hosted package.

Fail2banPAKET 01

Ban engine

Instead of standalone install → included in Log Guardian

Fail2ban + iptables scripts

No separate Fail2ban. Log line to ipset/XDP kernel ban ~20 ms — policy, tenant, FP trust in one pipeline.

  • ~20 ms median
  • ipset + XDP
  • 0 fail (5 min)
ModSecurityPAKET 02

WAF / CRS layer

Instead of standalone install → included in Log Guardian

ModSecurity + separate nginx integration

No separate ModSecurity module. OWASP CRS 121 rules, PCRE2 JIT — single pass from nginx log line.

  • 100% CRS parity
  • 100% recall
  • 0.2% FP
CrowdSecPAKET 03

SOC & signal layer

Instead of standalone install → included in Log Guardian

CrowdSec bouncer + separate console + manual proof

No CrowdSec piecemeal stack. Prometheus, SOC timeline, 89 tests, 14 evidence files, Telegram ops — one panel.

  • 89 tests
  • 72h soak PASS
  • 14 evidence files

Fail2ban + ModSecurity + CrowdSec → 1 single chain

Full story → /paketler

//:Sayılar

All numerical values on this site

Source: competitive-proof.json · bench-ban-latency.json · bench-vs-modsec.json · fp-report.json · soak-report.json

Ban & latency

20.23ms

Median ban latency

21.1ms

P90 ban latency

18.69ms

Min sample (21 runs)

21.64ms

Max sample (21 runs)

75ms

Laptop target (PASS)

50ms

Prod target

WAF & recall

100%

Real attack recall

100%

OWASP CRS parity

121

CRS rule count

0.2%

False positive rate

500

Benign test lines

1500

Bench corpus lines

Throughput

280.373EPS

WAF/CRS (aynı corpus, LG)

16.560EPS

ModSec CRS replay

16.93×

LG / ModSec hız oranı

3.57µs

Per-line latency (LG)

16

Bench worker count

Stability & proof

89

Automated tests

72saat

VPS soak duration

863

VPS soak örnek

0

Soak errors

14

Evidence files

80IP

JA3 cluster test

Reach & setup

3.65k+

Site visits

56

Country reach

~15dk

Core setup time

9091

Prometheus port

8443

Dashboard port (prod)

//:Pipeline

Single chain: from log to kernel ban

~20 ms from an nginx access log line to ipset ban — rivals have piecemeal architecture.

1

nginx access log

writable access log, log_guardian format

2

Parser + normalize

URI, method, XFF, body — one schema

3

CRS / WAF engine

OWASP CRS, PCRE2 JIT, schema/BOLA

4

Ban pipeline

policy + tenant + FP trust decision

5

ipset / XDP kernel

~20 ms kernel ban

6

Metrics + dashboard

Prometheus tenant + SOC timeline

XDR, Wasm marketplace and LLM Copilot are long-term optional layers — Core is production-ready on its own.

//:Pipeline · Step by step

Why each link matters

The chain overview is above — below, what each step does, its advantages and how we compare to rivals.

1

nginx access log

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.

75 automated tests · install gate PASS

Advantages

  • Works without replacing nginx; only a log format tweak is needed
  • log_guardian format exposes URI, method, XFF and body in one schema
  • No shipping logs to the cloud — fully self-hosted, data stays on your server
  • Per-line instant processing; setup in ~15 minutes

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.

2

Parser + normalize

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.

280,373 EPS · 16.93× ModSec (bench-vs-modsec.json)

Advantages

  • One schema — no format mismatch between parser, WAF and ban pipeline
  • XFF and proxy chains normalized for correct client IP extraction
  • High lines/sec throughput — measured in benchmarks
  • Strict mode catches missing fields at install gates

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.

3

CRS / WAF engine

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

  • 121 OWASP CRS rules — industry-standard WAF coverage
  • PCRE2 JIT for high throughput; 280,373 EPS measured
  • Schema/BOLA layer catches API abuse
  • 100% real-attack recall · 0.2% false positive (1500-line corpus)

Compared with rivals

Log Guardian

WAF + CRS in one product — no separate ModSecurity module. 16.93× faster than ModSec on the same 121 rules.

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.

4

Ban pipeline

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.

~20 ms median ban · 21 samples (bench-ban-latency.json)

Advantages

  • Policy + tenant + FP trust in one pipeline — no separate Fail2ban jail tuning
  • 0.2% FP on 500 benign lines — measured gate
  • Multi-tenant labels flow to Prometheus and dashboard
  • IPC auth is fail-closed; unauthorized ban commands are rejected

Compared with rivals

Log Guardian

~20 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.

5

ipset / XDP kernel

~20 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 ~20 ms median.

72h soak · 863 samples (VPS) · 0 errors

Advantages

  • Kernel-level ban — iptables/nftables + ipset; harder to bypass from userspace
  • Optional XDP packet drop; on laptop/VM --no-xdp + ipset is enough
  • ~20 ms median from log line to ban (21 samples)
  • Distributed attacks: JA3 cluster + per-IP ban — 100% on 80-IP live test

Compared with rivals

Log Guardian

Log → kernel ban in one chain, ~20 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.

6

Metrics + dashboard

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.

80 tests · competitive-proof.json · dashboard /tests

Advantages

  • tenant_id-tagged loganalyzer_* metrics — multi-tenant observability
  • SOC timeline, attack map and /tests proof matrix in one dashboard
  • Self-hosted :8443 — no data sent to third-party cloud
  • 14-file PDF/JSON evidence pack syncs automatically

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

Selected proof

Core · Pro · Proof — measurable results in a single chain.

//:CoreCORE

What="we do"

Single chain: nginx log → OWASP CRS → ~20 ms kernel ban. Production in ~15 minutes.

~20 ms banOWASP CRS
01 / 12

//:Why

Why Log Guardian?

Rivals are piecemeal — we offer measurable proof in a single chain.

01

Single chain

nginx log → OWASP CRS → ~20 ms kernel ban. No Fail2ban + ModSec + script pile.

02

Transparent proof

competitive-proof PDF, 89 tests, 72h soak — missing or fragmented in rivals.

03

MIT · Turkey

Open source, Turkish docs, self-hosted — no vendor lock-in.

04

Honest limits

ModSec blocks the first request inline; we're reactive. CDN absorbs L3/L4. In return our WAF/CRS speed is 16.93× ModSec on the same corpus.

05

3-in-1

Fail2ban, ModSecurity, CrowdSec not separate — ban + WAF + SOC in one product.

06

Kernel speed

~20 ms median ban — Fail2ban/CrowdSec in seconds–minutes; 21 measured samples.

07

Distributed attacks

JA3 cluster 100% recall — 80 IP live test; per-IP ban + cluster detection.

08

Operator flow

Telegram alert + one-click ack, SOC timeline, tenant metrics — :8443 after install.

89

Automated tests

72h

Soak PASS

~20ms

Kernel ban

56

Countries

280,373

EPS

//:Vs

Compared with rivals

Measured proof — Fail2ban / CrowdSec / ModSecurity architecture notes. The winner in each row is marked red.

The advantages we give you

Fail2ban only bans, ModSecurity WAF is a separate module, CrowdSec needs a piecemeal stack. Log Guardian merges these three jobs in one chain — with measured proof.

One install, one chain

You don't install and integrate Fail2ban + ModSecurity + CrowdSec separately. nginx log → WAF/CRS → kernel ban in one product, ~15 min setup.

~20 ms kernel ban

Median ~20 ms from log line to ipset/XDP ban. Fail2ban/CrowdSec stay in seconds–minutes; proven with 21 measured samples.

280,373 EPS · 16.93× ModSec

On the same corpus with the same 121 OWASP CRS patterns (PCRE2 JIT), WAF/CRS throughput is 280,373 EPS — 16.93× faster than ModSec's 16,560 EPS. Measured and reproducible (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).

MetricLog GuardianFail2banCrowdSeccomplementaryModSec + CRS
Strengths (measured)
Log → WAF → kernel banSingle chainBan onlyPiecemealWAF separate
WAF/CRS throughput (same corpus)280,373 EPS (16.93×)16,560 EPS
OWASP CRS parity100% (121 rules)Reference (100%)
Real attack recall100% (23 cat, 1K+10K)100%
Distributed / JA3 cluster ban100% (80 IP)Signal-based
nginx inline consultPASSSeparate module
L7 application protectionWAF + consult + eBPFCRS inline
Kernel / eBPF (XDP) banipset + XDPiptablesiptables/nft
False positive0.2% (measured)HighMediumCRS-dependent
Ban latency~20 mssec–minsecSeparate integration
Short stability (5 min)PASS (0 fail)
72h soakPASS (863/0 · VPS)
Evidence pack PDF+JSONAutomatic (14 files)NonePartialModule by module
Automated test matrix80 testsPartial
SOC timeline / dashboardYes (:8443)Console
Telegram ops + ackYes (one-click)Partial
Setup time~15 minminutesminuteshours (tuning)
Honest limits
Block the first request instantlyReactive (log line)ReactivePartlyInline (instant)
Volumetric L3/L4 scrubNone — CDN recommendedNoneNoneNone
Community signal networkSelf-hostedYes (global)
Edge / Cloud WAFOrigin layerBouncerProxy mode
Managed cloud / SaaSNone (self-hosted)NoneYes (console)
Red = the winner in that row

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. In return, on the same corpus with the same 121 CRS patterns our WAF/CRS throughput is 280,373 EPS — 16.93× ModSec's 16,560 EPS (bench-vs-modsec.json).

//:Charts

Compared in charts

Derived from measured proof (competitive-proof.json, bench-vs-modsec.json, fp-report.json, bench-ban-latency.json). Our line is phosphor turquoise.

Performance profile (9 axes)

Higher = better · 0–100 normalized · Throughput: bench-vs-modsec.json EPS ratio (280k vs 16.5k) — LG not scored 100

0255075100Single chainRecallLow FPBan speedProofThroughputDistributedDocsSetup
Log GuardianModSec + CRSCrowdSecFail2ban

Ban latency — measurement samples

Lower = better · 21 samples (bench-ban-latency.json) · target 75 ms

023456890hedef 75ms#1#2#3#4#5
Log GuardianTarget 75ms

72h soak — service uptime

Higher = better · 863 samples · 0 errors (VPS)

02550751000h12h24h36h48h60h72h
Log Guardian

False positive comparison

Lower = better · % · LG measured, rivals architectural note

0255075100Log GuardianCrowdSecFail2banModSec
FP oranı

WAF/CRS throughput (EPS) — same corpus

Higher = better · bench-vs-modsec.json · same 121 CRS patterns, PCRE2 JIT · 16.93× ModSec

075000150000225000300000Log GuardianModSec + CRS
EPS (aynı corpus)

Attack recall — by category

Higher = better · corpus · %

0285583110SQLiXSSRCELFIBotDistributed
Log GuardianModSec CRS

//:Honest

Honest limits

  • Reactive architecture — the first request may pass until the log line drops; ModSec blocks the first request inline while we're reactive.
  • We don't replace Cloudflare or commercial WAF — last defense at origin behind CDN.
  • We don't absorb L3/L4 DDoS — CDN + nginx rate limit first, then Log Guardian.
  • CrowdSec is complementary, not a rival — Guardian + CrowdSec LAPI signal → ban API.
  • Distributed botnet — per-IP ban; optional CrowdSec community signal layer.
  • Does: log → CRS/WAF → ~20 ms kernel ban, proof PDF, Telegram ops, MIT self-hosted.

//:Layers

Editions

01

Core

log → WAF → ipset ban (~15 min)

02

Pro

eBPF daemon, dashboard, metrics, fleet

03

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

89 automated verification tests.
%99 passed.

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.

See all testsProof PDFSTABILITY=1 bash scripts/full_proof_pack.sh

89

Total tests

88

Passed

72h

Soak PASS

~20ms

Ban pipeline E2E

OWASP CRS parity 100%72h soak PASSAPI fail-closedfalse positive 0.2%SRI + CSP hardenedMIT open source

//:Editions

Core · Pro · Pro Plus

Same C core, three packagings. Pick the layer you need — not an all-in-one 'mega platform'.

Corerecommended

Linux Log Guardian

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

  • nginx parser
  • OWASP CRS 121 rules
  • ban pipeline
  • ipset / XDP
  • Prometheus metrics
ProSOC panel

Linux Log Guardian Pro

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

  • SOC timeline (:8443)
  • Grafana + $tenant panels
  • Caddy TLS + JWT
  • fleet / multi-tenant
  • Telegram ops
Pro Plusmost complete

Linux Log Guardian Pro Plus

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

  • helm install log-guardian
  • kind + admission webhook
  • DaemonSet + operator
  • fleet showcase
  • Wasm/mesh (opt.)

The protection level is identical across all three editions. Pro and Pro Plus only add visibility and integration proof.

RAM & disk growth — the responsibility boundary

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.

LayerLog Guardian's responsibilityThird-party (outside us)
Corelog-guardian + daemon + config/DB (~110 MB RAM, ~4–55 MB disk)
ProSame Core binary; no extra protectionDocker images, Node.js dashboard, Grafana, Prometheus, Caddy
Pro PlusStill the same Core; no extra protectionkind/K8s node, Helm chart pods, operator, optional Wasm/mesh

//:Setup

Install guide by edition

Pick your tab; each guide is self-contained — you don't need to read Core for Pro, or Pro/Core for Pro Plus.

Core

Linux Log Guardian

5 steps

This guide completes end to end on its own. Ubuntu 22.04/24.04 or Debian 12 (amd64), root/sudo.

01

Dependencies

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 ...
02

Source + build + install

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
03

First run + API security

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
04

Nginx log format

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
05

Health + first ban test

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

Evidence pack

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

competitive-proof.pdf
competitive-proof.json
bench-vs-modsec.json
fp-report.json
bench-ban-latency.json
soak-report.json
SOAK_SUMMARY.md
sprint-prod-proof.json
siem-export-report.json
taxii-feed-report.json
vm-sprint-proof.json
geoip-mmdb-report.json
webhook-route-proof-report.json
webhook-telegram-live-report.json

Update: STABILITY=1 bash scripts/full_proof_pack.sh

//:Contact

Contact & contribute

Write for questions, collaboration or contributions. Bug reports and pull requests are welcome in the open-source spirit.

kurtulusutkucenikcontact@gmail.com