🚧 Under construction — VoTechWorks is being built. A free tech program — complimentary, as our commitment to get America working.
voTechWorksGrade 13 · a vocational technology learning center, by urbanicity
newSchoolWorks.com › VoTechWorks › Technology & Design › Cybersecurity › Linux for Cybersecurity › Lesson 12
TEC-CYBE44-04 · Lesson 12 · 14.5 clock hours · lab

Capstone Lab: Securing and Investigating a Linux Server

Objective. Students independently harden a misconfigured Linux server, investigate a simulated intrusion scenario embedded within it, and produce a professional security report.

⚠ Pending professional review

This lesson, its worked examples and its practice questions has not yet been verified by an industry-certified professional or by a certification or approval body. It is a study draft and may contain errors. Do not use it as instructions for work on a job site or on live equipment. Always follow your instructor, your supervising professional, and current official references and regulations.

VoTechWorks program approval and accreditation are still in progress. Credentials are issued only by the certifying bodies named in each program, after their own exams.

Capstone Lab: Securing and Investigating a Linux Server

Purpose of This Lab

This capstone lab brings together every skill from the Linux for Cybersecurity course. You will receive a deliberately broken Ubuntu Server virtual machine, find every security problem in it, fix those problems, and write a professional report that could go to a real client or employer. Working independently is required — the goal is to prove you can do this job without prompting.

Lab Safety and Professional Conduct

All work is performed inside an isolated virtual machine. Never connect the misconfigured VM to a production or public network. Keep it on a host-only or isolated virtual network adapter throughout the lab. Take a snapshot of the VM before making any changes so you can return to the original state if needed. Document every command as you type it — do not reconstruct commands from memory after the fact.

Phase 1 — Discovery

Begin by treating the VM the way an attacker or an auditor would: assume nothing is safe until you verify it.

SSH configuration. Open `/etc/ssh/sshd_config` and check for dangerous settings such as `PermitRootLogin yes`, `PasswordAuthentication yes`, and an exposed default port. Use `ss -tlnp` or `netstat -tlnp` to confirm which port the daemon is actually listening on.

Running services. Run `systemctl list-units --type=service --state=running` to inventory every active service. Compare that list to what a minimal server needs. Services such as `telnet`, `ftp`, `rsh`, or unneeded web servers represent unnecessary attack surface.

User accounts. Examine `/etc/passwd` for accounts with a valid shell that should not exist. Check `/etc/shadow` permission bits. Use `awk -F: '($3 == 0)' /etc/passwd` to find any non-root account with UID 0 — a major red flag.

File permissions. Run `find / -xdev -type d -perm -0002 2>/dev/null` to locate world-writable directories. Run `find / -xdev -perm -4000 -type f 2>/dev/null` to find SUID binaries that should not have that bit set.

Log analysis. Examine `/var/log/auth.log` and `/var/log/syslog` for injected intrusion indicators — repeated failed logins, successful logins at unusual hours, privilege escalation events, or connections from unexpected IP addresses. Use `grep`, `awk`, and `journalctl` to filter and count events systematically.

Firewall state. Run `sudo ufw status verbose` or `sudo iptables -L -n -v` to see whether a firewall is active and whether the rules are appropriate.

Record every finding in a numbered list as you go. Note the file path, the exact bad value or line, and a severity rating (Critical, High, Medium, or Low) based on the potential impact.

Phase 2 — Remediation

For each finding, apply a specific fix and record the exact command or file edit in your runbook.

Wrap all remediation commands into a Bash script so another engineer could reproduce your hardening on a fresh image. Comment each block of the script clearly.

Phase 3 — Security Report

Your written report must follow this structure:

1. Executive Summary — Two to three short paragraphs written for a non-technical manager. State what was found, how serious the risk was, and whether the system is now safe.

2. Technical Findings — One entry per vulnerability. Each entry must include the finding name, severity, the evidence you collected (exact command output or log excerpt), and the remediation you applied.

3. Conclusion — Summarize the overall security posture before and after remediation, and recommend any follow-up actions.

4. Appendices — Attach your runbook Bash script(s).

Use precise, plain language. Avoid vague phrases like "some issues were found." Name the specific file, setting, or account involved in every finding.

Grading Criteria

