I Built a System That Catches Hackers in Real Time
The Problem
It was a regular Tuesday morning at cloud.ng, a rapidly growing cloud storage company powered by Nextcloud. Thousands of users were uploading files, sharing documents, and going about their day.
Then the alerts started firing.
Someone was hammering the server with thousands of requests per second. Not a real user. An attacker. A bot. Something trying to take the platform down. This is called a DDoS attack (Distributed Denial of Service). The goal is simple: flood a server with so much traffic that real users cannot get through.
My job as the DevSecOps engineer?
Build something that catches it before it becomes a problem. Here is exactly how I did it—explained so simply that even if you have never written a line of Python before, you will understand every part.
Live dashboard: http://hngdevops.mooo.com
GitHub: https://github.com/Ada-Mazi/hng-anomaly-detector
What I Built
A daemon a program that runs silently in the background 24/7 that does four things
1.Watches every single HTTP request hitting the server.
2.Learns what normal traffic looks like.
3.Detects when something looks wrong.
4Blocks the attacker automatically and sends me a Slack alert.
No human needed. No button to press. Fully automatic.
The Tech Stack
Python: Easy to read, great for math and data processing.
Nginx: Sits in front of the app and logs every request.
Docker: Packages everything into containers that run anywhere.
iptables: The Linux firewall that actually blocks bad IPs.
Flask: Serves the live monitoring dashboard.
Slack: Sends instant notifications when something happens.
Part 1 — Watching Every Request
The first challenge was reading Nginx logs in real time. Nginx writes one line to a log file for every HTTP request. My detector reads that file continuously, line by line, as new lines appear. This is called tailing a log file.
I configured Nginx to write logs in JSON format, so they are easy to parse:
Every line gives me the IP address, timestamp, and status code. My detector reads this and builds a picture of who is doing what.
Part 2 — The Sliding Window (The Secret Sauce)
I need to know: how many requests did this IP send in the LAST 60 seconds?
The naive approach would be to count requests per minute and reset the counter every 60 seconds. But if an attacker sends 1000 requests in the last 10 seconds of one minute and 1000 in the first 10 seconds of the next, your counter sees two batches of 1000 rather than one burst of 2000.
My solution: a sliding window using a deque.
A deque is a double ended queue. Think of it like a train new passengers board at the back, and old ones exit from the front.
No resets. No boundaries. Just a smooth, always-accurate picture of the last 60 seconds.
Part 3 -The Baseline (Teaching the System Normal)
I cannot hardcode what counts as "too many" requests because normal traffic varies wildly. At 3 AM, 10 requests/min might be high. At 3 PM, 10,000 might be normal.
The system learns. Every second, I record how many requests arrived. I keep a rolling 30-minute window of these counts and calculate:
Mean: The average requests per second.
Standard Deviation: How much the traffic typically varies.
The system automatically adjusted its understanding of normal based on real-world patterns.
Part 4 Catching the Attacker (Z-Score Detection)
I use the baseline to calculate a Z-score:The Z-score tells me: how many standard deviations above normal is this rate?
Z-score 1.0: Slightly above average.
Z-score 3.0: Extremely unusual.
Z-score 4.0+: BANNED.
Part 5 Blocking the Attacker with iptables
Once flagged, the system runs one Linux command:
iptables -I INPUT -s [ATTACKER_IP] j DROP
I INPUT: Inserts the rule at the top.
s: Matches the source IP.
j DROP: Silently discards the packets. The attacker gets nothing back.
The ban uses a backoff schedule:
1st ban: 10 minutes
2nd ban: 30 minutes
3rd ban: 2 hours
4th+ ban: Permanent
Part 6 — The Slack Alerts & Audit Log
Every event sends a Slack message within seconds. Whether it's an IP BANNED, a GLOBAL SPIKE, or an AUTO-UNBAN, I am always in the loop.
Everything is also recorded in a structured Audit Log for forensic analysis:
[2026-04-28T20:12:08Z] BAN ip=34.31.206.191 | condition=zscore=4.0 | rate=3 | baseline=1.0 | duration=600
Part 7 — The Live Dashboard
I built a web dashboard that refreshes every 3 seconds showing:
Global requests per second.
Banned IPs and countdowns.
Top 10 source IPs.
System health (CPU/Memory).
How to Run This Yourself
You need a Linux VPS with at least 2 vCPU and 2GB RAM.
What I Learned
Security is not about walls; it is about awareness. The moment you start measuring and understanding your normal traffic, anomalies become obvious.
This project was built as part of HNG Internship Stage 3. It was the hardest thing I have built so far, and I am proud of every line of it.
GitHub: Ada-Mazi
Dashboard: hngdevops.mooo.com
Top comments (0)