The Ultimate Guide to Understanding UFW Logs

In the realm of Linux system security, firewalls serve as the first line of defense against network threats. The Uncomplicated Firewall (UFW) stands out as a user-friendly interface to the powerful but complex iptables firewall system. While setting up UFW might be straightforward, understanding its logs requires deeper knowledge. These logs contain valuable information about connection attempts, potential threats, and overall network activity on your system.

System administrators, security professionals, and Linux enthusiasts who monitor their systems actively know that firewall logs provide critical insights into security incidents and network issues. By learning to read and analyze UFW logs effectively, you can identify suspicious activities, troubleshoot connectivity problems, and strengthen your system’s security posture.

This comprehensive guide will walk you through everything you need to know about UFW logs—from basic concepts to advanced analysis techniques—helping you transform raw log data into actionable security intelligence.

Understanding UFW Fundamentals

The Uncomplicated Firewall, as its name suggests, simplifies the process of configuring a firewall on Linux systems. Developed primarily for Ubuntu, UFW now features in numerous Linux distributions as a default security component. It functions as a frontend to iptables, abstracting the complex syntax into easy-to-use commands.

UFW operates by filtering network packets based on predefined rules. When a packet arrives at your system, UFW examines it against these rules in sequence until it finds a match. Depending on the matching rule, UFW either allows or denies the packet. These decisions—and attempts to connect—are recorded in the UFW logs.

The core strength of UFW lies in its simplicity. Instead of writing complex iptables rules like:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

You can use the more intuitive:

sudo ufw allow 22/tcp

This simplicity doesn’t compromise functionality. UFW supports both IPv4 and IPv6, stateful inspection, rate limiting, and detailed logging options—all essential features for a robust firewall solution.

The relationship between rules and logs is direct: each rule can generate log entries when traffic matches its criteria. Understanding this relationship helps when analyzing logs to verify if your firewall rules are working as intended.

The Importance of Firewall Logging

Firewall logging isn’t just an optional feature—it’s a security necessity. Without proper logging, your firewall acts as a silent guardian, providing no visibility into the threats it confronts daily.

Comprehensive logging provides several critical benefits:

• Threat detection: Logs reveal potential intrusion attempts, port scans, and brute force attacks targeting your system.
• Troubleshooting: When applications can’t connect to services, logs help determine if the firewall is blocking legitimate traffic.
• Compliance requirements: Many regulatory frameworks require detailed firewall logs for audit purposes.
• Forensic analysis: In case of a security incident, historical logs provide valuable evidence for investigation.
• Network visibility: Logs offer insights into normal traffic patterns, helping establish baselines for anomaly detection.

Consider firewall logs as your security camera footage—they might seem uneventful most of the time, but become invaluable when an incident occurs. Regular review of these logs transforms your security stance from reactive to proactive.

Enabling and Configuring UFW Logging

Before diving into log analysis, you need to ensure UFW logging is properly configured. By default, UFW includes basic logging, but you might want to adjust the verbosity based on your needs.

First, check if UFW is running and logging is enabled:

sudo ufw status verbose

If UFW isn’t active, enable it with:

sudo ufw enable

UFW offers several logging levels to balance detail against performance:

• off: No logging (not recommended for security-conscious environments)
• low: Logs blocked packets matching default policy and packets matching logged rules
• medium: Adds logging for invalid packets and new connections
• high: Provides more details including packets with rate limiting
• full: Maximum verbosity without rate limiting (caution: can generate massive logs)

To set your logging level, use:

sudo ufw logging medium

For most environments, the medium level provides sufficient information without overwhelming your log files. High or full levels are better suited for temporary troubleshooting rather than continuous use due to their significant disk space requirements.

Keep in mind that extensive logging impacts system performance. On busy servers, consider the tradeoff between log detail and system resources when selecting your logging level.

UFW Log Locations and Storage

Knowing where to find UFW logs is essential for effective monitoring. On most Linux distributions, particularly Ubuntu and Debian-based systems, UFW logs appear in several locations:

• /var/log/ufw.log: The dedicated UFW log file where most entries appear
• /var/log/syslog: Contains UFW entries among other system logs
• /var/log/kern.log: Stores kernel-related messages, including some firewall operations

The logging service rsyslog handles the routing of UFW messages to these files. Its configuration determines how logs are processed, stored, and rotated. The default configuration file is located at /etc/rsyslog.d/20-ufw.conf.

Log rotation prevents log files from consuming excessive disk space. The logrotate utility typically manages this process, compressing and archiving older logs while maintaining recent entries. Check your log rotation configuration at /etc/logrotate.d/ufw.

For environments requiring centralized logging, you can configure rsyslog to forward UFW logs to a remote syslog server:

# In /etc/rsyslog.conf, add:
:msg, contains, "[UFW " @192.168.1.100:514

