Skip to content

Linux Security Basics

Most Linux servers are compromised through basic gaps, not exotic ones: weak credentials, exposed services, running as root when not needed, unpatched software, and overly broad permissions. Fix the basics first.

This is a defensive, operations-oriented cheat sheet. It assumes you are securing a system you administer.

The First Rule

Do not run things as root unless they truly need root. Every program, script, and service should run with the smallest effective privilege that still lets it do its job.

Common patterns: - Use a dedicated service account for a service. - Use sudo for specific administrative commands, not for a permanent root shell. - Avoid logging in as root over SSH if you can avoid it.

Users and Groups

View users and groups

cat /etc/passwd
cat /etc/group
id
who
w

/etc/passwd holds user account information. /etc/shadow holds hashed passwords and aging info, and should be readable only by root.

Create and manage users

sudo useradd -m -s /bin/bash newuser
sudo passwd newuser
sudo usermod -aG sudo newuser        # add to a privilege group on many distros
sudo usermod -L newuser              # lock account
sudo usermod -U newuser              # unlock account
sudo userdel -r newuser              # remove user and home directory

Groups matter

Groups are how you grant shared access without giving everyone the same permissions.

sudo groupadd data-readers
sudo usermod -aG data-readers alice

Check membership with:

groups alice
id alice

File Permissions

The permission model

Each file has: - An owner - A group - Permissions for owner, group, and others

Common permission bits: - r — read - w — write - x — execute for files, traverse for directories

View permissions

ls -l

Example:

-rw-r----- 1 appuser data-readers 4096 Sep  6 10:12 results.csv

Meaning: - Owner appuser can read and write. - Group data-readers can read. - Others have no access.

Change permissions

chmod 640 results.csv
chmod u+x script.sh
chmod -R g+rX /shared/data

Use X (capital) carefully: it sets execute only where it makes sense, such as directories or files that already have execute.

Change ownership

sudo chown appuser:data-readers results.csv
sudo chown -R appuser:appuser /var/lib/myapp

Do not make everything owned by root "to be safe." That usually breaks legitimate access and makes maintenance harder.

Sensitive permission mistakes

  • World-writable files and directories
  • Private keys or credentials readable by others
  • Data directories open to everyone
  • Executables that should not be executable

Check broadly writable paths:

find / -perm -002 -type f 2>/dev/null

Use such searches carefully; they are diagnostic, not a substitute for understanding the system.

sudo

sudo lets permitted users run commands as another user, usually root.

Basics

sudo whoami
sudo -l                          # see what your account may run
sudo less /etc/shadow            # example of a privileged command

Good sudo habits

  • Prefer specific sudo permissions over blanket ALL.
  • Require a password unless there is a strong operational reason not to.
  • Do not share a single privileged account.
  • Review /etc/sudoers or drop-in files in /etc/sudoers.d/.
  • Use visudo to edit sudoers configuration safely.
sudo visudo

sudoers example idea

A safe configuration approach is to grant only what a role needs. For example, a deploy user may be allowed to restart one service and read one log directory, but not to become root freely.

Exact rules depend on your environment; the principle is to narrow the blast radius.

SSH

SSH is one of the most important entry points to a server. Harden it.

Key-based authentication

Prefer SSH keys to passwords where practical.

ssh-keygen -t ed25519
ssh-copy-id user@host

Protect private keys with a passphrase, and restrict their file permissions:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Hardening sshd_config

Common defensive settings in /etc/ssh/sshd_config or a drop-in under /etc/ssh/sshd_config.d/:

  • Disable root login if you do not need it
  • Disable password authentication if keys are in use
  • Limit which users or groups may log in
  • Use strong key types and avoid obsolete algorithms
  • Consider disabling unused features

After changes:

sudo sshd -t          # test configuration syntax
sudo systemctl restart sshd

Do not restart SSH until you have tested that you can still log in another way, or you risk locking yourself out.

SSH hygiene

  • Use separate keys for separate purposes when it helps.
  • Remove old or unused keys from authorized_keys.
  • Treat authorized_keys like a privilege list; audit it periodically.
  • Use a firewall or network rules to limit who can reach SSH.
  • Consider bastion hosts or VPNs for sensitive environments.

