Harden and Defend a Linux Server

Lock down a Linux server with firewall rules, logging, and brute-force detection.

Introduction

30 Second Summary

Every server connected to the internet faces a constant barrage of automated attacks. Within minutes of going online, bots begin probing for weak passwords and open ports. Knowing how to lock down a system is one of the most in-demand skills in cybersecurity.

In this project, you will harden a Linux server from a default install to a secure baseline, configure firewall rules, simulate a brute-force attack, and detect it by reading authentication logs.

What You'll Build

A hardened Ubuntu Server virtual machine with an active firewall, logging, and brute-force detection running inside UTM on your Mac.

By the end of this project, you'll have:

A running Ubuntu Server 24.04.4 LTS VM with a hardened configuration including disabled unnecessary services and enforced password policies.
A UFW firewall enforcing a default-deny incoming policy with explicit SSH allow rules and logging enabled.
Detected a simulated brute-force SSH attack by analyzing authentication logs for failed login attempts, source IPs, and timestamps.
A security baseline document mapping your hardening changes to CompTIA Security+ SY0-701 exam domains.
Secret Mission: Install and configure Fail2ban to automatically block brute-force attackers.

Are there any prerequisites?

None. This guide includes setup instructions for all required tools. You just need a Mac with UTM already installed and enough disk space for the Ubuntu Server ISO (around 3 GB) and a 20 GB virtual hard disk.

Set Up Your Lab Environment

Every security professional needs a safe place to practice. A virtual machine gives you an isolated environment where you can break things, attack services, and test defenses without affecting your real computer.

In this step, you will create a virtual machine in UTM and install Ubuntu Server on it. This VM becomes your dedicated security lab for the rest of the project.

In this step, get ready to:

Create a virtual machine named SecurityLab in UTM.
Install Ubuntu Server 24.04.4 LTS on the VM.
Log in and verify your installation is working.

Locate your downloaded Ubuntu Server ISO

You already downloaded the Ubuntu Server 24.04.4 LTS ISO file earlier. Before creating the VM, confirm you know where the file is saved on your Mac.

Open Finder and navigate to your Downloads folder.
Confirm you see the ISO file. It will be named ubuntu-24.04.4-live-server-arm64.iso (Apple Silicon) or ubuntu-24.04.4-live-server-amd64.iso (Intel).

Which ISO do I have?

If your Mac has an Apple M1, M2, M3, or M4 chip, you need the arm64 ISO. If your Mac has an Intel processor, you need the amd64 ISO.

You can check by clicking the Apple menu and selecting About This Mac.

Create the Ubuntu Server VM in UTM

UTM uses a wizard to walk you through creating a new virtual machine. You will select the virtualization type, attach the ISO, and configure memory and disk size.

In UTM, click the + button at the top of the window to open the VM creation wizard.
Select Virtualize.
Select Linux.

The next page asks you to select a boot ISO.

Click Browse and navigate to your Downloads folder.
Select the Ubuntu Server ISO you downloaded.
Click Continue.

The next page is where you set the memory and CPU allocation.

Set the RAM to 2048 MB (2 GB).
Leave the CPU cores at the default.
Click Continue.

The next page is where you set the drive size.

Set the disk size to 20 GB.
Click Continue.

The next page asks about a Shared Directory. You do not need this for the lab.

Skip the shared directory and click Continue.
On the summary page, click Save to create the VM.

Your new VM appears in the sidebar on the left side of the UTM window. Right-click the VM and select Edit to rename it.

In the Information tab, change the name to SecurityLab and click Save.
Select SecurityLab in the sidebar and click the large Play button (▶) to boot the VM from the ISO.

VM won't start or shows an error?

Make sure you selected Virtualize (not Emulate) during setup. Virtualize uses Apple's native hypervisor for best performance with ARM ISOs.

If you see a kernel or architecture error, confirm you downloaded the correct ISO for your Mac (arm64 for Apple Silicon, amd64 for Intel).

Help me troubleshoot my UTM VM

Install Ubuntu Server on the VM

The VM boots from the ISO and launches the Ubuntu Server installer. This is a text-based installer that you navigate using your arrow keys, Tab, and Enter.

What is a text-based installer?

Ubuntu Server does not include a graphical desktop. The installer uses a menu-driven text interface. Use the arrow keys to move between options, Space or Enter to select, and Tab to move between buttons like Done and Back.

Follow these steps through the installer screens:

