Linux User Management Tutorial: Complete Security Guide

1. /etc/passwd

A plain text file that stores basic information about every user account on the system.

Uses:

• Maps usernames to User IDs (UIDs) and Group IDs (GIDs).
• Lists user home directories and default shells.
• Used for user identification and login shell assignment.

2. /etc/shadow

A more secure text file that stores hashed user password information.

Uses:

• Contains actual password hashes and password aging information.
• Only accessible by the root user and essential security processes, protecting sensitive password hashes from regular users.
• Used by authentication mechanisms (like login, su, sudo) to verify user credentials.

3. /etc/group

A plain text file that defines the system’s group accounts.

Uses:

• Maps group names to Group IDs (GIDs).
• Lists members of each group for access control.
• Allows for management of file and process permissions by group.

Breakdown:

• username: root ⟶ The account name (superuser)
• password: x ⟶ Placeholder (real password is in /etc/shadow)
• UID: 0 ⟶ User ID (0 = root user)
• GID: 0 ⟶ Group ID (0 = root group)
• User Info: root ⟶ Full name or description
• Home Directory: /root ⟶ Directory for user files
• Shell: /usr/bin/zsh ⟶ Default login shell for commands

Note:

• System users (daemon/bin/sys) often have login disabled with shells like /usr/sbin/nologin.
• Human users have real shells (like /bin/bash or /usr/bin/zsh).

Command Breakdown:

• sudo - Required because /etc/shadow is only readable by root.
• awk -F: - Use colon (:) as field separator to parse shadow file.
• ($2 == "" || $2 == "*" || $2 == "!") - Check password field (field 2) for:
• "" - No password hash set.
• "*" - Account locked/disabled (common for system accounts).
• "!" - Password locked (user cannot login with password).
• {print $1 " has no password"} - Print username with descriptive message.

Command Breakdown:

• $5 - References field 5 (maximum password age in days).
• ($5 == "" || $5 == 99999) - Checks for:
• "" - No maximum age set.
• 99999 - Effectively infinite (273+ years).
• Both conditions mean the password never expires..

Command Breakdown:

• $3 - References field 3 (last password change date in days since epoch).
• systime() - AWK function returning current time in seconds since Unix epoch (1970-01-01).
• systime()/86400 - Converts current time to days since epoch (86400 seconds = 1 day).
• systime()/86400-30 - Calculates date 30 days ago in days since epoch.
• if($3 > systime()/86400-30) - If account's last password change is more recent than 30 days ago.

• cat /etc/group: The cat command reads the content of the /etc/group file (which lists all user groups on the system) and prints it to the standard output.
• |: The pipe takes the output from cat /etc/group and passes it as input to the next command, grep.
• grep -E "(sudo|wheel|admin)":
grep: Filters the input lines.
-E: Enables Extended Regular Expressions.
"(sudo|wheel|admin)": The pattern searches for any line that contains the string sudo OR the string wheel OR the string admin.

Command Breakdown: sudo chage -l testuser

