Omarchy CIS
hardening.

Instead of creating a throwaway virtual machine that I would probably never use again, I completed the assignment on my own Arch-based Omarchy workstation. This gave me a reason to learn more about the security controls, configuration layers, and recovery options on the system I use every day.

The assigned benchmark targets Debian, so the goal was not to copy commands blindly or claim full CIS compliance. Each selected recommendation had to be evaluated, translated to the right Arch or Omarchy mechanism, and tested without breaking normal workstation use.

• Created a Snapper recovery point and documented both targeted and full rollback paths.
• Ran a privileged Lynis audit to establish a repeatable security baseline.
• Mapped ten applicable CIS Debian recommendations to Omarchy's Arch-based configuration.
• Captured the noncompliant state before making changes.
• Applied one controlled hardening set covering kernel settings, core dumps, login banners, protocol modules, and sudo behavior.
• Verified every control independently, checked system health, and repeated the full Lynis scan.

The ten selected controls restricted core dumps, disabled three unused network protocol modules, enabled recommended IPv4 security settings, replaced the information-revealing login banner, and shortened the cached sudo authentication period.

The implementation used native configuration drop-ins instead of editing distribution-owned files. That kept the changes easy to inspect, test, and remove while respecting the way systemd, modprobe, PAM, and sudo combine configuration from multiple locations.

All ten selected controls passed the final audit. An assertion-based verifier produced twenty passing checks, Lynis reported zero warnings, the hardening index increased from 69 to 71, and the suggestion count fell from 33 to 29.

Network routing, the private Tailscale connection, the host firewall, sudo configuration, and systemd service health remained normal after the changes. The final report preserves the procedure, before-and-after evidence, analysis, limitations, and recovery instructions so another researcher could reproduce the experiment.

A benchmark written for one Linux distribution can still provide useful guidance on another, but only when the intent of each control is separated from the distribution-specific command used to implement it. Package names, file locations, PAM layout, boot tooling, and configuration precedence all required verification.

The project also reinforced that a scanner score is supporting evidence, not proof of compliance. The stronger result came from combining a rollback plan, preserved baseline data, direct control assertions, operational health checks, and an identical final scan.