Choose your language (English is the default) and press Enter.
If the installer offers to update itself, select Continue without updating.
Select your keyboard layout and press Done.
On the network configuration screen, accept the default (DHCP) and select Done.
On the proxy screen, leave it blank and select Done.
On the mirror screen, accept the default and select Done.
On the storage screen, leave Use an entire disk selected and select Done.
On the storage summary screen, select Done and then confirm by selecting Continue to write changes to disk.

Now you reach the profile setup screen. This is where you configure your server identity.

In the Your name field, type analyst.
In the Your server's name field, type securitylab.
In the Pick a username field, type analyst.
In the Choose a password field, choose a strong password you will remember. Type it again to confirm.
Select Done.

Pick a password you will remember

You will type this password frequently throughout the project whenever you run sudo commands. Choose something memorable but not trivial.

The next screen is the SSH setup screen.

Use Space to check the Install OpenSSH server option.
Select Done.

Why install OpenSSH now?

OpenSSH is the standard tool for remote server administration. Installing it during setup means your server is ready for SSH connections immediately.

In later steps, you will use SSH to simulate a brute-force attack against this service.

On the featured snaps screen, do not select anything. Select Done.
The installer now downloads and installs packages. Wait for it to finish. This may take a few minutes.
When the installation completes, select Reboot Now.

What if the VM hangs after reboot?

After selecting Reboot Now, the VM may hang at a black screen with a blinking cursor. This is a known UTM behaviour. Stop the VM by clicking the square stop button, then click the play button (▶) to start it again. It will boot into your new installation.

After the reboot, you will see a login prompt.

Type your username analyst and press Enter.
Type your password and press Enter. The password will not appear on screen as you type. This is normal.

You are now logged into your Ubuntu Server VM.

Verify your hostname by running:

hostname

You should see securitylab printed in the terminal.

Seeing a different hostname or login error?

If hostname returns something other than securitylab, you may have made a typo during the profile setup. You can fix it later with sudo hostnamectl set-hostname securitylab.

If you cannot log in, double check you are typing the password correctly. Remember that no characters appear while typing passwords in Linux terminals.

Help me troubleshoot my Ubuntu Server login

Your lab environment is ready. Next up, you will harden this server by disabling unnecessary services and configuring password policies.

Establish a Security Baseline and Harden the Server

Your lab environment is ready and Ubuntu Server is running inside UTM. Now it's time to lock it down.

A fresh server install comes with services and settings designed for convenience, not security. Every running service is a potential entry point for an attacker. In this step, you'll reduce that exposure by removing what you don't need and enforcing stricter access policies.

In this step, get ready to:

Update all system packages to their latest versions.
Audit and disable unnecessary services.
Apply a password aging policy for your user account.

Update the system and audit running services

The first step in any server hardening process is making sure all software is up to date. Outdated packages often contain known vulnerabilities that attackers can exploit.

Update all installed packages by running this command:

sudo apt update && sudo apt upgrade -y

What does this command do?

sudo apt update refreshes the list of available packages from Ubuntu's repositories.
sudo apt upgrade -y installs all available updates. The -y flag automatically confirms the installation so you don't have to type "yes" for each package.

This command may take a few minutes depending on how many packages need updating.

Seeing a lock error?

If you see a message about the package lock being held, another process is updating packages in the background. Wait 30 seconds and try the command again.

help me fix a package lock error on Ubuntu

After the update finishes, you need to see what's currently running on your server.

List all currently running services by running this command:

sudo systemctl list-units --type=service --state=running

What does this command do?

systemctl is the tool for managing services on Ubuntu.
--type=service filters to show only services (not other system units like timers or sockets).
--state=running shows only services that are actively running right now.

You should see a table listing services like ssh.service, systemd-journald.service, and others. Each running service is part of your server's attack surface.

What is an attack surface?

Your attack surface is the total number of entry points an attacker could use to get into your system. Fewer running services means fewer potential vulnerabilities to exploit.

This concept falls under CompTIA Security+ Domain 4 (Security Operations), which covers 28% of the SY0-701 exam.

Disable unnecessary services and configure password policy

Now that you know what's running, you can disable services you don't need. Each disabled service removes a potential attack vector from your server.

Disable the snapd service and its socket by running these commands:

sudo systemctl disable --now snapd
sudo systemctl disable --now snapd.socket

Why disable snapd?

snapd manages Snap packages on Ubuntu. For a security lab focused on hardening, you don't need it running.

The disable --now flag does two things: it stops the service immediately, and it prevents it from starting again on future reboots. Disabling unnecessary services is a core hardening practice tested on the Security+ exam.

