Do You Need a SIEM on a Small VPS? Wazuh vs journald

Do you need a SIEM on a small VPS?

Usually not. If you run one to five servers and nobody is assigned to read alerts every day, a SIEM adds more work than protection. What you do need from the SIEM idea is cheap: logs that survive a reboot, a copy of them somewhere an intruder cannot reach, and a handful of alerts for events that really matter.

The decision comes down to two questions. First, do you have enough hosts that an event on one needs to be linked to an event on another? Second, will someone open the console, tune the rules and respond to what it shows? If both answers are yes, a SIEM is worth evaluating. If either is no, start with the lightweight setup below, which is also the data foundation any SIEM needs later. For what to look for inside the logs, see our server monitoring and log analysis guide. This article is only about the tooling decision.

What a SIEM is and what it does

SIEM stands for Security Information and Event Management. The NIST glossary, citing SP 800-92, defines it as "A program that provides centralized logging capabilities for a variety of log types." A second NIST entry, from SP 800-128, describes a SIEM tool as an application that gathers security data from system components and presents it as actionable information through a single interface. People also search for it as "SIEM system", "SIEM server" or the common misspelling "SEIM". A "SIEM server" is simply the central machine that receives the data, not a separate kind of product.

In practice a SIEM does five jobs: it collects logs from agents or syslog, stores them centrally, applies detection rules, correlates events across sources and raises alerts you can act on. NIST SP 800-92 adds two useful points: there are no standards specific to SIEM, so each product stores data in its own format, and the agent to server traffic in such products is typically encrypted over TCP. See the SIEM glossary entry for a short definition.

When a SIEM is overkill

A SIEM earns its cost through correlation and daily use. These are the situations where that value is missing:

• Few hosts. Correlation links events across systems. With one server there is nothing to link, and with two to five you can often read the same logs in one central place.
• Nobody reads the alerts. A dashboard that no one opens detects nothing. An alert that arrives by email and gets handled is worth more than a platform that sits idle.
• The platform outweighs the workload. The Wazuh quickstart lists 4 vCPU, 8 GiB of RAM and 50 GB of storage for 90 days of data even for 1 to 25 agents. That is likely larger than the small VPS you want to watch.
• Tuning time you do not have. Detection rules need adjusting to your own traffic or they produce noise, and noise gets ignored.
• No compliance driver. If no contract or regulation demands searchable retention and documented alerting, the lightweight route is enough.

A SIEM also does not replace focused tools. fail2ban still blocks the brute force described in our SSH brute force protection guide, and the intrusion prevention layer still acts before logs are read at all.

The lightweight alternative: journald plus off-server logs

The core of the SIEM idea is affordable on any VPS: keep logs that survive, and keep a copy where an intruder cannot reach it. Someone with root on a compromised host can edit or delete local logs, so the off-server copy is what makes the trail trustworthy.

Step 1: make the journal persistent. According to the journald.conf(5) manual, the default for Storage= is fixed when systemd is compiled, and auto writes to disk only if /var/log/journal exists. Setting the value explicitly removes the question. Drop-in files are read from /etc/systemd/journald.conf.d/ and all options live in the [Journal] section:

[Journal]
Storage=persistent
SystemMaxUse=500M

Save this as /etc/systemd/journald.conf.d/persistent.conf and run sudo systemctl restart systemd-journald. The manual says SystemMaxUse= defaults to 10% of the file system, capped at 4G, and accepts suffixes such as M and G, so pick a size that fits your disk. Check the result with the journalctl(1) options below. See the journalctl glossary entry for the basics:

journalctl --list-boots
journalctl --disk-usage
journalctl -u ssh --since yesterday -p warning

The unit is ssh on Debian and Ubuntu and sshd on the RHEL family. -p warning shows that level and everything more important.

Step 2: forward a copy to another machine. The omfwd documentation says plain TCP is often used for reliable delivery, recommends TCP with TLS for modern deployments and warns that plain TCP cannot always tell which messages arrived when a connection breaks. Its guaranteed-delivery option is the RELP protocol through the omrelp module. A TLS forward from the omfwd examples looks like this:

action(
    type="omfwd"
    target="logs.example.com"
    port="6514"
    protocol="tcp"
    StreamDriver="ossl"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.com"
)

The receiver needs a matching TLS setup. The rsyslog TLS tutorial uses anonymous authentication only as a quick start and says the bundled test certificates are not for production, so create your own certificate authority and certificates. The receiving host should accept connections only from your servers. Then test the whole path with logger and look for the line on the receiver. The rsyslog glossary entry explains the daemon. Note that journald hands messages to a syslog daemon through ForwardToSyslog=, and per the manual only forwarding to wall is enabled by default, so the logger test is your proof that messages actually arrive.

Simple alerting without a SIEM

Collected logs only help if something tells you when they contain trouble. Three small tools cover the common cases, and none needs a central server.

• fail2ban notifications. The default action in jail.conf only bans. The file also defines action_mwl, which bans, sends mail with a whois report and includes the matching log lines. The default mta is sendmail, so a working mail setup is required. The shipped defaults are maxretry = 5 within findtime = 10m, and the sshd jail is disabled until you enable it. In jail.local:

  [DEFAULT]
  action = %(action_mwl)s
  
  [sshd]
  enabled = true

  Set destemail and sender to your own values in the same file. Our fail2ban setup guide covers tuning.
