Forem: Opatola Bolaji Prince

Building a Smart Security Guard for Your Server 🛡️

Opatola Bolaji Prince — Tue, 28 Apr 2026 17:12:25 +0000

This project is part of the HNG DevOps internship (Stage 3), and trust me, it sounds way more complicated than it actually is. Let's break it down together.

What Are We Building?

Think of it like hiring a smart security guard for your website who:

Watches the door - Keeps track of everyone visiting your site
Learns the pattern - Figures out what "normal" traffic looks like
Spots the troublemakers - Detects when something fishy is happening
Takes action - Blocks suspicious visitors automatically
Sends you alerts - Notifies you on Slack when there's trouble
Shows a dashboard - Gives you a live view of what's happening

Cool, right? Let's see how it all works!

Understanding the Key Concepts (No Jargon, I Promise!)

1. The Sliding Window (Think: Security Camera Footage)

Imagine you have a camera recording your front door. Instead of keeping all footage forever, you only keep the last 60 seconds. When a new second is recorded, the oldest one gets deleted.

In our system:

We track how many people visited in the last 60 seconds
Every second, we add new data and remove the oldest
This gives us a "rolling" view of recent activity

Why is this useful?

It helps us spot sudden spikes in traffic that might indicate an attack!

# Simple example (Python makes this easy!)
from collections import deque

# This automatically keeps only the last 60 items
recent_traffic = deque(maxlen=60)

# Every second, we add new data
recent_traffic.append(current_visitors)

# Old data automatically disappears!

2. The Baseline (Your "Normal" Traffic Pattern)

Your baseline is like knowing your daily routine. If you usually get 10-15 visitors per second, that's your "normal."

How we calculate it:

Watch traffic for 30 minutes
Calculate the average (mean)
Calculate how much it varies (standard deviation)

Example:

Normal traffic: 13 visitors/second ± 2
This means 11-15 is totally normal
But 50 visitors/second? That's suspicious!

import statistics

# Collect 30 minutes of data
traffic_data = [12, 15, 13, 14, 16, 11, 12, ...]

# Calculate your "normal"
average = statistics.mean(traffic_data)  # Example: 13.5
variation = statistics.stdev(traffic_data)  # Example: 2.1

3. The Z-Score (How Weird is This Traffic?)

The z-score is just a fancy way of asking: "How unusual is this compared to normal?"

Simple formula:

z-score = (current traffic - normal traffic) / variation

What it means:

Z-score of 0 = Perfectly normal
Z-score of 1-2 = A bit high, but okay
Z-score of 3+ = ALERT! Something's wrong!

Real example:

normal = 13.5 visitors/second
variation = 2.1
current = 30 visitors/second

z_score = (30 - 13.5) / 2.1
# Result: 7.86 — Definitely an attack!

if z_score > 3.0:
    print("🚨 ATTACK DETECTED!")

4. The 5x Rule (Backup Check)

Sometimes the z-score isn't enough. The 5x rule is simple:

If traffic is 5 times higher than normal, it's an attack — no matter what!

Why? If you normally get 2 visitors/second, even 10 might not trigger the z-score, but it's still 5x your normal traffic!

Setting Up Your Project

What You'll Need

A Google Cloud account (free tier works!)
A Slack account (to receive alerts)
Basic knowledge of:
- Running commands in terminal
- What Docker is (even just a basic idea)
- Python basics (if statements, loops)

Step 1: Create Your Cloud Server

Go to Google Cloud Console
Create a new VM (virtual machine):
- Name: hng-stage3
- Type: e2-medium (2 CPU, 4GB RAM)
- Disk: Ubuntu 22.04 LTS, 20GB
- Firewall: Allow HTTP and HTTPS traffic
Click "Create" and wait a minute

Don't forget: Open port 8080 for your dashboard!

Go to VPC Network → Firewall
Create a new rule called allow-dashboard-8080
Allow TCP port 8080 from anywhere (0.0.0.0/0)

Step 2: Connect to Your Server

Click the "SSH" button next to your VM in Google Cloud Console. A terminal will open — this is where the magic happens!

Step 3: Install the Tools

Run these commands one by one:

# Update your system
sudo apt update && sudo apt upgrade -y

# Install Docker (the easy way!)
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# Install Docker Compose
sudo apt install docker-compose -y

# Install Python
sudo apt install python3 python3-pip git -y

# Create your project folder
mkdir ~/hng-stage3
cd ~/hng-stage3