Confirm the services stopped by checking the output. You should see lines indicating the service and socket have been disabled.

Seeing 'unit not found' for snapd?

If your Ubuntu Server installation did not include Snap, you may see an error saying the unit was not found. This is fine. It means the service was never installed, so there is nothing to disable.

help me figure out which services to disable on my Ubuntu Server

Next, you'll enforce a password aging policy. Password policies ensure credentials are rotated regularly, reducing the window of opportunity if a password is compromised.

Apply a password aging policy for your analyst account by running this command:

sudo chage -M 90 -m 7 -W 14 analyst

What does this command do?

-M 90 sets the maximum password age to 90 days. After 90 days, the password must be changed.
-m 7 sets the minimum password age to 7 days. This prevents users from cycling through passwords quickly to reuse an old one.
-W 14 sets the warning period to 14 days before expiration. The user gets notified 14 days before they must change their password.

This is an identity and access management control tested under Security+ Domain 4 (Security Operations).

Verify your hardening changes

Always verify that your changes took effect. A configuration you think you applied but didn't is worse than no configuration at all.

Check that the disabled services are gone by running this command again:

sudo systemctl list-units --type=service --state=running

Compare this output to what you saw earlier. The snapd services should no longer appear in the list.

Verify your password policy by running this command:

sudo chage -l analyst

You should see output showing your configured values: maximum 90 days, minimum 7 days, and warning 14 days.

What should I see?

The output displays labeled fields from the system's shadow file. Look for these three lines to confirm your policy is active:

Maximum number of days between password change: 90
Minimum number of days between password change: 7
Number of days of warning before password expires: 14

🙋‍♀️ Values still showing defaults?

If the output shows 99999 for maximum days or 0 for minimum days, the chage command did not apply correctly. Make sure you typed the username analyst at the end of the command (not your Mac username).

help me fix my password policy settings

Your server is now running only the services it needs, with a proper password policy in place. Next up, you'll configure the UFW firewall to control exactly which network traffic can reach your server.

Configure the UFW Firewall

Your server is now hardened with unnecessary services disabled and password policies in place. The next layer of defense is controlling what network traffic can reach your server in the first place.

Right now, your server accepts connections on every port. In this step, you will configure UFW (Uncomplicated Firewall) to block all incoming traffic by default and only allow the specific connections you need.

In this step, get ready to:

Set a default-deny incoming policy with an explicit allow for SSH.
Enable the firewall and turn on logging.
Verify your firewall rules are active and correct.

Set default policies and allow SSH

A well-configured firewall starts with a "default deny" policy. This means all incoming traffic is blocked unless you create an explicit rule to allow it.

Set your default policies and allow SSH access by running these commands:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh

What do these commands do?

sudo ufw default deny incoming blocks all incoming connections by default. Nothing gets through unless you explicitly allow it.
sudo ufw default allow outgoing allows your server to make outbound connections (for updates, downloads, etc.).
sudo ufw allow ssh creates an explicit exception for SSH traffic on port 22, so you can still access your server remotely.

💡 What is implicit deny?

Implicit deny (also called default deny) is one of the most tested firewall concepts on the Security+ exam. The principle is simple: block everything by default, then only allow what is explicitly needed.

This approach ensures that if you forget to create a rule for a service, that service is blocked rather than exposed. It falls under Domain 1 (General Security Concepts) and Domain 4 (Security Operations).

You won't see a visible change yet. These rules take effect once you enable UFW in the next substep.

Seeing a permission error?

Make sure you include sudo at the start of each command. UFW requires root privileges to modify firewall rules.
If you see a "command not found" error, UFW may not be installed. Run sudo apt install ufw and try again.

Help me troubleshoot UFW permission errors on my Ubuntu Server VM.

Enable UFW and enable logging

With your rules configured, it is time to activate the firewall. You will also turn on logging so that blocked traffic is recorded for later analysis.

Enable the firewall and turn on logging by running these commands:

sudo ufw enable
sudo ufw logging on

What about the SSH warning?

When you run sudo ufw enable, you may see a prompt saying Command may disrupt existing ssh connections. Proceed with operation (y|n)? Type y and press Enter to proceed.

Since you are working directly on the VM console (not over SSH), this warning does not affect you. You already allowed SSH in the previous substep, so remote access remains available.

After running both commands, you should see Firewall is active and enabled on system startup confirming the firewall is running.

Firewall didn't enable?

