dcid (Daniel)

If you use a SIM or logging server, having the proper loggingg in there showing who is accessing it covers that PCI requirement.

Three layers and you want all three.

At the source, rate limit. rsyslog has $SystemLogRateLimitInterval, most agents can cap per file.

In the pipeline, deduplicate. Identical messages in the same minute collapse to one with a count. That is the one that saves you in exactly your situation.

At the platform, alert on volume rather than only on content. A source that triples its rate is worth knowing about whether or not the messages are interesting. Almost nobody does this and it is the cheapest of the three.

Without knowing the exact request shape yet, the generally useful things to grep for on any WordPress pre-auth issue:

POST to anything under /wp-json/ from addresses that have never done a normal GET
Requests to xmlrpc.php that are not the usual pingback noise
Any 200 on a path ending .php inside wp-content/uploads
New files in uploads with a php extension, if you have file integrity monitoring

The last one is the highest signal by a distance. Nothing legitimate writes a php file into uploads.

It is on every intrusion checklist as roughly step one after getting privilege, because it removes the record of how they got in.

Sometimes it really is an admin being tidy. That is a training conversation rather than a shrug, and it is worth finding out which before deciding.

Short version is you have to notice when your logging stops.

10.7.2 lists the controls whose failure must be detected and the audit logging mechanism is one of them. So if a server stops sending logs, something has to raise it.

This is genuinely hard because a source going quiet produces no event anywhere. There is no log line that says nothing is happening. Everything looks calm and the one system you cannot see is the one you should worry about.

What they want is a mechanism comparing expected sources against actual, an alert when the gap appears, and evidence you acted on it when it fired. That last part is the one people forget.

Hardest alert to build, most valuable one to have.

The shape is a scheduled check that asks a question rather than a rule that reacts to an event. Did we see at least one matching event in the last N hours, if not, alert.

The trap is that it fires on the first bank holiday and everyone learns to ignore it. Give the window generous margin, and monitor the check itself, because a silence detector that silently dies is worse than not having one.

Same pattern covers a host that stopped sending logs entirely, which is the version that actually saves you.

Drop them, but count them first.

That logid with type="traffic" subtype="forward" action="close" is a session ending normally. Nobody has ever investigated an incident by reading one. The value is entirely in aggregate: which networks your users reach, how much moved, when that changed.

So do not store the lines, do keep counters for destination country, service, bytes.

One thing worth checking while you are in there. Are you logging denies at all? A lot of FortiGates are set up to log accepts and not blocks, which is exactly backwards. Blocked traffic is the interesting half and a fraction of the volume.

Sysmon for Linux over Tetragon is interesting, most people go the other way. Was it purely setup time or did you hit something specific?

Biased, obviously, since I wrote the first one.

OSSEC is smaller and does less. If you want file integrity monitoring and log analysis on a set of servers and nothing else, it still does that and you can read the whole thing in an afternoon.

Wazuh is OSSEC plus a lot: dashboard, agent management, compliance mapping, an Elasticsearch stack underneath. If you want those, take them, that is what it is for.

Honest version is that most people asking this want Wazuh and are checking they are not missing something.