After this lesson you can explain what a process is and identify suspicious process behaviour, describe how Linux user/group/permission models enforce the principle of least privilege, navigate the Linux file system and recognise security-sensitive paths that attackers target, explain what a service daemon is and why disabling unnecessary services matters, use core Linux monitoring commands to establish a system baseline, read and interpret key log files, and compare the Windows and Linux security models — with direct application to the OS reality of maritime OT workstations.
In Lessons 1 and 2, you learned what you are protecting (assets, CIA Triad) and how data moves between protected systems (TCP/IP, networks). This lesson addresses the third question: what happens inside the systems themselves?
Every attack that succeeds on a network eventually reaches a host — a server, a workstation, a control system. That host runs an operating system. The operating system manages processes (which programs are running), users (who can do what), the file system (where data lives), and services (what listens on which ports). Understanding these host-level concepts is the prerequisite for everything else in cybersecurity: writing effective detection rules, conducting forensic investigations, securing systems against privilege escalation, and understanding how attackers achieve persistence.
For maritime professionals, this lesson has a particular edge: the operating systems running on shipboard navigation and OT workstations are, in many cases, well past their end-of-life dates. Understanding what good OS security looks like makes it immediately clear why end-of-life OS on safety-critical systems is a serious problem — and why patching those systems is so operationally complex.
1. Processes — What's Running and Why It Matters
A process is a running instance of a program. When you open a browser, a navigation software application, or execute a malware payload — the operating system creates a process. Each process has its own memory space, open file handles, network connections, and execution context. Every process is assigned a PID (Process ID) — a unique integer used to reference it.
Processes have a parent–child hierarchy. When one process spawns another (its child), the child inherits certain properties from the parent — including the user context under which it runs. This relationship is fundamental to both system operation and attack technique. A word processor spawning a command shell is abnormal. A browser spawning PowerShell.exe is a major red flag — exactly the behaviour pattern that attackers use when exploiting document-based malware, and exactly what Endpoint Detection and Response (EDR) tools are designed to catch.
From a security standpoint, you need to understand both what processes should be running (the baseline) and how to identify ones that should not be. The process name alone is not reliable — attackers commonly name malware after legitimate Windows processes (svchost.exe, lsass.exe) or place legitimate-looking names in unexpected file system locations.
Security relevance — process anomalies: Threat hunters and EDR platforms look for: (1) unexpected parent–child relationships (e.g., svchost.exe → cmd.exe → powershell.exe — a common malware execution chain); (2) processes listening on network ports that should not be (a text editor with an active TCP listener); (3) processes running from world-writable locations like /tmp or C:\Users\Public; (4) processes with the same name as legitimate system processes but running from a different path or with a different parent. Each of these is a behavioural detection signal.
2. Users, Groups, and Permissions — Least Privilege in Practice
Linux enforces access control through a user/group/permission model that implements the principle of least privilege — each user, process, and service should have only the minimum access rights needed to perform its function, and no more. This is one of the most important security principles in computer science, and its violations are one of the most common paths to privilege escalation.
Every file and directory in Linux has three permission sets: one for the owner, one for the group, and one for everyone else (others). Each set has three bits: read (r = 4), write (w = 2), and execute (x = 1). Permissions are displayed in long listing format (ls -la) or set numerically (e.g., 755, 644).
The root user (UID 0) has unrestricted access to the entire system — bypassing all permission checks. Root is the equivalent of SYSTEM on Windows. Attackers always seek to escalate to root. The root account should never be used for routine operations; use sudo for specific privileged commands, which creates an audit trail in /var/log/auth.log.
A particularly dangerous permission is the SUID bit (Set User ID): a file with SUID set runs with the file owner's privileges, regardless of who executes it. A SUID binary owned by root effectively gives any user who can execute it temporary root-level access. Attackers search for misconfigured SUID binaries as a privilege escalation path. The command find / -perm -4000 2>/dev/null finds all SUID files on a system.
3. The Linux File System — Where Attackers Look and Defenders Monitor
Linux uses a single hierarchical file system rooted at /. Everything is a file — including processes (/proc), hardware devices (/dev), and configuration settings (/etc). Unlike Windows with its drive letter system, there are no C:\ or D:\ drives in Linux. All storage, including external drives, is mounted into the same tree.
Security analysts need to know the standard directory layout because attackers consistently target and abuse specific paths — and defenders write monitoring rules around them. Knowing what should be at a given path makes it easier to identify what should not be there.
4. Services and Daemons — What Runs in the Background
A service (called a daemon on Linux) is a background process started at boot time that provides a persistent function: a web server (nginx, Apache), an SSH server (sshd), a database engine (postgresql), a mail daemon (postfix), or a logging collector (rsyslog). Daemons typically end in 'd' by naming convention — sshd, crond, httpd, auditd.
Modern Linux uses systemd as the service manager and init system. Services are defined in unit files (typically in /etc/systemd/system/ or /lib/systemd/system/) and can be started, stopped, restarted, enabled (auto-start on boot), or disabled. Every service has a corresponding log stream accessible via journalctl.
From a security perspective, services are both a risk surface and a persistence mechanism. Every unnecessary service is an attack surface — an additional port listening, an additional codebase that may contain vulnerabilities, an additional process that could be exploited. The hardening principle is simple: if a service is not required, disable it.
Attackers install malicious services to achieve persistence — ensuring their access survives system reboots. A malicious systemd service file in /etc/systemd/system/ will be executed as root at every boot. Service enumeration is therefore a mandatory step in post-compromise forensics: compare the current service list against a known-good baseline and investigate any additions. Scheduled tasks (cron on Linux, Scheduled Tasks on Windows) are similarly abused for persistence.
5. Log Analysis and System Monitoring
Logs are the primary evidence source for both proactive security monitoring and reactive forensic investigation. Every authentication event, every process start, every file modified, every network connection — each generates log entries. Without logs, you cannot detect attacks in progress, reconstruct what happened after a breach, or demonstrate compliance with security requirements.
Effective log analysis requires knowing what normal looks like. A single failed SSH login is noise. One thousand failed SSH logins in two minutes from a single IP is a brute-force attack. Two failed logins followed by one successful login followed by immediate execution of id && whoami && cat /etc/shadow is a confirmed breach. Pattern recognition — establishing the baseline and detecting deviations — is the core skill of a security analyst.
In a SIEM (Security Information and Event Management) environment — covered in depth in Part 4 — logs from all these sources are collected centrally, parsed, and correlated across events from multiple systems. The host-level log knowledge in this lesson directly feeds into the detection rules and investigation workflows you will encounter in the SIEM lessons.
6. Windows vs Linux — Security Architecture Comparison
Both Windows and Linux are pervasive in security operations — Windows dominates corporate desktops and many maritime OT HMIs; Linux underpins servers, network devices, embedded systems, and the majority of security tooling. Understanding the security architecture of both is essential for any practitioner who works across mixed environments — which describes almost every maritime cybersecurity engagement.
- A process is a running program instance with its own PID, memory, and parent–child relationship. Anomalous parent–child relationships are a primary EDR detection signal.
- Linux enforces access via user/group/permission bits. The principle of least privilege (minimal required access) limits the blast radius of any compromise. SUID files are a privilege escalation risk.
- Security-sensitive paths: /etc (config, credentials), /var/log (forensic evidence), /tmp (world-writable, malware staging), /home (SSH keys, history), /proc (live process data).
- Services are attack surface and persistence targets. Disable everything not required. Enumerate services as a mandatory forensic step.
- Log analysis — knowing what normal looks like — is the foundation of both detection and incident response. Key logs: auth.log, syslog, auditd. Key commands: ss, lsof, journalctl.
- Windows and Linux have different privilege models, logging systems, remote access protocols, and persistence mechanisms — both appear in maritime environments.
- Maritime OT workstations frequently run end-of-life operating systems (Windows XP, Windows 7) that cannot be patched without voiding OEM certification. Compensating controls (isolation, monitoring, whitelisting) are the IACS UR E26 response to this reality.
Lesson 4 — Kali Linux and Security Testing applies the OS knowledge from this lesson in a security assessment context. Kali Linux is a Debian-based Linux distribution purpose-built for security testing. Understanding processes, file systems, services, and monitoring commands — everything in this lesson — is the prerequisite for using Kali Linux effectively and responsibly. You will also learn the critical ethical and legal framework for security testing, and why maritime OT environments require a much more cautious approach than standard IT penetration testing.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment