Basic System Security

Why Basic Security Matters

Linux has a strong security model, but a default installation is rarely “secure enough” on its own. Basic system security is about:

• Reducing the attack surface (fewer ways to get in)
• Limiting damage when something goes wrong
• Detecting and responding to suspicious activity

For beginners, the goal is not to build a perfectly hardened system, but to follow a few consistent habits and use the core tools correctly.

This chapter gives you a practical baseline that works on most Linux systems, and prepares you for the more advanced security topics in later parts of the course.

Fundamental Security Concepts

Threat model (what are you protecting from?)

Before changing settings, know what you’re protecting against. Typical threats for a beginner system:

• Casual network scans and automated attacks from the internet
• Weak passwords being guessed or leaked
• Malware or malicious scripts you accidentally run
• Curious local users on a shared machine

You will usually not defend against advanced, targeted attackers at this stage. Your configuration choices should be “good enough” for realistic threats, not perfect.

Ask yourself:

• Is this machine exposed to the internet, or only a local network?
• Do other people have user accounts?
• Is there critical data (password vaults, SSH keys, personal documents)?

Your answers influence how strict you should be (for example, whether to allow SSH at all, how strong passwords must be, etc.).

The principle of least privilege

Least privilege means: every user, program, and service should have only the permissions they truly need—no more.

Concrete examples:

• Use sudo for administrative commands instead of logging in as root
• Run a web server as a dedicated low-privilege user, not as root
• Restrict which users can run sudo, and what they can do with it

You’ll apply this principle to users, services, and remote access tools like SSH.

Security is a process, not a setting

There is no “secure” checkbox. Security requires:

• Initial configuration (what you’ll learn here)
• Regular updates
• Occasional review (logs, user accounts, open services)
• Adjustments as your system’s role changes

Build the habit of thinking “How can this be misused?” whenever you enable a new feature or install new software.

Building a Secure Baseline

Keep the system updated

Unpatched software is one of the most common ways systems get compromised.

Basic rules:

• Enable automatic security updates where possible
• Manually check for updates on a schedule (for example, weekly)

Typical commands:

• Debian/Ubuntu-based:

  sudo apt update
  sudo apt upgrade

• Fedora/RHEL:

  sudo dnf upgrade

• Arch:

  sudo pacman -Syu

On desktop systems, consider enabling automatic updates (using your distro’s tools) at least for security fixes.

Install only what you need

Every extra package is:

• More code that could contain vulnerabilities
• Possibly a new network-facing service

Good practices:

• Avoid installing random software from untrusted websites
• Prefer your distribution’s official repositories
• Periodically remove unused packages and services

Example (Debian/Ubuntu):

sudo apt remove package-name
sudo apt autoremove

Less software → smaller attack surface.

User Accounts and Access

Avoid logging in as root

Direct root logins are dangerous:

• Any mistake can severely damage the system
• Attackers who obtain your credentials immediately get full control

Recommended approach:

• Use a normal user account for daily work
• Use sudo to run administrative commands

Example:

sudo apt install htop
sudo systemctl restart ssh

Check who is allowed to use sudo (varies by distro, but often membership in a group like sudo or wheel):

getent group sudo
getent group wheel

Limit that group to only trusted users.

Use strong, unique passwords

Basic guidelines:

• At least 12–16 characters
• Mix of letters, numbers, symbols
• Avoid dictionary words, personal info, or simple patterns
• Use a password manager so you don’t reuse passwords

On multi-user or server systems, enforce stronger policies (covered more deeply in the “Password policies” chapter), but as a baseline:

• Never share your account password
• Never store passwords in plain text files on the system

Lock or remove unused accounts

Unnecessary accounts are an entry point if their password gets guessed or leaked.

Steps:

1. List user accounts (human users usually have UID ≥ 1000):

   getent passwd

2. Identify:
• Old user accounts you no longer need
• Test or default accounts created by some software
3. Remove or disable them:
• Lock an account (prevent logins but keep files):

     sudo usermod -L username

• Remove an account (optionally with its home directory):

     sudo userdel username          # keep home dir
     sudo userdel -r username       # remove home dir too

Do not remove system/service accounts (UIDs usually below 1000) unless you are sure what they are used for.

Screen locking and physical access

