Locking down user accounts and enforcing the principle of least privilege is one of the most critical steps in local server defense. Even with a hardened network perimeter, a single compromised or poorly configured user account can open the door to local privilege escalation.

Here is a practical production guide for securing user accounts.

1. Auditing and Purging Default Accounts

Securing a fresh OS install starts with removing unnecessary system users that often ship by default. These dormant accounts represent an unnecessary attack surface.

# Lock an account’s password to prevent login (e.g., games, news, ftp)

sudo passwd -l username

# Completely remove an unneeded user account and its home directory

sudo userdel -r username

2. Enforcing Principle of Least Privilege (Sudoers & System Users)

A major vector for local privilege escalation is poorly configured administrative rights or running background applications with too much authority.

Eliminating the NOPASSWD Trap

Every line in your configuration that grants passwordless execution is a wide-open backdoor if that user account or a web application script is compromised. In production environments, always require password validation for privileged commands.

To safely audit and modify system privileges, never edit the file directly. Always use the safe editing wrapper:

sudo visudo

Review the file and strictly eliminate or modify any lines granting unrestricted access:

# CRITICAL RISK: Remove or restrict lines formatted like this in production:
dbadmin ALL=(ALL) NOPASSWD: ALL

Implementing Role-Based Service Accounts

Application services should never execute within a root terminal context. If your web server (Nginx/Apache) or database engine (MySQL/PostgreSQL) is compromised while running as root, the attacker instantly gains complete control of the operating system.

When deploying local background tasks or applications, isolate them cleanly by building custom, non-interactive system users:

# Create a system user (-r) with no login shell (-s) and a specific home directory (-d)

sudo useradd -r -s /sbin/nologin -d /var/www/app appuser

# Restrict directory access exclusively to the dedicated service account

sudo chown -R appuser:appuser /var/www/app
sudo chmod 750 /var/www/app

3. Enforcing Strong Password Policies via PAM

To prevent brute-force or dictionary attacks on local accounts, you can enforce password complexity requirements using the Pluggable Authentication Modules (PAM) library.

Open the password quality configuration file:

sudo nano /etc/security/pwquality.conf

Uncomment and update the following directives to enforce strict security baselines:

# Minimum length of the password
minlen = 14

# Minimum number of character classes required (Uppercase, Lowercase, Digits, Symbols)
minclass = 4

# Maximum number of allowed consecutive identical characters
maxrepeat = 2

# Reject passwords that contain the username in reverse
usercheck = 1

4. Configuring Account Expiration and Password Aging

Forcing periodic password rotations and automatically locking inactive administrative accounts prevents old, forgotten credentials from being exploited.

Edit the shadow utility configuration file:

sudo nano /etc/login.defs

Configure these variables to establish password aging rules for all newly created accounts:

# Maximum number of days a password may be used
PASS_MAX_DAYS   90

# Minimum number of days allowed between password changes
PASS_MIN_DAYS   7

# Number of days warning given before a password expires
PASS_WARN_AGE   7

Note: To apply these aging rules to an existing user immediately, run the following command:

sudo chage --maxdays 90 --mindays 7 --warndays 7 username

5. Securing the Superuser Account (root)

The root account should be tightly restricted. System administrators should always log in as an unprivileged user and elevate their permissions using sudo only when absolutely necessary.

Lock the Root Password

Locking the root account prevents direct login attempts while preserving sudo functionality for authorized users:

sudo passwd -l root

Restrict TTY Access

To block root from logging in via standard physical or virtual console terminals (except the primary secure console), empty out the /etc/securetty configuration file or restrict its entries:

# Backup and create a clean, restricted terminal access list

sudo mv /etc/securetty /etc/securetty.bak
sudo touch /etc/securetty

6. Regular Access Auditing & Monitoring

Hardening a server is not a one-time event; you must consistently audit system access profiles to detect unauthorized persistence.

Run regular audits on system access history to filter out default services and isolate exactly who has accessed an active console shell session:

# Display all system accounts that have successfully authenticated, filtering out inactive default users

lastlog | grep -v "Never"

Security Warning: If this output displays a dormant system service user (like bin, sys, or ftp) or an unfamiliar user account showing active login timestamps, treat it as an active indicator of compromise (IoC) and investigate immediately.

7. Implementation Checklist

[ ] Lock or delete dormant system accounts (games, ftp, etc.).

[ ] Run visudo and ensure NOPASSWD entries are removed for production accounts.

[ ] Isolate web and database runtime operations into dedicated /sbin/nologin service accounts.

[ ] Enforce a 14-character minimum password length in pwquality.conf.

[ ] Restrict password reuse and set a 90-day expiration limit in login.defs.

[ ] Lock the root account password and mandate the use of sudo.

[ ] Setup a cron job or manual log check routine utilizing lastlog to audit account use anomalies.