A security-focused guide to lastb — covering failed authentication forensics, brute force scale measurement, credential stuffing pattern identification, and btmp log analysis.
What is lastb?
The lastb command reads from /var/log/btmp — the binary log of all failed login attempts — and displays them in reverse chronological order. Where last shows successful logins, lastb shows every authentication failure: the username that was attempted, the source IP, the terminal type (typically ssh:notty for remote attempts), and the timestamp. This data is essential for quantifying brute force attack volume, identifying targeted accounts, detecting credential stuffing campaigns, and measuring the effectiveness of rate-limiting tools like fail2ban. On a publicly accessible SSH server, the btmp log is almost always large — hundreds to thousands of entries per day is normal.
Syntax
lastb
lastb -n 20
lastb -iF
lastb -a
lastb username
lastb -f /var/log/btmp.1Identical syntax to last: -n N limits entries, -i shows IPs instead of hostnames, -F shows full timestamps, -f reads from an alternative file. lastb requires root privileges — the btmp file is readable only by root to prevent information disclosure about authentication failures to regular users.
Key Options and Flags
| Flag / Parameter | Description | Security Note |
|---|---|---|
-i | Display IP addresses instead of resolving hostnames | Always use -i for security analysis — attacker IPs often lack reverse DNS |
-F | Display full timestamps with year and seconds | Use with -i for complete forensic information per entry |
-n N | Limit to the most recent N entries | — |
username | Filter to show only failed attempts for the specified username | Filter by your admin account names to see if they are being targeted specifically |
-f file | Read from an alternative btmp file (e.g., rotated archives) | — |
Common Use Cases
Count Failed SSH Attempts per Source IP
The most common use case for lastb is quantifying brute force attack volume by source IP. Sorting by IP frequency identifies the most aggressive attack sources — these are candidates for firewall blocking or are already being handled by fail2ban. If the same IP appears thousands of times, it means fail2ban is either not configured or failed to block it.
lastb -i --no-login 2>/dev/null | awk '{print $3}' | sort | uniq -c | sort -rn | head -20Identify Targeted Usernames in Credential Stuffing
Credential stuffing attacks use real username/password combinations leaked from other services. Unlike random brute force, these attacks try specific, realistic usernames. Counting which usernames are most frequently targeted reveals whether attackers are guessing common names, targeting your specific admin accounts, or using leaked credential lists.
lastb -i 2>/dev/null | awk '{print $1}' | sort | uniq -c | sort -rn | head -20Measure fail2ban Effectiveness Before and After Configuration
After deploying or tuning fail2ban, the btmp log provides before/after comparison data. The number of failed attempts per source IP should be at most the fail2ban maxretry value (typically 5-10) for any IP that was successfully banned. If you see thousands of attempts from a single IP, fail2ban is not blocking it — either the jail is misconfigured, the filter does not match your sshd log format, or the ban is not persisting.
# Total failed attempts in btmp
lastb 2>/dev/null | wc -l
# Attempts per IP - if any IP shows > maxretry, fail2ban is not working
lastb -i 2>/dev/null | awk '{print $3}' | sort | uniq -c | sort -rn | head -20Security Relevance: Failed Authentication as Attack Intelligence
Every failed login attempt in btmp is actionable intelligence about your attack surface. The username column reveals what accounts attackers believe exist on your system: large numbers of attempts against admin, ubuntu, pi, test, or root indicate automated credential stuffing from botnets. Attempts against your actual usernames — especially unusual or internal ones — suggest targeted reconnaissance or insider knowledge. The source IP column gives you blocking targets: IPs with dozens of attempts are already being blocked by fail2ban if configured correctly; IPs with thousands are not being blocked and should be added to a permanent firewall deny list. High btmp volume with low success in the last output confirms your authentication controls are holding. High btmp volume combined with any successful login from an unfamiliar IP is a confirmed breach indicator.
- btmp is only readable by root — running lastb as a non-root user will show no output or an error
- A missing or very small btmp on a publicly accessible server is suspicious — it may have been cleared by an attacker
- lastb -i output on a busy server can be extremely large — always pipe to head or use -n to limit output
- IP addresses in btmp are often VPN exit nodes, Tor relays, or compromised hosts — direct attribution to an attacker is rarely possible from IP alone
- Username enumeration: if an attacker sees different error responses for valid vs. invalid usernames, they can use btmp data to verify which accounts exist
Practical Examples
Top 20 attacking IPs by failed attempt count
lastb -i 2>/dev/null | awk 'NF>1 && $3 ~ /^[0-9]/ {print $3}' | sort | uniq -c | sort -rn | head -20Extracts IP addresses from lastb output and ranks them by attack frequency. Any IP with more than your fail2ban maxretry value (typically 5) that has not been banned indicates a fail2ban configuration issue. IPs with thousands of attempts that are not banned should be permanently blocked in iptables or ufw.
Top targeted usernames — reveals credential stuffing or targeted attack
lastb 2>/dev/null | awk 'NF>1 && $1 !~ /^(btmp|begins)/ {print $1}' | sort | uniq -c | sort -rn | head -20Lists the most frequently attempted usernames. A long tail of random names (admin, root, test, ubuntu, pi) indicates automated scanning. Attempts against your specific internal usernames indicate targeted attacks or insider knowledge — treat these as a higher-severity threat.
Total brute force volume in the last 24 hours
lastb -iF 2>/dev/null | awk -v date="$(date +'%b %e')" '$0 ~ date {count++} END {print count " failed attempts in the last 24h"}'Counts total failed attempts for today. This gives a baseline metric: a normal publicly accessible SSH server typically sees 500-2000 failed attempts per day. Sudden spikes to tens of thousands indicate a targeted or DDoS-level brute force campaign directed at your server specifically.
Troubleshooting Common Issues
Problem: lastb shows no output even though SSH login attempts are occurring
Solution: Verify /var/log/btmp exists and is not empty: ls -la /var/log/btmp. If it does not exist, failed logins are not being recorded. On some distributions, btmp must be created manually: touch /var/log/btmp && chmod 600 /var/log/btmp. Also verify the PAM configuration includes pam_faillog or pam_tally2.
Problem: lastb output shows IP addresses as hostnames instead of IPs
Solution: Use lastb -i to force IP display. Without this flag, lastb attempts reverse DNS lookup for each entry, which is slow and unreliable for attacker IPs. Always use -i for security analysis.
Problem: btmp file is enormous and lastb takes minutes to run
Solution: Rotate btmp manually: mv /var/log/btmp /var/log/btmp.1 && touch /var/log/btmp && chmod 600 /var/log/btmp. For analysis of a large file, use lastb -n 1000 to limit output, or use utmpdump /var/log/btmp | tail -1000 for raw analysis. Consider implementing logrotate for btmp.
Summary
The lastb command gives you direct visibility into the volume and nature of authentication attacks against your server. Use it to quantify brute force scale, validate fail2ban effectiveness, and identify targeted credential stuffing. The combination of lastb (failed attempts) and last (successful logins) gives a complete authentication picture: high failed volume with no unknown successful logins means your defenses are holding; any unknown successful login from a high-attempt IP source is a confirmed breach.
- Run
lastb -i | awk '{print $3}' | sort | uniq -c | sort -rn | head -20to instantly quantify attack sources - IPs appearing more than fail2ban’s maxretry setting indicate fail2ban is not banning them — investigate the jail configuration
- Attempts against your actual admin usernames indicate targeted attacks — escalate the threat level and increase monitoring
Related Commands
last for successful login history • fail2ban for SSH brute force prevention • grep auth.log for rapid log triage • journalctl for systemd authentication logs
How Many Brute Force Attempts Hit Your Server Today?
INTRAM deploys and monitors fail2ban, rate limiting, and SSH hardening across all managed servers. We reduce attack surface and block credential stuffing before it becomes a breach.
Harden My SSH Access