DEV Community: Uchechukwu Enyi

Anomaly Detector

Uchechukwu Enyi — Mon, 27 Apr 2026 14:37:58 +0000

I Built a Tool That Catches Hackers in Real Time — Here's How It Works

Have you ever wondered how websites protect themselves from being flooded with fake traffic? Or how a server "knows" that something suspicious is happening?

I just built a tool that does exactly that — and in this post, I'll explain every part of it in plain English. No security background needed. Let's go.

What Is This Project?

Imagine you run a cloud storage website. Thousands of people visit it every day. Most of them are normal users uploading files, logging in, browsing around.

But one day, someone decides to attack your website. They write a script that sends thousands of requests per second from one IP address, trying to crash your server or sneak past your security. This is called a DDoS attack (Distributed Denial of Service).

My tool sits between the internet and the website, watches every single request coming in, and asks one question:

"Does this look normal — or is something weird happening?"

If something looks weird, it automatically blocks the attacker and sends me a message on Slack.

The Big Picture

Here's the flow in simple terms:

Someone visits the website
        ↓
Nginx (the traffic cop) lets them through and writes a note about it
        ↓
My tool reads those notes in real time
        ↓
It checks: "Is this normal traffic, or a spike?"
        ↓
If it's a spike → Block the IP + Send Slack alert
If it's normal  → Do nothing, keep watching

The "notes" Nginx writes are called access logs — one line per request, saved to a file.

Part 1: Reading the Log File (The Monitor)

Every time someone visits the website, Nginx writes a line to a log file that looks like this:

{"source_ip":"45.33.12.99","timestamp":"2025-04-25T10:32:01","method":"GET","path":"/login","status":200,"response_size":1452}

That's one visitor, at one moment in time.

My tool opens that file and reads it line by line, forever — like someone sitting next to a printer watching pages come out. In Python, this is called "tailing" a file.

with open("/var/log/nginx/hng-access.log") as f:
    f.seek(0, 2)  # Jump to the end (don't replay old history)
    while True:
        line = f.readline()
        if not line:
            time.sleep(0.05)  # No new line yet, wait a tiny bit
            continue
        process(line)  # We got a new request!

Simple, right? It just keeps checking for new lines forever.

Part 2: The Sliding Window (Counting Recent Requests)

Now that we can read each request, we need to answer: "How many requests came in the last 60 seconds?"

A naive approach would be to count all requests in the last minute. But that resets every 60 seconds and loses accuracy.

Instead, I use a sliding window — think of it like a moving spotlight that always shows you exactly the last 60 seconds.

Here's the idea using a real-world analogy:

Imagine a bouncer at a club keeping a paper roll. Every time someone enters, they write the time on the roll. Every few seconds, they tear off the old end (entries older than 60 seconds). The number of entries left = people who arrived in the last 60 seconds.

In Python, I use a deque (double-ended queue) — a list you can add to on the right and remove from the left efficiently:

from collections import deque
import time

window = deque()  # Our "paper roll"

def record_request():
    now = time.time()
    window.append(now)  # Write the time on the roll

    # Tear off old entries (older than 60 seconds)
    cutoff = now - 60
    while window and window[0] < cutoff:
        window.popleft()

    # How many requests in the last 60 seconds?
    rate = len(window) / 60
    return rate  # requests per second

I maintain one of these windows per IP address and one globally (all IPs combined).

Part 3: The Baseline (Learning What "Normal" Looks Like)

Here's the clever part. We can't just say "more than 10 requests per second is an attack" — because maybe your website normally gets 50 requests per second at peak hours, and only 2 at night.

So instead of hardcoding a number, my tool learns what normal looks like over time.

Every second, it records the current traffic rate. It keeps the last 30 minutes of these recordings. Every 60 seconds, it calculates:

Mean — the average traffic rate over the last 30 minutes
Standard deviation — how much the traffic varies