If you see an error about iptables modules, make sure your VM is running the standard Ubuntu kernel. UTM with a fresh Ubuntu Server install should have no issues.
If the command hangs, press Enter again. The prompt may be waiting for your y confirmation.

Help me troubleshoot enabling UFW on my Ubuntu Server VM in UTM.

Verify firewall status and rules

Check your firewall configuration by running this command:

sudo ufw status verbose

What should I see?

The output should show:

Status: active at the top.
Default: deny (incoming), allow (outgoing), disabled (routed) showing your default policies.
A rule showing port 22/tcp as ALLOW IN from Anywhere.

This confirms your host-based firewall is active with explicit allow rules. On the Security+ exam, you will be tested on your ability to configure and verify firewall rules (Domain 4: Security Operations).

🙋‍♀️ Status shows inactive?

Go back and run sudo ufw enable again. Make sure you type y when prompted.
If 22/tcp is not listed, run sudo ufw allow ssh and then check the status again.

Help me fix my UFW firewall status on Ubuntu Server.

Your firewall is now locked down with a default-deny policy and logging enabled. Next up, you will simulate a brute-force attack and use your server's logs to detect it.

Simulate and Detect a Brute-Force Attack

Your firewall is active and logging traffic. Now it is time to put your defenses to the test by simulating the most common type of attack a server faces.

In this step, you will deliberately generate failed login attempts against your own server, then hunt for evidence of those attempts in the authentication logs. This is the same detection workflow a SOC analyst performs when investigating suspicious activity.

In this step, get ready to:

Simulate a brute-force password attack using failed login attempts.
Detect the attack by analyzing authentication logs.
Review firewall logs for blocked traffic.

Generate failed login attempts

A brute-force attack is when an attacker tries many password combinations against a login service, hoping to guess the correct one. You are going to simulate this by deliberately entering wrong passwords on your own server.

Simulate a local login attempt by running this command:

su - fakeuser

When prompted for a password, type any random text and press Enter.
Repeat this 5-6 times. Each failed attempt generates a log entry.

Now simulate a remote-style attack over SSH by targeting localhost.

Start an SSH login attempt against a fake user by running this command:

ssh fakeuser@localhost

If prompted about the host fingerprint, type yes and press Enter.
Enter wrong passwords 5-6 times when prompted.
Press Ctrl+C to cancel the SSH session when you are done.

What does this simulate?

You just generated the same log entries that a real brute-force attack would produce. Attackers use automated scripts to try thousands of password combinations per minute against SSH servers exposed to the internet.

Security+ concept: this falls under Domain 2 (Threats, Vulnerabilities, and Mitigations, 22%). Password attacks including brute-force and password spraying are common attack types tested on the exam.

🙋‍♀️ SSH connection refused?

If you see a connection refused message, your OpenSSH server may not be running. Run sudo systemctl status ssh to check. If it is inactive, start it with sudo systemctl start ssh.

Help me troubleshoot SSH connection issues on my Ubuntu Server VM.

Analyze authentication logs

Every login attempt on a Linux server is recorded in the authentication log. This is the first place a security analyst looks when investigating suspicious activity.

Search the authentication log for failed login attempts by running this command:

sudo cat /var/log/auth.log | grep "Failed"

You should see multiple entries that look similar to this:

Failed password for invalid user fakeuser from 127.0.0.1 port XXXXX ssh2

What does this output tell you?

Each log entry contains the information an analyst needs to investigate: the timestamp of the attempt, the username tried, the source IP address (127.0.0.1 because you attacked from localhost), and the service targeted (ssh2).

In a real incident, the source IP would be an external address. You would use it to trace the attacker's origin and decide whether to block the IP at the firewall level.

Count the total number of failed attempts by running this command:

sudo cat /var/log/auth.log | grep "Failed" | wc -l

The number returned should roughly match how many times you entered wrong passwords across both the su and ssh attempts.

Not seeing any results?

Make sure you entered wrong passwords during the previous substep. If you accidentally typed the correct password or skipped the attempts, go back and run su - fakeuser a few more times with incorrect passwords.

Also check that grep uses a capital F in "Failed". Log entries are case-sensitive.

Help me find failed login attempts in my Ubuntu Server auth.log.

Check UFW logs for blocked traffic

Your firewall logs record any traffic it blocked. Since you enabled UFW logging in the previous step, blocked connections appear in a dedicated log file.

View the most recent firewall log entries by running this command:

sudo cat /var/log/ufw.log | tail -20

What should I see?

