Loading...

VONDS ©

Lab 90: Configuring Account Lockout with faillock

Back to Lab Index

Harden authentication by validating faillock’s active system policy and enforcing consistent lockout behavior after repeated failures. Inspect per-user failure records and reset counters only after you confirm the event is benign and documented.

security auth hardening

Scenario

Security reports repeated failed logins against the appuser account. You need to verify the active lockout policy, apply a clear baseline in /etc/security/faillock.conf , and validate per-user failure records before safely resetting the counter.

Operator context

Lockout policy is a balance between slowing brute-force attempts and preventing self-inflicted outages. Your job is to apply a predictable policy, validate it from the CLI, and capture the state before you reset counters.

Objective

  • Display system-wide faillock values and confirm what is active.
  • Apply an explicit deny, fail interval, and unlock time in /etc/security/faillock.conf .
  • Inspect failure records for appuser and capture evidence.
  • Reset the failure counter only after validation.
  • Re-check user state to confirm failures are cleared.

Concepts

  • Lockout primitives: deny , fail_interval , unlock_time .
  • Active policy validation using faillock --system before changing defaults.
  • Per-user failure inspection with faillock --user to distinguish typos from suspicious activity.
  • Reset workflow: capture state, validate intent, reset counter, confirm cleared.

Walkthrough

Step 1 : Check system-wide faillock policy values.
Command 
sudo faillock --system

This displays the active values that control lockout behavior: how many failures trigger lockout, the time window used to count failures, and how long the lock remains in place. 

# Example output (varies by distro/config):
deny = 0
fail_interval = 900
unlock_time = 600
Step 2 : Set an explicit baseline policy in /etc/security/faillock.conf .
Command 
sudo nano /etc/security/faillock.conf
# OR
sudo vim /etc/security/faillock.conf

Define a clear deny threshold and unlock time so behavior is consistent during credential stuffing or brute-force. Keep the policy strict enough to slow attacks, but short enough to avoid prolonged user lockouts during normal mistakes. 

# Example policy values:
deny = 5
fail_interval = 900
unlock_time = 900
Step 3 : Inspect failure records for appuser.
Command 
sudo faillock --user appuser

Use this view to confirm the failures are real and to gather evidence (timestamps and source address where available). Capture this state before you reset anything. 

# Example output (varies by system):
appuser:
    When                Type  Source             Valid
    2025-01-01 10:15:32 R    192.168.10.50      V
    2025-01-01 10:16:05 R    192.168.10.50      V
    2025-01-01 10:16:40 R    192.168.10.50      V
Step 4 : Reset the failure counter for appuser.
Safety note

Resetting counters removes evidence. Do this only after you confirm the source is benign, or after incident response has collected what it needs.

Command 
sudo faillock --user appuser --reset

This clears the recorded failures for the user so they can authenticate normally again. In production, pair this with documentation: who requested it, why it was safe, and what evidence was captured first. 

# Expected outcome:
# The user’s faillock record is cleared.
Step 5 : Confirm failures are cleared and not still accumulating.
Command 
sudo faillock --user appuser

If failures immediately reappear, something is still attempting to authenticate with bad credentials (a service, script, or an attacker). That is a containment problem, not a reset problem. 

# Example output:
appuser:
    No login failures.

Common breakpoints

faillock --system does not show the expected values

Confirm you edited the correct file at /etc/security/faillock.conf and that your system is actually using faillock for PAM. Some environments manage auth policy centrally or via a baseline tool.

faillock --user shows failures after a reset

Something is still failing authentication. Identify the source address and correlate it with known services. Do not keep resetting counters while an active source continues to generate failures.

You lock out a real user during testing

Validate policy in a controlled window and document the numbers you applied. If the environment is sensitive, start with a short unlock time while you confirm behavior and adjust once you have confidence.

Failures are missing timestamps or source addresses

Availability of source metadata depends on the auth path and logging configuration. Treat the faillock record as one data point and correlate with system logs in a real incident.

Cleanup checklist

If you changed policy values for this lab, revert them to your baseline once testing is complete. If you reset a user’s counter, confirm the failures are not reappearing and that the lockout policy is still enforcing as intended.

Commands 
sudo faillock --system
sudo faillock --user appuser
Success signal

System policy reflects your intended deny, interval, and unlock values, and the appuser record remains clear unless new failures occur.

Reference

  • faillock --system : Displays current system-wide lockout policy values.
    • Values include deny , fail_interval , and unlock_time .
  • nano /etc/security/faillock.conf : Edit the primary configuration file for faillock defaults.
    • /etc/security/faillock.conf : Defines baseline policy values.
  • vim /etc/security/faillock.conf : Edit the primary configuration file for faillock defaults.
    • /etc/security/faillock.conf : Defines baseline policy values.
  • faillock --user <user> : Shows recorded failures for a specific user.
  • faillock --user <user> --reset : Resets failure records for a user after validation.