32.7 Red vs Blue, Project and Real Incidents

By Ravindra Bagale Last updated: 27 September 2026

Chala mitrano, SSH keys, fail2ban, firewalld/ufw, sudo yum update, unused services, SELinux, web harden, segmentation/VPN, Suricata/Snort – aata Purple Team loop. Red OWN Amazon Linux / Metasploitable-style lab host madhe weak SSH password ani open host firewall dakhavto; Blue keys-only sshd + fail2ban + firewalld + patch + disable unused + SELinux awareness ne band karto. Tumhi Sahyadri Traders style OWN Kali→lab host madhe build → hack → fix karun Purple report liha. Soft target rahila nahi – re-prove with nmap. Samjla ka? Dusryacha production – kadhi nahi.

Red Team vs Blue Team – Linux and network hardening

Red team (attacker) does	Blue team (defender) detects / stops
SSH password spray / default creds on OWN Metasploitable-style host	Keys-only sshd (`PasswordAuthentication no`, `PermitRootLogin no`); `fail2ban`; `/var/log/secure` watch
Leave host firewall open (all ports) while SG is "someone else's job"	firewalld / ufw on the host + AWS SG least privilege; only needed ports
Skip patches so old daemons stay exploitable	Regular `sudo yum update`; reboot when kernel needs it; remove unused packages
Abuse unused services (FTP, Telnet, old Samba) left enabled	Disable/remove unused services; `sudo service <name> stop`; boot enable only what you need
Drop SELinux to permissive "so the app works" and forget	Keep SELinux enforcing; fix labels/policies instead of disabling
Flat lab network: web + DB + admin on one segment	Segmentation + VPN for admin; Suricata/Snort alerts to SIEM (Ch.31)

Defender chi simple checklist: keys-only SSH → fail2ban → firewalld/ufw + SG → sudo yum update → disable unused → SELinux enforcing → web harden + HTTPS → segment/VPN → IDS alert path → re-prove with nmap from Kali. Red = weak lab host; Blue = harden + prove closed. Interview madhe "I left password SSH open" peksha "I hardened my OWN Amazon Linux lab host, re-ran nmap from Kali host-only, and showed the noisy ports and password SSH were gone" jast strong.

# OWN lab only – Sahyadri Traders (Pune) Amazon Linux / Metasploitable-style host
# Kali host-only e.g. 192.168.56.10 → target 192.168.56.20 (or YOUR Amazon Linux EC2)
mkdir -p ~/labs/sahyadri-harden
# 1) BASELINE (Red awareness – detect weak surface on OWN host):
#    From Kali: nmap -sS -sV -p- 192.168.56.20 | tee ~/labs/sahyadri-harden/nmap-before.txt
#    On target (Amazon Linux YOU own):
#      sudo grep -E 'PasswordAuthentication|PermitRootLogin|MaxAuthTries' /etc/ssh/sshd_config
#      sudo service firewalld status || true
#      sudo yum list updates | head
# 2) FIX (Blue – OWN target only):
#    # SSH keys only (keep a second session open while testing – Ch.32.2)
#    sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
#    sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
#    sudo service sshd restart
#    sudo yum install -y fail2ban
#    sudo service fail2ban start
#    sudo service fail2ban status
#    sudo yum install -y firewalld
#    sudo systemctl enable firewalld    # boot only
#    sudo service firewalld start
#    sudo firewall-cmd --permanent --add-service=ssh
#    sudo firewall-cmd --reload
#    sudo yum update -y
#    # stop one unused lab service you identified (example name only):
#    # sudo service vsftpd stop
# 3) RE-VERIFY from Kali host-only:
#    nmap -sS -sV -p- 192.168.56.20 | tee ~/labs/sahyadri-harden/nmap-after.txt
#    # expect fewer open ports; password SSH path closed; fail2ban bans noisy tries
echo 'Scope: Sahyadri OWN lab / Free Tier – host-only or your EC2 only' \
  > ~/labs/sahyadri-harden/scope.txt
echo 'Fix: sshd keys | fail2ban | firewalld | yum update | disable unused' \
  >> ~/labs/sahyadri-harden/scope.txt

Ravindra Bagale's Tip

Students take an nmap-before screenshot and stop there – but they don't set up sshd keys, fail2ban and firewalld. The second mistake: turning off password SSH with only one session open – lock-out! Rule: OWN lab only → second SSH session open → keys + fail2ban + firewalld + yum update → nmap-after → Purple report. Hardening means proving it is closed, not "I think I fixed it". Don't worry, the checklist gets you there.

Lab

Tumchya OWN Amazon Linux EC2 (Free Tier) kiwa Metasploitable-style host-only VM var aadhi nmap baseline Kali pasun save kara (~/labs/sahyadri-harden/nmap-before.txt). Mag Blue steps: sshd keys-only + fail2ban (sudo yum / sudo service) + firewalld allow-SSH-only + sudo yum update. Unused lab service ek disable kara. Punha nmap – noisy ports / password path kami zala pahije. Internet spray nahi; dusryacha server nahi.

