Understanding Failed Login Attempts with lastb
and Securing Your Server
As a system administrator or hobbyist running a Linux server, keeping an eye on security is critical—especially if your machine is exposed to the internet. One powerful tool for spotting potential threats is the lastb
command, which reveals failed login attempts. In this post, we’ll dissect a specific command—sudo lastb -a | head -10 2>/dev/null || echo "No failed login data available"
—and use its output to highlight security risks and actionable steps to harden your server.
What Does the Command Do?
Let’s break it down:
-
sudo lastb -a
:-
lastb
lists failed login attempts stored in/var/log/btmp
, a binary log file tracking bad login tries (typically via SSH or local authentication). - The
-a
flag appends the source IP or hostname to each entry, making it easier to track attack origins. -
sudo
is required because reading/var/log/btmp
needs elevated privileges.
-
-
| head -10
:- Pipes the output to
head -10
, limiting it to the 10 most recent failed attempts. Without this, you might get flooded with entries on a busy server.
- Pipes the output to
-
2>/dev/null
:- Redirects any error messages (e.g., if
/var/log/btmp
is empty or inaccessible) to/dev/null
, silencing them.
- Redirects any error messages (e.g., if
-
|| echo "No failed login data available"
:- If the command fails (e.g., no data exists or permissions are insufficient), this fallback prints a friendly message instead of leaving you with silence.
Here’s a sample output from March 27, 2025:
nobody ssh:notty Thu Mar 27 19:40 - 19:40 (00:00) 67.180.137.28
root ssh:notty Thu Mar 27 19:24 - 19:24 (00:00) 105.73.190.106
pi ssh:notty Thu Mar 27 18:38 - 18:38 (00:00) 2.51.27.140
pi ssh:notty Thu Mar 27 18:38 - 18:38 (00:00) 2.51.27.140
guest ssh:notty Thu Mar 27 18:22 - 18:22 (00:00) 23.121.67.63
guest ssh:notty Thu Mar 27 18:22 - 18:22 (00:00) 23.121.67.63
nobody ssh:notty Thu Mar 27 17:50 - 17:50 (00:00) 65.20.247.231
test1 ssh:notty Thu Mar 27 17:34 - 17:34 (00:00) 65.20.205.147
test1 ssh:notty Thu Mar 27 17:34 - 17:34 (00:00) 65.20.205.147
unknown ssh:notty Thu Mar 27 17:18 - 17:18 (00:00) 61.3.24.190
Each line shows a failed attempt with:
-
Username: Common targets like
root
,pi
, orguest
. -
Connection Type:
ssh:notty
indicates a non-interactive SSH session—typical in automated attacks where bots probe credentials without opening a shell. - Timestamp: Clustered attempts (e.g., 17:18–19:40) suggest automation.
-
Source IP: Geographically diverse IPs (e.g.,
67.180.137.28
(US) or105.73.190.106
(Africa)) hint at a botnet.
Security Risks
These failed attempts signal real threats:
- Brute-Force Attacks: Automated scripts trying common username/password combinations.
- System Takeover: A successful breach could lead to malware installation or data theft.
-
Resource Abuse: Mass attempts may slow your server or fill logs (
/var/log/btmp
).
How to Secure Your Server
1. Disable Root Login via SSH
Edit /etc/ssh/sshd_config
:
PermitRootLogin no
Restart SSH: sudo systemctl restart sshd
.
Why? Forcing attackers to guess both a username and password raises the bar.
2. Enforce SSH Keys (Disable Passwords)
- Generate a key pair on your local machine:
ssh-keygen -t ed25519 -a 100 # Stronger than RSA
- Copy the public key to the server:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server
- Disable password logins in
/etc/ssh/sshd_config
:PasswordAuthentication no ChallengeResponseAuthentication no
- Restart SSH:
sudo systemctl restart sshd
.
3. Install and Configure Fail2Ban
- Install:
sudo apt install fail2ban
- Customize
/etc/fail2ban/jail.local
:[sshd] enabled = true maxretry = 3 # Ban after 3 failures bantime = 1d # Ban for 1 day ignoreip = 192.168.1.0/24 # Whitelist your LAN
- Restart:
sudo systemctl restart fail2ban
. - Verify:
sudo fail2ban-client status sshd
.
4. Change the SSH Port (Optional)
Edit /etc/ssh/sshd_config
:
Port 2222 # Replace 22 with a non-standard port
Update firewall rules (ufw
):
sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp
Note: This is not a standalone fix—combine it with Fail2Ban and SSH keys.
5. Manage Logs and Rotate btmp
Prevent /var/log/btmp
from growing unchecked:
- Edit
/etc/logrotate.conf
:/var/log/btmp { missingok monthly rotate 3 compress maxsize 10M }
- Test:
sudo logrotate -vf /etc/logrotate.conf
.
6. Investigate and Block Suspicious IPs
- Check IP reputation:
whois 61.3.24.190 | grep -i "country\|netname\|descr" curl -s "https://abuseipdb.com/check/61.3.24.190" | grep -A5 "ISP\|Usage"
- Block manually in
/etc/hosts.deny
:sshd: 61.3.24.190
- For bulk blocking, use
ipset
or CrowdSec.
Final Thoughts
The command sudo lastb -a | head -10
is a quick security health check. If you see repeated failed logins:
- Act immediately: Disable weak authentication methods.
- Layer defenses: Combine SSH keys, Fail2Ban, and firewalls.
-
Monitor: Schedule regular log reviews (
sudo lastb -a
) or use tools likelogwatch
.
Stay proactive, and happy securing! 🔒