Sean Muilenburg

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 owning the whole FOSS design instead of renting a black box.

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 impact surface — when something does go wrong, blast radius is constrained by least privilege and segmented roles designed in advance.
• 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 foundation for personal and MSSP-scale systems. The Stork/Kea work below sits on this same philosophy: performance and APIs matter, but they ride on images that already take security, auditability, and operability seriously.

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.

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.