Sean Muilenburg AvalonWave Software

MSSP Operator · Systems · Networking · Security

Sean Muilenburg

My time as an MSSP operator gave me confidence under real load: insight into the security needs of production infrastructure, and hard-won experience operating and maintaining complex webs of systems—identity, addressing, mail, monitoring, and the policy planes that hold them together when something breaks at 2 a.m.

AvalonWave Software is my hobbyist software organization. Under that name I document my projects which have been used in production MSSP operations and, also, collaborate with fellow hobbyists game developers. What you will find here is a portfolio of real systems, hardened edges, and solutions I designed myself—not a faceless product brochure.

I treat uptime, observability, and security as one design problem—not three afterthoughts. When vendor plug and play options do not fit the environment, I stay with the problem until the architecture is coherent, operable, and defensible.

About me Case studies Webmail

About Me

Two tracks. One standard of work.

Professionally, I operate and design infrastructure with an MSSP operator’s discipline. Personally, I run AvalonWave Software as a place to publish information about what I've built and to work with people who share an interest in game development and open source tooling.

Both tracks demand the same attention to detail: understand the business needs, understand the security requirements, iterate over designs, document the entire system, and then make it hold under change.

The case studies below walk from a friends-and-family mail platform, through hardened RHEL image practice, into MSSP-scale DHCP modernization and network policy AAA— the same ideas applied at different scales.

More About Me

Dual purpose

  • Systems & security — internet services, MSSP-oriented operations, identity, mail, DHCP, hypervisors, networking, and hardening.
  • FOSS & game dev — open foundations I can read and control, and games as another outlet for creative thinking with fellow hobbyists.

How I work

  • Security — A security first mindset, using the NIST SDLC framework, SP 800 security controls, and remediate against CPEs and CWEs
  • Persistence — baseline, remediate, re-verify; stay on hard problems until the design is operable in production, not only on a whiteboard.
  • Creativity — purpose-built solutions when defaults fail: Open Source Software, APIs, and hardened images using architectures that fit the real environment.

Practice

Areas of demonstrated practice

Five domains I work in hands-on. This is a living map of experience—not a service menu. The case studies that follow are concrete examples drawn from this map.

RHEL & Unix services

Day-to-day practice on RHEL and Unix: Bind9, ISC Kea, ISC Dhcpd, Postfix, SNMP monitoring and collection, Websites, and more. The Modern Internet is built on Unix Systems, Practical experience with these systems is the foundation for understanding how to operate and secure them.

Hypervisor infrastructure

Compute estates across Proxmox, VMware, KVM/QEMU, and Hyper-V—clusters, storage choices, migration strategy, and capacity planning that still work when something fails.

Enterprise networking

Hands-on work with Cisco and Arista gear: routing, switching, segmentation, and the policies that keep multi-site and multi-tenant topologies coherent under change. Radius, AAA, and network policy is a first-class design problem, not an afterthought.

Windows, identity & collaboration

Windows Server, Active Directory, Exchange, and Microsoft 365 in real hybrid contexts— identity continuity, messaging, and the operational glue between cloud and on-prem.

Security analysis & hardening

CompTIA-aligned security practice applied to live systems: analysis, CIS Level 2 (CIS2) benchmark alignment, and FIPS 140-3–oriented hardening for servers and cryptographic posture—written so the next operator can verify it.

Scripting & Programming

Scripting and programming for automation, integration, and observability: Bash, PowerShell, Python, and other languages as needed to make the estate operable and auditable. Automation provides the foundation for consistent, repeatable, and reliable operations. Costly mistakes are avoided when the estate is managed as code.

Hardening

Harden first. Prove it. Keep it that way.

Security is configuration, evidence, and continuous discipline. The custom RHEL image practice in the case studies is the concrete form; this section is the standing rule: analyze, harden, and re-verify so posture survives the next deploy.

  • Baseline and remediate systems against CIS Level 2 (CIS2) guidance.
  • Align cryptographic and module choices with FIPS 140-3 oriented deployments.
  • Threat-aware review of edge services: mail, auth, DHCP, DNS, remote access, and admin paths.
  • Documented hardening patterns you can audit, automate, and hand to the next on-call.
