CyberPatriot Resources · Resource 04

Linux: Ubuntu & Mint

Use official Ubuntu, Linux Mint, systemd, and manual-page references to understand users, privilege, permissions, services, logs, remote access, firewalling, and evidence.

Linux administration can change a large amount of system state with a small command. Check scope, dependencies, and side effects before making broad changes.

Linux resource rule

Understand the command before running the command

Use documentation whenever you are uncertain about syntax, scope, dependencies, or reversibility.

Official references

What to study

Users & Groups

Understand /etc/passwd, /etc/shadow, and /etc/group.
Use getent to inspect users and groups.
Distinguish normal users from system and service accounts.
Review sudo access before changing privilege.

Permissions

Understand owner, group, and other permission bits.
Know the difference between chmod and chown.
Treat recursive permission changes as high risk.
Investigate world-writable files in context.

Services

Use systemctl to inspect services and startup state.
Review unit files and overrides when behavior is unexpected.
Understand dependencies before disabling unfamiliar services.
Verify required applications after service changes.

Logs & Evidence

Use journalctl for systemd-managed logs.
Review relevant files under /var/log.
Correlate authentication, service, process, and network evidence.
Keep system and timestamp context with findings.

SSH & Remote Access

Confirm whether SSH is required by the competition scenario.
Review sshd service state and configuration.
Check authentication settings and listening exposure.
Verify approved remote access after any change.

Firewall & Networking

Use ip and ss to understand network state.
Use UFW when it is the intended firewall interface.
Remember that UFW is a frontend for Linux packet filtering.
Verify required connectivity after firewall changes.

Observation command reference

id

Show user identity and group membership.

getent passwd

Review account entries.

getent group

Review groups and membership.

sudo -l

Show allowed sudo privileges for the current user.

ps aux

Review running processes.

pstree -ap

View parent-child process relationships.

systemctl --type=service

Review systemd service units.

systemctl status NAME

Inspect one service.

journalctl -u NAME

Review logs for one systemd unit.

ss -tulpn

Review listening TCP and UDP sockets.

ip addr

Review interface addressing.

ip route

Review routing state.

ufw status verbose

Review UFW status and rules.

stat FILE

Review file metadata.

find

Locate files using ownership, permissions, time, path, and other attributes.

Important Linux paths

/etc/passwd

User-account definitions and user IDs.

/etc/shadow

Protected password and account-aging information.

/etc/group

Group definitions and membership.

/etc/sudoers

Primary sudo policy configuration.

/etc/sudoers.d/

Additional sudo policy files.

/etc/ssh/sshd_config

OpenSSH server configuration on many Linux systems.

/etc/systemd/system/

Local systemd units and overrides.

/etc/cron.*

System scheduled-task locations.

/var/log/

Traditional service and operating-system logs.

Using references during competition work

An account looks unauthorized

1

Compare the account with the approved-user list.

2

Review UID, groups, shell, home directory, and privilege.

3

Determine whether it is a user, system account, or service account.

4

Preserve useful authentication evidence.

5

Make only the justified change and verify required access.

A service looks suspicious

1

Identify the service, executable, startup state, and listener.

2

Check whether required functions depend on it.

3

Review journal and configuration evidence.

4

Do not disable it only because the name is unfamiliar.

5

Verify mission functionality after any change.

Permissions look too open

1

Record the current owner, group, and permission mode.

2

Determine the intended purpose of the object.

3

Check whether an application depends on the existing permissions.

4

Avoid broad recursive chmod or chown changes.

5

Test the affected service or application afterward.

SSH exposure looks wrong

1

Confirm whether SSH is required.

2

Check sshd service and listening state.

3

Review authentication-related configuration.

4

Review firewall exposure.

5

Test the approved remote-access path after changes.

Weak habit vs better habit

Weak habit

Delete unfamiliar users immediately.

Better habit

Classify the identity, compare it with the scenario, and check privilege and dependencies first.

Weak habit

Use chmod -R to fix permissions quickly.

Better habit

Change only the specific file or directory whose intended permissions are understood.

Weak habit

Disable every unfamiliar service.

Better habit

Inspect the service, process, listener, dependencies, logs, and mission purpose first.

Weak habit

Restart when the system behaves strangely.

Better habit

Collect process, service, log, configuration, and network evidence before considering a reboot.

Weak habit

Disable SSH because remote access is dangerous.

Better habit

Confirm mission requirements and secure only the exposure or authentication settings justified by evidence.

Weak habit

Run a remembered command without checking it.

Better habit

Use the man page or official documentation when the command's scope or side effects are uncertain.

Linux resource checklist

01

Use official Ubuntu, Mint, systemd, and man-page references first.

02

Classify accounts before changing or removing them.

03

Review sudo and group membership when evaluating privilege.

04

Avoid broad recursive chmod and chown operations.

05

Understand service purpose and dependencies before disabling it.

06

Use journalctl and appropriate log files to support conclusions.

07

Preserve evidence before removing suspicious persistence.

08

Confirm whether SSH is required before changing remote access.

09

Map listeners to owning processes and services.

10

Review UFW or the system's intended firewall carefully.

11

Verify required services and network access after changes.

12

Let the competition scenario determine what must remain functional.