Linux Security and Hardening — DedSec Project

Purpose: Build a systematic approach to hardening Linux hosts and diagnosing security-relevant configuration.

Security model

Linux security is layered across identities, discretionary permissions, capabilities, mandatory access controls, kernel boundaries, services, packages, network policy, and application configuration.

Hardening is not a list of commands. Start with the system's role and remove what it does not need.

Accounts and privilege

Inventory local accounts, service identities, login shells, sudo policy, SSH access, and dormant accounts. Prefer named administrative users over shared accounts so actions remain attributable.

Avoid granting broad passwordless sudo access unless the workflow truly requires it. Narrow command delegation is better than making every operator equivalent to root.

Filesystem permissions

Review ownership and write permissions on:

• service configuration;
• startup files;
• scheduled-task definitions;
• SSH configuration and keys;
• secrets;
• application directories;
• log destinations;
• backup paths.

World-writable paths in privileged workflows deserve particular attention.

Services

For each listening service, document owner, purpose, bind address, authentication, data handled, and update mechanism. Disable unnecessary services rather than trying to harden software the host does not need.

SSH hardening

Prefer modern key-based authentication, restrict administrative access, review authorized keys, protect host keys, and log sign-ins. Whether password authentication is appropriate depends on environment and compensating controls, but internet-facing administration requires especially strong controls.

Software updates

Know which repositories the host trusts. Use supported distributions and security updates. For critical production systems, pair updates with inventory, testing, rollback plans, and maintenance windows.

Mandatory access control

SELinux and AppArmor can constrain processes beyond normal file permissions. Do not disable them merely because a policy blocks an application; determine whether the application or policy should change.

Linux capabilities

Capabilities split some traditional root powers into smaller privileges. Review unusual file and process capabilities. Grant only what a service requires.

Containers do not replace host hardening

Container isolation still relies on the host kernel. Protect the host, container runtime socket, image supply chain, runtime permissions, and orchestration credentials.

Logging and time

Central logs need consistent timestamps. Synchronize time, protect logging configuration, and retain security events according to operational and legal requirements.

Integrity monitoring

File hashes can detect change but do not explain whether it was authorized. Combine integrity data with package manager records, deployment logs, configuration management, and administrator change history.

Backups

Protect backups from the same credentials used to administer production. Test restore procedures and define recovery objectives.

Safe review commands

On systems you administer, benign checks may include identifying listeners, disk usage, processes, package status, service status, and permission metadata. Record outputs as evidence rather than making immediate changes you cannot reverse.

Hardening checklist

• Supported OS release.
• Security updates current.
• Minimal packages/services.
• Unique named accounts.
• Least-privilege sudo.
• SSH keys reviewed.
• Secrets protected.
• Firewall rules justified.
• Mandatory access control enabled where supported.
• Time synchronization working.
• Central logging present.
• Backups isolated and restored in tests.
• Configuration drift monitored.

Authorized lab

Create a disposable Linux VM or container host. Establish a baseline of accounts, services, listening ports, packages, and key configuration. Disable one unnecessary service, tighten one file permission, and add one logging control. Re-run the baseline and document exactly what changed.

Learning goal: hardening should produce measurable, explainable state changes.

Linux hardening in more depth

Start with the smallest required service set. Every daemon, package, account, scheduled task, network listener, and privileged helper adds maintenance responsibility. A hardened system is one whose purpose is understood and whose unnecessary capabilities have been removed.

Accounts and privilege

Disable or remove stale accounts, use groups deliberately, restrict sudo rules, avoid shared administrator credentials, and prefer logged privileged elevation over persistent root sessions. Service accounts should not have interactive shells unless required.

Services and network exposure

Inventory listeners, map each one to a package/process/owner, and decide which interface it should bind to. A host firewall should reflect intended service exposure, but application authentication and authorization are still required.

Filesystem and secrets

Protect SSH keys, service credentials, environment/config files, backups, and logs. World-writable paths and unsafe temporary-file handling deserve attention. Mount options and mandatory-access-control systems such as SELinux/AppArmor can provide additional containment where supported and correctly configured.

Updates and reboot reality

Patch management includes knowing when an update actually becomes active. Kernel, library, service, and container updates can require restart/reboot/redeployment. Track support lifecycle and test recovery before making risky production changes.

Guided study workflow

Before you begin

Modules 01, 06, and Linux/Termux basics.

Practice task

Harden a Linux test system you own: users, sudo, SSH policy, services, permissions, updates, firewall, logs, and backups. Capture before/after evidence.

Continue with

Recommended next modules: 23, 47, 48, 49.