DEV Community: Atena

I Added ML Anamoly Detection to My Cybersecurity Tool - Here's What the Numbers Actually Showed

Atena — Sat, 15 Aug 2026 19:25:45 +0000

A few weeks ago, I built Log Sentinel, a log analysis dashboard that detects brute force attacks, directory scanning, and error spikes in Apache server logs using rule-based detectors. The rules worked well, but I kept wondering: what would a machine learning model catch that my rules missed? And more importantly, would ML actually be better?

I spent two weeks adding an Isolation Forest model to find out. The results were more interesting than I expected.

What I built

The ML upgrade adds a second detection layer on top of the existing rule-based system. Instead of checking specific conditions like "did this IP make 10+ failed logins?", the Isolation Forest learns what normal traffic looks like from the data itself and flags anything statistically unusual.

Before the model can run, I transform each IP address into a 5-feature behavioural vector:

request_count — total requests made
error_rate — fraction of requests returning 4xx or 5xx errors
unique_paths — how many different URLs they visited
night_traffic_ratio — fraction of requests made between midnight and 6 am
avg_bytes — average response size

All five features get normalized to mean=0, std=1 using StandardScaler. Without normalization, an IP with 1000 requests would dominate an IP with 10 requests purely because of scale.

The model is configured with contamination=0.15; I tuned this by testing values from 0.05 to 0.50 and picking the one with the best F1 score on a labelled evaluation dataset.

The evaluation setup

To measure performance properly, I generated a labelled dataset of 230 IPs: 200 normal and 30 attackers (10 brute force, 10 directory scanners, 10 error spikers). Each IP has a ground truth label so I can compute precision, recall, and F1 for both detectors.

Printing accuracy on training data proves nothing. You need labelled ground truth to know if your model actually works.

The results

Metric Rule-Based Isolation Forest
Precision 1.0000 0.8571
Recall 1.0000 1.0000
F1 Score 1.0000 0.9231
False Positives 0 5
False Negatives 0 0

The rule-based detectors achieved perfect scores. The Isolation Forest caught every single attacker (recall=1.0) but flagged 5 innocent IPs along the way (precision=0.857).

What this actually means

My first instinct was to be disappointed that ML didn't win. But the more I thought about it, the more interesting the result became.

The rule-based detectors achieved perfect scores because the evaluation dataset contains well-defined, structured attack patterns, exactly the patterns the rules were written to catch. Of course they're perfect: I designed both the rules and the data.

The Isolation Forest's false positives tell a different story. It flagged 5 normal IPs that happened to have slightly unusual behaviour; maybe they made a burst of requests, or visited an uncommon path. The model found something statistically interesting about them even though they weren't attackers.

In a real production environment, this is actually the more valuable behaviour. Rules only catch what you anticipated. ML catches things you didn't think to write rules for.

The real insight is that both detectors belong in the same system. Rules handle known attack signatures with zero false alarms. ML handles the unknown. My dashboard now runs both and shows you exactly where they agree and where they disagree, which is where the interesting cases live.

What I'd do differently

The biggest limitation of my evaluation is that I generated the labelled dataset myself. Real attack patterns are messier and more diverse than synthetic data. A more honest evaluation would use real labelled log data from a production environment.

I'd also experiment with other unsupervised algorithms; Local Outlier Factor and One-Class SVM are worth comparing against Isolation Forest on the same dataset.

The live dashboard

Both detectors run on every analysis. The dashboard has three views: rule-based results, ML results, and a comparison showing which IPs were caught by both, rules only, or ML only. There's also a Model Performance section showing the confusion matrices and F1 scores side by side.

Live demo: atenahfr.github.io/log-sentinel/frontend/index.html

Source code: github.com/atenahfr/log-sentinel

How I Built a Log Analysis Tool to Detect Network Anomalies

Atena — Mon, 13 Jul 2026 22:47:52 +0000

When I started this project, I wanted to build something that actually does something, not another todo app or weather widget. I'm a third-year CS student at TMU, and I wanted a portfolio project that would make a security engineer say, "Oh, that's interesting."

The result is Log Sentinel, a log analysis dashboard that parses Apache server logs, detects suspicious patterns, scores threats by risk level, and explains every detection in plain English.

Here's how I built it:

The problem with most log analysis tools
Most tools tell you what was flagged. They show you a table of IPs and error codes. But they don't tell you why it's suspicious or what to do about it.

I wanted Log Sentinel to be different. Every flagged event generates a plain-English explanation like:
"This IP made 40 failed login attempts on /login. Normal users fail 1-2 times at most. This volume strongly suggests an automated brute force attack."

This makes the tool readable by non-technical stakeholders, not just security engineers.

The detection logic
I built four rule-based anomaly detectors using Python and pandas:

Brute force detection: if the same IP makes more than 10 failed login attempts (HTTP 401 on /login), it gets flagged. Real brute force attacks look exactly like this: hundreds of automated requests hitting the same endpoint.

Directory scanning: attackers use automated tools to probe servers for hidden files like /.env, /admin, /config.php. Each probe returns a 404. I flag any IP generating more than 10 404 errors.

Server error spikes: repeated 500 errors from the same IP often mean someone is sending malformed requests, possibly attempting injection attacks. I flag IPs causing more than 5 server errors.

Off-hours traffic: legitimate users are rarely active at 3 am. Any traffic between midnight and 6 am gets flagged as inherently suspicious, regardless of volume.

Each detector returns a pandas DataFrame with the flagged IP, the count that triggered it, and an auto-generated explanation built from the actual numbers.

*The risk scoring system *
Different attack types carry different weights. I assigned base scores based on severity:

Brute force: 80 points
Server error spike: 60 points
Directory scanning: 40 points
Off-hours traffic: 30 points

If one IP triggers multiple detectors, the scores stack. An IP doing brute force during off-hours gets 110 points, automatically labelled Critical. This makes the dashboard immediately scannable: biggest threats at the top, explained in plain English.

The technical stack
The backend is Python and Flask. pandas handles all the log parsing and aggregation; groupie operations make it easy to count events per IP, calculate hourly averages, and flag statistical outliers.

The frontend is a single HTML file with a terminal aesthetic, matrix rain animation, monospace font, and green-on-black colour scheme. I built the timeline chart from scratch using HTML divs instead of Chart.js, which gave me more control over the animations and styling.

The whole thing is deployed on Render (backend) and GitHub Pages (frontend), with a /api/demo endpoint that generates sample attack data so anyone can see it working instantly without uploading a file.

What I'd build next
The rule-based detectors work well, but they have fixed thresholds. The next evolution would be replacing them with scikit-learn's Isolation Forest, an unsupervised anomaly detection algorithm that learns what "normal" traffic looks like and flags statistical outliers automatically.

I'd also add an SQLite database to store analysis history, so you can track whether the same IP appears across multiple sessions.

Try it yourself
The live demo is at atenahfr.github.io/log-sentinel/frontend/index.html - click Load Demo and the full threat report appears instantly.

The full source code is on GitHub.