Patching and Least Modules

Module 5 already treated a CVE as a named bug with an owner and a date. Web-server patching is that ticket applied to the daemon and its modules: OS packages, vendor builds, or a managed platform’s update channel. An outdated Server token is a hint that the cadence slipped; a missing token is not proof you are current. Defenders patch first, then optionally genericize the remaining nameplate (Module 4). You do not need a proof-of-concept to write “update nginx from the vendor channel I already trust.” You do not download a public exploit “to confirm.” Confirmation on a box you own is: package version, changelog, restart, still serving YOUR content. Confirmation is not a shell.

python http.server is a teaching clerk, not a production product. You will not spend this lesson patching CPython to finish the module. You will write the principle: if you ran Apache, nginx, IIS, or a reverse proxy you owned, you would enroll it in updates, remove default content (Lesson 1), and record the owner of that cadence. Unpatchable leftover software is a timed liability — isolate it, replace it, or keep it off any network that is not loopback. Lesson 4 stays on 127.0.0.1 partly because the stdlib server is not a hardened production stack.

sudo apt install python3

brew install python3

uname -a ; python3 --version

cat >> "$NOTES" << 'EOF'
cadence: (weekly / on notify — fill)
hiding_banner: not a substitute
EOF

A web daemon is a core plus optional modules: language runtimes, CGI, WebDAV, status/info pages, autoindex, proxy, dav, and a long vendor list you do not need to memorize. Least modules means: if you cannot name a user who needs it, unload it. Autoindex is directory listing from Lesson 1 — disable it on servers you run. Status pages that print versions and uptime are banners with extra columns — bind them to loopback or turn them off. CGI and unused language modules are extra interpreters sitting behind HTTP. You need those names so a config review has verbs. You do not need a kit that exploits a specific module on a stranger. This course will not publish module-exploit steps.

Wrong instinct: “I will enable every module on a campus host so I can practice turning them off.” That instinct is unauthorized change plus a larger blast radius. Right instinct: on a VM or listener YOU own, load only what the lab needs (static files), write which extras you would refuse in production, and leave other people’s daemons alone. If a blog titled with a cert acronym publishes “enable this dangerous module then pwn it,” that blog is not this course. Cyberlium’s authorized surface is YOUR config intent plus a locked ticket.

TLS is the transport Module 8 already named: the path is encrypted and the name on the certificate should match the name you typed. A production web server that faces a LAN you do not fully trust, or the internet, should speak HTTPS with a certificate you control — not leftover HTTP because “it is only a lab forever.” python -m http.server speaks plain HTTP. That is acceptable on loopback for a teaching clerk. It is not a reason to bind 0.0.0.0 on café Wi-Fi so classmates can “help test TLS by attacking me.” Binding HTTP to the world is how yesterday’s demo becomes today’s leaked files. Lesson 4 hardcodes 127.0.0.1 so the missing TLS is contained by the bind, not by hope.

You will not get a TLS-stripping cookbook. You will not “practice SSL attacks” on a shop. You will write: production faces TLS; this teaching server stays on loopback; I will not advertise HTTP on 0.0.0.0. HSTS, redirect-to-HTTPS, and certificate hygiene are named controls for a stack you would own later. Proving you can bypass them on a stranger is unauthorized testing. If you ever have RoE to review TLS, that writing will name the host. You do not have RoE for the café portal or a random SaaS login.

A service that only needs to read a static folder should not run as Administrator or root. Topic 1 called this least privilege; Module 6 applied it to daily account vs admin; Module 4 applied it to listeners. After a web-server finding, ask: if this clerk were abused, what else could that UID touch? Dedicated workers (www-data, nginx, a user you created) exist so a bug in HTTP is not a bug in /etc/shadow. You will not “prove” least privilege by exploiting the service. You will write the intended user and the path it may read. Do not store secrets in the document root. Do not start python http.server as root. Do not start it in $HOME.

A useful failure: the site “would not start,” so someone launched the daemon as root and left it. That is the worked example in other Cyberlium topics and it still fails here. Another failure: run the clerk as your personal login so it can read your SSH keys and mail. Blast radius is the point of the dedicated user. Lesson 4 uses your normal account on a throwaway folder — acceptable for a two-terminal demo you then stop — and the notes still say production would use a worker UID. Empty “we run as root because Docker” without an owner and a revisit date is hollow compensate, the same shape Module 5 rejected.

On a computer you own, create cyberlium-lab if needed. Fill the template for a labeled stack you run or would run (this laptop’s future demo, a VM you created — not school.edu). chmod 600. The block writes notes only — no exploit, no extra host, no TLS-strip kit.

sudo apt install curl

curl -sS -m 8 -I "https://example.com/" | head -n 8
cat >> "$NOTES" << 'EOF'
production: TLS
lesson4_bind: 127.0.0.1 never 0.0.0.0
EOF

You now treat the daemon as a shrinkable surface: patch on a cadence, load only justified modules, speak TLS when the bind is not loopback, run a worker that is not root. None of those is an exploit. Notes are locked in cyberlium-lab. This is original Cyberlium teaching mapped to the CEH v13 web-servers domain — not official EC-Council training, not a cert, not exam dumps. Next — Logs as the First Responder — access and error logs on YOUR server, still not a wipe kit and still not a stranger’s /var/log.