Anes1032

Posted on Dec 12

Built an Audit System in a Single 15MB Binary That Even DBAs Can't Fool

#database #opensource #go #distributedsystems

When auditors ask you to prove your data hasn't been tampered with, what do you show them?

Access logs? Backups? pgaudit output?

But what if the DBA who generated those logs is the one committing fraud? How would you detect that?

DBAs are gods (Superusers). They have the power to modify data and erase the evidence. "We just have to trust the admins" — is that really acceptable?

I built an OSS called Witnz to answer this question: No Kafka, no dedicated DB, no additional servers, no complex configuration — just a single 15MB binary.

🔗 https://github.com/Anes1032/witnz

Witnz in 5 Seconds

Here's what happens when an attacker tries to tamper with data that should never change:

Witnz monitors PostgreSQL's transaction log (WAL) externally and instantly detects unauthorized changes — regardless of who made them.

Comparison with Existing Solutions

Solution	Setup Cost	Extra Infra	DBA Fraud Detection	Verification Speed
pgaudit	Low	None	❌ Logs can be deleted	N/A
Hyperledger Fabric	Very High	Kafka, CouchDB, CA...	⚠️ Overkill	Slow
immudb	Medium	Dedicated DB required	⚠️ Migration needed	Medium
Amazon QLDB	Medium	AWS-dependent	⚠️ Vendor lock-in	Medium
Commercial Tools	High	Dedicated servers	⚠️ Varies	Varies
Witnz	Low	None	✅	Fast (seconds)

Witnz delivers a blockchain-like trust model with the simplicity of a sidecar you can drop next to your app servers.

Why Can It Detect DBA Fraud?

The key is monitoring from outside the DB and locking evidence via distributed consensus.

Two Layers of Defense

Layer 1: Real-time WAL Monitoring (Instant)

Receives change events via PostgreSQL Logical Replication
Instantly detects UPDATE / DELETE and alerts
Even if the DBA deletes logs, Witnz has already captured the WAL

Layer 2: Merkle Root Verification (Periodic, Fast)

Periodically fetches all records in a single query and computes Merkle Root
Compares against stored Merkle Root Checkpoint instantly
Catches tampering that bypasses Logical Replication:
- Direct DB file manipulation
- Manual SQL during node downtime
- Restore from tampered backups
- Phantom inserts via unmonitored methods

Distributed Consensus for Tamper Resistance

Raft consensus (3+ nodes recommended, works with 1)
Nodes share "the correct DB state" (Hash Chain + Merkle Root)
Tampering is detected unless majority of nodes are compromised
BoltDB embedded: Evidence stored locally, zero external DB dependency

Bottom line: Even if a DBA tampers with the DB, it won't match the "ground truth" held by the Witnz cluster — and gets caught immediately.

Tech Stack: Simplicity First

- Language: Go (easy cross-compilation)
- DB Integration: PostgreSQL Logical Replication (jackc/pglogrepl)
- Consensus: Raft (hashicorp/raft)
- Storage: BoltDB (etcd-io/bbolt)
- Hashing: SHA256 + Merkle Tree
- Binary Size: ~15MB

Zero additional infrastructure. No Kafka, no dedicated DB, no Java VM.

Protection Mode: For Append-Only Tables

Witnz is designed for append-only tables like audit logs and transaction histories.

protected_tables:
  - name: audit_logs
    verify_interval: 30m  # Merkle Root verification every 30 min

  - name: financial_transactions
    verify_interval: 10m  # Higher frequency (still seconds for 1M records)

What Attacks Can It Detect?

Attack Scenario	Detection Method	Timing	Performance
`UPDATE` / `DELETE` via SQL	Logical Replication	Instant	Real-time
Direct DB file manipulation	Merkle Root verification	Next check	Fast (seconds)
Tampering during node downtime	Merkle Root verification	On startup	Fast (seconds)
Phantom Insert	Merkle Root verification	Next check	Fast (seconds)
Hash chain tampering	Raft consensus	Instant	Real-time
Record deletion	Merkle Root verification	Next check	Fast (seconds)