Congrats! Your server is ready! 🎉

Building the Detection System

Project Structure

Here's how we'll organize everything:

hng-stage3/
├── docker-compose.yml          # Starts all our services
├── nginx/
│   └── nginx.conf              # Web server config
├── detector/
│   ├── main.py                 # Main program
│   ├── monitor.py              # Watches the logs
│   ├── baseline.py             # Calculates "normal"
│   ├── detector.py             # Spots attacks
│   ├── blocker.py              # Blocks bad IPs
│   ├── notifier.py             # Sends Slack alerts
│   ├── dashboard.py            # Web dashboard
│   ├── config.yaml             # Your settings
│   └── requirements.txt        # Python packages needed

The Core Logic (In Plain English!)

1. Monitor the Traffic (monitor.py)

This script watches your web server logs and counts visitors every second.

# Every second, check how many people visited
def count_visitors():
    # Read the log file
    # Count new entries
    # Return the number
    return visitor_count

2. Learn What's Normal (baseline.py)

After collecting data for 30 minutes, calculate your baseline.

def calculate_baseline(data):
    average = sum(data) / len(data)
    # Calculate how much traffic varies
    variation = calculate_standard_deviation(data)

    return {
        'mean': average,
        'stddev': variation
    }

3. Detect Attacks (detector.py)

Compare current traffic to your baseline using the z-score.

def is_attack(current_traffic, baseline):
    z_score = (current_traffic - baseline['mean']) / baseline['stddev']

    # Check z-score rule
    if z_score > 3.0:
        return True

    # Check 5x rule
    if current_traffic > (baseline['mean'] * 5):
        return True

    return False

4. Block the Attacker (blocker.py)

Use iptables (a firewall tool) to block the bad IP address.

def block_ip(ip_address):
    # Add firewall rule to block this IP
    os.system(f"iptables -A INPUT -s {ip_address} -j DROP")
    print(f"🚫 Blocked {ip_address}")

5. Send an Alert (notifier.py)

Post a message to Slack so you know what's happening.

import requests

def send_slack_alert(message):
    webhook_url = "YOUR_SLACK_WEBHOOK_URL"

    payload = {"text": message}
    requests.post(webhook_url, json=payload)

Testing Your System

Step 1: Let It Learn (5-10 minutes)

Generate some normal traffic so the system can build a baseline:

# Install the testing tool
sudo apt install apache2-utils -y

# Send normal traffic (10 requests/second for 60 seconds)
ab -n 600 -c 1 -t 60 http://localhost/

Watch your detector logs:

docker logs hng-detector -f

You should see it learning and updating the baseline!

Step 2: Simulate an Attack

Now let's test if it can detect attacks:

# Send 100 requests/second for 60 seconds
ab -n 6000 -c 10 -t 60 http://localhost/

What should happen:

Detector spots the unusual traffic
Calculates a high z-score
Blocks the IP address
Sends you a Slack alert
Shows the attack on your dashboard

If you see all of this, you did it! 🎊

The Dashboard

Your dashboard runs on port 8080 and shows:

Live traffic graph - See requests per second
Baseline tracker - Your "normal" traffic pattern
Recent alerts - What attacks were detected
Blocked IPs - Who's been banned

Common Problems (And How to Fix Them)

Problem 1: "My logs are empty!"

Solution:

# Make sure the web server is running
docker ps

# Test by visiting your site
curl http://localhost/

# Check if logs are being created
docker exec hng-nginx tail /var/log/nginx/hng-access.log

Problem 2: "The detector isn't blocking anything!"

Solution:

# Make sure the detector has permission to use the firewall
docker inspect hng-detector | grep -i privileged
# Should show: "Privileged": true

# If not, add this to your docker-compose.yml:
# privileged: true
# network_mode: "host"

Problem 3: "Dashboard won't load!"

Solution:

# Check if the port is open on GCP
# Go to: VPC Network → Firewall → allow-dashboard-8080

# Test from your computer:
curl http://YOUR_SERVER_IP:8080/api/metrics

What I Learned

Building this project taught me:

How real security systems work - It's not magic, just math!
The power of baselines - Understanding "normal" helps you spot "abnormal"
Why automation matters - Blocking attacks manually would be impossible
Docker makes deployment easy - Everything runs in containers
Monitoring is crucial - You can't fix what you can't see

Key Takeaways

Start simple - Build one piece at a time