• sudo: Execute with administrative privileges (required to read other users' password info).
• chage: Change age - the password aging utility.
• -l: List/display current password aging settings.
• testuser: The target user account to inspect.

Flag Breakdown:

• M 90 or -maxdays 90: Password expires after 90 days.
• m 7 or -mindays 7: Minimum 7 days between password changes.
• W 14 or -warndays 14: Warn user 14 days before expiration.

• L: Locked
• P: Password set (active)
• NP: No Password

Flag Description:

• -a or --append: Appends user to supplementary groups without removing existing group memberships.
• -G or --groups: Specifies supplementary groups to add the user to.
• --shell or -s: Changes the user's default login shell.
• --lock or -L: Locks the user account by prefixing the password hash with an exclamation mark (!).
• --unlock or -U: Unlocks the account by removing the ! prefix from the password hash.
• --expiredate or -e: Sets the account expiration date.

• --remove: Complete Wipe
• tar -czf: Secure Archive Backup
• -c: Create new archive
• -z: Compress with gzip (reduces storage space)
• -f: Specify filename
• $(date +%Y%m%d): Automatic date stamping

Password Policies & Account Security in Linux are rules and settings designed to protect user accounts by ensuring strong passwords and restricting how accounts are used. This includes:

• Password length and complexity requirements (such as minimum number of characters and the use of letters, numbers, and symbols).
• Regular password changes (forcing users to update passwords periodically).
• Account lockout policies (blocking user access after repeated failed login attempts).
• Disabling or removing unused user accounts to prevent unauthorized access.

Flag Breakdown:

• -S - Displays the password status information for the given account.
• -l - Locks the user account password.
• -u - Unlocks the user account password (removes the lock).
• -e - Expires the user’s password immediately.

There are two types:

• Primary group: Automatically created for each user; it's their main group.
• Secondary group: Additional groups that a user can be added to for extra access and permissions.

Flag breakdown:

• sudo: Run with administrator privileges (needed to create directories in /opt).
• mkdir: Make directory command.
• p: Create parent directories if they don't exist (creates /opt/company/ first).
• {web,database,security}: Bash brace expansion - creates 3 directories at once.

Flag breakdown:

• sudo: Administrator privileges required to change ownership.
• chgrp: Change group ownership command.
• groupname: Target group (webdev, dbadmin, security).
• directory_path: Directory to change ownership for.

Flag breakdown:

• ls: List directory contents.
• l: Long format (detailed permissions, ownership, size, date).
• a: Show all files (including hidden ones starting with '.').

• Regular users need to change their passwords.
• Password data is stored in /etc/shadow (only root can write).
• SUID lets passwd run as root temporarily to update the password file.

You should always use visudo because it checks for mistakes before saving.

• If you edit /etc/sudoers directly with nano or vim and make even a tiny typo, sudo can stop working, and you could lose admin access.
• visudo prevents this by validating the file syntax and blocking bad changes, keeping your system safe.

Flag breakdown:

• sudo: Run with administrator privileges.
• l: List privileges (what commands user can run with sudo).
• U secureuser: Check privileges for specific user "secureuser".

Flag breakdown:

• sudo: Administrator privileges required.
• visudo: Safe editor for sudoers file.
• c: Check syntax only (doesn't open editor).

Flag breakdown:

• sudo: Access system log files.
• tail: Display end of file.
• f: Follow mode (shows new lines as they appear).
• /var/log/auth.log: Authentication log file.
• | grep sudo: Filter only sudo-related entries.

Flag breakdown:

• find: Search command.
• /: Search entire filesystem.
• type fr: Find files only (not directories).
• perm -4000: Find SUID files (run as owner).
• o: OR operator (logical OR).
• perm -2000: Find SGID files (run as group owner).
• exec ls -la {} \;: Execute ls -la on each found file.
• 2>/dev/null: Hide error messages .

Permissions are like access rules for files and folders. They determine:

• Who can access a file/directory.
• What they can do with it (read, write, execute).

-m (modify)

• Modifies or adds ACL entries.
• Does not remove existing ACL entries, only adds/updates specified ones.

-d (default)

• Sets default ACLs for directories.
• These ACLs are inherited by newly created files/subdirectories within that directory.
• Only applies to directories, not regular files

• -a - Show all files including hidden ones (ls).
• -k - Key/tag for audit rules and searching (auditctl, ausearch).
• -l - List entries (crontab: list cron jobs; auditctl: list audit rules).
• -p - Permission types to monitor in audit rules (auditctl):
• r - Read access
• w - Write access
• x - Execute access
• a - Attribute changes (permissions, ownership, timestamps)
• -u - Specify username for operations.
• -w - Watch/monitor a file or directory path (auditctl).

Line-by-Line Explanation

1. #!/bin/bash
• Shebang line.
• Tells the system to run the script using Bash shell.
2. USER=$1
• Assigns the first argument passed to the script to the variable USER.
• Example: ./user_audit_report.sh secureuser → USER=secureuser.
3. echo "=== User Activity Report for $USER ==="
• Prints a header for the report.
4. echo "Last Logins:"
• Prints a sub-header for the last login section.
5. last $USER | head -5
• last $USER → Shows the login history for the user.
• head -5 → Displays only the last 5 login entries.
6. echo -e "\nCurrent Processes:"
• Prints a sub-header for current processes.
• -e allows interpreting escape sequences like \n for a newline.
7. ps -u $USER -o pid,cmd
• Shows all processes owned by $USER.
• -o pid,cmd → Displays only PID and command name columns.
8. echo -e "\nGroup Memberships:"
• Prints a sub-header for groups.
9. groups $USER
• Lists all groups that the user belongs to.
10. echo -e "\nPassword Status:"
• Prints a sub-header for password info.
11. sudo passwd -S $USER 2>/dev/null
• Shows the account/password status for the user.
• Example output: secureuser P 09/01/2025 0 999 7 -1 (Password set, last change date, etc.)
• 2>/dev/null → Silences error messages (e.g., if not running as root).
12. EOF
• Appears to be leftover from a here-document (not required in normal scripts).
• Can be removed if the script is standalone.

Command Breakdown

• chmod ⟶ change file mode (permissions).
• +x ⟶ add execute permission
• user_audit_report.sh ⟶ the script file

Command Breakdown

• chmod ⟶ runs the script from the current directory.
• +x ⟶ the script name.
• user_audit_report.sh ⟶ argument passed to the script (the username to audit)

• ED25519: Modern, fast, secure, and compact ⟶ preferred choice for SSH keys.
• RSA: Older, slower, larger keys ⟶ use if ED25519 isn’t supported or for legacy systems.

Line-by-Line Explanation

1. #!/bin/bash ⟶ Use Bash shell to execute the script.
2. # Monitor SSH security events ⟶ Comment describing the script purpose.
3. echo "=== SSH Security Monitor ===" ⟶ Prints script header/title.
4. echo "Failed SSH logins in last hour:" ⟶ Section header for failed logins.
5. sudo grep "Failed password" /var/log/auth.log | grep "$(date +'%b %d %H')" | wc -l ⟶ Count failed SSH logins in the last hour.
6. echo -e "\nSuccessful SSH logins today:" ⟶ Section header for successful logins.
7. sudo grep "Accepted" /var/log/auth.log | grep "$(date +'%b %d')" | wc -l ⟶ Count successful SSH logins today.
8. echo -e "\nTop 5 IP addresses with failed attempts:" ⟶ Section header for top IPs.
9. sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -5 ⟶ List top 5 IPs causing failed login attempts.
10. echo -e "\nCurrent SSH connections:" ⟶ Section header for active connections.
11. ss -t state established '( dport = :ssh or sport = :ssh )' ⟶ Show all currently established SSH connections.
12. EOF ⟶ Marks end of a here-document if used with cat << 'EOF'.

1. Identify Security Vulnerabilities

Check for common misconfigurations:

# List users with sudo privileges
getent group sudo

# Check home directory permissions
ls -ld /home/alice

# Check sudoers files
sudo cat /etc/sudoers.d/alice

# Check password expiration settings
sudo chage -l alice

2. Fix Permission Issues

Correct directory permissions and insecure sudo:

# Set secure permissions for home directory
sudo chmod 755 /home/alice

# Remove insecure sudo file
sudo rm /etc/sudoers.d/alice

Explanation:

• chmod 755 ⟶ user can read/write/execute; group and others can read/execute only.
• Removing NOPASSWD entry ⟶ restores sudo password requirement.

3. Implement Password Policies

Set corporate-standard password policies:

# Set password expiration: max 90 days, min 7 days, warning 14 days
sudo chage --maxdays 90 --mindays 7 --warndays 14 alice

# Force users to change weak passwords
sudo passwd -e alice

• chmod 755 ⟶ controls password aging.
• passwd -e ⟶ forces password change at next login.

4. Configure Secure Sudo Access

Problem in the lab:

echo "alice ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/alice

• This gives passwordless sudo, which is insecure.
• Any user with this entry can execute any command as root without authentication.

5. Configure Proper Group Memberships

Ensure users only have necessary privileges:

# Verify alice is removed from sudo group
groups alice

# Optionally, assign to correct groups
sudo usermod -G webdev alice

6. Generate Security Assessment Report

   Document findings and fixes in a report:

cat << 'EOF' > security_assessment_report.txt
Corporate Linux Security Assessment
===================================

Users Audited:
- alice
- bob
- charlie

Vulnerabilities Found:
1. Weak password for alice
2. Unnecessary sudo privileges
3. World-writable home directory
4. Passwordless sudo

Fixes Applied:
1. Set strong password for alice
2. Removed alice from sudo group
3. Secured home directory permissions (chmod 755)
4. Removed insecure sudo entry

Password Policies:
- Max days: 90
- Min days: 7
- Warning: 14

Recommendations:
- Regularly audit sudo privileges
- Enforce strong password policies
- Monitor failed login attempts
- Review home directory permissions periodically
EOF

# View report
cat security_assessment_report.txt

1. Create Secure Directory Structure for Web Applications

# Create directories
sudo mkdir -p /var/www/development
sudo mkdir -p /var/www/production
sudo mkdir -p /var/log/webapp

# Set group ownership
sudo chown :webdevs /var/www/development
sudo chown :webadmins /var/www/production
sudo chown :webdevs /var/log/webapp
sudo chown :webadmins /var/log/webapp

2. Set Up Proper ACLs for File Sharing

# Enable ACLs if needed
sudo apt install acl

# /var/www/development: webdevs rwx, webadmins rx
sudo setfacl -m g:webdevs:rwx /var/www/development
sudo setfacl -m g:webadmins:rx /var/www/development

# /var/www/production: webadmins rwx, webdevs r
sudo setfacl -m g:webadmins:rwx /var/www/production
sudo setfacl -m g:webdevs:r /var/www/production

# /var/log/webapp: both groups rw
sudo setfacl -m g:webdevs:rw /var/log/webapp
sudo setfacl -m g:webadmins:rw /var/log/webapp

3. Configure Sudo Rules for Service Management

sudo visudo
# Add this at the end for limited web service management:
# Allow only webadmins group to restart web services
%webadmins ALL=NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl restart apache2
# Deny webdevs any sudo by default (no entry, or explicitly)

4. Implement Umask Settings

   Set restrictive umask defaults:

# For webdevs
echo "umask 027" | sudo tee -a /home/developer1/.bashrc

# For webadmins
echo "umask 027" | sudo tee -a /home/webmaster/.bashrc

# (027 ensures new files are only readable/writable by owner/group, not others)

5. Test Privilege Separation

5.1 Switch to each user and verify access:

# As developer1
sudo su - developer1
touch /var/www/development/devfile
ls -l /var/www/development
touch /var/www/production/devfile  # Should fail or be readonly

# As webmaster
sudo su - webmaster
touch /var/www/production/adminfile
ls -l /var/www/production
touch /var/www/development/adminfile  # Should be able to read, not write

5.2 Confirm ACLs:

getfacl /var/www/development /var/www/production /var/log/webapp

5.3 Confirm sudo access:

sudo -l   # As developer1: no web service management
sudo -l   # As webmaster: should list allowed systemctl commands

1. Identify All Recently Created Accounts

   Check /etc/passwd entries for users with high UIDs (likely non-system accounts) and review account aging details:

awk -F: '$3 >= 1000 {print $1}' /etc/passwd | xargs -I {} chage -l {}

Look for recent creation dates and the username suspicious_user.

2. Find Accounts with Sudo Access

   # Check the sudo (admin) group
   grep sudo /etc/group
   

   This lists all users with sudo privileges. Confirm if suspicious_user appears here.

3. Check for Suspicious Cron Jobs

# List cron entries for the compromised user
sudo crontab -u suspicious_user -l

Look for scheduled tasks like /tmp/backdoor.sh running every 5 minutes—a strong indicator of malicious persistence.

# Scan all users’ crontabs for other anomalies
for u in $(awk -F: '{if ($3>=1000) print $1}' /etc/passwd); do sudo crontab -u $u -l 2>/dev/null; done

4. Analyze Login Patterns

# Check recent logins for anomalies or logins by unknown users
last | head -20

Look for logins by suspicious_user or other unexpected times/IPs.

5. Secure the System and Remove Threats

   A. Remove Malicious User

   sudo deluser suspicious_user
   sudo rm -rf /home/suspicious_user
   

   B. Remove Malicious Cron Job & Script

   sudo crontab -u suspicious_user -r
   sudo rm -f /tmp/backdoor.sh
   

   C. Audit Sudoers and Lock Down Further

   • Check /etc/sudoers and /etc/sudoers.d/* for suspicious entries.
   • Reset passwords for privileged users if compromise is suspected.
   • Review SSH authorized keys:

   basgrep -r "" /home/*/.ssh/authorized_keys
   

   D. Reload security and auditing tools

   sudo systemctl restart sshd
   sudo ufw status            # Ensure firewall is active
   

6. Document Findings

# Create a plain-text incident report
cat < incident_report.txt
INCIDENT: Unauthorized user and cron job detected
- Detected new user: suspicious_user
- Detected sudo privileges for suspicious_user
- Malicious cron job: '*/5 * * * * /tmp/backdoor.sh'
- No unusual logins detected in last 20 entries
- Removed user, crontab, and backdoor script
- Restored system state and verified no residual risk remains
EOF