Why "Lightweight" Matters

Complex audit tools don't get adopted.

Hyperledger Fabric: Great tech, but Kafka + CouchDB + CA + MSP is too much
immudb: Migration cost to a dedicated DB is high
Commercial tools: Agents, servers, license management...

Witnz extracts just the essence of auditing into one binary.

✅ PostgreSQL only (RDS/Aurora/Cloud SQL compatible)
✅ Zero additional infrastructure
✅ One config file
✅ Start with systemd and forget about it

Getting Started (Single Node)

1. Enable Logical Replication in PostgreSQL

SHOW wal_level;  -- Should be 'logical'

2. Download Witnz

# Linux (amd64)
curl -sSL https://github.com/Anes1032/witnz/releases/latest/download/witnz-linux-amd64 \
  -o /usr/local/bin/witnz
chmod +x /usr/local/bin/witnz

3. Create Config

# witnz.yaml
database:
  host: localhost
  port: 5432
  database: mydb
  user: witnz
  password: secret

node:
  id: node1
  bind_addr: 0.0.0.0:7000
  grpc_addr: 0.0.0.0:8000
  data_dir: /var/lib/witnz
  bootstrap: true

protected_tables:
  - name: audit_log
    verify_interval: 30m

alerts:
  enabled: true
  slack_webhook: ${SLACK_WEBHOOK_URL}

4. Run

witnz init --config witnz.yaml
witnz start --config witnz.yaml

That's it. A scalable audit system running from a single 15MB binary.

Try It with Docker

git clone https://github.com/Anes1032/witnz.git
cd witnz
docker-compose up

Three Witnz nodes spin up and start monitoring PostgreSQL.

Use Cases

SOC2 / ISO27001 audits requiring tamper detection
Finance / Healthcare where tamper-proof evidence is legally required
Large SaaS protecting millions of audit log records
Multi-tenant SaaS proving data integrity to customers
Privileged Access Management reducing DBA fraud risk
HIPAA compliance protecting medical record access logs

Roadmap

Currently at MVP (v0.1.*). Here's the phased approach:

Terminology:

Raft Node: Customer-operated node in their VPC (current implementation)
Witnz Node: External monitoring node operated by Witnz Cloud (Phase 2)

Phase 2: Witnz Architecture Core 🔥

Revolutionary external monitoring architecture (single-region PoC)

Witnz Node & Zero-Trust Architecture

Witnz Node: External observer node that receives only hashes (no raw data access, no voting rights)
Customer Raft Cluster: Stays in customer VPC for low-latency consensus
Hash-only mode: Witnz Node verifies integrity without seeing actual data
Inconsistency detection: Alert when Raft Nodes report different hashes
Even if customer compromises all their Raft Nodes → Witnz Node detects it

External Anchoring

S3 Object Lock (WORM) integration — ~$0.001/year
Optional blockchain anchoring (Ethereum/Bitcoin) for public verifiability

Phase 3: Performance & Operations

Optimize for production and add basic operational capabilities

Performance:

Incremental Merkle Tree (handles billions of records)
CDC batch processing (10x throughput improvement)

Operations:

Health check endpoints
Structured logging
CDC reconnection logic

Phase 4: Service platform

Build Witnz-as-a-Service platform

Multi-region & Advanced Features:

Multi-region Witnz Node deployment (US/EU/AP)
Automated Witnz Node rotation (7-day cycle)
Witnz Pool management

SaaS Platform:

Managed Witnz Node infrastructure
Public audit log endpoints
Multi-tenant support
Web dashboard
Compliance tooling (SOC2, ISO27001)

Contributing

This is a fresh OSS project tackling DB auditing with Merkle Trees + Raft. Contributions welcome:

Bug reports & feature requests (Issues)
Code contributions (PRs)
Documentation improvements
Performance benchmarks
Other DB backends (MySQL, MariaDB)
Use case sharing

Especially looking for contributors interested in distributed systems, cryptography, and DB internals!

⭐ Stars, Issues, and PRs are greatly appreciated!