AlmaLinux Server Hardening Checklist: 20 Essential Security Steps

A fresh AlmaLinux installation is a starting point—not a complete security baseline. Use this practical AlmaLinux server hardening checklist to reduce unnecessary exposure, secure administrative access, preserve security controls, monitor activity and prepare for recovery.

This guide is intended for administrators securing AlmaLinux servers in labs, virtual machines, private clouds and production environments. Commands are examples, not a universal compliance profile: confirm the operating-system version, application requirements, access path and change-control process before applying them.

Before you change security settings

Hardening can interrupt remote access or break an application if changes are applied without understanding dependencies. Before changing SSH, firewall, authentication, cryptographic policy or kernel settings:

• Confirm the exact release and architecture with cat /etc/os-release.
• Take a tested backup or hypervisor snapshot and confirm that recovery works.
• Keep a working out-of-band console, hypervisor console or cloud serial console available.
• Record listening services, firewall rules, application ports and current SSH access.
• Apply one change at a time, validate it, and document how to roll it back.

The 20-point AlmaLinux server hardening checklist

1. Install security updates regularly

Keep the operating system and installed packages patched through approved repositories. Schedule maintenance windows for updates that require a reboot, and verify service health afterward.

sudo dnf check-update
sudo dnf upgrade --refresh

Review the proposed transaction before confirming it. In production, test updates on a representative non-production system and use a documented patch schedule. Avoid running an unreviewed automatic reboot on a critical server.

2. Remove software and services you do not need

Every unnecessary daemon or package can increase the attack surface. Inventory installed packages and enabled services, then remove or disable only components you have confirmed are not required.

systemctl --type=service --state=running
systemctl list-unit-files --type=service --state=enabled
sudo ss -lntup

Do not disable a service solely because its purpose is unfamiliar. Identify application, monitoring, backup, virtualization-agent and security dependencies first.

3. Use named administrator accounts and least privilege

Use individual accounts for people and automation identities for services. Grant administrative privileges only to users who need them, use sudo for controlled elevation, and remove access promptly when it is no longer required.

sudo useradd adminuser
sudo passwd adminuser
sudo usermod -aG wheel adminuser

Replace adminuser with your intended account name. Before changing SSH or root access, open a second session and confirm that the new account can log in and run only the intended administrative commands.

4. Secure SSH without locking yourself out

Prefer public-key authentication for administrative access. Limit SSH access using network controls and, where appropriate, an allowlist of authorized users or groups. Avoid permitting direct root login over SSH when your operational model supports named administrator accounts.

First inspect the effective configuration and existing drop-in files:

sudo sshd -t
sudo sshd -T | less
sudo ls -la /etc/ssh/sshd_config.d/

On systems where the OpenSSH configuration supports drop-in files, place managed overrides in the appropriate file under /etc/ssh/sshd_config.d/. Confirm include order and effective values with sshd -T; do not assume a new file overrides an earlier setting.

5. Configure firewalld for least exposure

Permit only required inbound services and restrict management ports to trusted networks wherever possible. Before enabling or reloading the firewall, make sure your active connection will remain allowed.

sudo systemctl enable --now firewalld
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

Use firewall-cmd --add-service=ssh --permanent only if SSH is the service and port you actually use. If SSH uses a custom port, configure the matching service or port rule and SELinux policy first. Add web, database or application ports only when required, and scope them to trusted sources when possible.

6. Keep SELinux enforcing

SELinux provides mandatory access controls that can limit the impact of compromised processes. Check its current state and investigate denials rather than turning it off to make an application work.

getenforce
sestatus

The target for a typical hardened server is Enforcing, unless a documented platform or application constraint requires a different approved design. Use SELinux-aware file contexts, ports and policy tools to resolve issues; do not blindly apply broad permissions.

7. Review accounts, passwords and authentication

• Remove stale accounts and lock unused accounts according to your account lifecycle policy.
• Use unique credentials and a managed password policy for accounts that still use passwords.
• Require multi-factor authentication for remote administrative access where supported by your access architecture.
• Protect privileged accounts and service credentials; never store secrets in shell scripts or public repositories.