CIS Level 2 (CIS2) Benchmarks translated into enforceable, reviewable system and image state.
FIPS 140-3 focus Cryptography and module posture for high-assurance environments.
Defense in depth Image hardening plus identity, policy, and monitoring—not a single control.

Case studies

Concrete systems, end to end

Four designs that show how the pieces fit. They move from the personal mail platform behind this site, through hardened RHEL images as a shared foundation, into MSSP-scale DHCP modernization with Stork and Kea, and finally into network policy for authentication, authorization, and accounting.

Hardened Foundation RHEL CIS2 FIPS 140-3 Images

Custom hardened RHEL-based images

Problem. Edge and service hosts accumulate drift. A one-time “secure install” is not a posture. If hardening is applied by hand after the fact, every new VM reintroduces attack surface, inconsistent crypto, and audit gaps. Production work— including DHCP platforms and other MSSP services—needs a starting image that is already defensible.

Design. I build custom RHEL-based images with hardening built in from the first boot, not painted on later. Baselines track CIS Level 2 (CIS2) expectations; cryptographic posture leans on FIPS 140-3 modules where the environment demands high assurance. The operating loop is deliberate: baseline → remediate → re-verify, with configuration treated as evidence you can re-check, not a screenshot from last quarter.

Built-in hardening is not cosmetic. It delivers:

  • Greater security — fewer weak defaults and fewer accidental openings on internet-facing and management paths.
  • Stronger auditability — a known image and known baseline make it possible to explain and prove what “secure” meant at deploy time.
  • Reduced attack surface — unnecessary services, packages, and permissions never ship with the image.
  • Reduced blast radius — when something does go wrong, blast radius is constrained by least privilege and segmented roles designed in advance.
  • Common Weaknesses — Our Evaluation process ensures we know the common vulnerabilities of our image and can address them proactively.
  • Defense in depth — image hardening is one layer that works with network policy, identity, monitoring, and application controls—not a single silver bullet.

Outcome. A reusable, secure, auditable foundation for personal and MSSP-scale systems that take security seriously out of the box.

Authoritative Mailbox OpenLDAP Postfix Dovecot Hardened Linux

Identity-centric virtual mail

Problem. This website’s main purpose is simple and personal: I built an email server for my friends and family to use. Consumer mail is fine until you want customized behavior—inbox cleanup policies, operator-visible diagnostics, realtime support from someone who actually runs the stack. For that you need identity, delivery, and access designed as one system, not three unrelated products.

Design. Everything runs on hardened Linux servers with free and open-source software. Roles are deliberate so onboarding, passwords, and mail flow share a single truth:

  • OpenLDAP — we manage identities here: virtual mail users, attributes, and the directory as the control plane for who exists and what they may use.
  • Postfix — SMTP service for submission and transfer, bound to that directory model rather than ad-hoc local accounts.
  • Dovecot — IMAP for mailbox access, authenticated against the same identity plane so clients and servers never disagree about who someone is.
  • Reverse proxy (access edge) — a TLS-facing reverse proxy sits in front of the mail IMAP / webmail client path, separating how people connect from the mailbox stack behind it. Client entry is an intentional layer, not an afterthought bolted onto the MTA.

Outcome. A living platform for people I care about, with room for customized behaviors such as inbox cleanup and realtime support when something goes wrong. Persistence shows up in keeping directory, SMTP, IMAP, and access edge aligned under real clients; creativity shows up in the way we treat identity as the control plane in OpenLDAP for mail, not a side effect of local accounts. Security shows up in the least privilege design. Users of the mail stack are virtual not local unix users, with zero access to the underlying RHEL platform

Next Gen DHCP Stork Kea RHEL CIS2 FIPS 140-3 Python