Think of it like a teacher grading on a curve. If the average test score is 70, a score of 95 is unusually high. If everyone scores between 85–95, then 95 is totally normal.

import math

samples = [2.1, 1.9, 2.3, 2.0, 1.8, ...]  # One sample per second, last 30 min

mean   = sum(samples) / len(samples)        # Average rate
stddev = math.sqrt(sum((x - mean)**2 for x in samples) / len(samples))

The tool also tracks traffic per hour separately. So if rush hour is always busier, it compares against rush hour data — not the quiet overnight average.

Part 4: Detecting the Attack (The Z-Score)

Now we have the current rate and we know what "normal" looks like. How do we decide if something is an attack?

I use a z-score — a simple math formula that answers:

"How many standard deviations above normal is this?"

z_score = (current_rate - mean) / stddev

If z_score > 3.0, that means the current rate is so far above normal that there's only a 0.1% chance it's a coincidence. That's our signal to act.

I also have a backup rule: if the rate is more than 5 times the average, it's flagged regardless of the z-score. Whichever rule fires first wins.

Real example:

Normal traffic: mean = 5 req/s, stddev = 1.5
Attacker sending: 50 req/s
Z-score = (50 - 5) / 1.5 = 30 → Way above 3.0 → 🚨 ATTACK DETECTED

There's also a bonus feature: if an IP is sending lots of error responses (like hitting bad login attempts over and over), we tighten the thresholds even further for that IP specifically.

Part 5: Blocking the Attacker (iptables)

Once we've decided an IP is an attacker, we need to stop them immediately.

iptables is a built-in Linux tool that acts like a firewall. You can tell it: "Drop all traffic from this IP address — don't even respond to them."

My tool runs this command in Python:

import subprocess

def ban_ip(ip):
    subprocess.run(["iptables", "-I", "INPUT", "-s", ip, "-j", "DROP"])
    print(f"Blocked: {ip}")

That's it. One command. The attacker's packets are now silently dropped by the operating system — they never even reach the web server.

You can verify it worked with:

sudo iptables -L INPUT -n

You'll see a line like:

DROP  all  --  45.33.12.99  0.0.0.0/0

Part 6: Auto-Unban (Giving Second Chances)

What if we accidentally blocked a real user? Or the attacker stopped and wants to try again?

My tool uses a backoff schedule — bans get longer each time the same IP misbehaves:

Offense	Ban Duration
1st time	10 minutes
2nd time	30 minutes
3rd time	2 hours
4th time	Permanent

Every 30 seconds, the tool checks: "Has anyone's ban expired?" If yes, it removes the iptables rule and sends a Slack notification.

Part 7: Slack Notifications

Every time something happens — a ban, an unban, or a global traffic surge — my tool sends a message to a Slack channel so I know about it immediately.

It looks like this:

🚨 IP BANNED
• IP: 45.33.12.99
• Condition: z-score=18.4
• Current rate: 120.00 req/s
• Baseline mean: 5.20 req/s
• Ban duration: 10 min
• Time: 2025-04-25T14:22:01

This uses Slack's "Incoming Webhooks" feature — you post a JSON message to a special URL, and it appears in your Slack channel.

Part 8: The Live Dashboard

Finally, the whole system has a web dashboard you can open in your browser. It shows:

Current global requests per second
The baseline mean and standard deviation
CPU and memory usage of the server
List of currently banned IPs
Top 10 most active IP addresses

It refreshes automatically every 3 seconds so you always see what's happening live.

Putting It All Together

Here's the whole system in one picture:

                        ┌─────────────────────────┐
