Linux Security & Hardening: Permissions, SSH, Firewalls, and System Protection

How Linux Protects Itself and How Administrators Make It Safer.

Linux is famous for stability, flexibility, and power; but none of that matters if the system cannot be trusted.

This tutorial focuses on how Linux enforces security by design, not as an afterthought. Linux does not rely on antivirus tools, external scanners, or bolt‑on security products. Instead, the operating system itself is built to:

• Limit damage when failures or misconfigurations occur
• Prevent unauthorized access
• Enforce least‑privilege access
• Harden itself for real production environments
• Detect suspicious activity
• Protect remote access
• Restrict what processes can do

This is the point where learners move beyond simply running commands and begin protecting systems.

It’s where beginners start thinking like administrators.

Security is not a checklist.

Security is not a tool.

Security is a mindset.

Every Linux system is built on four pillars:

• Understanding (how Linux works internally)
• Control (users, permissions, sudo, packages, services)
• Visibility (processes, networking, monitoring)
• Reliability (storage, filesystems, mounts, capacity)

But there is a fifth pillar, one that determines whether a system survives the real world: Trust

Trust is the foundation of Linux security.

In this guide, security is not treated as a checklist or an afterthought. Instead, it answers the core questions every administrator must be able to explain:

• Who is allowed to do what on the system?
• What is permitted to run and what is not?
• What happens when something goes wrong?
• How does Linux protect itself from mistakes, attacks, or misconfigurations?

This chapter is about understanding those answers and applying them with confidence in real systems.

WHAT IS LINUX SECURITY?

Linux security is a layered model, enforced by the kernel and configured by administrators. It combines:

whoami
groups
ls -l /
sudo ufw status
getenforce 2>/dev/null || aa-status 2>/dev/null

grep 'sudo' /etc/group
getent group sudo

getent group wheel

sudo gpasswd -d username sudo     # Debian/Ubuntu
sudo gpasswd -d wheel     # RHEL/CentOS/Fedora

id 
sudo -l -U username 2>/dev/null || echo "No sudo privileges"

sudo usermod -aG sudo victor     # or wheel on RHEL-family

ls -l /etc/passwd
ls -l /etc/shadow
stat /etc/passwd /etc/shadow
``

Expected:

Lab: Harden a Sensitive File

sudo touch /root/secrets.txt #Creates an empty file that is owned by root

#print the text and writes it into the file as root then output is suppressed with >/dev/null
#This avoids permission errors you would get if tried echo > file without root
echo "TOP-SECRET" | sudo tee /root/secrets.txt >/dev/null

#This ensures the file is owned by root and prevents accidental access by other users or groups
sudo chown root:root /root/secrets.txt

#Lock down permissions - Owner: read/write, Group: no access, Others: no access
#This is the correct mode for sensitive files (same as /etc/shadow)
sudo chmod 600 /root/secrets.txt

This means:

• Only root can read or modify it
• No other user can even open it
• Perfect for secrets, tokens, or lab exercises

Verify:

ls -l /root/secrets.txt
#perfect way to test file-permission hardening.
sudo -u nobody cat /root/secrets.txt || echo "Access correctly denied"

• nobody is the most restricted account on the system
• /root is only accessible to root
• /root/secrets.txt has permissions 600 (root‑only)

So the read attempt

• nobody is the most restricted account on the system
• /root is only accessible to root
• /root/secrets.txt has permissions 600 (root‑only)

So the read attempt must fail.

Tip: For shared project directories, consider setgid on directories to keep group ownership consistent:

#Change the group ownership - the /srv/project now belongs to the group dev
sudo chgrp dev /srv/project

#apply secure, collaborative permissions
sudo chmod 2770 /srv/project

🔐 Why this is powerful

• Every file created inside /srv/project automatically belongs to the dev group
• No accidental “wrong group” issues
• No outsiders can read or write
• Perfect for team collaboration, dev groups, or shared service directories

Lab: Find World‑Writable Files (Dangerous)

sudo find / -type f -perm -0002 2>/dev/null

Meaning:

• / → search the entire filesystem
• -type f → only files (not directories)
• -perm -0002 → files that are world‑writable
• 2>/dev/null → hide permission‑denied errors

World‑writable files are dangerous because any user can modify them, which opens the door to:

• privilege escalation
• tampering
• malicious code injection
• log poisoning
• service hijacking

This command helps you spot them.

SSH Security: Protecting Remote Access

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
sudo nano /etc/ssh/sshd_config

PermitRootLogin no
PasswordAuthentication no        # if you have keys in place
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
LoginGraceTime 30
MaxAuthTries 3
AllowUsers victor adminuser

sudo sshd -t

sudo systemctl restart ssh

ssh victor@SERVER
ssh root@SERVER  # should be denied

#Block all unsolicited inbound traffic
#This means no external system can initiate a connection to your machine unless you explicitly allow it.
sudo ufw default deny incoming

#Allow all outbound traffic
#Your system can reach the internet normally (updates, browsing, package installs).
sudo ufw default allow outgoing

#Allow SSH access
#This opens port 22 so you don’t lock yourself out if you’re using SSH.
sudo ufw allow OpenSSH

#Enable the firewall
#Activates UFW with the rules you’ve configured.
sudo ufw enable

#View the full firewall status
sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

#Check which services are listening on ports 22, 80, 443
ss -tulpn | grep -E ':(22|80|443)\b'

#Check UFW rules with numbering
sudo ufw status numbered

sudo bash -c 'cat >/etc/nftables.conf' <<'EOF'
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    iif lo accept
    ct state established,related accept
    tcp dport 22 accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;
  }

  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}
EOF

sudo nft -f /etc/nftables.conf
sudo systemctl enable --now nftables
sudo nft list ruleset

sudo systemctl stop nftables
sudo nft flush ruleset

getenforce # Enforcing | Permissive | Disabledsestatus # detailed view (if installed)

sudo aa-status
sudo aa-status | sed -n '1,20p'

sudo journalctl -t setroubleshoot --since "1 hour ago" 2>/dev/null | tail
sudo ausearch -m AVC,USER_AVC -ts recent 2>/dev/null | aureport -av

sudo dmesg | grep -i apparmor | tail -n 50
sudo aa-logprof # step through suggestions interactively

sudo setenforce 0 # temporary (runtime)# Re-enable to test:sudo setenforce 1

sudo tail -n 100 /var/log/auth.logsudo journalctl -xe

sudo tail -n 100 /var/log/securesudo journalctl -xe

sudo tail -f /var/log/syslog # Debian/Ubuntu
sudo tail -f /var/log/messages # RHEL-family

sudo ausearch -m USER_AUTH,USER_LOGIN -ts today | aureport -au