If any traffic was blocked by your firewall rules, you will see entries marked with [UFW BLOCK]. Your SSH attempts to localhost were allowed (port 22 is in your allow list), so they will not appear as blocked here.

The key takeaway is that you now have two detection sources working together. Authentication logs catch WHO tried to log in. Firewall logs catch WHAT traffic was rejected before it even reached a service. Together, these form your monitoring and detection capability.

💡 How does this map to Security+?

This is log analysis and monitoring, incident detection, and using data sources to support investigations. These skills fall under Domain 4 (Security Operations, 28% of the exam). The ability to identify source IPs, timestamps, and attack patterns from raw logs is exactly what performance-based questions test.

🙋‍♀️ UFW log file is empty or missing?

If the file does not exist, confirm logging is enabled by running sudo ufw status verbose. You should see Logging: on in the output. If logging is off, re-enable it with sudo ufw logging on.

If the file exists but is empty, that simply means no traffic has been blocked yet. This is normal if all your connections used the allowed SSH port.

Help me understand why my UFW log is empty.

You have successfully simulated an attack and detected it through log analysis. Next up, you will document all of your hardening work into a security baseline report that maps directly to the Security+ exam domains.

Document Your Security Baseline

You have successfully detected a simulated brute-force attack by reading authentication logs and firewall entries. That is real incident detection work performed daily by security analysts.

Now it is time to capture everything you did into a security baseline document. This report records your hardening changes, firewall configuration, and detected attack indicators. It also maps each action to the CompTIA Security+ SY0-701 exam domains so you can see exactly which objectives you covered.

In this step, get ready to:

Create a hardening report documenting all security changes.
Map your work to Security+ SY0-701 exam domains.
Save and verify the completed document.

Create a hardening report

A security baseline document records the state of a system after hardening. It gives you a reference point to detect unauthorized changes and proves the work you completed.

Open the nano text editor to create your report by running this command:

nano ~/security-baseline.txt

You should see the nano text editor open with an empty file.

Type the following report content into the editor:

=== SECURITY BASELINE REPORT ===

Date: [[TODAY_DATE="today's date, e.g. 2026-06-13"]]
Server: securitylab (Ubuntu Server 24.04.4 LTS)
Administrator: analyst

--- SERVICES DISABLED ---

snapd - disabled (not required for security lab operations)
snapd.socket - disabled (socket for snapd, also not required)

--- FIREWALL CONFIGURATION (UFW) ---

Default incoming policy: deny
Default outgoing policy: allow

Allowed ports:
  - 22/tcp (SSH) - ALLOW IN from Anywhere

Logging: enabled

--- PASSWORD POLICY ---

Maximum password age: 90 days
Minimum password age: 7 days
Warning period: 14 days

--- DETECTED ATTACK INDICATORS ---

Attack type: brute-force password attack (simulated)
Target: SSH service and local authentication
Source IP: 127.0.0.1 (localhost, simulated)
Failed login attempts: [[FAILED_COUNT="number of failed attempts you counted in Step 4"]]
Evidence: /var/log/auth.log entries showing Failed password for invalid user fakeuser

What does each section capture?

Services Disabled records what you turned off and why. This reduces your attack surface.
Firewall Configuration documents your UFW rules. The default-deny incoming policy implements implicit deny.
Password Policy records the identity and access management controls you applied.
Detected Attack Indicators documents evidence from your log analysis. This is the same data a SOC analyst would include in an incident report.

💡 Check your failed login count

If you do not remember your exact count from Step 4, you can open a second terminal or check after saving. The exact number is less important than documenting that you detected the attack.

Map your work to Security+ exam domains

The Security+ SY0-701 exam is divided into domains, each weighted by percentage. Mapping your hands-on work to these domains shows which exam objectives you practiced.

Below the attack indicators section in nano, add a blank line and then type the following domain mapping:


--- SECURITY+ SY0-701 DOMAIN MAPPING ---

Domain 1 - General Security Concepts (12%):
  Applied security controls (technical, preventive).
  Implemented implicit deny via UFW default policy.

Domain 2 - Threats, Vulnerabilities, and Mitigations (22%):
  Simulated password attacks.
  Applied mitigation through hardening and access control.

Domain 3 - Security Architecture (18%):
  Applied secure baselines.
  Designed defense-in-depth (hardening + firewall + logging).

Domain 4 - Security Operations (28%):
  Configured firewall, managed identities, analyzed logs,
  performed monitoring and detection.

Why map to exam domains?

