DEV Community: Stefan Sabolowitsch

Stop testing your flow collector with random NetFlow tuples

Stefan Sabolowitsch — Fri, 10 Jul 2026 10:31:11 +0000

If you have ever built or operated a flow collector, you know the problem: the
usual test generators emit random tuples. Random source IP, random destination,
random ports, random counters. That is fine for a parser smoke test — and
useless for everything after the parser. Dashboards look like noise, enrichment
has nothing meaningful to enrich, and "does my Top-Talkers panel actually make
sense?" is a question random data cannot answer.

I ran into this while building my own collector stack (flow collector →
VictoriaLogs → Grafana) and converting ElastiFlow dashboards to LogsQL. I
needed traffic that behaves like an enterprise network — repeatably, at a
controlled rate, without pointing test tooling at production. So I built one.

flowsimulator-go
is an open-source enterprise flow simulation platform written in Go. MIT
licensed, single static binary, one dependency.

The core idea: simulate sessions, not tuples

Instead of rolling dice per record, flowsimulator-go models an enterprise
network in YAML — sites, VLANs, address pools, endpoint personas
(windows_client, domain_controller, firewall, …), applications, and
services — and then plays ordered session chains on top of it.

The built-in windows-login template is a good example. One session produces
six flow records, in order:

DNS before Kerberos, Kerberos before LDAP, LDAP before SMB — the way a real
Windows logon looks on the wire. Web browsing resolves DNS before opening TLS.
Backups authenticate before they transfer. A behaviour profile
(interactive-tcp, bulk-transfer, asymmetric-download, …) shapes bytes,
packets, duration, and TCP flags per event.

There are ~30 built-in templates, including security patterns: port scans,
SSH/RDP brute force, SMB enumeration, beaconing, DNS tunneling, exfiltration,
and lateral movement. Crucially, these run as low-weight scenarios blended
into dominant normal traffic — because a detection dashboard tested against
100% attack traffic tells you nothing.

One neutral core, four wire protocols

Architecturally, everything funnels through a protocol-neutral FlowRecord:

The scenario engine knows nothing about wire formats; the encoders (NetFlow v5,
NetFlow v9, IPFIX, sFlow v5) know nothing about scenarios. Each exporter keeps
its own encoder state — sequence numbers, NetFlow v9/IPFIX template
refresh/cache, sFlow sample pools — so a mixed-protocol simulation behaves like
a fleet of independent devices. Templates are derived from a central,
source-backed IANA/IPFIX information element registry; custom enterprise IEs
can be added via registry files.

Runs are deterministic: same seed + same config = same dataset. That makes
regression testing across collector versions actually meaningful.

Quickstart

git clone https://forgejo.sabolowitsch.org/StefanSA/flowsimulator-go.git
cd flowsimulator-go
go run ./cmd/flowsimulator-go run -c configs/examples/minimal-netflow5.yaml --duration 5s

That sends five seconds of NetFlow v5 to 127.0.0.1:2055. Minimal configs
exist for all four protocols, enterprise examples model HQ/campus/datacenter/
hybrid-cloud topologies, and a continuous lab config runs all four protocols
until SIGTERM — useful as a permanent telemetry source for an observability
lab or collector burn-in. A JSON status endpoint reports records, packets,
bytes, per-protocol counters, and current rate while it runs.

What it deliberately does NOT do

A few honest boundaries, because I think tooling should state them up front:

No invented vendor fields. Cisco/Palo Alto/Fortinet enterprise IEs only enter the registry with a documented source. No made-up field numbers.
No payloads, no PCAP replay, no fuzzing. It serializes flow records, nothing else. The security scenarios are synthetic flow patterns for testing detection pipelines — they do not perform attacks.
IPv4 only for now. IPv6, IPFIX Options Templates, and richer NAT/MPLS/VXLAN/SD-WAN records are on the roadmap.

Try it

Repo: https://forgejo.sabolowitsch.org/StefanSA/flowsimulator-go
Docs: session template library, scenario model, protocol coverage plan, and integration test strategy are all in docs/
License: MIT

If you build or operate flow collectors — or you just want realistic NetFlow/
IPFIX/sFlow data for a Grafana lab — I would genuinely like to hear what breaks
and what is missing. Issues and feedback welcome.

