Server Monitoring and Log Analysis: Catching Attacks Early

What to actually monitor

A Linux server generates useful security evidence in five main places: authentication logs, web server logs, resource usage metrics, the list of open network ports, and the integrity of critical system files. Each answers a different question, and skipping any one of them leaves a blind spot that the others cannot cover.

According to NIST Special Publication 800-92 (Guide to Computer Security Log Management), log management should be treated as an ongoing operational process covering log generation, transmission, storage, analysis, and disposal, not a one-time setup task. The guide's core point is that logs only have value when there is a defined process for reviewing them and acting on what is found; a server generating gigabytes of untouched log files is not meaningfully more secure than one generating none.

Authentication logs

Authentication logs record every login attempt, successful or failed, and are usually the first place evidence of an attack appears. On Debian and Ubuntu systems this is /var/log/auth.log; on RHEL, CentOS, and similar distributions it is /var/log/secure.

What matters is not just failed logins but patterns in them. A handful of failed SSH attempts from a residential IP is routine internet background noise; five or more failed attempts from the same source within a short window is a signal worth acting on. A practical detection approach is to track failed login attempts per source IP over a rolling time window, for example flagging five failures in ten minutes, which is a threshold commonly used in brute-force detection write-ups because it separates typing mistakes from automated attack tools. Tools like fail2ban watch these logs directly and automatically add firewall rules to block offending IPs once a threshold is crossed, turning passive log data into an active defense. Our fail2ban setup guide covers configuring this from scratch, including jail tuning so you block real attackers without locking out legitimate users on shared or dynamic IPs.

Beyond brute force, watch specifically for: successful logins at unusual hours for that account, logins to accounts that should never be used interactively (service accounts), and any use of sudo or su that doesn't match your team's normal admin activity. These are lower-volume but higher-signal events than raw failure counts.

Web server logs

Web server access and error logs record every request your public-facing services receive, and reviewing them for abnormal request patterns, error spikes, and known attack signatures is how you catch web-layer attacks that never touch SSH at all. This is a separate data source from authentication logs and covers a completely different attack surface.

Look for repeated requests to paths that don't exist on your site (a sign of automated vulnerability scanning), sudden spikes in 4xx or 5xx status codes, unusually large numbers of requests from a single IP or user agent, and requests containing obvious injection patterns in the query string. Adding $request_time to your nginx log format, alongside the standard fields, helps because it shows how long each request took to process, and a flood of individually cheap-but-numerous requests can be a resource-exhaustion attempt even when no single request looks malicious. Our nginx security best practices guide covers configuring a security-oriented log format and rate limiting these endpoints directly at the web server layer.

A log analyzer such as GoAccess can turn raw access logs into a real-time dashboard, which makes anomalies far easier to spot visually than scrolling through raw text, especially when combined with a GeoIP database to see which countries traffic and attack attempts are actually coming from.

Resource usage

Tracking CPU, memory, disk, and network usage over time establishes a baseline for what "normal" looks like on your server, so that deviations, a sudden CPU spike at 3am, disk filling up unexpectedly, unusual outbound bandwidth, stand out as investigation triggers rather than being invisible.

Resource anomalies matter for security because several attack types show up here before they show up anywhere else: cryptomining malware drives sustained CPU usage, a compromised server being used to send spam or participate in a DDoS botnet drives unusual outbound network traffic, and a log injection or disk-fill attack shows up as rapidly growing disk usage. Basic tools like top, htop, vmstat, and iftop are enough to check manually; for ongoing monitoring, even a simple scheduled script that records these metrics and alerts on thresholds catches most of what matters without needing a full monitoring platform.

The key practice is comparing against your own server's baseline, not a generic threshold. A database server legitimately running at 70% CPU during business hours is normal; the same load on a server that's usually idle at that hour is worth a look.

Listening ports and network connections

Checking which ports are actually listening for connections, and confirming each one belongs to a service you intentionally run, catches misconfigurations and backdoors that log review alone can miss, because a listening port doesn't necessarily generate log entries until something connects to it.

Run ss -tulpn (or netstat -tulpn on older systems) periodically and compare the output against what you expect to be running. A new listening port you didn't open, especially on a high or unusual port number, is one of the more reliable indicators of a compromised server, since attackers frequently install a backdoor listener for persistent remote access. This check takes under a minute and catches a category of compromise that authentication and web logs won't show at all.