Domain 4 (Security Operations) carries the highest weight at 28% of the exam. Most of what you did in this project falls under Domain 4. Seeing the mapping helps you understand which exam topics you have now practiced hands-on.

Together, Domains 2, 3, and 4 account for 68% of the exam. This single project touched all three.

Save and verify your report

Save the file by pressing Ctrl+O on your keyboard.
Press Enter to confirm the filename.
Exit nano by pressing Ctrl+X.

Verify your report saved correctly by running:

cat ~/security-baseline.txt

You should see your entire security baseline document printed to the terminal, including the date, disabled services, firewall rules, password policy, attack indicators, and domain mapping.

Seeing an empty file or command not found?

If the file is empty, you may have exited nano without saving. Run nano ~/security-baseline.txt again and retype your content. Press Ctrl+O then Enter before exiting with Ctrl+X.
If you see No such file or directory, check for typos in the path. The file should be at ~/security-baseline.txt (in your home directory).

Having trouble saving?

✔️ Awesome, I've got everything!

Great. Double check that your document includes all five sections: services disabled, firewall configuration, password policy, detected attack indicators, and the domain mapping.

ⓧ I'd like to double check the full document

Scroll up and confirm your security-baseline.txt contains all of these sections, in order:

Header with date, server name, and administrator.
SERVICES DISABLED section listing snapd and snapd.socket.
FIREWALL CONFIGURATION (UFW) section showing default deny incoming, allow outgoing, port 22 allowed, and logging enabled.
PASSWORD POLICY section showing 90 day max, 7 day min, 14 day warning.
DETECTED ATTACK INDICATORS section with attack type, target, source IP, failed login count, and evidence path.
SECURITY+ SY0-701 DOMAIN MAPPING section covering Domains 1 through 4 with your actions mapped to each.

Secret mission

Install Fail2ban for Automated Threat Response

You detected a brute-force attack by reading logs manually. But what if your server could fight back on its own? In this secret mission, install and configure Fail2ban to automatically ban attackers after repeated failed login attempts. This takes you from detection to automated response.

Clean Up Your Resources

This project runs entirely locally inside a UTM VM. There are no cloud resources or ongoing costs to worry about.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

UTM VM SecurityLab (Ubuntu Server 24.04.4 LTS with all hardening configurations, UFW rules, Fail2ban, and logs).
Ubuntu Server ISO file downloaded to your Mac (approximately 2.8-3.2 GB).

Keep everything running

No action needed. Choose this if you are still actively building or want to continue experimenting with your hardened server.

Your SecurityLab VM will remain in UTM, ready to start any time.
All your firewall rules, Fail2ban configuration, logs, and security-baseline.txt are preserved inside the VM.
The Ubuntu Server ISO stays on your Mac in case you want to create additional VMs later.

Pause - I'll come back to this later

Shut down the VM to free up system memory while keeping all your work intact.

In the VM console, run:

sudo shutdown now

The VM will power off. Your hardening configuration, firewall rules, Fail2ban settings, and logs are all saved to the virtual hard disk.
To resume later, open UTM and click the Play button (▶) on the SecurityLab VM.

Delete - I don't want to use this again

Remove all project resources and start fresh. This permanently deletes your VM and all files inside it.

If the VM is still running, shut it down first:

sudo shutdown now

In UTM, right-click the SecurityLab VM in the sidebar.
Select Delete.
When prompted, confirm to remove the VM and all its data.
Delete the Ubuntu Server ISO from your Downloads folder. Open Finder and navigate to Downloads.
Find the file named ubuntu-24.04.4-live-server-arm64.iso (Apple Silicon) or ubuntu-24.04.4-live-server-amd64.iso (Intel) and move it to the Trash.
Empty the Trash to reclaim the disk space.

Nice Work!

You just hardened a Linux server from a default install to a secure baseline, configured firewall rules, and detected a simulated attack through log analysis. These are the core hands-on skills that make up 28% of the CompTIA Security+ SY0-701 exam and the daily work of security operations professionals.

You've learned how to:

Harden an Ubuntu Server by disabling unnecessary services, enforcing password policies, and establishing a documented security baseline.
Configure a UFW firewall with a default-deny incoming policy, explicit SSH allow rules, and logging enabled.
Simulate a brute-force SSH attack and detect it by analyzing authentication logs for failed login attempts, source IPs, and timestamps.
Secret Mission: Install and configure Fail2ban to automatically ban IPs after repeated failed login attempts, moving from manual detection to automated incident response.

Ready to quiz yourself?