Do not blindly set password-aging values for every account: service accounts, emergency accounts and centrally managed identities may need different policies.

8. Enable security-relevant logging and auditing

Centralize logs where possible and retain them long enough to support investigation and compliance. Review authentication failures, privilege use, service changes and security alerts. The audit daemon can provide additional event records where configured for your requirements.

systemctl is-active rsyslog
systemctl is-active auditd
journalctl -p warning --since "24 hours ago"

These commands report service state and recent warnings; they do not by themselves prove that all required events are audited. Define an audit policy, protect logs from unauthorized modification, and forward important events to a separate logging system.

9. Synchronize system time

Accurate time is important for log correlation, certificates, authentication and incident response. Use your approved NTP source and confirm that the time synchronization service is healthy.

timedatectl status
systemctl status chronyd

10. Minimize network exposure

Check which TCP and UDP sockets are listening and map each to an approved service. Place databases, management interfaces and internal APIs on private networks where possible. Apply cloud security groups, hypervisor port groups, network ACLs and host firewall rules as complementary controls.

sudo ss -lntup
ip address
ip route

Do not expose SSH, database ports or management dashboards directly to the internet unless the architecture explicitly requires it and compensating controls are in place.

11. Apply secure file and directory permissions

Review permissions on SSH keys, application configuration, backups, credentials and log files. Restrict secrets to the service or administrator that needs them. Avoid broad recursive permission changes such as chmod -R 777, which can create serious security problems.

stat /etc/ssh/sshd_config
sudo find /etc -xdev -type f -perm -0002 -print

The second command identifies world-writable files under /etc; review each result rather than automatically changing permissions, because legitimate package or application configurations may differ.

12. Protect SSH host keys and private keys

Private keys must remain secret, have appropriate permissions and be rotated or revoked when exposure is suspected. Verify server host-key fingerprints through a trusted channel when onboarding administrators or automation. Never paste private keys into tickets, chat messages or source control.

13. Review kernel and system security settings carefully

Use the distribution’s supported defaults unless a security baseline, workload requirement or vendor guide justifies a change. Kernel parameters can affect networking, containers, databases and high-availability software, so test them in a staging environment before deployment.

Avoid copying a large sysctl hardening block from an unrelated distribution or older guide without reviewing each parameter and its compatibility.

14. Install only trusted software and repositories

Prefer official AlmaLinux repositories and vetted vendor repositories. Review third-party repository signing keys, package provenance and update policies before enabling them. Remove repositories that are no longer needed, and do not disable package signature verification to work around installation errors.

dnf repolist --enabled
rpm -qa gpg-pubkey

15. Secure application services individually

Operating-system hardening does not replace web server, database, container runtime, monitoring agent or application security. Disable unused modules, use encrypted protocols, restrict service accounts and management endpoints, and follow the vendor’s supported hardening guidance for every exposed application.

16. Use secure remote administration paths

For cloud and virtualized servers, use provider firewalls, VPNs, bastion hosts, private management networks or identity-aware access where appropriate. Restrict access to hypervisor consoles and cloud control planes with role-based access and MFA. A host firewall is only one layer of network security.

17. Back up data and test recovery

Maintain encrypted backups with access controls and a retention policy. Keep a copy isolated from normal administrator credentials, monitor backup failures, and periodically perform a restore test. A VM snapshot is useful for short-term rollback but should not be treated as the only backup.

18. Monitor vulnerabilities and security events

Subscribe to relevant AlmaLinux security advisories and maintain an inventory of operating systems, packages and exposed services. Define who triages alerts, how quickly critical issues are handled and how emergency patches are approved.

19. Assess the server against a recognized baseline

Use a version-matched benchmark such as the CIS AlmaLinux OS Benchmark or an organization-approved baseline. Review each recommendation for applicability, record exceptions and scan regularly. A successful scan is evidence about the rules tested—not a guarantee that the system is secure or compliant with every requirement.