If someone can sit at your keyboard, many protections become weaker.

Basic habits:

• Lock your screen when leaving (Super+L in many desktops)
• Set an automatic screen lock timeout in your desktop settings
• On laptops, require password on resume from suspend/sleep

If you share the computer with others, give them their own user accounts instead of sharing yours.

Basic Network Security

Understand your exposure

Determine if the system is reachable from outside:

• Is it directly connected to the internet, or behind a router?
• Does your router forward any ports to this machine?
• Is this a VPS or cloud server with a public IP?

On a personal home desktop behind a NAT router, your exposure is usually lower than on a cloud server with a public IP. Still, do not rely only on the router for defense.

See which services are listening

Before configuring a firewall, know what’s listening on network ports.

Common tools:

sudo ss -tuln     # TCP/UDP listening sockets, numeric addresses

Look for lines like:

• *:22 → SSH
• :80 or :443 → HTTP/HTTPS
• 127.0.0.1:xxxx → only accessible locally (lower risk)

If you see services you don’t need, disable or remove them (details on service management are covered in the systemd chapter; here the idea is: fewer listening services → less attack surface).

Using a host firewall

Host firewalls restrict which network connections are allowed. For beginners, two main tools:

• ufw (common on Ubuntu and related systems)
• firewalld (common on Fedora, RHEL, some others)

You’ll learn in depth about firewalls in a later chapter; here we stick to basic use.

Simple UFW usage

Check status:

sudo ufw status verbose

Typical secure baseline on a server:

• Allow SSH (if you need remote access)
• Allow service ports you actually use (e.g., 80/443 for a web server)
• Deny everything else

Example:

sudo ufw allow OpenSSH        # or: sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

On a desktop, you might:

• Enable it
• Allow only outgoing connections by default
• Allow specific incoming services if you run them

Simple firewalld usage

Check running state:

sudo firewall-cmd --state

List allowed services in the default zone:

sudo firewall-cmd --list-all

Add basic rules (permanent + reload):

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

If you don’t need SSH on a machine, don’t open it.

SSH Security Basics

SSH is the standard protocol for remote command-line access. Because it often exposes your system directly to the internet, securing it is essential.

Decide whether you need SSH

If you never administer the machine remotely:

• Don’t enable the SSH server at all
• Or disable it if your distro installed it by default:

sudo systemctl disable --now ssh    # Debian/Ubuntu service name
sudo systemctl disable --now sshd   # Fedora/RHEL/Arch service name

No SSH service → one less major attack surface.

Basic SSH hardening steps

If you do use SSH:

1. Use strong passwords or, preferably, key-based authentication
2. Avoid root login over SSH
3. Optionally change defaults to reduce automated noise

Disable root login via SSH

Edit the SSH server configuration file, typically /etc/ssh/sshd_config:

Look for or add:

PermitRootLogin no

Then reload the service:

sudo systemctl reload sshd

Log in as a normal user, then use sudo for admin tasks.

Prefer SSH keys over passwords

High-level steps (details belong to the SSH chapter, but you should know the basic idea):

1. On your client machine, create a key pair:

   ssh-keygen -t ed25519

2. Copy the public key to the server:

   ssh-copy-id user@server

3. Once confirmed working, you can disable password authentication in /etc/ssh/sshd_config:

   PasswordAuthentication no

and reload:

   sudo systemctl reload sshd

With passwords disabled, attackers cannot brute-force SSH passwords, they must steal your private key (which you should protect with a passphrase).

Reduce brute-force noise

Automated bots will often try to log in over SSH repeatedly. To slow them down or block them:

• Use a firewall to limit who can reach SSH (for example, your own IP range)
• Consider tools like fail2ban (monitors logs and blocks attackers temporarily via firewall rules)

Even a rule like “only allow SSH from my office/home IP range” dramatically reduces risk, if practical for you.

Using Linux Security Frameworks (Overview)

Two kernel-level mechanisms commonly found on Linux systems are SELinux and AppArmor. They enforce mandatory access controls (MAC) beyond traditional Unix permissions.

This chapter focuses on knowing they exist and how to avoid breaking your system by accident; deeper coverage appears in their dedicated chapter.

Check whether SELinux or AppArmor is active

• On SELinux-based systems (Fedora, RHEL, CentOS, some others):

  getenforce
  # Output: Enforcing / Permissive / Disabled

