Reading ModSecurity Attacks in Safety Monitor Pro

Every WHM server with ModSecurity enabled produces a stream of web-attack events — SQL injection attempts, path traversal, scanner probes, brute-force login floods. Raw, that stream lives in the ModSecurity audit log and is nearly unreadable at scale. The Intrusion Monitor in Safety Monitor Pro exists to make it legible: it reads the log your server already writes and turns it into a live, per-domain view of what's hitting you and how hard.

What the Intrusion Monitor reads

The monitor is a reader, not a new sensor. It parses the ModSecurity audit log that cPanel/Apache already generates. It does not install a second web-application firewall and it does not inject itself into your request path — it consumes the events ModSecurity has already recorded and correlates them.

Parsing is bounded and incremental. The monitor tracks its position in the log and reads forward from where it left off, so it does not re-scan a large audit log from scratch on every load. That's what keeps it light even on a busy server with a lot of traffic.

Per-domain breakdown

Instead of one undifferentiated firehose, the monitor groups events by the domain that was targeted. For each domain you can see:

• The volume of attack events over recent time windows.
• The source IPs generating them, ranked by how noisy they are.
• The kind of activity — injection attempts, traversal, scanners, login abuse — classified from the ModSecurity rule data.

This matters because a single compromised or targeted site often looks very different from background internet noise. Seeing it per domain lets you tell "one site is under a focused attack" apart from "the whole internet is knocking politely and being blocked."

Repeat-offender and brute-force detection

The monitor doesn't just list events — it recognises patterns across them:

• Repeat offenders. IPs that generate attack events again and again are surfaced and ranked, so the handful of addresses actually worth acting on rise to the top instead of drowning in one-off probes.
• Brute-force behaviour. Bursts of authentication failures or high-frequency hammering from a single source are flagged as brute-force patterns rather than treated as unrelated single events.

The goal is signal, not volume. A thousand log lines might reduce to three IPs that deserve a decision from you.

How to act: allow or deny via CSF

When you decide an IP should be blocked — or that a flagged address is actually legitimate and should be allowed — Safety Monitor Pro acts through CSF, the firewall your server already runs. It does not maintain a parallel, hidden block list of its own:

• Deny adds the offending IP to CSF's deny rules, so the firewall drops it going forward.
• Allow adds a trusted IP to CSF's allow list — useful when a monitoring service, office IP, or your own address was caught by a rule.

Because the change lands in CSF, it's visible and reversible with the standard CSF tooling you already know. For the full picture of how the plugin and the firewall cooperate, read CSF, LFD & Safety Monitor: How They Work Together.

What it does NOT do

This is the important part. The Intrusion Monitor is read-only by default and never takes destructive action on its own:

• It does not auto-ban IPs behind your back. Deny/allow are actions you confirm.
• It does not kill processes, restart services, or suspend accounts in response to an attack.
• It does not rewrite your ModSecurity rules or your web server config.
• It does not send your logs off the server — parsing happens locally, and nothing about the attack data leaves the box.

The design principle is deliberate: surface the threat clearly, recommend an action, and let the administrator make the call. You get visibility without the risk of an automated system blocking a legitimate customer or taking down a service at 3 a.m.

Want this running on your server? Get Safety Monitor Pro, or see the technical documentation for how the Intrusion Monitor fits the wider architecture.