Compliance hardening

The Mividas Installer can be switched into a hardened operating mode aligned with FIPS 140-3, the DISA STIG baseline, and the CIS benchmarks.

Enabling features

Mividas Server Status, 2026-09-07 12:54:53
=================================

12:54:53 up 17:34,  0 users
load average: 0.30, 0.41, 0.38

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       2.7G  213M  2.4G   9% /var/log
/dev/loop0      3.9G   76K  3.7G   1% /tmp
/dev/sda4        11G  1.3G  9.2G  12% /
/dev/sda5       183G   18G  158G  11% /home

43/43 services are up

IP:
eth0 UP 10.10.10.10/24

Installer is running: https://10.10.10.10:8999/
Internet status: working
Time sync: OK (10.10.10.1, stratum 3)
? Select action  Security settings
? Select action  (Use arrow keys)
   Disable admin account
   Disable SSH-login using password
   Configure unattended security upgrades for host VM packages
 ❯ Compliance hardening (FIPS, STIG) [Preview]
   Set GRUB menu-edit password (protects boot menu editing; default boot still works)
   List named operator accounts (sudo-group users with SSH keys)
   Disable further changes using boot console-wizard
   Back

After your Mividas Installer has unlocked compliance hardening, the following options will be available from the Mividas Installer CLI:

Mividas Server Status, 2026-09-07 13:02:29
=================================

13:02:29 up 17:41,  0 users
load average: 0.91, 0.57, 0.43

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5       183G   18G  158G  11% /home
/dev/loop0      3.9G   76K  3.7G   1% /tmp
/dev/sda4        11G  1.3G  9.2G  12% /
/dev/sda3       2.7G  213M  2.4G   9% /var/log

43/43 services are up

IP:
eth0 UP 10.10.10.10/24

Installer is running: https://10.10.10.10:8999/
Internet status: working
Time sync: OK (10.10.29.1, stratum 3)
? Select action  Security settings
? Select action  Compliance hardening (FIPS, STIG) [Preview]
? Select compliance features to activate  (<up>, <down> to move, <space> to select, <a> to toggle, <i> to invert)
 ❯○ FIPS 140-3 cipher mode (kernel fips=1; sshd lockdown; reboot)
  ○ STIG-aligned hardening (sshd, login.defs, sysctl, coredump)
  ○ STIG CAT III advisory rules (modprobe blacklist, faillock, pwquality)
  ○ Strip bundled CA roots from the system trust store (operator-added roots only)

Flag	What it covers
FIPS 140-3 cipher mode	Kernel fips=1, SSH algorithm lockdown, FIPS-validated TLS, SCRAM database auth
STIG-aligned hardening	DISA CAT I/II controls: SSH, login.defs, sysctl, core dumps, audit supplement
STIG CAT III advisory rules	Additive CAT III set: module blacklist, password quality, account lockout
Strip bundled CA roots	Removes the distribution’s CA bundle from the system trust store

CAT III is additive – selecting it implies the CAT I/II baseline. The CA-strip flag is independent and can be used without STIG.

FIPS 140-3 cipher mode

Enabling FIPS pins fips=1 on the kernel command line and switches the appliance to FIPS-validated cryptography end-to-end.

Enabling FIPS mode restricts the system to FIPS 140-3 validated cryptography. In practice:

• Specific crypto only – SSH, TLS and database authentication are limited to validated algorithms. Non-validated options are removed.
• Tighter access – The administrator password policy is stricter.
• Some features are unavailable – The incoming SMTP receiver and the proxy service are turned off, and only FIPS-compatible SSL modes can be selected.

FIPS mode applies to the host, the Mividas Installer, and all deployed products.

STIG-aligned hardening (CAT I/II)

The rule set is a focused subset of the Debian STIG / DISA SRG: the controls with the highest impact that do not break the Mividas runtime.

• SSH – Login banner, stricter login limits and timeouts, and risky features (root login, empty passwords, X11 forwarding, host-based auth) disabled. Applied as a drop-in, so existing Match blocks keep working.
• Accounts and passwords – Passwordless sudo is disabled. Password aging and minimum length enforced, failed-login delays added, and new accounts set to auto-lock after their password expires.
• Kernel, network and filesystem – Hardened sysctl settings covering ASLR, kernel information exposure, spoofing, and ICMP protections, and filesystem link protections.
• Core dumps – Disabled system-wide.
• Auditing – Extra audit rules layered on the standard Mividas baseline, covering account changes, privileged commands, and audit integrity.
• Compliance checks – Read-only checks report empty passwords and non-root UID 0 accounts; they never change anything.

In the Installer and deployed products, several settings are locked to their secure values — audit-to-syslog on, LDAP TLS verification enforced, SAML debug off, proxy service off, and a hardened administrator password policy. These are enforced in the model layer, so they can’t be changed via the web interface or the API.

STIG CAT III (advisory rules)

CAT III layers on top of CAT I/II for deployments that must also satisfy the advisory findings. It is mainly stricter about passwords and lockouts.

• Kernel module blacklist – Rare network protocols, removable storage, and legacy filesystems are blocked. Takes effect on the next boot.
• Password quality – Longer, more complex passwords with history and dictionary checks, enforced for root as well.
• Account lockout – Accounts lock after repeated failed attempts, including root, and lockouts are audited.
• PAM stack – Lockout and password-history modules are registered through pam-auth-update, so the Debian common-* files are never hand-edited.
• su restricted – Only members of the sudo group may use su.
• Ctrl-Alt-Del – Masked on the console.

Strip bundled CA roots

An independent flag for deployments that must trust only their own PKI.

When enabled, every CA root shipped by the distribution is disabled and the trust bundle is rebuilt from scratch. What survives:

• Every root the operator installed.
• The Installer’s own trust anchor.

Unticking the flag restores exactly the roots that were disabled.

Password policy for the Installer administrator

The password chosen when the Installer is first opened is checked for strength, and the requirements are listed above the field.

Host state	Requirement
FIPS or STIG active	At least 15 characters, with upper case, lower case, digits and special characters.
Neither active	The previously configured requirements, unchanged.

Follow-up steps

After a change, the wizard lists any of these that still apply to the host:

Set a GRUB bootloader password (recommended with FIPS)

Without one, anyone with console access can edit the kernel command line and boot without fips=1. Set it from Security settings → Set GRUB menu-edit password. It protects editing of boot entries (the e and c keys) only – the default unattended boot still works without authentication.

Enable Docker user-namespace remapping (CIS 2.8, recommended with STIG)

Without it, every container process could be run as the real host root. This is a planned-maintenance operation, not something applied in the background:

sudo cli docker enable-userns

It stops Docker and rewrites file ownership across the entire Docker data root, so the stack is down while it runs. Take a VM snapshot or a full backup first.

Install a login banner

The VM ships no legal/consent banner, because the required wording differs per deployment and picking the wrong one is worse than picking none. Install the text your authorizing official gives you in /etc/issue.net (shown by SSH before authentication) and /etc/issue (console). STIG mode already points SSH at /etc/issue.net, and the file is read per connection, so no reload is needed after editing the text. /etc/motd is shown after authentication and does not satisfy this class of control on its own.

Named operator accounts

Independent of the compliance flags, the wizard supports per-operator named accounts for day-to-day administration instead of the shared admin account, covering NIST 800-53 IA-2 (uniquely identify and authenticate users) and AC-2 (account management). Accounts are placed in the sudo group, get their SSH public keys installed, and inherit the host password policy. Removing an operator disables the account rather than deleting it, so historic audit records stay attributable.