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

32. Linux and Network Hardening

By Last updated:

Chala mitrano, attack kasa hoto he aapan khup baghitla. Aata ulta vichar karu: server itka majboot kasa karaycha ki attack yashasvi ch hou naye? Yalach "hardening" mhantat – ghar la chaan kulup, CCTV ani majboot darwaja lavne. Ya chapter madhe SSH lock karne, fail2ban, firewall, updates, users ani permissions, Apache/Nginx hardening, VPN ani IDS (Snort/Suricata) shiku. Pratyek step tumchya Chapter 6-16 madhlya EC2 server var lagu hote. Samjla ka? Chala!

What you will learn in this chapter

  • Hardening principles: least privilege, attack surface, defence in depth
  • SSH hardening: keys only, no root login, fail2ban
  • Host firewall with firewalld and ufw
  • Patching, users, sudo, file permissions and services
  • Web server hardening for Apache and Nginx
  • Network hardening: segmentation, VPN, and IDS/IPS with Snort and Suricata

Before you change SSH or the firewall

Always keep your current SSH session open while you test a new setting in a second terminal. If the new login fails you can still fix it from the first session. Test on a lab VM or a fresh EC2 instance first, never directly on a live customer server.

Concepts in this chapter

  1. 32.1Hardening Principles
  2. 32.2SSH Hardening and fail2ban
  3. 32.3Host Firewall: firewalld and ufw
  4. 32.4Patching, Users, Permissions and Services
  5. 32.5Web Server Hardening
  6. 32.6Network Hardening: Segmentation, VPN and IDS/IPS
  7. 32.7Red vs Blue, Project and Real Incidents
  8. 32.8How a VPN Works

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

Chapter 32: Linux and network hardening — practice tasks

Open chapter lessons · Full guided lab: harden ubuntu server ssh keys ufw fail2ban (not repeated here)

32.1 Turn on UFW with SSH first

EasyIT

Why: A firewall with no SSH rule locks you out.

What: Enable UFW safely on your VM.

How:

  1. sudo ufw allow OpenSSH
  2. sudo ufw enable
  3. sudo ufw status

Expected output: Status: active; OpenSSH ALLOW.

Hint

Do this on console or with a second session open.

Answer / how to check
  1. SSH still works after enable.

32.2 Disable password SSH

MediumBanking

Why: Keys beat passwords for servers.

What: Allow only public-key login.

How:

  1. Copy your key with ssh-copy-id.
  2. In sshd_config: PasswordAuthentication no.
  3. sudo systemctl reload ssh
  4. Try password login — must fail.

Expected output: Password login rejected; key works.

Hint

Keep a console open until tested.

Answer / how to check
  1. ssh -o PreferredAuthentications=password fails.

32.3 Install fail2ban

EasyLogistics

Why: Auto-ban reduces noise and risk.

What: Ban after 3 fails in a lab.

How:

  1. sudo apt install fail2ban
  2. Set maxretry=3 in jail.local.
  3. Fail SSH 3 times from a second IP; check fail2ban-client status sshd.

Expected output: Banned IP listed.

Hint

Unban with fail2ban-client set sshd unbanip.

Answer / how to check
  1. Status shows 1 banned IP.

Extended teaching notes

Why this lesson matters

Part 11 turns tool skills into professional defensive practice: web risks, cloud, SOC work, hardening, cryptography, Indian law and careers. Every example below stays inside systems you own or public teaching material.

Indian company (sample data)

Suppose we are a junior security engineer at an Infosys or TCS client project. You take this lesson's checklist, map it to three production services (for example a Spring Boot API, a Node.js portal and a Python job), and open tickets with evidence and owners.

Global practice

Follow public guidance from OWASP, CERT-In, CISA and cloud provider Well-Architected / security pillars. Cite them in reports.

Everyday analogy

A cricket team that only practises hitting but never fielding loses matches. Offence skills in a lab exist to improve fielding in real systems.

Apply across stacks

Wherever code appears, ask the same questions.

Java / Spring Boot

Parameterise queries, encode output, limit Actuator, patch dependencies.

.NET

EF Core parameters, HTTPS, Data Protection API, patch NuGet.

Node.js

helmet, parameterized SQL, npm audit, lockfiles.

Python

ORM, autoescape, pip-audit, Bandit.

Go / PHP / Ruby

Safe templates, prepared statements, govulncheck / composer audit / Brakeman.

nginx / Apache / Tomcat

Hide versions, TLS, least-open ports.

MySQL / PostgreSQL / MongoDB / Redis

No public ports, auth on, least-privilege users.

AWS / Azure / GCP

Roles not keys, private data stores, cloud logs on.

Defender worksheet

  1. Write a 5-line summary.
  2. Name one related public breach or advisory.
  3. Practise one safe command on a lab you own.
  4. Write the fix for a teammate.

Recap

  • Permission first.
  • Fix over spectacle.
  • Evidence in notes.

Defender's worksheet (do this today)

  1. Write the lesson title and date.
  2. List three owned systems where it applies.
  3. Run one safe lab check and paste evidence.
  4. Write a two-sentence fix for a teammate.
  5. Note one CERT-In or CISA advisory that relates (title + date).

Indian workplace (sample)

At a Wipro or LTIMindtree client SOC, turn this lesson into one playbook step with an owner and a due date.

Global practice

Compare your notes with OWASP, CIS Benchmarks or a cloud Well-Architected security question. Write the overlap in five lines.

Family test

Explain the risk and the fix without jargon. If a parent or sibling can repeat the warning, you are ready to teach juniors.

Common mistakes

  • Skipping permission.
  • Tool collecting without fixing.
  • Publishing lab screenshots that contain secrets.
  • Treating encoding as encryption.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.

Key terms for this page

  • Control: a safeguard (patch, config, process).
  • Finding: a weakness with evidence.
  • Remediation: the fix and how you verified it.
  • Scope: systems you are allowed to touch.
  • Least privilege: only the access required for the task.
  • Defence in depth: several controls in layers.

Mini case study

Suppose we are a junior engineer at Zoho or Freshworks (sample data). A weekly review asks each person to present one control from their area. You pick a control from this lesson, show a before/after screenshot from a lab, and list the production ticket you would open. That habit builds both skill and credibility.