Stork and Kea DHCP integration

Problem. My time working in an MSSP gave me the opportunity to design our Stork/Kea stack—and finally give clients a real path off the deprecated ISC dhcpd. Legacy dhcpd can still hand out leases, but it does not meet modern expectations for API-driven control, high-performance operation, or first-class monitoring. Operators needed a next-generation DHCP plane without abandoning hardening or operability on the way there.

Design principles. The platform was assembled as a system, not a single binary swap:

  • Migration with intent — Kea replaces dhcpd as the high-performance DHCP engine, so clients gain a supported path forward instead of living on deprecated software.
  • Hardened RHEL-based images — the stack runs on custom images with CIS Level 2 (CIS2) focus and FIPS 140-3 cryptographic modules, so DHCP infrastructure inherits the same built-in hardening model described above.
  • Control plane vs. data plane — Stork provides command and control over the Kea daemon: a proven API surface and monitoring metrics so operators can see and steer the estate. Kea remains the next-generation, high-performance DHCP server that actually serves clients.
  • Integration facade — custom Python scripts implement a facade pattern in front of the Kea Management API. Automation and operators talk to a stable, intentional interface instead of scattering raw API calls across tools and tribal knowledge.
  • Observability as design — Stork metrics and API-driven visibility are part of the architecture, not a dashboard added after outages.

Outcome. Clients can move off ISC dhcpd onto a Stork-managed Kea platform that is fast, operable, and aligned with hardened RHEL practice. Creativity shows up in the facade and image strategy; persistence shows up in making control, leases, crypto posture, and monitoring agree under MSSP-scale constraints.

Policy plane RADIUS AAA Network policy RHEL

Network policy authentication, authorization, and accounting

Problem. Networks fail at the policy seams. Devices can obtain connectivity while still being the wrong identity, with the wrong privileges, and with no reliable record of what they did. Authentication, authorization, and accounting (AAA) treated as three separate afterthoughts produces gaps that neither DHCP alone nor a firewall rule of the week can fix.

Design. I treat network policy as an AAA problem on purpose: authentication establishes who or what is connecting, authorization decides what that principal may reach, and accounting records the session so operations and security share the same evidence. RADIUS and related policy control on RHEL/Unix sit at the center of that plane, coordinated with the rest of the access story—addressing, identity, and monitoring—so policy is not a silo.

Outcome. A clearer control model for access networks: decisions are explicit, enforceable, and reviewable. Persistence shows up in aligning AAA with real topologies and change windows; creativity shows up in designing policy as a first-class system rather than a checklist of vendor defaults.

Technology

Living documentation of my practice

The following is a living map of the technology I work with day to day. It is not a service menu, but a snapshot of the tools and platforms I have used in production environments, and the ones I continue to explore. The case studies above are concrete examples drawn from this map.

Information Technology and MSSP Operations

RHEL OpenLDAP Postfix Dovecot Stork Kea ISC dhcpd (legacy) Python DNS / BIND DHCP RADIUS Network policy / AAA SNMP Proxmox VMware KVM / QEMU Hyper-V Cisco Arista Windows Server Active Directory Exchange Microsoft 365 CIS Level 2 (CIS2) FIPS 140-3 Hardened images MSSP ops

Game Development

Unity C# Godot GD Script Unreal Engine C++ Blueprints

Game development

Hobbyist collaboration, same craft habits

Through AvalonWave Software I also document experiments and collaborate with fellow hobbyists interested in game development. It is the quieter half of the dual purpose: interactive design as another place to practice creative problem-solving—state, feedback, constraints—without displacing systems and security work.

Early experiments and playable builds live on a small hub when they are ready to ship. Sparse on purpose; substance over studio marketing.

Games hub →

Contact

Questions about the work

If you want to talk systems, hardening, Stork/Kea, mail design, or how a solution was put together—use the contact form below. For mail access on the friends-and-family platform, open Webmail.

Open Webmail Read case studies