Skip to main content
Linux Command Line – Complete Beginner to Advanced Guide
CHAPTER 17 Beginner

Linux Security Basics

Updated: May 16, 2026
30 min read

# CHAPTER 17

Linux Security Basics

1. Introduction

The exact second a new Linux server is deployed to the public internet (via AWS, DigitalOcean, or Linode), it is immediately besieged. Automated botnets continuously scan the IP address space, instantly detecting your server and launching thousands of automated brute-force attacks against your SSH port. If your only defense is a password, it is only a matter of time before the server is compromised. In this chapter, we will implement the mandatory minimum-security baseline known as "Server Hardening." We will replace weak passwords with unbreakable SSH Cryptographic Keys, seal off the network perimeter using the Uncomplicated Firewall (UFW), and install automated defense mechanisms like Fail2Ban.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Generate and deploy SSH RSA/Ed25519 Cryptographic Keys.
  • Secure the SSH Daemon by disabling root login and password authentication.
  • Configure and enable the Uncomplicated Firewall (UFW) on Ubuntu.
  • Understand the function of iptables as the underlying firewall engine.
  • Deploy Fail2Ban to automatically detect and block malicious IP addresses.

3. Securing SSH (Cryptographic Keys)

Passwords can be guessed, phished, or brute-forced. Cryptographic Keys cannot. An SSH Key is a pair of files:
  • Public Key: (The Lock). You place this file on the remote server.
  • Private Key: (The Key). You keep this securely on your laptop.

1. Generate the Keypair (On your local laptop):

bash
1 
ssh-keygen -t ed25519

*(This creates the two mathematical files in your hidden ~/.ssh directory).*

2. Copy the Lock to the Server:

bash
1 
ssh-copy-id admin@192.168.1.50

Now, when you type ssh admin@192.168.1.50, you are logged in instantly via mathematical verification. No password required!

4. Hardening the SSH Configuration

Now that you have the magical key, you must weld the password keyhole shut. You must edit the master SSH configuration file on the server.
bash
1 
sudo nano /etc/ssh/sshd_config

Find and change these specific lines:

  • PermitRootLogin no (Prevents hackers from logging in as the ultimate admin).
  • PasswordAuthentication no (Completely disables the ability to type a password. If a hacker does not possess your physical Private Key file, it is mathematically impossible for them to log in).
*(Save the file and restart the service: sudo systemctl restart sshd).*

5. Configuring the Firewall (UFW)

By default, all network ports on a new Linux server are open. A firewall acts as a bouncer, dropping all traffic except the specific ports you explicitly permit. The core firewall in Linux is called iptables, but its syntax is notoriously complex. Ubuntu created the Uncomplicated Firewall (UFW) to make it easy.

1. Set the Default Rules:

bash
12 
sudo ufw default deny incoming
sudo ufw default allow outgoing

*(Block everything coming in; allow the server to talk out).*

2. Allow Specific Ports: If you enable the firewall now, you will lock yourself out! You MUST allow SSH first.

bash
123 
sudo ufw allow ssh      # Allows Port 22 for remote control
sudo ufw allow http     # Allows Port 80 for web traffic
sudo ufw allow https    # Allows Port 443 for secure web traffic

3. Turn it On:

bash
12 
sudo ufw enable
sudo ufw status verbose

6. Automated Defense (Fail2Ban)

Even with a firewall, hackers can still hit the open SSH port. If they don't have the key, the server rejects them, but they will try 50,000 times a second, consuming your CPU. Fail2Ban is a background program that constantly reads the /var/log/auth.log file. If it sees an IP address fail to log in 5 times within 10 minutes, Fail2Ban dynamically writes a new Firewall rule that instantly bans that IP address from the server completely.
bash
1234 
# Install the defense system
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

*(It works automatically out of the box!)*

7. Diagrams/Visual Suggestions

