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.

• 2>/dev/null:

  • Redirects any error messages (e.g., if /var/log/btmp is empty or inaccessible) to /dev/null, silencing them.

• || 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, or guest.
• 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) or 105.73.190.106 (Africa)) hint at a botnet.

Security Risks

These failed attempts signal real threats:

1. Brute-Force Attacks: Automated scripts trying common username/password combinations.
2. System Takeover: A successful breach could lead to malware installation or data theft.
3. 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:

1. Act immediately: Disable weak authentication methods.
2. Layer defenses: Combine SSH keys, Fail2Ban, and firewalls.
3. Monitor: Schedule regular log reviews (sudo lastb -a) or use tools like logwatch.

Stay proactive, and happy securing! 🔒