Internet requests  ───► │  Nginx (reverse proxy)  │
                        │  writes JSON log lines  │
                        └──────────┬──────────────┘
                                   │ log file
                        ┌──────────▼──────────────┐
                        │     Monitor Thread       │
                        │  tails log line by line  │
                        └──────────┬──────────────┘
                                   │ parsed request
                        ┌──────────▼──────────────┐
                        │    Detector Thread       │
                        │  z-score & rate check    │
                        └──────┬──────────┬────────┘
                               │          │
               ┌───────────────▼─┐    ┌───▼──────────────┐
               │  Blocker        │    │  Notifier         │
               │  iptables DROP  │    │  Slack alert      │
               └────────┬────────┘    └───────────────────┘
                        │
               ┌────────▼────────┐
               │  Unbanner       │
               │  removes rule   │
               │  after timeout  │
               └─────────────────┘

Every component runs in its own thread — meaning they all run simultaneously, like workers in a factory each doing their own job at the same time.

What I Learned

Building this taught me a few things I hadn't truly understood before:

Security is about patterns, not rules. The most powerful part of this system isn't the blocking — it's the baseline that learns what's normal. A hardcoded rule would break on the first unusual-but-legitimate traffic spike.
Simple data structures go a long way. A deque + a timestamp is enough to build a production-grade sliding window. You don't need a database.
Linux tools are powerful. iptables has been in Linux for decades. One shell command blocks an IP at the kernel level — nothing the attacker sends can get through.

Want to Build It Yourself?

The full code is available at: https://github.com/ucheenyi/hng-detector

The README has step-by-step setup instructions starting from a fresh Linux server.

Thanks for reading! If you found this helpful, drop a like or comment — I'd love to hear what you're building.

UC Pocket Ubuntu OS: From 303MB to 80MB with Docker Optimization

Uchechukwu Enyi — Thu, 17 Apr 2025 10:45:00 +0000

Introduction

As developers and DevOps engineers, we constantly seek ways to optimize our environments—reducing image sizes, improving security, and maintaining performance. In this article, I'll walk you through how I transformed a standard 303MB Ubuntu Docker image into a lean 80MB distroless-based container while retaining full functionality (SSH, Apache, and persistent storage).

We'll cover:

✅ Multi-stage builds to eliminate unnecessary dependencies

✅ Distroless optimization for security and size reduction

✅ Persistent storage to retain data across container restarts

✅ DevSecOps benefits (smaller attack surface, faster CI/CD)

✅ How non-Linux users can replace VMs with this pocket Ubuntu

The Problem: Bloated Ubuntu Images

Initially, my Dockerfile used a standard Ubuntu base with SSH and Apache:

Original Dockerfile (303MB)

FROM ubuntu:latest

# Set environment variables
ENV TZ=Africa/Lagos
ENV LANG=en_US.UTF-8

