
How to Monitor System Authentication Logs on Ubuntu
System authentication logs are your server’s digital security diary, recording every login attempt, authentication failure, and user session activity. Understanding how to monitor these logs on Ubuntu is crucial for maintaining server security, detecting unauthorized access attempts, and troubleshooting user authentication issues. This guide will walk you through the essential tools and techniques for monitoring authentication logs on Ubuntu, from basic log inspection to advanced automated monitoring solutions.
Understanding Ubuntu Authentication Logs
Ubuntu uses several log files to track authentication activities, each serving different purposes and containing specific types of information. The primary authentication logs are stored in the /var/log/
directory and are managed by rsyslog or systemd-journald depending on your system configuration.
The main authentication logs include:
- /var/log/auth.log – Contains most authentication-related messages including SSH logins, sudo commands, and PAM authentication
- /var/log/secure – Alternative location on some systems for security-related messages
- /var/log/btmp – Binary log of failed login attempts
- /var/log/wtmp – Binary log of successful logins and system events
- /var/log/lastlog – Shows last login time for each user
These logs capture different authentication events using the Pluggable Authentication Modules (PAM) framework and various system services. Understanding the structure and content of these logs helps you identify security patterns and potential threats.
Essential Commands for Log Monitoring
Let’s start with the basic commands every sysadmin should know for monitoring authentication logs. These commands provide immediate insights into your system’s authentication activity.
To view recent authentication events in real-time:
sudo tail -f /var/log/auth.log
For examining failed login attempts:
sudo grep "Failed password" /var/log/auth.log
To check successful SSH logins:
sudo grep "Accepted" /var/log/auth.log
The last
command provides a user-friendly view of recent logins:
last -10
For failed login attempts, use lastb
:
sudo lastb -10
To see the last login time for all users:
lastlog
These basic commands form the foundation of authentication log monitoring, but they’re just the beginning. For production environments, you’ll need more sophisticated monitoring approaches.
Advanced Log Analysis Techniques
Moving beyond basic commands, advanced log analysis involves parsing log patterns, filtering specific events, and extracting meaningful security intelligence from raw log data.
Create a comprehensive authentication summary script:
#!/bin/bash
# auth_summary.sh - Generate authentication activity summary
echo "=== Authentication Summary for $(date) ==="
echo
echo "Recent Successful Logins:"
grep "Accepted" /var/log/auth.log | tail -5
echo -e "\nFailed Login Attempts (last 10):"
grep "Failed password" /var/log/auth.log | tail -10
echo -e "\nTop 5 Failed Login IPs:"
grep "Failed password" /var/log/auth.log | \
grep -oP 'from \K[0-9.]+' | sort | uniq -c | sort -nr | head -5
echo -e "\nSudo Commands (last 5):"
grep "sudo:" /var/log/auth.log | tail -5
echo -e "\nSSH Key Authentication:"
grep "Accepted publickey" /var/log/auth.log | tail -5
For analyzing authentication patterns by time periods:
# Today's authentication events
grep "$(date '+%b %d')" /var/log/auth.log
# Events from specific hour
grep "$(date '+%b %d %H')" /var/log/auth.log
# Weekend authentication activity (potentially suspicious)
grep -E "(Sat|Sun)" /var/log/auth.log
Using awk for more complex log parsing:
# Extract failed login attempts with timestamp and IP
awk '/Failed password/ {print $1, $2, $3, $11}' /var/log/auth.log
# Count authentication events by hour
awk '{print $3}' /var/log/auth.log | cut -d: -f1 | sort | uniq -c
Setting Up Automated Monitoring
Manual log checking isn’t scalable for production environments. Automated monitoring systems can detect suspicious patterns and alert you to potential security incidents in real-time.
Create a fail2ban-style monitoring script:
#!/bin/bash
# monitor_auth.sh - Basic authentication monitoring script
LOGFILE="/var/log/auth.log"
ALERT_THRESHOLD=10
TEMP_FILE="/tmp/auth_monitor.tmp"
# Count failed attempts in last hour
FAILED_COUNT=$(grep "Failed password" $LOGFILE | \
grep "$(date '+%b %d %H')" | wc -l)
if [ $FAILED_COUNT -gt $ALERT_THRESHOLD ]; then
echo "ALERT: $FAILED_COUNT failed login attempts in the last hour" | \
mail -s "Authentication Alert" admin@yourdomain.com
# Log the alert
echo "$(date): Alert sent for $FAILED_COUNT failed attempts" >> \
/var/log/auth_monitor.log
fi
# Check for new user additions
if grep -q "new user" $LOGFILE; then
NEW_USERS=$(grep "new user" $LOGFILE | tail -5)
echo "New user accounts detected: $NEW_USERS" | \
mail -s "New User Alert" admin@yourdomain.com
fi
Set up this script to run every 15 minutes via cron:
*/15 * * * * /usr/local/bin/monitor_auth.sh
For more sophisticated monitoring, consider using journalctl with systemd:
# Monitor authentication events in real-time
journalctl -u ssh -f
# Show authentication events from last hour
journalctl --since "1 hour ago" | grep -i auth
# Filter by specific service
journalctl _SYSTEMD_UNIT=ssh.service --since today
Log Rotation and Management
Authentication logs can grow large quickly, especially on busy servers. Proper log rotation and management ensures you maintain historical data without consuming excessive disk space.
Ubuntu uses logrotate to manage log files. Check the current authentication log rotation configuration:
cat /etc/logrotate.d/rsyslog
Customize log retention for authentication logs:
# /etc/logrotate.d/auth-custom
/var/log/auth.log {
daily
rotate 90
compress
delaycompress
missingok
notifempty
create 640 syslog adm
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
For high-traffic servers, consider hourly rotation:
/var/log/auth.log {
hourly
rotate 168 # 7 days worth of hourly logs
compress
delaycompress
missingok
notifempty
create 640 syslog adm
}
Integration with Security Tools
Modern security monitoring often involves integrating authentication logs with dedicated security tools and SIEM systems. Here are several approaches for different infrastructure needs.
Install and configure fail2ban for automated IP blocking:
sudo apt update
sudo apt install fail2ban
# Create custom jail configuration
sudo nano /etc/fail2ban/jail.local
Basic fail2ban configuration for SSH protection:
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 7200
For centralized logging, configure rsyslog to forward authentication events:
# /etc/rsyslog.d/50-auth-forward.conf
# Forward authentication logs to central server
auth,authpriv.* @@logserver.yourdomain.com:514
Using auditd for enhanced authentication monitoring:
sudo apt install auditd audispd-plugins
# Add authentication monitoring rules
sudo nano /etc/audit/rules.d/auth.rules
Sample auditd rules for authentication monitoring:
# Monitor authentication events
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/group -p wa -k group_changes
-w /etc/sudoers -p wa -k sudoers_changes
# Monitor login/logout events
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillock -p wa -k logins
Performance and Storage Considerations
Authentication log monitoring can impact system performance and storage, especially on high-traffic servers. Understanding these impacts helps you design efficient monitoring solutions.
Server Type | Daily Log Size | Recommended Retention | Monitoring Frequency |
---|---|---|---|
Development Server | 10-50 MB | 30 days | Hourly |
Production Web Server | 100-500 MB | 90 days | Every 15 minutes |
High-Traffic Server | 1-5 GB | 30 days (compressed) | Real-time |
SSH Bastion Host | 500 MB – 2 GB | 180 days | Real-time |
For VPS environments with limited storage, implement compressed log archiving:
# Compress old logs daily
find /var/log -name "auth.log.*" -mtime +1 -exec gzip {} \;
# Archive logs older than 30 days to remote storage
find /var/log -name "auth.log.*.gz" -mtime +30 -exec \
rsync {} backup@storage.example.com:/logs/archive/ \; -delete
Real-World Use Cases and Examples
Let’s examine practical scenarios where authentication log monitoring provides critical security insights and operational intelligence.
Scenario 1: Brute Force Attack Detection
A typical brute force attack pattern appears in logs as repeated failed login attempts from the same IP address:
Mar 15 14:23:45 server sshd[12345]: Failed password for root from 192.168.1.100 port 22 ssh2
Mar 15 14:23:47 server sshd[12346]: Failed password for admin from 192.168.1.100 port 22 ssh2
Mar 15 14:23:49 server sshd[12347]: Failed password for user from 192.168.1.100 port 22 ssh2
Detection script for this pattern:
#!/bin/bash
# detect_brute_force.sh
THRESHOLD=20
TIME_WINDOW=300 # 5 minutes
# Find IPs with excessive failed attempts
grep "Failed password" /var/log/auth.log | \
awk -v threshold=$THRESHOLD -v window=$TIME_WINDOW '
{
ip = $11
timestamp = $1 " " $2 " " $3
attempts[ip]++
if (attempts[ip] >= threshold) {
print "BRUTE FORCE DETECTED: " ip " (" attempts[ip] " attempts)"
}
}'
Scenario 2: Unusual Login Hours
Detecting logins during off-hours can indicate compromised accounts:
# Check for logins between 11 PM and 6 AM
grep "Accepted" /var/log/auth.log | \
awk '$3 ~ /^(23|0[0-5]):/ {print "Off-hours login:", $0}'
Scenario 3: Privilege Escalation Monitoring
Monitor sudo usage patterns to detect potential privilege abuse:
# Track unusual sudo patterns
grep "sudo:" /var/log/auth.log | \
awk '{user = $5; cmd = substr($0, index($0, "COMMAND=")); count[user]++}
END {for (u in count) if (count[u] > 50) print u ": " count[u] " sudo commands"}'
Best Practices and Common Pitfalls
Effective authentication log monitoring requires following established best practices while avoiding common implementation mistakes that can compromise security or system performance.
Security Best Practices:
- Always protect log files with appropriate permissions (640 or 644)
- Implement log integrity checking using tools like AIDE or Tripwire
- Forward logs to a centralized, secured logging server
- Regularly rotate and archive logs to prevent disk space issues
- Use encrypted connections for remote log transmission
- Implement access controls for log viewing and analysis
Performance Optimization:
# Use efficient grep patterns
grep -E "(Failed|Accepted)" /var/log/auth.log # Better than multiple greps
# Limit search scope with date ranges
sed -n '/Mar 15 14:00/,/Mar 15 15:00/p' /var/log/auth.log
# Use awk for complex parsing instead of multiple piped commands
awk '/Failed password/ && /Mar 15/ {print $11}' /var/log/auth.log | sort | uniq -c
Common Pitfalls to Avoid:
- Not monitoring log file growth – can fill disk space unexpectedly
- Relying solely on auth.log – some events may appear in other logs
- Ignoring timezone considerations in multi-server environments
- Over-alerting on false positives, leading to alert fatigue
- Not testing log rotation configurations before production deployment
- Forgetting to monitor binary logs (wtmp, btmp, lastlog)
Advanced Monitoring Solutions
For enterprise environments or dedicated servers requiring comprehensive security monitoring, consider implementing advanced solutions that provide real-time analysis and threat intelligence.
ELK Stack (Elasticsearch, Logstash, Kibana) integration for authentication logs:
# Logstash configuration for auth logs
input {
file {
path => "/var/log/auth.log"
start_position => "beginning"
type => "auth"
}
}
filter {
if [type] == "auth" {
grok {
match => {
"message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} %{WORD:service}(?:\[%{POSINT:pid}\])?: %{GREEDYDATA:message}"
}
}
if "Failed password" in [message] {
grok {
match => {
"message" => "Failed password for %{WORD:username} from %{IP:source_ip}"
}
add_tag => ["failed_auth"]
}
}
}
}
output {
elasticsearch {
hosts => ["localhost:9200"]
index => "auth-logs-%{+YYYY.MM.dd}"
}
}
Custom Python monitoring script for real-time analysis:
#!/usr/bin/env python3
import re
import time
import smtplib
from collections import defaultdict, deque
from email.mime.text import MIMEText
class AuthMonitor:
def __init__(self, log_file="/var/log/auth.log"):
self.log_file = log_file
self.failed_attempts = defaultdict(deque)
self.alert_threshold = 10
self.time_window = 300 # 5 minutes
def parse_log_line(self, line):
failed_pattern = r'Failed password for \w+ from (\d+\.\d+\.\d+\.\d+)'
match = re.search(failed_pattern, line)
if match:
return match.group(1)
return None
def check_brute_force(self, ip):
current_time = time.time()
attempts = self.failed_attempts[ip]
# Remove old attempts outside time window
while attempts and attempts[0] < current_time - self.time_window:
attempts.popleft()
return len(attempts) >= self.alert_threshold
def send_alert(self, ip, attempt_count):
msg = MIMEText(f"Brute force attack detected from {ip} ({attempt_count} attempts)")
msg['Subject'] = 'Security Alert: Brute Force Attack'
msg['From'] = 'monitor@yourserver.com'
msg['To'] = 'admin@yourserver.com'
# Send email (configure SMTP settings)
# smtp_server.send_message(msg)
print(f"ALERT: Brute force from {ip} ({attempt_count} attempts)")
def monitor(self):
with open(self.log_file, 'r') as f:
f.seek(0, 2) # Go to end of file
while True:
line = f.readline()
if line:
ip = self.parse_log_line(line)
if ip:
self.failed_attempts[ip].append(time.time())
if self.check_brute_force(ip):
self.send_alert(ip, len(self.failed_attempts[ip]))
else:
time.sleep(1)
if __name__ == "__main__":
monitor = AuthMonitor()
monitor.monitor()
For comprehensive security monitoring, integrate with threat intelligence feeds and implement correlation rules that can detect sophisticated attack patterns across multiple log sources. Tools like OSSEC, Wazuh, or commercial SIEM solutions provide enterprise-grade authentication monitoring capabilities.
The key to effective authentication log monitoring lies in balancing security requirements with system performance, implementing appropriate alerting thresholds, and maintaining consistent monitoring practices across your infrastructure. Regular review and tuning of your monitoring rules ensures they remain effective against evolving threats while minimizing false positives.
For additional information on Ubuntu logging systems, consult the official Ubuntu documentation on log files and the rsyslog documentation for advanced configuration options.

This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.
This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.