Vaultwarden-Plus v1.36.3: Organization Account Recovery — without breaking zero-knowledge

Stefan Sabolowitsch — Fri, 03 Jul 2026 09:17:16 +0000

Every operator who runs Vaultwarden for a team eventually hits the same wall: a member forgets their master password. In a zero-knowledge system that's supposed to be a dead end by design — the server can't just "reset" what it never had access to.

Bitwarden solves this upstream with Organization Account Recovery: enrolled members hand the org an encrypted recovery blob, and an admin can trigger a recovery that forces a password reset — all without the server ever seeing a plaintext password or vault key. That capability has been on the operator wishlist for Vaultwarden for a long time.

As of v1.36.3, it's integrated into Vaultwarden-Plus.

What actually shipped

Admin-triggered recovery for enrolled organization members, driven through the official Web Vault Admin Console.
Forced password-reset flow for the affected member on next login (update-temp-password).
Support for both legacy and V2 password payloads, plus 2FA-only recovery requests.
A Web Vault adapter that handles the older /reset-password path and the current /recover-account calls, so official-client compatibility stays intact.

The part I care about most: the security model didn't move

Account recovery is exactly the kind of feature that's easy to ship badly — by quietly weakening the threat model. So the hard constraint was: zero-knowledge stays zero-knowledge.

The server still never stores plaintext master passwords, plaintext vault keys, plaintext org private keys, passkey PRF secrets, trusted-device material, or decrypted vault contents. Recovery only works when org policy, enrollment, authorization, and a valid recovery payload all line up — and credential mutation stays fail-closed if a request is malformed or incomplete. Recovery material, tokens and mail links are never logged.

In other words: an admin can get a locked-out colleague back into their vault, but "admin" never becomes "can read everyone's passwords."

Operator notes

No database or config migration required — drop-in for existing deployments.
You'll need SMTP / sendmail / SES configured for recovery notification mail.
The bundled Web Vault is intentionally pinned to 2026.4.1 (validated against this recovery flow); upgrades beyond it wait until an upstream artifact is available and separately validated.
Validated end-to-end on an isolated stack (SQLite + Maildev): policy → enrollment → admin recovery → forced reset → completion.

Try it

services:
  vaultwarden:
    image: forgejo.sabolowitsch.org/stefansa/vaultwarden-plus:1.36.3
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vw.domain.tld"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80   # TLS terminates at your reverse proxy

Release & full notes: https://forgejo.sabolowitsch.org/StefanSA/vaultwarden-plus/releases/tag/v1.36.3

If you run Vaultwarden for an organization, I'd love to hear how you currently handle lost-master-password situations — and whether this matches what you'd need. 🔐

Vaultwarden-Plus: A Password Manager Built for Operators

Stefan Sabolowitsch — Wed, 24 Jun 2026 11:29:39 +0000

If you search dev.to for Vaultwarden, you'll find dozens of excellent guides: how to deploy it with Docker, how to put it behind a reverse proxy, how to back it up, how to do it for $3 a month. They all answer the same question — how do I stand this up?

This article answers a different one: what happens after it's running, for years, for other people?

That's the question behind Vaultwarden-Plus.

First, the obvious disclaimer

Vaultwarden has been my password manager of choice for years. It's lightweight, fast, reliable, and one of the best examples of what a community-driven open source project can achieve. Thousands of people use it every day to self-host their passwords while staying fully compatible with the official Bitwarden clients.

So why a fork?

The honest answer surprised even me: I wasn't looking for more features. I was looking for a project that prioritizes long-term operation.

Vaultwarden-Plus is not a replacement for upstream, and it's not an attempt to compete. Upstream is excellent and keeps moving the whole ecosystem forward. Plus just asks a narrower question:

What would a Vaultwarden distribution look like if every single decision were made from the perspective of the person who has to operate it?

From self-hosting to operating

Running a password manager for yourself is one thing. Running it for your family, your friends, or an organization changes the perspective completely.

Every update matters. Every config change matters. Every security improvement matters. And — most underrated of all — every unexpected behavior matters, because you're the one who gets the message at 23:00 that "the login is weird."

