PAM Security on Linux: Authentication Stacks, Password Policy, and MFA

1. Introduction

Pluggable Authentication Modules, or PAM, sit behind many Linux login paths. SSH, sudo, console login, su, screen lockers, and other services may rely on PAM stacks to decide whether authentication succeeds and what account or session rules apply. A PAM change can therefore affect a much larger part of the system than it first appears. This article focuses on defensive administration, auditing, and authorized lab work. The objective is to understand the control, identify misconfiguration before it becomes an incident, and build a repeatable hardening process that can be applied across real Linux environments.

2. How It Works

PAM configuration is organized into service-specific stacks. Modules participate in authentication, account, password, and session phases. Control flags such as required, requisite, sufficient, and optional determine how module results are combined. Distributions often generate common stacks from higher-level tools, so administrators should understand the platform’s supported management method. Linux security is layered, so this control should be considered together with identity, filesystem permissions, service configuration, kernel policy, network segmentation, and centralized monitoring. A single command rarely tells the whole story; the effective security posture comes from how these layers interact.

3. The Security Problem

Weak password policy, incorrectly ordered modules, disabled lockout logic, permissive null-password settings, or an untrusted custom PAM module can weaken every service that consumes the affected stack. Direct manual edits may also be overwritten by package or configuration-management updates. These weaknesses are often created gradually by troubleshooting, legacy migrations, vendor installation scripts, or temporary exceptions that later become permanent. A good security review therefore looks not only for obviously dangerous settings, but also for configuration that no longer has a clear owner or business justification.

4. How Attackers Abuse It

An attacker who obtains root can modify PAM for credential collection or persistence. From a defensive perspective, unexpected PAM files or modules are high-value indicators because they sit directly on the authentication path. Misconfiguration can also make brute-force attacks easier or unintentionally bypass controls. In an authorized assessment, the goal is to demonstrate exposure safely and report the exact condition that creates the risk. In production incident response, avoid making destructive changes before collecting enough context to understand whether the issue is a simple misconfiguration, active abuse, or a persistence mechanism.

5. How to Detect / Enumerate & Audit It

Command

grep -R --line-number -v '^#' /etc/pam.d 2>/dev/null | head -n 200

What it does: Review active PAM rules.

What to look for: Unknown modules, permissive controls, or unusual custom entries.

Defensive use: Create a high-level authentication-stack inventory.

Command

grep -R --line-number 'pam_faillock\|pam_pwquality\|pam_unix' /etc/pam.d /etc/security 2>/dev/null

What it does: Find common lockout and password-quality controls.

What to look for: Missing or inconsistent policy.

Defensive use: Check whether expected controls are present.

Command

find /lib /usr/lib -path '*security*pam_*.so' -type f -ls 2>/dev/null | head -n 100

What it does: List PAM modules.

What to look for: Unrecognized custom modules or recent files.

Defensive use: Support integrity review.

Command

authselect current 2>/dev/null || true

What it does: Show current authentication profile on distributions that use authselect.

What to look for: Unexpected profile or feature changes.

Defensive use: Avoid unsupported manual edits on managed systems.

A useful operational habit is to save the output of these checks in a baseline for each server role. A database server, bastion host, developer workstation, and container node will not look identical, so comparison should be against a known-good peer or documented configuration rather than against a generic assumption.

6. How to Audit the Environment

• Map which critical services use which PAM stacks.
• Review password quality and lockout policy against organizational requirements.
• Verify PAM module files come from trusted packages and are not writable.
• Use distribution-supported tooling such as authselect or pam-auth-update where applicable.
• Test authentication changes in a recovery-capable environment before production rollout.
• Document every exception with an owner, reason, and review date.
• Re-check the control after upgrades because packages and deployment automation can silently change defaults.

7. How to Fix / Harden It

• Use supported PAM profile management rather than ad-hoc editing when available.
• Deploy MFA through a reviewed PAM module only where recovery and break-glass procedures exist.
• Apply password quality and lockout settings appropriate to the threat model.
• Protect /etc/pam.d and PAM module directories with strict ownership.
• Monitor package integrity and configuration changes.
• Apply changes through configuration management when possible so the desired state is reproducible.
• Test hardening first on a staging host or a disposable snapshot and verify that critical services still function.

8. Detection & Monitoring

• Alert on changes to /etc/pam.d, /etc/security, and PAM module directories.
• Investigate authentication behavior that suddenly changes across multiple services.
• Correlate PAM modifications with newly observed login failures or successes.
• Keep time synchronization reliable so host events can be correlated with firewall, identity, EDR, and SIEM data.
• Send high-value security logs off-host because a fully compromised root account can often alter local evidence.

9. MITRE ATT&CK Mapping

MITRE ATT&CK is most useful here as a common language for detection engineering and incident reporting. The mapping does not mean every misconfiguration is an active attack; it shows which attacker behaviors may become easier when the control is weak.

10. Practical Lab

In an isolated Linux lab or disposable VM:

1. Clone a disposable VM before experimenting with PAM.
2. Inspect the SSH and sudo PAM stacks.
3. Enable a safe password-quality control using the distribution-supported method.
4. Test successful and failed authentication.
5. Revert the VM if the authentication stack becomes unusable.
6. Capture screenshots or command output before and after the change so you can prove what the control actually changed.
7. Revert the VM or remove the test configuration when finished.

11. Key Takeaways

• PAM Security on Linux should be treated as part of a layered security model, not as an isolated setting.
• Inventory the current state first, because unknown configuration is difficult to secure.
• Prefer least privilege, explicit ownership, and documented exceptions.
• Monitor changes to the control itself; attackers often try to weaken defenses after gaining access.
• Test fixes in a lab and verify the effective runtime state, not only the configuration file.

Continue learning: Linux Security

This guide is part of our Linux Security series. Related guides in this series cover permissions, sudo, SUID/SGID, Linux capabilities, SSH, PAM, systemd, logging, firewalls, DNS, process security, filesystems, encryption, auditd, kernel hardening, containers, mandatory access control, package security, incident response, and backup protection.