BLOG POSTS
How to Monitor System Authentication Logs on Ubuntu

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.

Leave a reply

Your email address will not be published. Required fields are marked