Pair this with a review of active outbound connections, not just listening ports: a compromised server reaching out to an unfamiliar external IP on a regular interval is a classic sign of command-and-control communication, and it will not appear in your authentication or web server logs at all.

File integrity monitoring

File integrity monitoring (FIM) builds a baseline record of hashes, permissions, and timestamps for critical system files, then alerts when something changes outside of an expected update, catching modified binaries, added backdoors, and unauthorized configuration changes that never show up in an application log at all.

AIDE (Advanced Intrusion Detection Environment) is the standard open-source FIM tool for Linux, functioning as a free alternative to the older commercial Tripwire product. It works by scanning specified paths, typically /etc, /bin, /sbin, /usr/bin, and other system binary and configuration directories, and comparing current file attributes against the stored baseline database on each run:

# Initialize the baseline (once, on a known-clean system)
aideinit

# Run a check against the baseline
aide --check --config=/etc/aide/aide.conf

Schedule this as a regular cron job or systemd timer so checks run automatically, and route the output somewhere you'll actually see it, since a FIM report nobody reads provides the same value as no monitoring at all. When you intentionally update system packages, regenerate the baseline afterward so routine patching doesn't generate constant false alarms; the balance between catching real changes and drowning in expected ones is the main ongoing maintenance task with FIM tools.

Separating signal from noise

The single biggest reason server monitoring fails in practice is alert fatigue: when every minor event generates a notification, real incidents get lost in a stream of routine noise and eventually get ignored altogether. Effective monitoring means being deliberate about what actually warrants an alert versus what belongs in a periodic summary.

A practical approach is to separate events into three tiers. First, immediate alerts for rare, high-confidence indicators: a new listening port, a new SSH key added to authorized_keys, a root login from an unfamiliar location, a FIM alert on a core system binary. Second, a daily or weekly digest for elevated-but-common events: aggregate failed login counts, unusual but not extreme traffic patterns, disk usage trending upward. Third, raw log retention with no active alerting for routine, expected volume, kept for investigation after the fact rather than reviewed continuously.

Tune thresholds against your own server's actual traffic pattern rather than a generic number pulled from a blog post, since what counts as anomalous varies enormously between, say, a low-traffic internal tool and a public e-commerce site. Revisit the thresholds periodically too: a server's normal traffic pattern shifts as the business grows, and a threshold that made sense six months ago may now be either too noisy or too lax.

Centralized and correlated log analysis

Centralizing logs from multiple sources into one searchable location, and correlating events across those sources, catches attack patterns that no single log file reveals on its own; this is the core idea behind SIEM (Security Information and Event Management) thinking, even for organizations too small to run a full SIEM platform.

The distinction matters in practice. Basic log management centralizes and stores log data, which is a real improvement over logs scattered across individual servers with short local retention, but it is largely passive: you still have to know to search for something. A SIEM system adds real-time correlation and rule-based alerting across combined sources, so it can connect a pattern like "failed SSH logins from IP X, followed twenty minutes later by a new outbound connection from that same server" into a single flagged incident, where each individual log line, viewed in isolation, might not look urgent enough to investigate. According to industry guidance on SIEM for small and mid-sized businesses, a full SIEM deployment often requires dedicated staff and can be a heavier operational burden than a smaller organization can sustain, while a log management solution enhanced with basic SIEM-style correlation features can deliver much of the practical benefit without that overhead.

For most small businesses, the realistic path is not "buy a SIEM" but "make sure logs from every server, and every service on those servers, land in one place where correlation and alerting can actually happen," whether that's a lightweight self-hosted stack or a managed monitoring service. The alternative, logs sitting locally on each server with no cross-referencing, means an attacker who gets a foothold on one system and pivots to another leaves a trail that exists but that nobody is positioned to connect together in time to matter.

If monitoring reveals that an incident has already happened rather than one that's still unfolding, the response process matters as much as the detection did; see our server breach incident response guide for what to do once you've confirmed a compromise. And if you're building monitoring as one piece of a broader hardening effort, the VPS security checklist covers where log analysis fits alongside firewall rules, SSH hardening, and patching.

If you are deciding how far to go with log collection, read do you need a SIEM on a small VPS; the reference pages for journalctl, rsyslog and auditd cover the tools.