Ravindra BagaleCourses & study guides मराठी Track your progress

4. Amazon EC2: Launch and Connect to Your Linux Server

Chala mitrano, aata aapan swatahcha server banavnar aahot – AWS EC2 var. Pudhe Kali Linux madhun jya servers la "target" mhanun baghnar aahot, te kase banatat he aadhi swatah anubhavla pahije. Aaj aapan EC2 mhanje kay, instance kasa launch karaycha, key pair, security group, aani Windows, Linux, Mac varun SSH ne login kasa karaycha he step by step karnar aahot. Console ughda, aani majhya sobat pratyek step kara – fakt vachu naka.

What you will learn in this chapter

  • What EC2 is: instance, AMI, instance type, key pair, security group, EBS, region and AZ
  • How to choose an instance type for labs
  • Launching an instance step by step from the console
  • Protecting the private key with chmod 400 and connecting from Linux/Mac
  • Connecting from Windows with PowerShell, PuTTY and MobaXterm
  • First commands after login, instance metadata (IMDSv2) and the instance lifecycle

Concepts in this chapter

  1. 4.1What Is EC2? Key Concepts
  2. 4.2Choosing an Instance Type
  3. 4.3Launching an Instance Step by Step
  4. 4.4Key Pairs, chmod 400 and SSH from Linux/Mac
  5. 4.5SSH from Windows: PowerShell, PuTTY and MobaXterm
  6. 4.6First Commands After Login and Instance Metadata
  7. 4.7Instance Lifecycle: Stop, Reboot, Terminate

The chapter recap is at the end of the last concept page.

Chapter 4: Amazon EC2 launch and connect — practice tasks

Open chapter lessons · Full guided lab: launch ec2 safely key pair my ip billing alarm (not repeated here)

4.1 Fix a too-open security group (paper task)

EasyRetail

Why: SSH open to 0.0.0.0/0 is the most common cloud mistake.

What: Use the data file and rewrite each rule safely.

Data file: security-group.csv

PortSourcePurpose
220.0.0.0/0Admin SSH
800.0.0.0/0Website
33060.0.0.0/0Database
80800.0.0.0/0Old test app

About this file: Made-up inbound rules of a shop's EC2 server. Each row is one rule. Columns: Port = port allowed; Source = who may connect (0.0.0.0/0 = everyone); Purpose = why it was added.

How:

  1. For each rule ask: does the whole internet need it?
  2. Admin ports → your IP /32 only.
  3. Databases → no internet rule; app connects locally or by security group.
  4. Unused test ports → delete.

Expected output: 22 → your-ip/32; 80 → keep; 3306 → delete; 8080 → delete.

Hint

Only the public website needs 0.0.0.0/0.

Answer / how to check
  1. Count rules open to 0.0.0.0/0 afterwards: only 80 (and 443 if HTTPS).

4.2 Check key file permissions before SSH

EasyIT

Why: SSH refuses a key that others can read, and a leaked key = server takeover.

What: Create a dummy key and set safe permissions.

How:

  1. Run ssh-keygen -t ed25519 -f ~/lab-key -N ''.
  2. Run ls -l ~/lab-key.
  3. Run chmod 400 ~/lab-key.
  4. Run ls -l ~/lab-key again.

Expected output: Permissions change to -r--------.

Hint

400 = owner read only.

Answer / how to check
  1. stat -c %a ~/lab-key prints 400.

4.3 Read who logged in to your VM

MediumLogistics

Why: After launch, check that only you have logged in.

What: On your own VM, list recent logins and failed attempts.

How:

  1. Run last -n 10.
  2. Run sudo grep 'Failed password\|Invalid user' /var/log/auth.log | tail (Amazon Linux: sudo journalctl -u sshd | grep Failed).
  3. Count unique attacking IPs: ... | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -rn | head.

Expected output: Your own IP in last; on a public VM, failed tries from unknown IPs.

Hint

See the lab linked above for a full walk-through.

Answer / how to check
  1. If an unknown IP appears in last (successful), treat it as an incident.

Extended teaching notes

Why this lesson matters

Use this lesson to strengthen systems you own: understand the risk, practise safely in a lab, then write and apply the fix.

Apply the fix across stacks

Same class of bug, same idea in every language.

Java / Spring Boot

Parameterise queries, encode output, CSRF tokens, limited Actuator, dependency scanning.

ASP.NET Core

EF Core / parameterised SQL, Razor encoding, HTTPS, Data Protection.

Node.js / Express

helmet, parameterised SQL, npm audit, avoid eval and shell concat.

Python / Django / Flask / FastAPI

ORM, autoescape, pip-audit, Bandit; never shell=True with user input.

PHP / Laravel

PDO/Eloquent, Blade escaping, composer audit.

Go / Ruby

database/sql placeholders / ActiveRecord; html/template / ERB escaping; govulncheck / Brakeman.

nginx / Apache / Tomcat

Hide versions, TLS, security headers, least-open ports.

MySQL / PostgreSQL / MongoDB / Redis

Private networks, auth on, least-privilege users, no 0.0.0.0/0.

AWS / Azure / GCP

Roles not long-lived keys, private data stores, cloud audit logs on.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

  1. Write the lesson title, date and the exact lab target you are allowed to use.
  2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
  3. Run one safe check from the lesson on a lab system only. Paste the command and output.
  4. Write a two-sentence fix you would give a teammate.
  5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

  • Control: a safeguard (patch, config, process, detection).
  • Finding: a weakness backed by evidence.
  • Remediation: the fix plus how you verified it.
  • Scope: systems you have written permission to touch.
  • Least privilege: only the access the task needs.
  • Defence in depth: several layers so one failure does not end the story.

Common mistakes

  • Skipping written permission "just for a quick scan".
  • Practising on hostel, office or public targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
  • Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Fix > spectacle.