Authentication and Account Lockout

  • Disable or remove accounts that are no longer needed.
  • Lock accounts that should not currently be used.
  • Use MFA where the system and access path support it.
  • Watch for repeated authentication failures in logs.

Repeated failed logins can mean probing or brute-force attempts, not just typos.

Process Security

Run services as non-root

A service that does not need root should not run as root. If it is compromised, the attacker inherits its privileges.

Check what is running

ps aux
systemctl status sshd
systemctl list-units --type=service

Inspect listening ports

sudo ss -tlnp
sudo lsof -i -P -n

Know which services are exposed and why. If you see something unexpected, investigate before ignoring it.

Limit what a process can reach

Where available and appropriate, use sandboxing and confinement mechanisms. The exact tools vary by distro and workload, but the idea is consistent: reduce what a compromised process can see and do.

Updates and Patching

Keep the system and its packages updated. Unpatched software is one of the easiest ways to turn a small mistake into a real compromise.

sudo apt update && sudo apt upgrade     # Debian/Ubuntu-style
sudo dnf upgrade                         # Fedora/RHEL-style
sudo yum update                          # older RHEL-style

Updates should be tested in non-production environments when possible, but security updates should not be ignored indefinitely. Balance caution with timeliness.

Firewalls

A host firewall reduces exposed services even if the network is misconfigured.

Common tools: - ufw on many Debian/Ubuntu systems - firewalld on many Fedora/RHEL systems - iptables/nftables at a lower level

ufw example

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

Only allow what you need. A default-deny posture is safer than allowing "just in case."

Be careful not to lock yourself out of remote access when enabling a firewall. Test rules in a way that preserves access.

Logs

Logs are where you notice intrusion attempts, misconfigurations, and abuse.

Useful log sources

  • Authentication: /var/log/auth.log or /var/log/secure
  • System messages: /var/log/syslog or /var/log/messages
  • Journal: journalctl
  • SSH and sudo activity
  • Application logs

Quick views

sudo tail -f /var/log/auth.log
sudo journalctl -u sshd
sudo journalctl -xe
grep " Failed" /var/log/auth.log

What to watch for

  • Repeated failed logins
  • Unexpected sudo usage
  • New or modified users/groups
  • Services starting or stopping unexpectedly
  • Logins from unusual locations or at unusual times
  • Outbound connections you did not expect

Correlation across logs is more useful than any single line.

Filesystem and Backup Hygiene

  • Back up configuration and data, and verify restores.
  • Keep secrets out of world-readable locations.
  • Use encryption for sensitive data at rest where appropriate.
  • Separate data, logs, and executables when it reduces risk.
  • Remove old credentials, keys, and accounts you no longer use.

A backup you have never tested restoring is not a reliable backup.

Basic Incident Hygiene

If you suspect a compromise:

  1. Preserve evidence if you can, but prioritize containment.
  2. Do not quietly assume it is "just a glitch."
  3. Check authentication logs, sudo usage, active sessions, and recent changes.
  4. Rotate credentials that may have been exposed.
  5. Compare the current system state against a known-good baseline where possible.
  6. Escalate according to your incident process.

Do not start by making a pile of changes that destroys the evidence you might need.

Common Mistakes

  • Running services as root "because it is easier"
  • Enabling password authentication when keys would be safer
  • Leaving unused accounts, keys, or services enabled
  • Opening firewall ports and forgetting them
  • Ignoring logs because "nothing has happened yet"
  • Hardcoding credentials in scripts or config files
  • Sharing private keys between machines without a clear reason
  • Failing to test backups and recovery procedures

A Minimal Server Hardening Checklist

  • Unique user accounts with least privilege
  • SSH key authentication, root login disabled if appropriate
  • Unnecessary services disabled or removed
  • Firewall allowing only required ports
  • Regular updates
  • Logging enabled and reviewed
  • Backups tested
  • Secrets stored securely, not in code or configs everyone can read
  • No shared admin accounts unless you have a very good reason

Official Documentation

  • Your distribution's security and administration documentation is the most relevant source.
  • SSH: man sshd_config, man ssh, man ssh-keygen
  • sudo: man sudo, man sudoers, man visudo
  • System logs and journal: man journalctl
  • Firewall tools: documentation for ufw, firewalld, nftables, or iptables as appropriate to your system

Last Updated

2026-09-06 — Initial version.