# Install packages
RUN apt-get update && \
    apt-get install -y \
    tzdata \
    locales \
    openssh-server \
    apache2 \
    && rm -rf /var/lib/apt/lists/*

# Configure timezone & locale
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && \
    echo $TZ > /etc/timezone && \
    locale-gen en_US.UTF-8

# Set up SSH
RUN mkdir /var/run/sshd && \
    echo 'root:password' | chpasswd && \
    sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config

# Expose ports
EXPOSE 22 80

# Persistent data volume
RUN mkdir /data

# Keep container running
RUN echo '#!/bin/bash\n\
service ssh start\n\
service apache2 start\n\
tail -f /dev/null' > /entrypoint.sh && \
    chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]

Issues with this approach:

❌ 303MB is too large for a minimal Ubuntu environment

❌ Unnecessary packages increase security risks

❌ No multi-stage optimization

The Solution: Distroless + Multi-Stage Builds

By using multi-stage builds and distroless base images, we reduce bloat while keeping essential functionality.

Optimized Dockerfile (80MB)

# Stage 1: Builder (Full Ubuntu)
FROM ubuntu:22.04 AS builder

# Install only essentials
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    openssh-server \
    apache2 \
    && rm -rf /var/lib/apt/lists/*

# Configure SSH
RUN mkdir /var/run/sshd && \
    echo 'root:password' | chpasswd && \
    sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config

# Stage 2: Distroless Runtime
FROM gcr.io/distroless/base-debian11

# Copy only necessary binaries
COPY --from=builder /usr/sbin/sshd /usr/sbin/
COPY --from=builder /usr/sbin/apache2 /usr/sbin/
COPY --from=builder /bin/bash /bin/

# Copy essential libraries
COPY --from=builder /lib/x86_64-linux-gnu/ /lib/x86_64-linux-gnu/
COPY --from=builder /lib64/ld-linux-x86-64.so.2 /lib64/

# Set up persistent storage
RUN mkdir /data && chmod 777 /data
VOLUME /data

# Entrypoint script
RUN echo '#!/bin/bash\n\
/usr/sbin/sshd -D &\n\
/usr/sbin/apache2 -DFOREGROUND &\n\
tail -f /dev/null' > /entrypoint.sh && \
    chmod +x /entrypoint.sh

EXPOSE 22 80
ENTRYPOINT ["/entrypoint.sh"]

Key Optimizations

✔ Multi-stage build separates build and runtime dependencies

✔ Distroless base removes unnecessary packages (no shell, no bloat)

✔ Only essential binaries copied (SSH, Apache, Bash)

✔ Persistent /data volume for file storage

How to Use UC Pocket Ubuntu

1. First, Run the Container in Detached Mode

docker run -d \
  -p 2222:22 -p 8080:80 \
  -v ~/ubuntu-data:/data \
  --name my-ubuntu \
  ucheenyi/uc-pocket-ubuntu

2. Then, Execute Commands Inside the Running Container

# Get an interactive bash shell
docker exec -it my-ubuntu bash

# Or run single commands
docker exec my-ubuntu ls /data
docker exec my-ubuntu apt-get update

3. Access Services

SSH: ssh root@localhost -p 2222 (password: password)
Apache: Open http://localhost:8080

4. Stop and Remove When Done

docker stop my-ubuntu
docker rm my-ubuntu
# Your data persists in ~/ubuntu-data on host

Why This Matters for DevSecOps & DevOps

🔹 Smaller Attack Surface (No unnecessary packages = fewer CVEs)

🔹 Faster CI/CD Pipelines (Smaller images = quicker deployments)

🔹 Cost-Efficient (Replaces heavy VMs with lightweight containers)

🔹 Cross-Platform (Windows/Mac users get full Ubuntu CLI without VMs)

Final Thoughts

By applying multi-stage builds and distroless optimization, we reduced the image size by 73% while keeping all functionality.

My Dockerhub link for the image:

https://hub.docker.com/r/ucheenyi/uc-pocket-ubuntu

This approach is perfect for:

✅ Developers needing a lightweight Ubuntu environment

✅ DevOps teams optimizing CI/CD pipelines

✅ Security teams minimizing attack surfaces

Implementing GitOps with FluxCD for Kubernetes Applications

Uchechukwu Enyi — Sun, 13 Apr 2025 20:16:50 +0000

This guide provides a clear, standardized process for configuring FluxCD to manage Kubernetes applications using GitOps principles. It automates the deployment of application manifests from a Git repository to a staging namespace, utilizing a streamlined folder structure for simplicity and efficiency. The guide includes practical tests to validate GitOps functionality through an image tag update and pruning via replica adjustments, while preserving local Git integration for robust configuration management.

Prerequisites

Kubernetes Cluster: A running cluster, such as Kind, Minikube, AKS, or EKS.
kubectl: Installed and configured to interact with the cluster.
Flux CLI: Installed (e.g., curl -s https://fluxcd.io/install.sh | bash).
Git: Installed for managing repositories.
GitHub Account: Maintaining two repositories:
- <github-username>/flux-config: Stores Flux configurations.
- <github-username>/app-repo: Contains application manifests.
GitHub Personal Access Token (PAT): Configured with repo scope permissions.
Working Directory: /flux-config.

Step 1: Set Up the Environment

Create Working Directory:

   mkdir -p /flux-config
   cd /flux-config

Initialize Git Repository: Set up a local Git repository for configuration management:

   git init
   git branch -M main

Configure GitHub Credentials: Set environment variables for authentication, replacing <github-username> and <your-token> with your GitHub credentials:

   export GITHUB_USER=<github-username>
   export GITHUB_TOKEN=<your-token>

Verify Cluster Compatibility: Confirm the cluster is ready for Flux:

   flux check --pre

Expect confirmation of kubectl (version 1.26 or higher), cluster connectivity, and Flux CLI readiness.
Resolve issues, such as setting kubeconfig with kubectl config use-context <context>.

Step 2: Create Folder Structure

The folder structure is minimal, including only critical configuration files, with flux-system/ generated during setup.

/flux-config/
├── .git/
├── clusters/
│   ├── staging/
│   │   ├── app-repo.yaml
│   │   └── apps.yaml
├── flux-system/ (auto-generated)
│   ├── gotk-components.yaml
│   ├── gotk-sync.yaml
│   └── kustomization.yaml

Steps:

Create directories:

   mkdir -p clusters/staging

Create configuration files:

   touch clusters/staging/app-repo.yaml clusters/staging/apps.yaml

Step 3: Configure Resources

Define resources to monitor the application’s Git repository and deploy its manifests.

Edit clusters/staging/app-repo.yaml:

   apiVersion: source.toolkit.fluxcd.io/v1
   kind: GitRepository
   metadata:
     name: my-app
     namespace: flux-system
   spec:
     interval: 1m
     url: https://github.com/<github-username>/app-repo
     ref:
       branch: main

Instructs Flux to check the repository every minute for changes.

Edit clusters/staging/apps.yaml:

   apiVersion: kustomize.toolkit.fluxcd.io/v1
   kind: Kustomization
   metadata:
     name: my-app
     namespace: flux-system
   spec:
     interval: 5m
     sourceRef:
       kind: GitRepository
       name: my-app
     path: ./kubernetes/manifests
     prune: true
     targetNamespace: staging

Configures Flux to apply manifests from kubernetes/manifests/ to the staging namespace, with pruning enabled to remove undefined resources, reconciling every five minutes.

Step 4: Commit Configurations

Add and commit configurations to the local repository:

git add clusters/staging/
git commit -m "Add GitRepository and Kustomization for my-app"

Step 5: Bootstrap Flux

Initialize Flux to deploy its controllers and synchronize configurations with GitHub.

Run Bootstrap:

   flux bootstrap github \
     --owner=$GITHUB_USER \
     --repository=flux-config \
     --branch=main \
     --path=clusters/staging \
     --personal

Creates or updates <github-username>/flux-config.
Installs Flux controllers (e.g., source-controller, kustomize-controller) in the flux-system namespace.
Generates flux-system/ with gotk-components.yaml, gotk-sync.yaml, and kustomization.yaml.
Pushes configurations to GitHub and sets Flux to monitor clusters/staging/.

Verify Setup: Ensure Flux components are running:

   kubectl get pods -n flux-system

Confirm pods like source-controller-... and kustomize-controller-... are active.

Step 6: Configure Application Manifests

Set up manifests in the application repository to define Kubernetes resources.

Clone Application Repository:

   cd /
   mkdir temp-app
   cd temp-app
   git clone https://github.com/<github-username>/app-repo.git
   cd app-repo
   mkdir -p kubernetes/manifests

Create kubernetes/manifests/deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app
     namespace: staging
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: my-app
           image: nginx:1.14.2
           ports:
           - containerPort: 80

Create kubernetes/manifests/service.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: my-app-service
     namespace: staging
   spec:
     selector:
       app: my-app
     ports:
     - protocol: TCP
       port: 80
       targetPort: 80
     type: ClusterIP

Commit and Push:

   git add .
   git commit -m "Add my-app manifests"
   git push origin main

Step 7: Create Namespace

Ensure the staging namespace is present:

kubectl create namespace staging --dry-run=client -o yaml | kubectl apply -f -

Step 8: Verify Deployment

Confirm Flux has correctly applied the manifests.

Check GitRepository:

   flux get sources git my-app -n flux-system

Expect Ready: True, indicating repository sync.

Check Kustomization:

   flux get kustomizations my-app -n flux-system

Expect Ready: True, confirming manifest deployment.

Verify Resources:

   kubectl get deployments,services -n staging

Expect a my-app deployment (1 replica, nginx:1.14.2) and my-app-service.

Step 9: Test GitOps with Image Tag Update

Validate GitOps by updating the application’s image tag and confirming Flux applies the change.

Update Image Tag: Edit /temp-app/app-repo/kubernetes/manifests/deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app
     namespace: staging
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: my-app
           image: nginx:1.18.0
           ports:
           - containerPort: 80

Commit and Push:

   cd /temp-app/app-repo
   git add kubernetes/manifests/deployment.yaml
   git commit -m "Update my-app image to nginx:1.18.0"
   git push origin main

Reconcile (Optional): Accelerate the update:

   flux reconcile kustomization my-app -n flux-system

Verify Update: Inspect running pods:

   kubectl get pods -n staging -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Expect new pods running nginx:1.18.0, with old nginx:1.14.2 pods terminated.

Step 10: Test Pruning with Replica Adjustment

Ensure pruning maintains the Git-defined state by introducing and correcting a configuration drift.

Increase Replicas Manually: Modify the deployment:

   kubectl scale deployment my-app -n staging --replicas=3

Verify Increase:

   kubectl get deployment my-app -n staging

Expect 3 replicas.

Reconcile: With deployment.yaml specifying replicas: 1, Flux will revert the change:

   flux reconcile kustomization my-app -n flux-system

Verify Pruning:

   kubectl get deployment my-app -n staging

Expect 1 replica, confirming Git state enforcement.

Step 11: Troubleshoot

Address issues to ensure a reliable GitOps pipeline.

Bootstrap Issues:
- Verify GITHUB_TOKEN has repo scope: curl -H "Authorization: token $GITHUB_TOKEN" https://api.github.com/user.
- Confirm network access and repository settings.
GitRepository Problems:
- Validate repository URL and branch.
- Check status: kubectl describe gitrepository my-app -n flux-system.
Kustomization Errors:
- Ensure path: ./kubernetes/manifests exists in app-repo.
- Review logs: kubectl logs -n flux-system -l app=kustomize-controller.
Update or Pruning Failures:
- Confirm prune: true in apps.yaml.
- Inspect events: kubectl describe kustomization my-app -n flux-system.

FluxCD: Transforming Kubernetes with GitOps

FluxCD redefines Kubernetes application management by leveraging GitOps, DevSecOps, CD pipeline, and DevOps principles. With a compact /flux-config structure, it automates deployments, ensuring consistency, security, and collaboration for any application.

GitOps: FluxCD establishes Git as the single source of truth, synchronizing manifests from <github-username>/app-repo. Updating an image from nginx:1.14.2 to 1.18.0 illustrates automated deployment, while pruning replicas from 3 to 1 enforces the declared state, enhancing traceability and control.
DevSecOps: Security is integrated through Git’s access controls and Flux’s pull-based synchronization, reducing manual cluster interactions. Declarative configurations enable early validation, supporting DevSecOps’ emphasis on secure development and operations.
CD Pipeline: FluxCD’s continuous polling drives seamless updates, automating changes like image tag updates without manual intervention, accelerating delivery for modern applications.
DevOps: Centralized Git configurations unite development and operations teams, while automated synchronization and pruning minimize operational effort, reflecting DevOps’ focus on collaboration and efficiency.

FluxCD delivers a robust, secure, and automated GitOps framework, empowering teams to manage Kubernetes applications with confidence and precision.

[Boost]

Uchechukwu Enyi — Thu, 10 Apr 2025 13:49:25 +0000