Bots rarely announce themselves. They scrape product pages, hammer login forms, probe for exposed admin panels, and quietly test whether your rate limit is real. For a security team of two or three people, the hard part isn't caring about this. It's seeing it without standing up an enterprise platform and hiring someone to run it.

The tools below are all open source, all reasonably well maintained, and all capable of running on hardware you already have. None of them is a complete answer on its own. Together, they cover the three jobs that matter: reading logs, noticing when something deviates from normal, and telling a human.

Start With Signals, Not Tools

Every tool here reads from roughly the same small set of sources. If those sources aren't in place, no dashboard will save you. Before installing anything, confirm you can answer these questions:

• Where do request logs live, and how long are they kept? (nginx, Apache, HAProxy, a CDN, a cloud load balancer)
• Do you have per-IP request rates over time, or only raw access logs?
• Are authentication failures logged separately from general traffic?
• Is there anything on the network side — firewall logs, DNS queries, TLS fingerprints?

A single afternoon spent standardizing timestamps and switching to a JSON log format pays off for years. Tools disagree about format, and a consistent log shape makes every one of them easier to feed.

Six Open-Source Tools That Earn Their Place

CrowdSec

CrowdSec reads your logs, applies scenarios — behavioral rules like "many 404s from one IP" or "repeated SSH auth failures" — and decides whether an actor deserves blocking. Its distinguishing feature is the community blocklist: signals from other deployments can protect yours, which is genuinely useful when you don't have the telemetry to spot a distributed botnet yourself. Remediation happens through "bouncers," small components that talk to your firewall, nginx, or cloud edge. Start in detection-only mode, review the decisions for a week, then turn on enforcement.

Fail2ban

The classic. Fail2ban tails log files, matches regex filters, counts failures inside a time window, and triggers an action — an nftables drop, a Cloudflare API call, an email. It isn't clever, and that's the appeal. When a bot floods /wp-login.php or SSH, a well-written jail handles it in seconds. The real work is writing filters that don't catch legitimate users. Test each filter against a real log excerpt with fail2ban-regex before you ship it, and set a generous findtime before you set an aggressive maxretry.

GoAccess

GoAccess turns an access log into a live report, either in a terminal or a browser tab. For bot work it's less about blocking and more about understanding: which user agents dominate, which paths get hammered, which countries and networks the traffic comes from, and how requests distribute across the hour. Keep it running for triage. When something looks off, it answers "is this a bot or just a busy day?" in about ten seconds.

Wazuh

Wazuh is the heaviest option here and the closest thing to a full SIEM. Agents collect logs, file integrity events, and process data from your hosts; a manager evaluates them against decoders and rules and can trigger active responses. It ships with alerting integrations for email, chat, and ticketing, and maps many rules to known adversary techniques. If you need anomaly detection beyond simple thresholds — unexpected file changes, new listening ports, odd credential activity — the setup cost is worth it for a small team.

Zeek

Zeek sits on a network tap or span port and writes structured logs about what it observes: connections, HTTP requests, DNS lookups, TLS handshakes. Bots that never touch your web server — port scanners, command-and-control beacons, credential stuffing aimed at another host — show up here. Its scripting language lets you write small detections, and the notice framework turns them into alerts. Expect a learning curve, and pair it with a log pipeline so its output has somewhere useful to land.

Grafana Loki with Grafana Alerting

Loki indexes labels rather than full text, which keeps it cheap enough to run on modest hardware. Ship nginx, application, and auth logs in with Promtail or Grafana Alloy, then query with LogQL. The value for bot monitoring is correlation: alert on a spike in 401 responses, then pivot to see which user agents and paths produced it. Alert rules route through contact points — email, webhook, chat — and Alertmanager handles grouping and silencing, so one bot wave produces one notification instead of four hundred.

Keeping Alerts Useful Instead of Noisy

Alert fatigue takes down small teams faster than any botnet. A few rules of thumb:

1. Alert on rates and ratios, not single events. "More than 50 failed logins from one IP in five minutes" beats "failed login."
2. Measure before you set a threshold. If normal traffic is three requests per second, don't alert at four.
3. Route by severity: informational findings to a dashboard, actionable ones to a phone.
4. Review every alert weekly during the first month. If it never caught anything real, tune it or delete it.

Write the alert text for the person who will read it half-awake. Include the IP, the target, the count, and one sentence on what to check next.

Where to Start This Week

Pick one log source and one tool. For most teams that means Fail2ban or CrowdSec on the public-facing host, because results appear the same day. Run it in detection mode first, watch what it wants to block, then enforce. Add GoAccess for visibility, and Wazuh if you have a spare machine and want host-level anomaly detection. Bring in Zeek and Loki once you have more than a couple of hosts and a real need to correlate across them.

Then document what you deployed. A short note in your runbook — which tool reads which log, what it blocks, and how to switch it off — matters more than a clever rule, because the person debugging at 2 a.m. is often not the person who installed it.

Photo: Markus Spiske / Pexels