Setting Up an AlmaLinux System: From Hardware Planning to Enterprise Hardening
Setting up an AlmaLinux system follows a structured process that spans from hardware planning to post-installation hardening, including resilience, reproducibility, and continuous auditing strategies. This guide integrates enterprise security best practices aligned with CIS, DISA STIG, and HIPAA benchmarks.
1. Preparation and Firmware (BIOS/UEFI)
1.1 System Requirements
- Minimum RAM: 1.5 GB (4 GB or more recommended for production)
- Disk space: 10 GB minimum, 20 GB recommended for general use
- Supported architectures: x86_64 (Intel/AMD), aarch64 (ARM64), ppc64le (PowerPC), s390x (IBM Z)
1.2 BIOS/UEFI Configuration
It's essential to decide between legacy BIOS or UEFI before starting. UEFI is required to enable Secure Boot, a feature AlmaLinux supports to ensure only signed and authorized kernel modules are loaded. Verify boot order and disable Secure Boot if there are driver conflicts. The BIOS/UEFI choice determines the partitioning scheme: MBR for legacy BIOS, GPT for UEFI. Verify compatibility of critical controllers (Intel 8254x NIC, Atheros chips, storage HBAs), as some require additional firmware in isolated environments.
1.3 ISO Download and Verification
- Available types: boot (network installation), minimal (standalone base), dvd (full packages)
- Import the AlmaLinux public key and verify the SHA256 checksum of the downloaded image to ensure integrity
-
Boot media creation:
ddon Linux/macOS, or Rufus/Fedora Media Writer on Windows - USB of at least 8 GB (12 GB recommended for convenience)
2. Configuration in the Anaconda Installer
Once booted from the USB, Anaconda will guide the configuration through the "Installation Summary."
2.1 Localization and Time
Configure keyboard, language support, and time zone. Enable network time (NTP) for precise synchronization, which is critical for forensic log consistency.
2.2 Software Selection
Base environment: Server with GUI, Server (no GUI), Minimal Installation, or Virtualization Host. Select add-ons according to the server role, applying the principle of minimal attack surface.
2.3 Partitioning Strategy with LVM
Custom partitioning with LVM (Logical Volume Manager) is fundamental for operational resilience. LVM allows expanding disks online without downtime and applying restrictive mount options per volume.
- Separate
/var,/tmp,/home, and/var/loginto independent LVM volumes - Apply options in
/etc/fstab: for/tmpand/var/tmpusenoexec(blocks binary execution),nosuid(ignores set-user-ID),nodev(ignores special devices) - For
/var/log, isolation prevents a disk-filling DoS attack from compromising the root partition - The XFS filesystem (default in AlmaLinux) allows online growth with
xfs_growfs
Note: filesystems like Ext3/4 reserve 5% of space exclusively for root, allowing recovery if a user fills the disk.
2.4 Encryption
Enable "Encrypt my data" in Anaconda to protect data at rest using LUKS encryption with a strong passphrase.
2.5 Network and Hostname
Enable detected network interfaces and assign an FQDN (Fully Qualified Domain Name) hostname.
2.6 Security Profile (SCAP Compliance)
From Anaconda, SCAP policies can be applied that automate the initial hardening of the system, establishing the security baseline from the first boot.
Available profiles:
- CIS Benchmark Level 1 or Level 2
- DISA STIG
- HIPAA
CIS Level 2 is the most restrictive and suitable for environments with strict compliance requirements.
2.7 User Settings
- Define a strong password for root
- Create a regular user and mark them as Administrator for sudo access
- Root should never be used for routine operations
2.8 FIPS (Highly Regulated Environments)
In environments that require it, enabling FIPS mode ensures the system uses only certified cryptographic algorithms.
⚠️ Important warning: FIPS must be enabled from the installer boot using the
fips=1kernel parameter, not as a post-installation step. Post-installation conversion can break software that depends on non-certified algorithms (legacy MD5 implementations, certain OpenSSL versions). Cold-initialized FIPS mode is significantly more reliable.
3. Post-Installation and Hardening Phase
After the first reboot, proactive maintenance and layered security steps are executed.
3.1 Initial Update
Run sudo dnf update immediately to apply the latest security patches and errata (ALSA). Audit active services with systemctl list-units --type=service and disable everything not necessary for the server role (minimal attack surface principle).
3.2 SELinux Management
- Verify that SELinux is in Enforcing mode
- Never disable it as a solution to problems
- Fix incorrect labels with
restorecon, not by disabling protection - Adjust behaviors with SELinux booleans before resorting to policy changes
- Analyze denials with
ausearch -m avcorsealertfor precise diagnosis
3.3 SSH Management
SSH configuration is one of the most critical attack surfaces on any network-exposed server.
- Disable root login:
PermitRootLogin no - Force use of Protocol 2
- Force public key authentication and disable password authentication
- Restrict access with
AllowUsersorAllowGroupsin/etc/ssh/sshd_config - Consider changing the default port (22) to reduce noise in access logs
3.4 Firewall Configuration
- Verify that
firewalldis active and enabled at boot - Apply the principle of least network privilege: only strictly necessary services (SSH, HTTP/S, etc.) with open ports
- Review active zones and connections with
firewall-cmd --list-all
3.5 Auditing with auditd
SELinux and firewalld protect the system, but auditd provides the forensic event logging required by frameworks like CIS or STIG. Without auditd, a system may be secure but not auditable.
- Verify that
auditdis active and configured to record critical security events - Configure a remote log server via Syslog-ng with SSL/stunnel tunnels — this ensures logs are tamper-proof even if the host is compromised (auditd is useless if an attacker with root access can wipe local records)
- Validate post-installation time synchronization with
chronyc tracking, as precise timestamps are essential for forensic log consistency
3.6 Least Privilege with sudo
- Configure
/etc/sudoerswith least privilege policies, limiting which commands each user or group can execute - Enable logging of all commands executed via sudo for full traceability
- Always use
visudoto edit sudoers, avoiding syntax errors that could lock out access
3.7 Kernel Live Patching
In environments with high-availability SLAs, the traditional patch → reboot → maintenance window cycle represents a significant operational cost. Implement KernelCare or TuxCare to apply critical security patches to the kernel and system libraries (Glibc, OpenSSL) without needing to reboot. This maximizes availability and eliminates maintenance windows for urgent security patches.
4. Resilience and Operational Continuity
4.1 Backup Strategy
A hardened system without backups represents an equally serious operational risk as a system without hardening. Backups must be defined before going to production.
- Configure LVM snapshots for quick captures of the system state before critical changes
- Implement regular external backups with tools like Restic, Bacula, or automated
rsyncpolicies - Periodically verify the integrity and restorability of backups
4.2 Continuity with LVM
LVM allows extending disks and growing XFS filesystems online with minimal or no downtime. Plan volumes with anticipated growth space to avoid capacity emergencies.
4.3 Long-Term Update Strategy
For migrations between major versions (e.g., AlmaLinux 8 to 9), use the ELevate project, which allows in-place upgrades without reinstalling the system. Plan update windows and document the pre-migration state with LVM snapshots.
5. Reproducibility and Configuration Management
5.1 Automation with Ansible
The manual guide becomes real value when translated into reusable, idempotent code. Ansible allows reproducing exactly the same state across any number of servers.
- Automate configuration of SELinux labels, booleans, and firewall rules
- Ensure every deployed server is identical to the previous one, eliminating configuration drift
- Version the playbooks in a source control system for change traceability
5.2 Integration with Existing Infrastructure
- Domain joining with
realm joinfor integration with Active Directory (via Winbind or SSSD) or FreeIPA, centralizing identity management - Configure internal package repositories for air-gapped environments or those with software approval policies
6. Active Vulnerability Management
Everything above covers initial configuration and maintenance. A complete enterprise cycle requires continuous evaluation — a server that meets CIS Level 2 today may not meet it six months later after updates and operational changes.
6.1 Scanning with OpenSCAP
Run oscap xccdf eval periodically against the same CIS/STIG profile applied during installation. Reports identify configuration drift from the initial baseline. Integrate scans into CI/CD pipelines or schedule them with cron for automatic evaluation.
6.2 Auditing with Lynis
Lynis complements OpenSCAP with a broader system security approach. Run lynis audit system and review the additional hardening recommendations.
Conclusion
This order of operations ensures the system is not only functional from the first minute, but meets enterprise security standards from its initial deployment. The sequence covers the four dimensions of a mature production system:
- 🔒 Secure by design — hardening from Anaconda
- 🔍 Auditable — auditd + remote logs
- 🔄 Resilient — LVM + backups + live patching
- ♻️ Reproducible — Ansible + configuration management
Active vulnerability management with OpenSCAP and Lynis closes the cycle by ensuring compliance is maintained over time, not just at the moment of deployment.
Originally published in https://lbcristaldo.hashnode.dev/
Top comments (0)