Résumé
ONYEDIKACHI BERNARDCLOUD · DEVSECOPS · AI
RésuméGet in touch
CASE 04NETWORK & PERIMETER

The Wide-Open Security Group

A web server and its database had SSH and MySQL open to the whole internet. I closed both, limited the database to the web app's security group, and checked the app and its database connection still worked.

Status: REMEDIATED · VERIFIED

DOMAIN
Network & perimeter
PLATFORM
AWS EC2, Security Groups
SEVERITY
High
OUTCOME
Attack surface reduced

TOOLS

AWS CLIAmazon EC2AWS Security GroupsAWS Systems Manager Session ManagerNetcat
RESULT
BEFORESSH and MySQL open to 0.0.0.0/0
AFTERHTTP only, database from the app
01

Objective

I set out to find risky security group rules on a web application and its database, cut the network exposure down to what the app needs, and confirm the app could still reach its database afterwards.

02

Scenario

The environment had a public-facing web server and a database server in a private subnet. The web server's security group allowed SSH, HTTP and MySQL from 0.0.0.0/0, and the database's security group also allowed MySQL from 0.0.0.0/0.

03

What I found

web-app-sgPUBLIC
TCP/22    SSH     0.0.0.0/0
TCP/80    HTTP    0.0.0.0/0
TCP/3306  MySQL   0.0.0.0/0
FINDING 01HIGH

SSH open to the internet

The web server's security group accepted SSH on TCP/22 from any IPv4 address, which widened the server's management attack surface for no reason.

FINDING 02HIGH

MySQL open to the internet

Both the web server's and the database's security groups accepted MySQL on TCP/3306 from 0.0.0.0/0. The database was reachable from the whole internet instead of only from the application that uses it.

04

What I did

  1. Found the instances

    I listed the running EC2 instances and identified the web server and the database.

  2. Read the inbound rules

    I inspected both security groups with the AWS CLI and found the public SSH and MySQL rules.

  3. Closed public SSH and MySQL on the web server

    HTTP stayed open because the app needs it.

  4. Locked the database to the app

    I removed the 0.0.0.0/0 MySQL rule and added one that allows TCP/3306 only from the web server's security group.

  5. Moved admin access to Session Manager

    Systems Manager replaced SSH for administering the web instance.

05

Validation

The web server's security group now shows HTTP as its only inbound service. The app still answered, and the database still accepted connections from the web server through the new rule:

BASH
curl -s http://<PUBLIC_IP>
# Status: Application is running normally.

nc -v 10.0.2.10 3306 -w 3
# Ncat: Connected to 10.0.2.10:3306.
06

Before and after

RULEBEFOREAFTER
Web app SSH 22From 0.0.0.0/0Removed
Web app HTTP 80From 0.0.0.0/0Kept
Web app MySQL 3306From 0.0.0.0/0Removed
Database MySQL 3306From 0.0.0.0/0Web app security group only
07

What I recommend

  1. 01Do not expose admin access such as SSH to the whole internet; use Session Manager or a restricted source.
  2. 02Keep databases private and allow access only from the resources that need them.
  3. 03Use security group references for app-to-database traffic.
  4. 04Prefer HTTPS on 443 over HTTP on 80 for public web apps.
  5. 05Review security group rules regularly for public exposure.

“A security group should expose only the traffic the application needs. Internal services such as databases belong behind the application, not on the public internet.”

WHAT I LEARNED

SKILLS IT PROVES

  • Cloud Security
  • AWS Security Groups
  • EC2 Security
  • Network Security
  • Least Privilege
  • Attack Surface Reduction
  • Security Hardening
  • Security Validation
  • AWS CLI
View my labs on GitHub