• On AppArmor-based systems (Ubuntu, Debian, etc.):

  sudo aa-status

If your system uses one of these, changing its mode (e.g., disabling it) can have security consequences. For basic administration, you should:

• Avoid disabling SELinux/AppArmor without a good reason
• If something appears blocked, check logs first (often in journalctl or under /var/log/)

For beginners, the most important habit is: don’t casually turn these systems off to “make things work” without understanding the cost.

System Integrity and Malware Basics

Be cautious with sources and scripts

Most compromises on personal Linux systems come from:

• Running untrusted scripts you found online
• Installing random .sh or .run files
• Adding third-party repositories without understanding who maintains them

Safer habits:

• Prefer official repositories over custom installers
• Read scripts before running them, especially if they use sudo
• Avoid commands that start with curl ... | sudo bash unless you truly trust the source and understand the script

Basic file integrity awareness

You don’t need full-blown integrity monitoring at this stage, but be aware of:

• System binaries in /bin, /usr/bin should not be modified casually
• Configuration files in /etc should change only when you or trusted software changes them

If you suspect unwanted changes:

• Check package integrity (commands differ by distro; often something like verifying installed packages against repositories)
• Inspect configuration files’ modification times with ls -l or stat

Later chapters will introduce dedicated file integrity tools; here, the key is to be suspicious of unexpected changes.

Malware on Linux

Linux malware exists, but it usually requires:

• You running something malicious
• Or a vulnerable service that’s exposed and unpatched

Basic protection:

• Stay updated
• Minimize exposed services
• Don’t run unknown binaries or scripts

Antivirus is less common on Linux desktops, but:

• It can be useful on mail/file servers to protect Windows clients
• It may be required by some corporate policies

For most beginners managing personal Linux systems, solid configuration and habits are more impactful than installing antivirus.

Logs and Basic Incident Awareness

Know where to look

If something suspicious happens (failed logins, weird errors), logs often hold the clues.

Common locations:

• journalctl (systemd journal; primary logging interface on systemd systems)
• Files under /var/log/:
• /var/log/auth.log or /var/log/secure for authentication events
• /var/log/syslog or /var/log/messages for general system logs

Examples:

• View recent auth events:

  sudo journalctl -u sshd --since "1 hour ago"

• View failed login attempts (distro-specific paths):

  sudo grep "Failed password" /var/log/auth.log
  # or:
  sudo grep "Failed password" /var/log/secure

Signs of trouble

Things worth investigating:

• Many repeated failed SSH logins (common, but still worth understanding)
• Unknown user accounts suddenly appearing
• Sudden changes in startup behavior or new services listening on the network
• High CPU or network activity from unknown processes

At this basic level, your goal is simply:

• Notice when something looks off
• Check logs to gather information
• If necessary, disconnect the system from the network while you investigate further (or seek help)

Practical Checklist for a New System

Use this as a quick starting point for a newly installed Linux machine:

1. Update the system

   # Example for Debian/Ubuntu
   sudo apt update && sudo apt upgrade

2. Create a non-root user (if needed) and use sudo
   Ensure you have an unprivileged account and that root login is not used for routine work.
3. Set strong passwords
   Use a password manager; change any weak/default passwords.
4. Remove or lock unused accounts

   getent passwd
   sudo userdel -r olduser          # if appropriate

5. Check running services and network exposure

   sudo ss -tuln

Disable services you don’t need.

6. Enable and configure a firewall
• For UFW:

     sudo ufw allow OpenSSH
     sudo ufw enable
     sudo ufw status

• Or configure firewalld similarly.

7. Secure SSH if used
• Disable root login
• Use SSH keys instead of passwords where possible
• Consider limiting SSH to trusted IPs
8. Confirm SELinux/AppArmor status (if present)
   Don’t disable them casually; note that they’re part of your defense.
9. Set up screen lock and physical security basics
   Require a password on resume, lock screen on inactivity.
10. Familiarize yourself with logs
    Run:

    sudo journalctl -b | less

to see what normal logs look like on your system.

Following these steps provides a solid, practical security baseline for most beginner Linux setups. As you progress through later chapters, you’ll refine this baseline with advanced monitoring, hardening, and incident response techniques.