Over time I'd accumulated a growing pile of local patches: security hardening, CI changes, operational notes. Eventually it stopped being a personal patch set and started being a project. Vaultwarden-Plus is that project, made public.

The rules I actually maintain it by

1. The official client comes first

One rule is close to absolute:

If the official Bitwarden clients don't work, the feature is probably wrong.

Compatibility beats experimental functionality every time. You keep using the apps you already trust — browser extension, desktop, mobile, CLI — with no modified clients and no special workflows. A "cool feature" that only works in a patched client isn't a feature for an operator; it's a future support ticket.

2. Validation before implementation

Implementing everything is easy. Maintaining everything is not. So every proposed change runs the same gauntlet before a single line is written:

Is there a real operational problem behind it?
Does an upstream solution already exist?
Does it improve security?
How much maintenance cost does it add?
Can it be reviewed independently?
Can it be removed later without breaking unrelated things?

Sometimes the answer is a new feature. Sometimes the best engineering decision is to do nothing — and write down why.

3. Small changes scale better

Big rewrites look impressive in a changelog and are miserable to review and maintain three years later. Plus deliberately prefers focused, well-scoped additions. The features that exist today exist because an operator hit a real wall:

Mail dispatch hardening — non-critical account notifications are dispatched outside latency-sensitive request paths, while critical OTP and security mails stay fail-closed. A slow SMTP server should never block a login; a security mail should never silently get dropped.
DKIM signing for outgoing notification mail — because "your users' password-reset mail lands in spam" is an operational problem, not a UI one.
AWS SES mail transport — SES as a first-class alternative to plain SMTP for people who already run their mail through it.
Send email verification — require recipients to verify their address before they can open a Send.
OpenDAL / S3 enhancements — better S3-compatible object storage for attachments and data.
Passkey login (experimental) — passwordless sign-in via passkeys.
2026.5 client-compatibility updates — keeping pace with recent official Bitwarden client releases, so the "official client first" rule stays true in practice.

None of these turn the UI upside down. All of them make the service a little more predictable in production — which is exactly the property you care about when other people's passwords live on your box.

4. Documentation is part of the product

One lesson from years of running infrastructure: undocumented decisions eventually become forgotten decisions. Plus keeps a small set of canonical documents that evolve with the code — current project state, implemented functionality, upstream assessments, product goals, maintenance strategy. The docs are treated as part of the software, not an afterthought.

5. Upstream is a partner, not a competitor

The biggest risk for any long-lived fork is pointless divergence. So every upstream proposal gets continuously categorized into one of four buckets:

Implement · Watch · Defer · Reject

The goal is not to collect the most custom features. It's to stay small, understandable, and maintainable while adopting the improvements that give operators clear value.

What this means for you

Vaultwarden-Plus will probably never have the longest feature list. That's intentional. The focus stays on security, operational reliability, maintainability, reproducible releases, and compatibility with the official clients.

If you already run Vaultwarden, the switch is meant to be undramatic: same clients, same data model, same mental model — just decisions tuned for the person holding the pager. One small but telling example of that mindset: Plus does not recommend Rocket's built-in TLS for production. It expects TLS termination at an external reverse proxy (Traefik, Nginx, HAProxy, …) and the container to speak plain HTTP behind it — fewer moving parts in the crypto path, fewer surprises during an upgrade.

Try it

Stable container images are published to the project's own registry, so a Compose file is all you need:

services:
  vaultwarden:
    image: forgejo.sabolowitsch.org/stefansa/vaultwarden-plus:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vw.domain.tld"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80   # TLS terminates at your reverse proxy

The project lives here:

👉 Source, releases, issues & container registry: forgejo.sabolowitsch.org/StefanSA/vaultwarden-plus

One ground rule: report Plus-specific behaviour to the Plus tracker, not to upstream. If a bug reproduces on a stock Vaultwarden install, it belongs upstream. Keeping that boundary clean is part of being a good downstream citizen.

If you maintain self-hosted services or open source projects of your own, I'd genuinely like to hear how you approach long-term maintenance — the patches that never made it upstream, the "we decided to do nothing" calls, the docs you wish you'd written sooner. That's the conversation I'm hoping this starts.

Technical deep-dives on the individual hardening changes will follow. If that philosophy resonates, follow along. 🔐