*Visual Concept: The Hardened Perimeter* Draw a castle (The Linux Server).
  • The Moat: Represents the Firewall (UFW). Only the drawbridges for Port 80, 443, and 22 are lowered.
  • The Guards on the Wall: Represents Fail2Ban. Show them actively throwing a net over an IP address that tries to cross the Port 22 drawbridge too many times.
  • The Vault Door: Represents the SSH Service. Show that it has no keyhole (PasswordAuthentication no), only a biometric scanner that requires the exact Public/Private Key pair to open.

8. Best Practices

  • Never Lose Your Private Key: If you set PasswordAuthentication no, and your laptop hard drive crashes (destroying your Private Key file), you are permanently locked out of your own cloud server. There is no "Forgot Password" button in Linux. You must physically rebuild the server. Always securely back up your Private Key (ided25519) to an encrypted offline drive.

9. Common Mistakes

  • Enabling UFW before allowing SSH: The most common mistake beginners make is typing sudo ufw default deny incoming and immediately typing sudo ufw enable. The firewall instantly activates, slams all the doors shut, and immediately terminates your active SSH session. You are locked out. Always type sudo ufw allow ssh *before* enabling the firewall.

10. Mini Project: Audit Your Firewall

If you are running Ubuntu in a VM or WSL:
  1. 1. Check if the firewall is running: sudo ufw status. (It will likely say "inactive").
  1. 2. Allow SSH traffic: sudo ufw allow ssh.
  1. 3. Enable it: sudo ufw enable.
  1. 4. Let's pretend you are hosting a custom game server on Port 25565. Allow it: sudo ufw allow 25565.
  1. 5. Run sudo ufw status numbered.
  1. 6. You realize you don't need the game server anymore. Delete the rule using its number: sudo ufw delete [RuleNumber].
You just secured a network perimeter.

11. Practice Exercises

  1. 1. Explain the cryptographic logic behind an SSH Keypair. Why is setting PasswordAuthentication no considered the gold standard of Linux server security?
  1. 2. Detail the exact consequence of enabling the Uncomplicated Firewall (UFW) with a default deny policy before explicitly allowing Port 22.

12. MCQs with Answers

Question 1

A security administrator modifies the /etc/ssh/sshdconfig file and changes the directive PermitRootLogin to no. What specific threat does this mitigation address?

Question 2

Which automated defense mechanism actively monitors system log files and dynamically injects firewall rules to block malicious IP addresses exhibiting brute-force behavior?

13. Interview Questions

  • Q: You are tasked with securing a brand-new, public-facing Ubuntu web server. Walk me through the exact, step-by-step "Server Hardening" checklist you would execute within the first 10 minutes of deployment.
  • Q: Explain the relationship between the Uncomplicated Firewall (UFW) and iptables. Why was UFW created for the Ubuntu ecosystem?
  • Q: A developer complains that they cannot log into a server via SSH. The server responds with "Permission denied (publickey)". What is the mechanical reason for this error, and how is it resolved?

14. FAQs

Q: Does Linux get viruses? Do I need an Antivirus? A: Linux desktop malware is exceedingly rare because of the strict file permission architecture (Chapter 6). A downloaded virus cannot execute without the user explicitly typing chmod +x and providing their sudo password. However, Linux servers are targeted by *vulnerability exploits*. Hackers don't use viruses; they find a flaw in the Apache web server code, exploit it remotely, and take control. Firewalls, SSH keys, and constant package updates (Chapter 11) are your "antivirus."

15. Summary

In Chapter 17, we transitioned from configuring the server to actively defending it against the hostility of the public internet. We eliminated the severe vulnerability of brute-force password guessing by implementing the cryptographic certainty of SSH Key authentication, officially locking the sshdconfig doors. We deployed the Uncomplicated Firewall (UFW) to enforce a strict "default deny" perimeter at the network layer, granting access solely to explicitly required ports. Finally, we automated our threat response by deploying Fail2Ban, ensuring the server autonomously defends itself against repetitive malicious scanning without human intervention.

16. Next Chapter Recommendation

The server is secure. It is time to make it useful. Let's install the critical infrastructure that powers the internet. Proceed to Chapter 18: Linux for DevOps and Servers.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Monitoring and System Logs
Next Chapter Linux for DevOps and Servers

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5

🧪 Related Labs 3