Your instructor will assess the live VM and your report against a rubric: vulnerability discovery (40%), correct remediation (30%), report clarity and accuracy (20%), and professional presentation (10%). A score of 75% or higher with no critical vulnerability left unaddressed is required to pass.

Connection to Certification Objectives

As you work, keep your CompTIA Security+ and CySA+ objective checklists nearby. Log analysis, hardening configurations, least-privilege principles, and incident investigation appear directly on both exams. This lab is practice for the real job and for the test.

Key terms8

Attack surfaceThe total set of points on a system where an unauthorized user could attempt to enter or extract data; reducing unnecessary services shrinks the attack surface.
SUID (Set User ID)A Linux file permission bit that causes an executable to run with the privileges of the file's owner rather than the user who launches it; misused SUID binaries are a common privilege-escalation vector.
World-writable directoryA directory whose permissions allow any user on the system to create, modify, or delete files within it; a significant misconfiguration that attackers exploit to plant files or overwrite data.
Rogue accountA user account added to a system without authorization, often by an attacker to maintain persistent access after an initial compromise.
RunbookA documented, reproducible set of commands or procedures used to perform a specific operational task such as hardening a server; essential for consistent and auditable security work.
Executive summaryThe opening section of a security report written for non-technical decision-makers; it states key findings, risk level, and remediation status without deep technical detail.
Least privilegeA security principle that grants users and processes only the minimum access rights needed to perform their legitimate function, limiting the damage that can result from errors or compromise.
Log analysisThe systematic review of system and application log files to detect anomalies, suspicious activity, or evidence of a past or ongoing intrusion.
In class: Receive a deliberately misconfigured VM image containing weak SSH settings, unnecessary services, world-writable directories, a rogue user account, and injected log entries indicating a simulated intrusion; work independently to discover all issues using tools from the full course. · Apply remediation for every vulnerability found — correcting permissions, hardening SSH, disabling services, removing the rogue account, and applying firewall rules — capturing all commands in a reproducible runbook. · Write and present a two-to-three-page security report structured as an executive summary, technical findings (each finding with severity, evidence, and remediation), and a conclusion; include the Bash scripts written during remediation as appendices.
Materials: Misconfigured Ubuntu Server VM image provided by instructor, all tools covered in prior lessons, report template, CompTIA Security+ and CySA+ exam objective checklists used as self-review criteria
Check: Instructor scores report and live VM state against a rubric: vulnerability discovery (40%), correct remediation (30%), report clarity and accuracy (20%), and professional presentation (10%); pass = 75% overall with no critical vulnerability left unaddressed.

Practice check8

Answer each question, then check it. Nothing is recorded; this is your own practice.

CompTIA Security+: Threats, Attacks and Vulnerabilities
1. During discovery, you run `awk -F: '($3 == 0)' /etc/passwd` and see two entries: `root` and `support`. What does this indicate?
CompTIA Security+: Implementation
2. Which command correctly removes a rogue user account named `backdoor` and deletes its home directory in one step?
CompTIA CySA+: Security Operations
3. A security report finding states: 'SSH permits root login with password authentication on port 22.' Which severity rating is most appropriate?
CompTIA Security+: Implementation
4. You want to find all world-writable directories on a Linux system while staying within the local filesystem. Which command accomplishes this?
CompTIA CySA+: Security Operations
5. After hardening, you reload the SSH daemon with `sudo systemctl reload sshd`. What is the advantage of `reload` over `restart` in a production context?
CompTIA CySA+: Threat and Vulnerability Management
6. In `/var/log/auth.log` you find hundreds of entries showing failed password attempts for the root account from the same external IP address over 30 minutes, followed by one successful login. What type of attack does this pattern most likely represent?
CompTIA Security+: Implementation
7. Your runbook includes the command `sudo chmod o-w /tmp/shareddata`. What does the `o-w` argument specify?
ISC2 CC: Access Controls Concepts
8. The ISC2 CC credential emphasizes which foundational concept that is directly demonstrated by restricting unnecessary services and removing the rogue account in this lab?
Record this lesson on my transcript. Sign in with your key and enrollment email to record lessons (enroll free if you have no key). This page stays open to read and practise.
← Previous lessonProgram plan