A single compromised web process can spawn thousands of processes, exhaust file descriptors, and take down the entire server—if resource limits aren't enforced. The Pluggable Authentication Modules (PAM) framework and /etc/security/limits.conf allow you to cap resources per user/group, enforce password policies, and add additional authentication factors. This lesson combines resource control with PAM hardening to create a resilient Linux account security architecture.
The file /etc/security/limits.conf sets hard and soft limits for users and groups on parameters like nproc (max processes), nofile (open file descriptors), memlock (locked memory), and cpu (CPU time). Hard limits can only be increased by root; soft limits can be raised by the user up to the hard limit. Applying limits to service accounts (www-data, mysql) prevents resource exhaustion attacks. Use systemd's LimitNOFILE/LimitNPROC for finer per-service control.
# Example limits.conf entries
# <domain> <type> <item> <value>
@webops hard nproc 200
www-data soft nofile 4096
www-data hard nofile 8192
* soft core 0Setting core 0 for all users disables core dumps, which can contain sensitive memory data.
PAM configuration files in /etc/pam.d/ (e.g., common-auth, common-password, sshd) define the authentication stack. Hardening includes: enforcing strong passwords with pam_pwquality.so (minlen=12, dcredit=-1, ucredit=-1, ocredit=-1, lcredit=-1), limiting login attempts with pam_tally2.so or pam_faillock.so, and implementing MFA with pam_google_authenticator.so. Always test PAM changes with a separate root session open—a misconfiguration can lock all users out.
# Enforce password quality in common-password
sudo sed -i 's/pam_unix.so obscure sha512/pam_unix.so obscure sha512 remember=5/' /etc/pam.d/common-password
# Add pwquality
# Add line: password requisite pam_pwquality.so retry=3 minlen=12 difok=3💡 Always use the 'requisite' or 'required' control flags appropriately: 'requisite' stops immediately if the module fails, 'required' continues the stack but will deny at the end. This affects the error message shown.
| PAM Module | Purpose | Example Usage |
|---|---|---|
| pam_pwquality.so | Password strength enforcement | password requisite pam_pwquality.so minlen=12 |
| pam_faillock.so | Account lockout after failed attempts | auth required pam_faillock.so deny=5 unlock_time=600 |
| pam_limits.so | Enforce limits.conf | session required pam_limits.so |
| pam_umask.so | Set default umask | session optional pam_umask.so umask=027 |
Restrict which users can use su (usually to the 'wheel' group on RHEL, or 'sudo' on Debian) by modifying /etc/pam.d/su. Add auth required pam_wheel.so use_uid. For sudo, ensure that PAM is configured to prompt for the user's own password (not root's) via pam_unix.so. Also, set timestamp_timeout=0 in sudoers to reduce risk of session hijacking.
⚠️ A buggy PAM configuration can make the system unbootable. Always keep a root shell open in a separate tty while testing PAM changes, and test with a non-root user before logging out.
Verify exercises to earn ★ 160 XP and unlock next lab level.