Today I took a big step in diving into how Linux systems manage and store logs, and how those logs can tell us a story about what’s happening on a server. At first, logs felt like just endless lines of confusing text, but once you break them down, they become powerful tools for system monitoring, troubleshooting, and even security investigations.

The Basics of Log Rotation

Linux stores logs for different applications and services inside /var/log. This process is handled by a tool called logrotate in Ubuntu. Over time, these logs can get huge, so the system automatically rotates them:

The current log stays as app.log.
Once it’s rotated, it becomes app.log.1, then app.log.2.gz, app.log.3.gz, etc.
The .gz files are compressed versions of older logs to save space.

This way, the system doesn’t get clogged up with endless giant log files, but you still keep history to review later.

Key Services That Log Information

1. Apache2 (Web Server)

Apache logs everything about how your web server runs and how people interact with it.

access.log → Every request made to the server. Includes IP addresses, what files users accessed, and the status code (e.g., 200 OK, 404 Not Found). This is extremely useful for spotting suspicious activity or just seeing what’s popular on your site.
error.log → Records errors, warnings, or even important notices. Despite the name, it doesn’t only store failures. It can also log info messages like Apache configured -- resuming normal operations. Basically, it’s about the server’s state of health.

Example from my practice:

A line in error.log wasn’t an actual error, just Apache announcing it started successfully.
Access logs can reveal details like which IP visited (10.9.232.111) and what file was accessed (catsanddogs.jpg).

2. UFW (Uncomplicated Firewall)

UFW is a user-friendly firewall tool in Ubuntu. It manages traffic rules, usually built on top of iptables.

Logs (ufw.log, ufw.log.1, etc.) show traffic that was allowed or denied.
This is where you’d see if someone’s repeatedly trying to connect to closed ports — useful for spotting brute force or intrusion attempts.
Unlike stateless firewalls, UFW is stateful, meaning it remembers the state of a connection (e.g., a reply to an accepted request won’t be blocked).

3. Fail2Ban

Fail2Ban is like your server’s security guard. It watches logs (especially authentication attempts) and automatically bans IPs that look suspicious — for example, too many failed login attempts.

Its logs (fail2ban.log) show when bans happen, what triggered them, and which IPs were blocked.
It’s one of the tools that help mitigate brute force attacks (when attackers try many passwords over and over until one works).

Firewall Layers and OSI Model

When I first learned about firewalls, it was in the context of the OSI model (network layers). Here’s the distinction I made:

Network firewalls → Operate at lower layers (packet-level, like IP filtering). Example: classic iptables rules like:

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

This allows incoming connections on port 22 (SSH).
Application firewalls (like WAFs) → Work at higher layers, inspecting HTTP requests, blocking SQL injections, cross-site scripting, etc. This is why firewalls can look very different — some block packets, while others analyze entire web requests.
UFW makes managing network firewall rules easier (stateful, user-friendly).

What I Learned About Apache Logs

Not everything in error.log is bad. Some entries are just notices or informational messages.
Access logs are gold for forensics. You can see IPs, requested files, response codes, and even detect potential intrusions.
Log analysis is part detective work, part diagnostics. Sometimes an error means a user mistyped their login; other times, it means your disk is literally full (no space left on device — which is critical!).

Why This Matters for Cybersecurity

Being able to read these logs isn’t just system admin work; it’s core cybersecurity practice:

Detecting brute force attempts (Fail2Ban + UFW logs).
Spotting suspicious requests or files accessed (Apache access logs).
Identifying server health issues before they become outages (Apache error logs).

At first glance, it’s overwhelming — but once you recognize patterns, you feel like a detective reading the “diary” of your system.

Final Thought

Today I realized: knowing commands is one part, but understanding the story logs are telling you is the real magic. Apache logs, UFW, and Fail2Ban together form a trio that not only keeps the system alive but also secure. Every log entry, no matter how small, could be the clue that reveals what’s really happening under the hood.

Understanding Apache Logs, UFW, and Fail2Ban in Ubuntu