Bash Scripting Saved Me — How I Automated NGold Deployment After AWS Attack Alert on My EC2




Day 7: Bash Scripting Saved Me — How I Automated NGold Deployment After AWS Attack Alert on My EC2

Yesterday was supposed to be just another Linux day. I woke up early in Port Harcourt, ready to write about file permissions and processes for Day 6. My Netflix Clone NGold was live and happy at 32.196.145.76:3000. I had just pushed a new build, Docker was running, and I was feeling like a real DevOps engineer. Then at 9:12 PM, my phone buzzed. AWS email: "Your Amazon EC2 instance has been identified as being targeted for penetration attempts."

My heart cut instantly. I opened the email with shaky hands. AWS GuardDuty was flagging my t2.micro instance. Someone, or some bot, was scanning my IP from different locations. The report mentioned SSH brute force attempts and suspicious port probing. I have never felt that kind of panic in this 7-day journey. I spent 6 days building, now is my project about to become someone's crypto mining machine?

I did what every junior DevOps engineer should do in an emergency: I did not panic delete. I logged into AWS Console, went to EC2, and clicked STOP. Not Terminate. Stop. This keeps your EBS volume, your config, your security group — it just powers off the server so the attack cannot continue. That was my Lesson 1 for Day 7: In the cloud, security is not a feature you add later. It is the foundation.

Why was I attacked? Because of how I deployed NGold. From Day 2 to Day 6, I was running docker run -p 3000:3000 ngold which means bind host port 3000 to container port 3000 on 0.0.0.0/0. That is, the whole internet. Plus my Security Group allowed inbound 0.0.0.0/0 on port 3000, and 0.0.0.0/0 on port 22 for SSH. This is like leaving your house door open in Diobu and putting a sign "Come in, food dey inside." Bots from Shodan, Censys, and hackers scan every public IP on AWS every minute. They try default passwords, they try to exploit open Docker sockets, they try to run curl to download miners. My little t2.micro with 1GB RAM almost became a bitcoin miner for someone in another continent.

But this painful alert taught me the most important DevOps skill of all, more important than Docker, more important than EC2: Automation via Bash Scripting.

Why does Bash Scripting matter? Because manual deployment is where security mistakes happen. My old manual process was 15 commands. I would SSH into EC2, then type git pull origin main, then docker stop ngold, then docker rm ngold, then docker build -t ngold ., then docker run -p 3000:3000 ngold, then sudo systemctl restart nginx, then sudo ufw allow 3000, then forget to sudo ufw deny 3000 later. If NEPA takes light in the middle, or network cuts, you start again and you will definitely miss a step. You will leave port 3000 open. You will forget to set --restart unless-stopped. You will forget chmod.

Bash scripting is like recording a voice note for Linux. Instead of telling Linux "do this, now do this, now do this" every single day, you write all instructions inside one file called deploy.sh, you give it execute permission once with chmod +x deploy.sh, and then forever you just run ./deploy.sh and Linux does everything while you sip garri and watch the logs.

My new automated process is just one command: ./deploy.sh. One command, zero mistakes, secure every time.

I created the file inside my NGold project root. Here is exactly what is inside my production deploy script now, after hardening:

#!/bin/bash
set -e
echo "Starting NGold Secure Deployment..."
sudo apt update -y
git pull origin main
docker stop ngold || true
docker rm ngold || true
docker build -t ngold .
docker run -d -p 127.0.0.1:3000:3000 --restart unless-stopped --name ngold ngold
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
curl -f http://localhost:3000 || echo "App failed!"
docker ps

3 Critical Security Fixes I Added:
1. Changed -p 3000:3000 to -p 127.0.0.1:3000:3000 — now only localhost can access it, Nginx proxies to it.
2. Added --restart unless-stopped — app auto-recovers after reboot.
3. Added UFW rules to close all ports except 22, 80, 443. Port 3000 hidden behind Nginx.

To make it executable: chmod +x deploy.sh and run: ./deploy.sh

This is DevOps! Automate, Secure, Repeat. You write once, run 100 times safely.

Second script: secure.sh installs fail2ban which bans IPs after 5 failed SSH attempts. Bot scanners try 1000 passwords per minute — fail2ban stops them cold.

My realization: Every DevOps engineer gets attacked. It is not if, it is when. What separates junior from senior is response: Stop instance, audit Security Groups, close ports, automate deployment, never hardcode IP in GitHub, always use Nginx reverse proxy with SSL.

My NGold is currently Stopped for audit. I will restart tomorrow with new Elastic IP and hardened script. That attack was not failure, it was free security training from AWS.

Live (Paused): 32.196.145.76:3000
GitHub: Sirvickcloud91/netflix-frontend-1
Diary: sirvick-deployments.blogspot.com

Day 8 Preview: Nginx Reverse Proxy + Custom Domain + Free SSL for sirvickcloud9.online

Have you ever gotten AWS attack alert? What did you do?

Comments

Post a Comment

Popular posts from this blog

How I Fixed GitHub Error: failed to push some refs to github.com in 2026

How I Deployed Netflix Clone (NGold) to AWS EC2 - Live at 32.196.145.76:3000 [Docker + Nginx Guide]

Understanding Linux Environment — The Real Engine Behind My AWS Cloud Deployment