Table of Contents
Introduction
Basic system security on Linux is about reducing risk with practical, repeatable habits. At this level you are not trying to build a perfectly secure system, but you are trying to avoid common mistakes that make attacks trivial. Security is a process, not a single tool, and it involves good configuration, regular updates, and proper access control.
This chapter gives you a conceptual overview of basic Linux security. The detailed use of specific tools and subsystems such as firewalls, authentication policies, SSH hardening, and mandatory access control will be covered in their own sections. Here, you will learn how to think about security on a Linux system and which routine actions matter the most.
Basic security is mainly about reducing attack surface, controlling access, and keeping systems up to date. Neglecting any of these three makes the rest of your efforts far less effective.
The Security Mindset
Security starts with how you think about your system. Instead of asking, “Can this work?”, you begin to ask, “What can go wrong if this works?” and “Who can reach this system and do what?”.
On a Linux system, almost every service you enable, every port you open, and every user account you create is a potential path an attacker can try to use. The goal is not to avoid changing anything, but to understand the impact of each change.
You also learn to assume that mistakes and bugs exist. Software will have vulnerabilities, users will choose weak passwords, and misconfigurations will happen. Basic security tries to limit the damage when something does go wrong, through isolation and least privilege.
The Principle of Least Privilege
One of the central ideas in security is the principle of least privilege. On Linux, this means that users, applications, and services should have only the permissions they need to do their job and no more.
For users, this means avoiding logging in as root for normal work and using elevated privileges only when strictly necessary. For processes, it means running services as dedicated unprivileged accounts whenever possible, and not granting write or execute access to files that do not require it.
This principle does not depend on any specific tool. Firewalls, access control frameworks, and sudo policies are all more effective when you design them to give out minimal permissions and to separate roles clearly.
Always start with no access, then grant only what is needed. Never start with full access and try to remove “dangerous” parts later.
Attack Surface and Service Exposure
Attack surface is the collection of ways an attacker can interact with your system. On a Linux machine, this usually includes open network ports, public facing services, SSH access, local user accounts, and sometimes physical access.
Reducing attack surface means turning off services you do not need, avoiding unnecessary software installation, and not exposing internal services to the wider network. A small, focused system is easier to defend and easier to understand.
A desktop that has only SSH listening from the local network is less exposed than a server that runs a web server, a database, and several legacy services that no one uses any more. Even if those unused services do not appear to cause problems day to day, they extend the set of possible entry points for an attacker.
Updates and Vulnerability Management
Keeping a Linux system updated is one of the simplest and most effective security practices. Security patches address known vulnerabilities that attackers actively scan for. When you run outdated software for long periods of time you are effectively leaving open doors that others already know how to exploit.
Basic security does not require you to understand every vulnerability in detail. It does require you to apply regular system updates from trusted repositories and to adopt a routine that fits your environment. A home user might update weekly, while a server administrator might follow a defined schedule and test updates before deployment.
You should also be aware that software you install from outside your distribution’s official repositories can lag behind in security fixes, or might not be maintained at all. Each additional third party package can introduce more risk and more work to keep track of.
Authentication and Identity
Authentication ties actions on a Linux system to specific identities, usually user accounts. Basic system security assumes that some users are local humans, while others are service accounts used by programs. You design your system so that each identity is used for a clear purpose.
Password based authentication remains common, especially for local logins. Weak or reused passwords are often the first thing attackers try to exploit, so basic security includes sensible password policies, not sharing accounts between people, and not using privileged accounts for routine tasks.
Logical access control depends heavily on accurate identity. If users share accounts or use insecure credentials, it becomes very difficult to know who did what or to block specific people from accessing the system when needed.
Local vs Remote Threats
Threats to a Linux system come from two broad directions, local and remote. Local threats include people who can sit at the keyboard, plug in USB devices, or boot from removable media. Remote threats involve access over the network, most often the internet.
Basic security acknowledges that physical access is highly powerful. A person with full physical access can often bypass many logical protections. For this reason, you typically focus network facing protections first, since internet based attacks tend to scale and spread more widely.
However, ignoring local security is also a mistake, especially on shared machines. Basic protections include requiring authentication for administrative changes, locking screens when unattended, and controlling which users can read sensitive data.
Defense in Depth
Defense in depth means you do not rely on a single protective measure. Instead, you implement several layers that each make attacks more difficult or limit the damage that can occur if one layer fails.
On a Linux system, this might look like a combination of correctly set file permissions, sensible sudo usage, a restrictive firewall, careful SSH configuration, and a mandatory access control system. Each layer assumes that another might fail.
As you learn more advanced tools, this layered approach becomes more detailed, but the basic idea starts here. You think not just about keeping attackers out, but also about slowing them down and containing them if they get in.
Never rely on only one security control. Always expect that any single safeguard can fail and design multiple, independent layers.
Logging and Accountability
Security is not only about prevention. It is also about being able to see what has happened and to respond appropriately. Logging is how Linux records many of the actions that occur on a system, such as logins, failed attempts, and service events.
For basic security, you do not need to analyze logs constantly, but you should know that they exist and that they matter when you suspect a problem. Good security practice includes ensuring that logs are stored reliably, not deleted accidentally, and not made world readable if they contain sensitive information.
Accountability comes from combining logs with identity. When each user has their own account and elevated actions are performed in a controlled way, it becomes possible to trace back changes and detect misuse.
Balancing Security and Usability
Every security measure has a cost. Stronger passwords can be harder to remember, more restrictive firewalls can block legitimate traffic, and frequent updates can require reboots or brief downtime. Basic system security seeks a sensible balance that fits your use case.
On personal machines you may tolerate slightly more prompts or minor inconveniences in exchange for much higher security. On production servers you might shape policies so that routine operations remain smooth while high risk actions are more tightly controlled.
The key is to avoid both extremes. Excessive restrictions that users routinely bypass are not effective, while lax configurations that never deny anything do not provide real protection. You instead aim for policies that are strict where it matters most and lightweight where the risk is low.
Building Security Habits
Tools matter, but habits matter more. Basic system security is often about what you do by default. Examples include locking your screen when you step away, avoiding running random scripts from untrusted sources, checking the origin of downloaded software, and not disabling security features “temporarily” without restoring them.
On Linux, these habits also include understanding when you are using elevated privileges, paying attention to warnings, and being cautious about exposing services to the internet. Over time, these become routine and require less effort.
In the following sections of this part of the course you will apply these concepts using specific tools and mechanisms. You will configure firewalls, adjust authentication policies, secure SSH access, and learn what SELinux and AppArmor contribute to tightening your system. The ideas introduced here will guide how you use each of those tools in practice.