This sends all UFW log messages to the syslog server at 192.168.1.100 on the standard syslog port 514.

Anatomy of UFW Log Entries

UFW log entries might appear cryptic at first glance, but each component provides valuable information about network events. Let’s break down a typical UFW log entry:

Aug 15 15:20:25 ubuntu-server kernel: [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:e2:52:42:fe:ed:fa:ce:be:ef:08:00 SRC=192.168.1.105 DST=192.168.1.10 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=16108 DF PROTO=TCP SPT=44592 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0

This entry contains several components:

• Date and time: Aug 15 15:20:25 – When the event occurred
• Hostname: ubuntu-server – The system generating the log
• Source: kernel – The log source (kernel-level firewall events)
• Action: [UFW BLOCK] – The firewall blocked this connection attempt
• Interface information:
  • IN=eth0 – Traffic came in through the eth0 interface
  • OUT= – No outgoing interface (blank for blocked incoming packets)
• MAC addresses: Hardware addresses for source and destination
• IP information:
  • SRC=192.168.1.105 – Source IP address
  • DST=192.168.1.10 – Destination IP address
• Packet details:
  • LEN=60 – Packet length in bytes
  • TOS=0x00 – Type of Service flags
  • PREC=0x00 – Precedence value
  • TTL=64 – Time To Live value
  • ID=16108 – Packet identifier
  • DF – Don’t Fragment flag is set
• Protocol information:
  • PROTO=TCP – TCP protocol
  • SPT=44592 – Source port
  • DPT=22 – Destination port (SSH in this case)
  • WINDOW=29200 – TCP window size
  • SYN – TCP SYN flag set (connection initiation)

The flags at the end (like SYN, ACK, FIN, RST) reveal the TCP connection state and are particularly useful for understanding connection patterns and potential attacks. For example:

• SYN alone often indicates connection attempts
• SYN-ACK shows a server responding to a connection request
• FIN indicates graceful connection termination
• RST may indicate abnormal connection termination

When analyzing these entries, pay special attention to blocked traffic attempting to reach sensitive services like SSH (port 22), database servers, or web administration interfaces.

Methods for Accessing and Monitoring UFW Logs

Efficient log analysis begins with proper access methods. Linux provides numerous tools for viewing and monitoring UFW logs, ranging from simple commands to sophisticated analysis frameworks.

Basic Command-Line Tools

For quick checks and real-time monitoring, these standard Linux commands are invaluable:

# View the entire UFW log file
less /var/log/ufw.log

# Monitor UFW logs in real-time
tail -f /var/log/ufw.log

# Filter for blocked connections
grep "UFW BLOCK" /var/log/ufw.log

# Count occurrences of blocked SSH attempts
grep "UFW BLOCK" /var/log/ufw.log | grep "DPT=22" | wc -l

# Extract unique source IPs attempting to connect to SSH
grep "UFW BLOCK" /var/log/ufw.log | grep "DPT=22" | awk '{print $13}' | cut -d= -f2 | sort | uniq -c | sort -nr

To streamline your workflow, create useful aliases in your .bashrc file:

# Add these to your ~/.bashrc
alias ufw-log='less /var/log/ufw.log'
alias ufw-watch='tail -f /var/log/ufw.log'
alias ufw-blocks='grep "UFW BLOCK" /var/log/ufw.log'

Advanced Monitoring Solutions

For professional environments, consider these more sophisticated options:

• Logwatch: Provides daily email summaries of firewall activity
• Fail2ban: Analyzes logs and automatically blocks suspicious IPs
• ELK Stack (Elasticsearch, Logstash, Kibana): Creates powerful visualizations and dashboards for log data
• Graylog: Enterprise-grade log management with alerting capabilities
• OSSEC: Host-based intrusion detection that correlates UFW logs with other security events

For real-time alerting, you can set up a simple script that runs periodically via cron:

#!/bin/bash
# Save as /usr/local/bin/ufw-alert.sh

THRESHOLD=10
IP_COUNT=$(grep "UFW BLOCK" /var/log/ufw.log | grep "DPT=22" | awk '{print $13}' | cut -d= -f2 | sort | uniq -c | sort -nr | awk '$1 > '$THRESHOLD'' | wc -l)

if [ $IP_COUNT -gt 0 ]; then
    echo "WARNING: $IP_COUNT IPs detected making excessive SSH connection attempts" | mail -s "UFW Alert: SSH Brute Force Attempt" admin@example.com
fi

Make the script executable and add it to crontab to run every hour:

chmod +x /usr/local/bin/ufw-alert.sh
(crontab -l ; echo "0 * * * * /usr/local/bin/ufw-alert.sh") | crontab -

Understanding UFW Log Patterns

Effective log analysis requires recognizing common patterns that indicate normal activity versus potential threats. With experience, you’ll develop an intuition for what looks suspicious in your environment.

Normal Traffic Patterns

• Regular connections to web servers (ports 80/443) during business hours
• Authentication attempts to SSH from known IP addresses
• Periodic connections from monitoring systems
• Established connections showing regular data flow

Suspicious Activities

• Port scanning: Sequential connection attempts to multiple ports from a single IP
• Brute force attacks: Repeated failed connection attempts to SSH or database services
• Unusual protocols: Connections using protocols not typically seen on your network
• Unusual hours: Activity during off-hours when legitimate users are offline
• Unusual source locations: Connections from geographic regions where you have no business presence

Here’s an example of a port scan pattern in UFW logs:

[UFW BLOCK] DPT=22 (SSH attempt)
[UFW BLOCK] DPT=80 (Web server)
[UFW BLOCK] DPT=443 (HTTPS)
[UFW BLOCK] DPT=3306 (MySQL)
[UFW BLOCK] DPT=5432 (PostgreSQL)

All from the same source IP within seconds—a classic scan signature.

Establishing a baseline of normal activity is crucial. Monitor your logs during typical operations for a week or two, noting patterns of legitimate traffic. This baseline becomes your reference point for identifying anomalies.

Creating Custom UFW Logging Rules

Standard UFW rules can be enhanced with specific logging directives to provide more granular visibility into particular types of traffic.

The basic syntax for creating logging rules follows this pattern:

sudo ufw allow log <port>/<protocol>
sudo ufw deny log <port>/<protocol>

The log keyword tells UFW to specifically log matches to this rule, even if your global logging level is low.

Some practical examples include:

# Log all SSH traffic (both allowed and blocked)
sudo ufw allow log 22/tcp

# Log all HTTP traffic but apply rate limiting
sudo ufw limit log 80/tcp

# Log denied traffic to a database server
sudo ufw deny log 3306/tcp

# Log traffic from a specific IP address
sudo ufw deny log from 192.168.1.100 to any

You can verify your rules with:

sudo ufw status verbose

Custom logging rules are particularly valuable for sensitive services where you want maximum visibility regardless of your global logging level. This approach gives you detailed information about specific services without the performance impact of full logging for all traffic.

For services experiencing brute force attempts, combine logging with rate limiting:

sudo ufw limit log 22/tcp comment 'Rate limit SSH with enhanced logging'

This limits connection attempts while ensuring all attempts (both successful and rate-limited) are logged.

Troubleshooting Common UFW Logging Issues

Even well-configured systems can experience logging problems. Here are solutions to common UFW logging issues:

Missing or Empty Log Files

If your UFW logs are missing or empty:

1. Verify UFW is active: sudo ufw status
2. Check logging is enabled: sudo ufw logging on
3. Verify rsyslog is running: systemctl status rsyslog
4. Check rsyslog configuration: cat /etc/rsyslog.d/20-ufw.conf
5. Restart services: sudo systemctl restart rsyslog

Excessive Logging

If logs are filling your disk:

1. Reduce logging level: sudo ufw logging low
2. Improve log rotation: Edit /etc/logrotate.d/ufw to rotate more frequently
3. Filter noisy traffic with specific rules instead of logging everything

Incorrect Timestamps

When log timestamps don’t match your system time:

1. Check your system timezone: timedatectl
2. Synchronize with NTP: sudo apt install ntp
3. Set correct timezone: sudo timedatectl set-timezone your_timezone

Duplicate Log Entries

If you see the same events logged multiple times:

1. Check rsyslog configuration for duplicate rules
2. Verify you don’t have UFW logs sent to multiple files
3. Restart rsyslog: sudo systemctl restart rsyslog

Logs Show Blocked Traffic Despite Allow Rules

This common issue occurs when rules are in the wrong order:

1. List all rules with numbers: sudo ufw status numbered
2. Check rule precedence (UFW processes rules in order)
3. Delete problematic rules and recreate them in the correct order:

sudo ufw delete <rule_number>
sudo ufw insert 1 allow from 192.168.1.0/24

Remember that UFW rules are processed in order from top to bottom until a match is found. If a deny rule precedes an allow rule for the same traffic, the deny rule takes precedence.

Best Practices for UFW Log Security

Logs contain sensitive information about your network topology and security settings. Protecting them should be a priority.

Secure Log File Permissions

Restrict access to log files:

sudo chmod 640 /var/log/ufw.log
sudo chown syslog:adm /var/log/ufw.log

Implement Log Integrity Verification

Set up file integrity monitoring:

sudo apt install aide
sudo aideinit

Then configure AIDE to monitor log files for unauthorized changes.

Configure Proper Log Retention

Balance security needs with storage constraints:

1. Configure logrotate for appropriate retention periods
2. Archive important logs to secure storage
3. Compress older logs to save space

Example logrotate configuration (/etc/logrotate.d/ufw):

/var/log/ufw.log {
    rotate 14
    daily
    compress
    delaycompress
    missingok
    notifempty
    create 640 syslog adm
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}

Implement Remote Logging

Send copies of logs to a secure log server:

1. Configure a central syslog server
2. Set up encrypted transmission (TLS/SSL)
3. Implement write-once storage for compliance requirements

This approach ensures logs survive even if the original system is compromised.

Advanced UFW Log Analysis Techniques

Beyond basic monitoring, advanced analysis techniques extract deeper insights from your logs.

Statistical Analysis

Use simple scripts to generate statistical summaries:

# Top 10 sources of blocked traffic
grep "UFW BLOCK" /var/log/ufw.log | awk '{print $13}' | cut -d= -f2 | sort | uniq -c | sort -nr | head -10

# Distribution of connection attempts by port
grep "UFW BLOCK" /var/log/ufw.log | grep "DPT=" | awk '{print $17}' | cut -d= -f2 | sort | uniq -c | sort -nr | head -10

Trend Analysis

Track changes over time to identify emerging threats:

# Connection attempts by hour
grep "UFW BLOCK" /var/log/ufw.log | awk '{print $1,$2,$3}' | uniq -c

Visualization

Transform raw logs into visual insights:

1. Export log data to CSV format
2. Import into visualization tools like Grafana or Kibana
3. Create dashboards showing traffic patterns, blocked attempts, and geographic distributions

For simple visualization, use command-line tools:

# Create a text-based histogram of SSH attempts by hour
grep "UFW BLOCK" /var/log/ufw.log | grep "DPT=22" | awk '{print $3}' | sort | uniq -c | sort -k2n | awk '{printf("%s %s ", $2, $1); for(i=0;i<$1/10;i++) printf "#"; print ""}'

Machine Learning for Anomaly Detection

For environments with significant traffic, consider machine learning approaches:

1. Collect baseline data during normal operations
2. Train models to recognize normal patterns
3. Set up alerts for deviations from normal patterns

Several open-source tools support this approach, including:

• OSSEC’s statistical analysis features
• ELK Stack’s machine learning capabilities
• AI-driven security platforms like Darktrace

Real-world Case Studies

Case Study 1: Detecting an SSH Brute Force Attack

A system administrator noticed unusual CPU usage on a server. Checking UFW logs revealed thousands of entries like:

[UFW BLOCK] IN=eth0 SRC=185.22.xx.xx DST=203.0.xx.xx DPT=22 PROTO=TCP
[UFW BLOCK] IN=eth0 SRC=185.22.xx.xx DST=203.0.xx.xx DPT=22 PROTO=TCP

All from the same source IP within minutes.

Solution: The administrator implemented:

1. A rate-limiting rule: sudo ufw limit log 22/tcp
2. Fail2ban configuration to automatically block repeat offenders
3. Moving SSH to a non-standard port with additional authentication

This combination effectively neutralized the attack while maintaining service availability.

Case Study 2: Troubleshooting Application Connectivity

After a system update, a web application stopped working. The developers suspected network issues. UFW logs showed:

[UFW BLOCK] IN=eth0 SRC=10.0.xx.xx DST=10.0.xx.xx DPT=6379 PROTO=TCP

The update had changed the application server’s IP without updating the firewall rules.

Solution: The administrator added the appropriate allow rule:

sudo ufw allow from 10.0.xx.xx to any port 6379 proto tcp

This case demonstrates how UFW logs quickly identify connectivity issues that might otherwise require extensive troubleshooting.

Integrating UFW Logs with Other Security Tools

UFW becomes even more powerful when integrated into a broader security ecosystem.

SIEM Integration

Security Information and Event Management (SIEM) systems correlate data across multiple sources:

1. Configure your SIEM to ingest UFW logs
2. Create correlation rules that match firewall events with other security events
3. Set up alerts for complex patterns that indicate sophisticated attacks

Popular SIEM options include:

• Splunk
• IBM QRadar
• AlienVault OSSIM (open-source)

IDS/IPS Integration

Intrusion Detection and Prevention Systems complement UFW:

1. Use UFW logs to verify IDS alerts
2. Configure OSSEC to analyze UFW logs and respond automatically
3. Feed blocked IPs from UFW into your IPS blacklist

Threat Intelligence Integration

Enhance UFW logs with external threat data:

1. Compare source IPs in UFW logs against threat intelligence feeds
2. Automatically block IPs known for malicious activity
3. Set priority alerts for connections from high-risk sources

Tools like OpenCTI can help manage and operationalize threat intelligence data alongside your firewall logs.