• Logwatch digests. Its manual calls it a customizable, pluggable log-monitoring system. It supports --detail with levels low, med and high, --range such as Yesterday, --output of stdout, mail or file, and --mailto. A daily summary of what happened is often all a one-server owner reads.
• File integrity checks. File integrity monitoring with AIDE tells you when system binaries or configuration change. Send its report off the server, or an intruder can edit it.

For deeper evidence of who ran what, the Linux audit daemon is the next source to add; see the auditd glossary entry. Keep alerts few and specific, as described in our monitoring guide, so that each one gets read.

When to step up to Wazuh

Wazuh is a free and open source platform that, in its own documentation's words, unifies XDR and SIEM capabilities. So yes, it counts as a SIEM, and it also includes file integrity monitoring, log data analysis, vulnerability detection and configuration assessment. The cost is that you run a small platform of your own.

The architecture page describes four components:

• The agent runs on each monitored endpoint and forwards security data to the server. The agent page states about 35 MB of RAM on average, and that the manager version must be the same or newer than the agent version.
• The server decodes events and matches them against rules.
• The indexer stores the analyzed data.
• The dashboard provides alerting and visualization.

Agents connect to the server on TCP 1514 by default and enroll on TCP 1515, with messages encrypted using AES by default. The server sends data to the indexer on port 9200 and the dashboard queries the server API on TCP 55000. You can place all components on one host (all-in-one), one per host (single-node) or cluster them (multi-node).

For sizing, the quickstart gives the all-in-one requirements: 4 vCPU, 8 GiB RAM and 50 GB for 1 to 25 agents with 90 days of data; 8 vCPU, 8 GiB and 100 GB for 26 to 50; 8 vCPU, 8 GiB and 200 GB for 51 to 100. It lists Ubuntu 16.04 to 24.04, RHEL 7 to 10, Amazon Linux 2 and 2023, and CentOS Stream 10 for the central components. For five servers you would run this on a separate host, not on one of the servers being watched.

Its FIM module runs a baseline scan, then alerts on checksum or attribute mismatches. Per the Wazuh documentation, scans run every 12 hours (43200 seconds) by default, and real-time monitoring is enabled per directory:

<syscheck>
  <directories realtime="yes">/etc</directories>
</syscheck>

Step up when you have several servers whose events need linking, a person who will own the rules, or a requirement for searchable retention. Otherwise stay light.

Log retention and tamper resistance

Retention. CISA's joint advisory AA22-131A recommends that all organizations store their most important logs for at least six months, noting that it can be months before incidents are detected. It also recommends a segregated logging regime. NIST SP 800-92 leaves exact periods to your own policy and legal requirements. Treat six months of important logs (authentication, sudo, web server, firewall) as a sizing target and keep the archive in your 3-2-1 backup plan.

Tamper resistance. Layer the protections:

• Off-server copy. This is the main control. The original syslog standard has no features to protect confidentiality or integrity, as SP 800-92 notes, so use TLS or RELP and a locked-down receiver.
• Journal sealing. journalctl --setup-keys generates a Forward Secure Sealing key pair. The sealing key stays on the host and the verification key should be stored externally. journalctl --verify --verify-key=KEY then checks authenticity. Sealing aims at detecting alteration and does not give you a second copy.
• Checksums for archives. SP 800-92 describes storing a message digest of archived log files securely so later changes are detected.
• Separate credentials. The log receiver should not share admin keys with the servers it collects from.

When something goes wrong, these copies are your evidence. See the server breach incident response guide and the incident response entry, and for the related backup principle, the ransomware protection guide.

Decision list: which setup fits you

• One or two servers, you read the logs yourself: persistent journal, an off-server copy, fail2ban with notifications and a scheduled AIDE check. No SIEM.
• Three to five servers, one admin: the same, plus a central log host that holds the forwarded logs and a daily Logwatch digest. Trial Wazuh on a spare machine only if you want its rules and dashboard.
• Several servers and one person who owns detection: Wazuh on its own host is a reasonable choice. Budget for the sizing above, the time to tune rules and agent upgrades.
• A contract or regulation requires searchable retention and documented alerting: a SIEM, self-run or managed, because you must show the evidence.
• No one has time to read alerts: do not buy more tooling. Compare running it yourself with having someone else do it in our managed security vs DIY guide.

The VPS security checklist shows where logging sits next to firewall, SSH and patching work, which usually matters more than any platform.

A rollout path in six steps

1. Make the journal persistent and confirm with journalctl --list-boots after the next reboot.
2. Forward logs off the server with TLS, then prove delivery with logger and a search on the receiver.
3. Add alerts: fail2ban notifications, a Logwatch digest and a scheduled integrity check whose report leaves the server.
4. Set a retention target of six months for important logs, and size the receiver's disk for it.
5. Trial Wazuh on a throwaway host with one or two agents, using the quickstart. Check that the alerts it produces are ones you would act on.
6. Decide with the list above. If you keep Wazuh, open only the ports the architecture page lists to the hosts that need them.

Not sure what your servers expose today? A read-only audit shows the current state without changing anything.