Test frequently - Don't wait until the end to test

Learn the concepts - Understanding why > memorizing code

Use tools wisely - Python and Docker handle the heavy lifting

Monitor everything - Logs are your best friend

Resources

Good luck, and happy coding! 🚀

P.S. If you found this helpful, give it a ❤️ and follow me for more DevOps tutorials!

Case Study: Deploying a Full-Stack MERN Application on AWS EC2 Using Docker & GitHub Actions

Opatola Bolaji Prince — Wed, 29 Oct 2025 12:54:37 +0000

If you’ve ever built a full-stack app and asked yourself:

“How do I deploy this professionally in production with DevOps best practices?”

This case study walks through exactly how I achieved that — step-by-step — including the challenges, mistakes, and real fixes.

Project Overview I built and deployed a production-grade full-stack note-taking application called Notify.

Technologies involved:

React + Vite for the frontend
Node.js + Express for the backend
MongoDB as the database
Docker & Docker Compose for containerization
AWS EC2 for hosting
GitHub Actions CI/CD for automated deployment

The goal: Push code → App auto-deploys to AWS → No manual server changes

Phase 1 — Dockerizing the MERN Application The first step was packaging each part of the application into its own container.

Backend Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 5000
CMD ["npm", "start"]

Frontend Dockerfile
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

The frontend is built and then served using Nginx — making it production-ready.

Phase 2 — Docker Compose for Multi-Service Orchestration To run all three containers together and ensure they communicate properly:

services:
  mongo:
    image: mongo:6
    container_name: mongo-db
    ports:
      - "27017:27017"
    restart: always

  backend:
    build: ./backend
    env_file: ./backend/.env
    environment:
      - MONGODB_URI=mongodb://mongo:27017/notifydb
    ports:
      - "5000:5000"
    depends_on:
      - mongo

  frontend:
    build: ./frontend
    ports:
      - "80:80"
    depends_on:
      - backend

Key insight:
The backend connects to MongoDB using the container name mongo, not localhost.

Phase 3 — Deploying to AWS EC2
I launched an Amazon Linux 2023 EC2 instance and prepared it for containerized deployment.
Installed Docker
Installed Docker Compose
Added ec2-user to Docker group
Security groups configured correctly

Opened inbound ports:

80 → Web traffic
5000 → Backend API
22 → SSH Access
Then deployed:
git clone https://github.com/emperorbj/notify.git
cd notify
docker compose up -d --build

🎉 Site instantly reachable via:

Phase 4 — Enabling CI/CD With GitHub Actions The goal was zero manual deployments after setup.

📌 Every time I push to main:

EC2 pulls new code
Docker rebuilds
Containers restart automatically
Old images removed

GitHub Actions workflow:

name: Deploy to EC2

on:
  push:
    branches: ["main"]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: SSH Agent
        uses: webfactory/ssh-agent@v0.9.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Add Known Hosts
        run: ssh-keyscan -H ${{ secrets.EC2_HOST }} >> ~/.ssh/known_hosts

      - name: Deploy Over SSH
        run: |
          ssh ec2-user@${{ secrets.EC2_HOST }} << 'EOF'
            cd ~/notify
            git pull origin main
            docker compose down || true
            docker compose up -d --build
            docker image prune -f
          EOF

Real-World Problems I Had to Solve
This wasn’t smooth — and that’s exactly the valuable part.

Problems + Fixes: Backend couldn’t connect to MongoDB → switched URI to container name

Deployment failing due to wrong Docker version → updated Docker + enabled compose

Frontend wouldn’t load → exposed port 80, not Vite’s local 5173

SSH denied → fixed key pairing and GitHub secrets

Docker commands failing → added EC2 user to Docker group

Every issue taught me lessons developers don’t learn until production ✨

You can watch the process here :
https://www.loom.com/share/897f49af1b274e3fba6921c842d0653b

🎯 What This Project Proved

I now understand:

🔥 Container orchestration with Docker
🔥 Cloud deployment using AWS EC2
🔥 Networking between services in production
🔥 Continuous Deployment pipelines
🔥 Debugging real infrastructure failures

This project took me from “I can code this” to:

✅ “I can run this in production — automatically.”

✅ Final Result ✅

✔ Full MERN App running live on AWS
✔ 100% Dockerized microservices
✔ Push-to-deploy automation
✔ Secure, scalable architecture
✔ Excellent DevOps experience gained

This is now a foundation I can reuse for multiple future projects