10. security - mishraxharshit/harshitxmishra.github.io GitHub Wiki

Phase 10 — Security

Previous: [Phase 9 — System Administration](Phase-9-System-Administration) | Next: [Phase 11 — Advanced and DevOps](Phase-11-Advanced-and-DevOps)

10.1 The Security Mindset

Security in Linux is about applying the principle of least privilege: every user, process, and service should have only the access it needs to do its job, nothing more.

When you harden a system you are reducing the attack surface: the number of ways an attacker could gain access, escalate privileges, or cause damage.

10.2 Auditing Open Ports and Services

Before hardening, know what is running.

# See all listening ports and which process owns them
sudo ss -tlnp

# Check which services start on boot
systemctl list-unit-files --type=service --state=enabled

# Disable services you do not need
sudo systemctl disable --now avahi-daemon   # network discovery (usually unnecessary on servers)
sudo systemctl disable --now cups           # printing (unnecessary on servers)
sudo systemctl disable --now bluetooth      # if no Bluetooth hardware used

The rule: if a service is not needed, disable it. Every running service is a potential entry point.

10.3 Securing SSH

SSH is the most common entry point to Linux servers. Lock it down.

sudo nano /etc/ssh/sshd_config

Critical settings:

# Disable root login over SSH (use a regular user + sudo instead)
PermitRootLogin no

# Disable password authentication (use SSH keys only)
PasswordAuthentication no

# Only allow specific users to log in via SSH
AllowUsers alice bob

# Change the default port (minor obscurity benefit, reduces automated scans)
Port 2222

# Disconnect idle sessions after 10 minutes
ClientAliveInterval 300
ClientAliveCountMax 2

# Disable X11 forwarding if not needed
X11Forwarding no

# After editing, test the config before restarting
sudo sshd -t
# No output = syntax is valid

# Restart SSH (do this while in an existing session, not over SSH)
sudo systemctl restart ssh

10.4 Firewall with ufw and iptables

# ufw approach (Ubuntu — simple interface)
sudo ufw default deny incoming     # block all incoming by default
sudo ufw default allow outgoing    # allow all outgoing by default
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

# Rate limiting: allow SSH but block sources making too many connections
sudo ufw limit ssh

# iptables (lower level, more control)
# View current rules
sudo iptables -L -v -n

# Basic firewall with iptables
sudo iptables -P INPUT DROP          # default: drop all incoming
sudo iptables -P FORWARD DROP        # default: drop forwarding
sudo iptables -P OUTPUT ACCEPT       # default: allow all outgoing

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT            # allow loopback
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT  # allow SSH
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT  # allow HTTP

# Save rules so they persist after reboot
sudo apt install iptables-persistent
sudo netfilter-persistent save

10.5 fail2ban — Block Brute Force Attacks

fail2ban monitors logs and temporarily bans IPs that show signs of brute-force attempts.

sudo apt install fail2ban

# Configuration (always edit jail.local, not jail.conf)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

# Key settings:
# [DEFAULT]
# bantime  = 3600        # ban for 1 hour
# findtime = 600         # count failures within 10 minutes
# maxretry = 5           # after 5 failures

# [sshd]
# enabled = true
# port    = ssh

sudo systemctl enable --now fail2ban

# Check ban status
sudo fail2ban-client status sshd
sudo fail2ban-client status           # all jails

# Unban an IP
sudo fail2ban-client set sshd unbanip 192.168.1.100

10.6 File Integrity and Auditing

# Check for SUID files (programs that run as their owner, potential privilege escalation)
find / -perm -4000 -type f 2>/dev/null
# Review this list — most are expected (passwd, sudo, su) but unknown SUID files are a red flag

# Find world-writable files (anyone can modify)
find / -perm -0002 -type f 2>/dev/null | grep -v /proc | grep -v /sys

# auditd: the Linux auditing system
sudo apt install auditd
sudo systemctl enable --now auditd

# Watch who reads a sensitive file
sudo auditctl -w /etc/shadow -p r -k shadow_read

# View audit log
sudo ausearch -k shadow_read
sudo aureport --summary

10.7 AppArmor (Ubuntu's Mandatory Access Control)

AppArmor restricts what individual programs can do, regardless of the user running them. Even if nginx is compromised, it cannot access files outside its defined profile.

# Check AppArmor status
sudo aa-status

# AppArmor modes:
# enforce — violations are blocked and logged
# complain — violations are only logged, not blocked

# Check if a profile is in enforce or complain mode
sudo aa-status | grep nginx

# Put a profile in complain mode temporarily
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

# Return to enforce mode
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# View profile for a program
sudo cat /etc/apparmor.d/usr.sbin.nginx

10.8 Security Checklist for a New Server

Run through this list when deploying any new server:

  1. Create a non-root user with sudo access. Disable root SSH login.
  2. Set up SSH key authentication. Disable password authentication.
  3. Enable and configure the firewall. Block all ports not in use.
  4. Install fail2ban to protect against brute-force attacks.
  5. Keep the system updated: sudo apt update && sudo apt upgrade -y
  6. Remove or disable unnecessary services.
  7. Check for SUID files: find / -perm -4000 -type f 2>/dev/null
  8. Review listening ports: sudo ss -tlnp
  9. Enable automatic security updates if appropriate.
  10. Set a reasonable umask (default is 022, meaning new files are 644 and directories 755).

Phase 10 Exercises

Exercise 1: Run sudo ss -tlnp and identify every service that is listening. Disable any that you do not need.

Exercise 2: Review /etc/ssh/sshd_config. Does PermitRootLogin say no? Does PasswordAuthentication say no? (Only disable password auth after confirming SSH keys work.)

Exercise 3: Install fail2ban and check its status. How many IPs are currently banned?

Exercise 4: Run the SUID file search. List the results and explain why each one legitimately needs SUID.

Previous: [Phase 9 — System Administration](Phase-9-System-Administration) | Next: [Phase 11 — Advanced and DevOps](Phase-11-Advanced-and-DevOps)