Linux · Lesson 01
Linux Competition Workflow
Turn the overall competition strategy into a practical Linux workflow: understand the image, identify the distribution, establish a baseline, classify evidence, make controlled changes, and verify the final state.
This lesson is the map for the rest of the Linux pathway. It teaches how professionals reason about Linux security before later lessons go deeper into users, permissions, packages, services, networking, persistence, logs, and administration.
Lesson Snapshot
Learning objectives
What this workflow should help you do
Translate the overall CyberPatriot strategy into a Linux-specific competition workflow.
Read the scenario before making changes and identify required users, services, applications, networking, and forensic questions.
Build a useful Linux baseline using read-only inspection commands before broad hardening begins.
Separate high-confidence fixes from findings that require investigation, dependency review, or teammate coordination.
Make controlled Linux changes that preserve required functionality and forensic evidence.
Verify the final Linux state from both the configuration and user/service perspective.
Core idea
Linux is not a list of commands
A competition image is a functioning system with identities, services, packages, permissions, network paths, configuration, evidence, and dependencies. Commands are tools for understanding and changing that system, not substitutes for reasoning.
Linux risk
Short commands can have large consequences
A single command can change ownership, permissions, packages, firewall rules, services, or account access across the system. Strong Linux work starts with scope, evidence, and a verification plan before the command is run.
Step 1 · Understand the image
Read first, then inspect
Before the terminal becomes a hardening tool, it should be an observation tool. Start by understanding what the image is supposed to do and which parts of Linux are required to support that mission.
Scenario requirements
Identify authorized users, administrators, required services, software, network access, remote-management needs, restrictions, and forensic questions before changing the image.
Identity
Review users, groups, sudo privilege, login shells, home directories, locked accounts, and anything that conflicts with the scenario.
Services
Check running and enabled services, especially anything required by the scenario such as SSH, web services, logging, networking, or databases.
Software
Inventory installed packages, repository configuration, update posture, and software that appears required, unnecessary, unsupported, or unfamiliar.
Network exposure
Review interfaces, routes, listening ports, UFW status, required services, remote access, and DNS behavior before changing network controls.
Evidence
Read forensic questions early and preserve logs, account state, process information, scheduled tasks, configuration files, timestamps, and command output that may matter later.
Step 2 · Establish a baseline
Know the current Linux state before changing it
A baseline gives the team something to compare against after remediation. The commands below are primarily inspection commands. They help answer what is present, what is active, what is exposed, and what needs more investigation.
System identity
Confirm which system and distribution you are actually working on before assuming a tool, package, or default behavior.
hostnamectlcat /etc/os-releaseuname -aUsers
Establish which accounts exist, which shells they use, and which identities need closer review.
getent passwdawk -F: '{print $1, $3, $7}' /etc/passwdGroups and sudo
Administrative privilege is one of the highest-impact parts of a Linux image and should match the scenario.
getent groupgetent group sudosudo -lServices
A service may be required, unnecessary, misconfigured, or unfamiliar. The baseline tells you what is actually active.
systemctl --type=service --state=runningsystemctl list-unit-files --type=serviceProcesses
Running processes show which users, executables, and services are active right now and can reveal clues that need investigation.
ps auxps -eo user,pid,ppid,cmd --sort=userNetwork
Before changing firewall or service settings, understand interfaces, routes, listening ports, and network dependencies.
ip addrip routess -tulpnFirewall
Know whether UFW is active, what the default policy is, and which rules protect or expose required services.
sudo ufw status verbosePackages
Installed software and package sources can affect both security posture and required functionality.
apt list --installed 2>/dev/nullapt-cache policyScheduled execution
Scheduled jobs and timers may be legitimate maintenance or persistence. Their purpose should be understood before changing them.
crontab -lsudo ls -la /etc/cron.*systemctl list-timers --allLogs
Recent logs can explain service failures, authentication activity, configuration changes, and forensic clues.
journalctl -p warning --since todaysudo journalctl --since todayRead-only command set
Start with commands that describe the system
cat /etc/os-releaseIdentify the distribution and release before assuming Ubuntu- or Mint-specific defaults.
Changes system: No
getent passwdList account records using the system account database.
Changes system: No
getent group sudoInspect membership of the sudo group on systems that use it for administrative privilege.
Changes system: No
systemctl --type=service --state=runningList currently running systemd services.
Changes system: No
ps auxInspect running processes, users, resource usage, and command names.
Changes system: No
ss -tulpnInspect listening TCP/UDP sockets and associated processes where permissions allow.
Changes system: No
sudo ufw status verboseDisplay UFW status, default policy, and configured rules.
Changes system: No
systemctl list-timers --allReview systemd timers that may schedule recurring execution.
Changes system: No
Important note about sudo
Elevated inspection still deserves care
Some read-only commands need sudo to reveal complete information. Using sudo does not automatically make a command destructive, but it does mean the shell has elevated privilege. Read the command carefully before pressing Enter and avoid copying unfamiliar commands blindly.
A useful habit
Ask: “Is this command querying state, or changing state?” If you are not sure, check the manual page or help output first.
man command-nameStep 3 · Prioritize
Turn findings into decisions
A baseline usually creates more findings than the team can solve at once. Classification keeps the team from spending ten minutes on an uncertain process while a confirmed sudo or firewall problem remains unresolved.
Do Now
A clear scenario conflict or confirmed weakness with strong evidence, manageable risk, and a result you can verify quickly.
Example
The scenario names Morgan as the only administrator, but a confirmed standard user is also in the sudo group.
Investigate
A potentially important finding where the purpose, dependency, or evidence is still incomplete.
Example
An unfamiliar root-owned process is running, but its executable belongs to a package you have not identified yet.
Coordinate
A change may affect networking, remote access, a required service, another teammate, or evidence needed elsewhere.
Example
Changing UFW rules while SSH must remain available to an authorized administrator.
Revisit
The task is low-confidence, blocked, or consuming too much time compared with higher-value work.
Example
A strange log pattern needs deeper research while several confirmed account and permission problems are still unresolved.
Done / Verify
The configuration change is complete, but the team still needs to prove both the security improvement and required functionality.
Example
A user was removed from sudo and now needs privilege verification and an authorized login check.
Before changing anything
Eight questions
What exactly is wrong right now?
What Linux evidence proves it?
What does the scenario require?
Is the affected user, service, package, process, file, or network path required?
Could this change break SSH, networking, an application, package management, or another service?
Could this alter or destroy forensic evidence?
What is the least disruptive fix?
How will I verify both the security state and required functionality afterward?
Linux tool map
Know which tool answers which question
Terminal
Primary workspace for inspection, inventory, verification, and controlled administration.
systemctl
Inspect service state, enablement, dependencies, startup behavior, and recent failures.
journalctl
Review systemd journal evidence for services, authentication activity, errors, boots, and other events.
getent
Query users and groups through the system account databases without manually parsing every file.
ss
Inspect listening sockets and network exposure before changing services or firewall rules.
ip
Review addresses, interfaces, routes, and other current network state.
UFW
Review and manage host firewall policy on systems where UFW is the configured frontend.
APT
Inspect installed packages, repositories, updates, and package metadata on Ubuntu and Linux Mint.
Step 4 · Remediate carefully
Linux rewards precise changes
The goal is not to make the system look “locked down.” The goal is to correct confirmed weaknesses while keeping the scenario-required mission intact. The safest fix is usually the narrowest fix that addresses the evidence.
Do not delete unfamiliar accounts first
Confirm whether the account is human, service-related, package-created, or required by the scenario before disabling or removing it.
Do not disable unfamiliar services first
Identify the unit, package, dependencies, listening ports, and scenario role before stopping or disabling it.
Do not chmod recursively without scope
Broad recursive permission changes can break applications, SSH, service accounts, package-managed files, and user access.
Do not remove packages by name alone
Confirm whether the package is required directly or as a dependency before removal.
Do not flush firewall rules blindly
Required SSH, web, DNS, or application access can disappear if network controls are changed without a baseline.
Do not clear logs
Logs may answer forensic questions or explain service and authentication behavior. Preserve them unless the scenario explicitly requires otherwise.
Step 5 · Verify
A successful command is not proof of a successful fix
Verification asks whether the security state improved and whether the required system still works. Linux makes it easy to change configuration quickly, so disciplined teams re-query the state and test the dependent function afterward.
Configuration
Re-query the user, group, service, package, firewall rule, permission, or configuration file and confirm the intended state actually changed.
Security
Confirm the original exposure or weakness is reduced rather than merely shifted elsewhere.
Functionality
Test the authorized user, required service, SSH path, application, DNS resolution, or other scenario-required workflow.
Evidence
Confirm logs, timestamps, configuration history, or other artifacts needed for forensics were preserved.
Team
Record important changes and communicate anything that may affect another teammate or a later verification step.
Worked fictional round
How the workflow fits together
Scenario
A fictional Ubuntu image must keep SSH available for Morgan, keep an internal web service running, preserve Avery and Riley as standard users, and answer a forensic question about a root-owned scheduled command.
Baseline
The team identifies the distribution, users, sudo membership, running services, listening ports, UFW status, packages, processes, timers, cron locations, and recent logs before changing anything.
Prioritize
An unauthorized sudo membership goes to Do Now. A broad SSH firewall rule goes to Coordinate. The unknown scheduled command goes to Investigate because evidence must be preserved first.
Remediate
The team removes only the unnecessary sudo privilege, narrows SSH exposure without disabling the required service, and leaves the scheduled command unchanged until its purpose and evidence are documented.
Verify
The corrected user no longer has sudo access, Morgan can still connect through the authorized SSH path, the web service still responds, UFW remains active, and the scheduled-task evidence is preserved.
Common workflow mistakes
What strong Linux teams avoid
Starting with a hardening script
Bulk scripts can change many settings before the team understands required users, services, packages, or networking.
Treating every UID as a normal user
Linux systems contain human accounts and many service or system identities. Context matters before account changes.
Stopping unfamiliar services
Unknown does not mean unnecessary. Identify the package, dependency, port, and scenario purpose first.
Using recursive permission fixes
Commands such as broad recursive chmod or chown can damage service, package, and application behavior.
Locking yourself out of SSH
Changing sshd configuration, user authorization, firewall rules, or the service itself without coordinated verification can remove required access.
Ignoring logs until the end
Authentication, service, sudo, package, and scheduled-execution evidence may be changed or lost during remediation.
End-of-round Linux review
Finish in a known-good state
Re-read the Linux scenario and requirements.
Confirm the distribution and system identity.
Confirm every authorized user still exists.
Confirm sudo or administrative privilege matches the scenario.
Confirm required services remain running and enabled as appropriate.
Confirm important packages and applications remain installed.
Confirm required network interfaces, routes, DNS, and listening services work.
Confirm firewall state and required access paths.
Review scheduled jobs, timers, and startup findings.
Review important logs and forensic evidence.
Re-query every high-impact change.
Test SSH or other required remote access if applicable.
Test required applications or services from the user/client perspective.
Document unresolved Investigate items.
Finish in a known-good, secure, functional Linux state.
Reflection
Check your reasoning
Question 1
Why should the distribution be identified before broad Linux hardening begins?
Question 2
Why is an unfamiliar user, service, package, or process an Investigate item instead of automatically malicious?
Question 3
What makes a Linux change high-impact even when the command itself is short?
Question 4
Why should SSH and firewall changes be coordinated?
Question 5
Why are logs and scheduled-execution artifacts important to both security and forensics?
Question 6
What does complete verification look like after a Linux change?
The lesson to carry forward
Linux expertise is not measured by how many commands you can run. It is measured by how well you understand the system, justify the change, preserve required functions, and prove the result.