In this lesson, you will learn how to harden system service accounts by disabling interactive shell access and implementing proper account locking to minimize your attack surface.
Why Non-Interactive Accounts Matter
Service accounts are user accounts created specifically for background processes, such as a web server (www-data) or a database engine (mysql). Because these processes do not require a human to log in, these accounts should never be used to access a command-line interface. If an attacker manages to compromise a service, having an active shell allows them to navigate your system, escalate privileges, or download malicious payloads.
Preventing Shell Access
To prevent an account from being used interactively, you must ensure its shell is set to a non-functional entry in the /etc/passwd file. Instead of pointing to /bin/bash or /bin/sh, set the shell to /usr/sbin/nologin or /bin/false.
When an attacker (or a misconfigured script) tries to log in as a service user, /usr/sbin/nologin will politely reject the connection and display a message, while /bin/false will simply terminate the session immediately.
You can modify an existing account’s shell using the usermod command:
# Set the shell to nologin to block interactive access
sudo usermod -s /usr/sbin/nologin service_user_name
Enforcing Account Locking
In addition to restricting the shell, you should ensure the account password is permanently locked. Since service accounts shouldn't accept login passwords, you can "lock" the password hash in the /etc/shadow file. This prevents any authentication attempts from succeeding, even if a user knows the password or tries to bypass the shell restriction.
Use the passwd utility to lock the account:
# Lock the account password
sudo passwd -l service_user_name
This command prepends a ! to the encrypted password string in /etc/shadow, effectively invalidating it. By combining a restricted shell with a locked password, you ensure that the account is functionally isolated, serving only the specific daemon it was designed for, rather than becoming a potential entry point for unauthorized access.
Key Takeaway: Always assign /usr/sbin/nologin as the shell and lock the password for service accounts to ensure they cannot be used for interactive system access.