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

8. Hosting a Static Website and Changing the Configuration

By Last updated:

Chala mitrano, aata aapli pahili website internet var taakuya! Aaj aapan ek chhoti static site banavnar, ti server var upload karnar, aani Nginx aani Apache dogha ne – Amazon Linux aani Ubuntu var – host karnar. Mag real kaamasathi lagnare badal shikuya: document root badalne, port badalne, index page badalne aani server thoda secure karne. Pratyek step nantar browser madhe check kara – swatahchi site disli ki khup maja yete.

What you will learn in this chapter

  • Creating a sample website and uploading your own files (scp, git, SFTP)
  • Hosting it with Nginx and Apache on Amazon Linux 2023 and Ubuntu (four combinations)
  • Changing the document root, the port and the index page
  • SELinux and security group notes for each change
  • Basic hardening of a static web server

Concepts in this chapter

  1. 8.1Create the Sample Website and Upload Files
  2. 8.2Amazon Linux 2023 + Nginx
  3. 8.3Amazon Linux 2023 + Apache
  4. 8.4Ubuntu + Nginx
  5. 8.5Ubuntu + Apache
  6. 8.6Changing the Document Root
  7. 8.7Changing the Port
  8. 8.8Changing the Index Page
  9. 8.9Basic Hardening of a Static Web Server

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

Chapter 8: Hosting a static website — practice tasks

Open chapter lessons · Full guided lab: static site security headers curl (not repeated here)

8.1 Host a shop page safely in Docker

EasyRetail

Why: Even a simple page should only serve the files you meant to publish.

What: Serve one index.html for 'Sharma Sweets, Jaipur' with nginx in Docker.

How:

  1. mkdir site && echo '<h1>Sharma Sweets, Jaipur</h1>' > site/index.html
  2. docker run -d --rm -p 8090:80 -v $PWD/site:/usr/share/nginx/html:ro --name s nginx
  3. curl -s localhost:8090
  4. curl -s -o /dev/null -w '%{http_code}' localhost:8090/../etc/passwd

Expected output: The h1 text, and 400/404 for the path trick.

Hint

:ro mounts the folder read-only.

Answer / how to check
  1. Only index.html is reachable.

8.2 Check file permissions in the web root

EasyIT

Why: Web files writable by www-data let a hacked app rewrite your site.

What: Make site files owned by your user and read-only for nginx.

How:

  1. sudo chown -R $USER:www-data /var/www/html
  2. sudo find /var/www/html -type d -exec chmod 750 {} \;
  3. sudo find /var/www/html -type f -exec chmod 640 {} \;
  4. curl -I http://127.0.0.1/

Expected output: Site still loads with 200.

Hint

nginx only needs read.

Answer / how to check
  1. sudo -u www-data touch /var/www/html/x fails.

8.3 Make a custom 404 page that leaks nothing

MediumHealthcare

Why: Default error pages reveal server info.

What: Add a plain 404 page for a clinic site.

How:

  1. echo 'Page not found – City Clinic, Kolkata' | sudo tee /var/www/html/404.html
  2. Add error_page 404 /404.html; and server_tokens off; in nginx.
  3. sudo nginx -t && sudo systemctl reload nginx
  4. curl -si http://127.0.0.1/nope | head

Expected output: Your text, and Server header without version.

Hint

server_tokens goes in http or server block.

Answer / how to check
  1. Header shows 'Server: nginx' with no number.

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.

Extra depth

Re-read the original short section at the top of the page, then this expansion. Together they should exceed a solid lesson length. If anything still feels thin, add your own lab screenshot and a paragraph in your notebook — that personal evidence is what interviews ask for.

  • Permission before tools.
  • Patch and config before exploits.
  • Logs and backups before blame.
  • Teach one junior the warning from this page.