Start at the Center for Internet Security AlmaLinux OS Benchmark page and choose the benchmark for your AlmaLinux major version.

20. Document, review and retest the baseline

Record the baseline, approved exceptions, owner, change date and rollback steps. Reassess after OS upgrades, major application changes, new network exposure or a security incident. Hardening is an ongoing maintenance process, not a one-time checklist.

Baseline verification commands

Run these read-only checks to gather an initial view of a server. They do not replace a full vulnerability scan or compliance assessment.

# OS release
cat /etc/os-release

# Pending package update information
sudo dnf check-update

# SELinux state
getenforce
sestatus

# Firewall state and active rules
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

# Listening sockets and running services
sudo ss -lntup
systemctl --type=service --state=running

# SSH configuration syntax
sudo sshd -t

# Time synchronization
timedatectl status
systemctl is-active chronyd

# Recent warnings
journalctl -p warning --since "24 hours ago"

CIS benchmarks and compliance

The CIS AlmaLinux OS Benchmark provides version-specific secure configuration recommendations. The official Red Hat Enterprise Linux 10 Security Hardening guide is also a useful reference for many related Enterprise Linux security concepts, but verify commands and feature availability against the AlmaLinux release you run.

Organizations with formal requirements should select a benchmark and profile that matches their operating system and control framework. Test automated remediation before applying it to production: hardening changes can disrupt applications or remote access, and a scan alone does not establish compliance.

Common AlmaLinux hardening mistakes

• Disabling SELinux: troubleshoot policy denials and fix labels or policy rather than turning off a core control.
• Changing SSH without a rollback path: validate syntax and test a second session before closing the current one.
• Blocking required ports: document dependencies and test firewall changes through an out-of-band console.
• Applying generic scripts blindly: use a version-matched baseline and review every setting.
• Assuming backups are valid: perform restore tests and protect backup credentials separately.
• Confusing hardening with compliance: map controls to the actual required standard and retain evidence.

Frequently asked questions

What is AlmaLinux server hardening?

It is the process of reducing attack surface and strengthening controls on an AlmaLinux server through patching, access control, firewall configuration, SELinux, logging, secure service configuration, backup and ongoing assessment.

Is SELinux supposed to be enforcing on AlmaLinux?

For a typical hardened server, SELinux should remain in Enforcing mode unless a documented and approved requirement says otherwise. Resolve application compatibility issues with proper SELinux labels or policies rather than disabling it by default.

Should I disable SSH password authentication?

Public-key authentication is generally preferred for administrator access, but disable password authentication only after confirming key-based access works for every required administrator and automation workflow. Keep a tested recovery console available and validate the effective SSH configuration.

Is firewalld enough to secure an AlmaLinux server?

No. Firewalld limits network exposure but does not replace updates, secure authentication, SELinux, application hardening, centralized logs, backups, vulnerability management or network-level controls.

Which hardening benchmark should I use?

Choose the CIS AlmaLinux OS Benchmark or another approved baseline that matches your AlmaLinux major version and compliance requirements. Tailor the profile to the workload, test remediation, document exceptions and retain assessment results.

Can I run a hardening script directly on a production server?

Do not run an unfamiliar hardening script blindly in production. Review the script, test it on a representative system, confirm a recovery path, and apply changes through change control. Automated remediation can interrupt services or cause lockout.

Related AlmaLinux guides on VMoreCloud

Official sources and further reading

• CIS: AlmaLinux OS Benchmarks
• Red Hat: Security Hardening for RHEL 10
• AlmaLinux Wiki
• Red Hat documentation: Using SELinux

Conclusion: A well-hardened AlmaLinux server combines minimal exposure, timely patching, controlled administrator access, SELinux, firewall rules, reliable logs and tested recovery. Use this checklist as a repeatable baseline, adapt it to your workload, and validate each change before rolling it into production.

Technical disclaimer: Security requirements differ by release, workload and regulatory scope. Validate commands and configuration on the target AlmaLinux version, keep a recovery path, and test changes before production rollout.