Project: Build it, hack it, fix it

Build: For fictional Sahyadri Traders (Pune wholesale shop server lab) on your own Amazon Linux Free Tier EC2 or Metasploitable-style host-only VM:

Start from a deliberately weak state (short time only): password SSH allowed or host firewall not running; note one unused service still listening
Scope file: Kali IP, target IP/instance id, written note that this is Sahyadri's OWN practice host
Ethics card: IT Act – no third-party hosts; host-only / your SG only; no internet-wide scans

Hack (lab awareness – OWN systems only): From Kali 192.168.56.10 (or your lab Kali):

Run a full TCP nmap against the OWN target; save nmap-before.txt
Show password-auth SSH still accepted (lab only) or document open unnecessary ports from the scan
Optional: a few failed SSH tries to prove logs/fail2ban will matter after the fix – not a public spray

Do not attack production shops, do not scan random EC2 on the internet, do not disable logging on shared machines.

Fix:

Deploy SSH key; set PasswordAuthentication no, PermitRootLogin no, sensible MaxAuthTries; sudo service sshd restart (second session open)
Install/start fail2ban; install/start firewalld (or ufw on Ubuntu) and allow only needed ports
sudo yum update -y; stop/disable one unused service; keep SELinux enforcing if the OS uses it
Optional: Suricata sensor awareness from Ch.32.6 so noisy nmap shows in fast.log

Re-verify: Same nmap from Kali shows a smaller surface; password SSH rejected; fail2ban bans noisy retries. 1-page Purple report for owners Raja and Rani (Sahyadri ops): finding → control → fix → evidence. Peer-review with Zoya / Salman. IT Act: only systems you own or are authorised to test.

Real incident: Equifax – unpatched Apache Struts (2017)

In 2017, U.S. credit bureau Equifax disclosed a breach tied to an unpatched Apache Struts flaw (CVE-2017-5638). A patch had been available from the Struts project before the intrusion window; public reporting and later U.S. government reviews described a failure to patch a known internet-facing application in time. Equifax reported personal information exposure on the order of roughly 147 million consumers (treat published figures as reported). Weakness: large attack surface left on an unpatched framework – the same class of risk your Sahyadri sudo yum update and "remove unused services" checklist attacks. What would have reduced it: inventory of internet-facing apps, fast patch SLAs, WAF/virtual patching as a bridge, and segmentation so one web tier cannot reach everything. Lab lesson: nmap + patching is not "boring ops" – it is the Equifax-shaped Blue habit. Source: Equifax September 2017 disclosures, U.S. GAO / congressional hearing materials, and CVE-2017-5638 public advisories; verify current summaries.

Real incident: JPMorgan Chase – forgotten server without 2FA (2014)

In 2014, JPMorgan Chase disclosed a major cyber intrusion. Contemporary reporting (notably the New York Times and follow-on coverage) described attackers who had stolen credentials earlier and then reached a server that was overlooked in a bank-wide two-factor / hardening rollout – so that path still accepted access without the stronger control used elsewhere. The bank later reported contact information and related data tied to roughly 76 million households and about 7 million small businesses (treat figures as reported); it stated that account passwords and more sensitive authentication data were not taken in that event. Weakness: forgotten / inconsistently hardened exposure + missing MFA on an admin-facing path – unused or unmanaged surface, not a flashy zero-day. What would have reduced it: asset inventory ("what still has password-only SSH or no 2FA?"), MFA everywhere for remote admin, host firewall + jump/VPN patterns, and continuous hardening baselines. Lab lesson: your Sahyadri unused-service and SSH-key work is the small version of "do not leave one soft server behind". Source: JPMorgan Chase 2014 breach disclosures and major contemporary reporting (New York Times / Reuters summaries); verify current summaries.

Interview model (clean English): "I baseline an OWN lab host with nmap, harden SSH to keys-only with fail2ban and firewalld, patch with yum, disable an unused service, and re-prove the attack surface shrank from Kali on host-only."

Thodkyaat: soft target olakha, pan keys + fail2ban + firewall + patch + unused-off + re-prove shika. Aata pudhe cryptography – hashing, encryption ani certificates. Chala pudhe, mitrano!

Thodkyaat sangaycha tar

Hardening means least privilege, a small attack surface and several layers of defence.
Lock SSH with keys, no root login and fail2ban; keep a second session open while testing.
Add a host firewall (firewalld or ufw) on top of AWS security groups.
Patch often, clean up users, fix permissions, disable unused services and keep SELinux on.
Harden Apache/Nginx and PHP, and add security headers and HTTPS.
Segment networks, use a VPN for admin access, and watch traffic with Snort or Suricata.

Samjla ka? Tumcha server aata "soft target" rahila nahi. Pudhchya chapter madhe cryptography – hashing, encryption ani certificates kase kaam kartat. Chala pudhe, mitrano!