Hardening a Linux Server with UFW
- Introduction # 1.1 “Teaser” overview
In this project, I tested how a Linux host-based firewall changes the way a server appears during network reconnaissance.
Using Nmap, I scanned a TripleTen play-server before and after enabling UFW. Before the firewall was enabled, the server showed one open SSH port while the remaining scanned ports were closed. After UFW was configured, SSH remained available, but the other ports became filtered.
This simple before-and-after experiment helped me understand how firewall rules affect network visibility and how tools such as Nmap can be used to verify whether a defensive security control is actually working.
1.2 Introducing yourself to the cyber community
My background is in business administration, logistics, healthcare, and operations, so I am learning how to combine problem-solving and operational thinking with technical cybersecurity skills.
I am especially interested in defensive security and understanding how systems can be monitored, hardened, and tested in practical environments. This project gave me an opportunity to work directly with Linux, UFW, Nmap, and network traffic while learning from both the successful results and the mistakes I made during the process.
2. Setup
For this experiment, I worked in the TripleTen CloudShare lab environment. The main system I modified was the Linux play-server, while I used the Kali/Blue-Team workstation to perform Nmap scans against it.
Before making any firewall changes, I first verified the IP address of the play-server. I ran:
</> Bash
hostname -I
The play-server returned the IP address:
10.170.0.22
I then used the Kali workstation to perform a baseline scan of the server with:
</> Bash
nmap -sV 10.170.0.22
The baseline scan showed that TCP port 22 was open and running OpenSSH 9.6p1 Ubuntu. Nmap also reported that the other 999 ports in its default scan were closed.
Next, I returned to the play-server and checked the firewall status using:
</> sudo ufw status verbose
The result showed:
status: inactive
Because SSH was the only open service and I needed to preserve administrative access, I allowed TCP port 22 before enabling the firewall:
</> Bash
sudo ufw allow 22/tcp
I then enabled UFW:
</> Bash
sudo ufw enable
![[4_allow_SSH_port_22.jpeg]]
Finally, I verified the configuration using:
</> Bash sudo ufw status verbose
![[5_UFW_active_verbose.jpeg]]
UFW showed an active firewall with a default policy of deny incoming and allow outgoing, while TCP port 22 remained explicitly allowed.
Mistake I made during setup
During the setup process, I initially ran hostname -I on the Wazuh SIEM server instead of the play-server. The command returned several IP addresses, which made me realize that I was working on the wrong host.
I corrected the mistake by checking the terminal prompt, switching to the play-server, and running the command again. The correct play-server IP address was 10.170.0.22.
This mistake taught me that before running security or administrative commands, it is important to verify the hostname and confirm that I am working on the correct system.
3. Experiment time!
Experiment #1
Compare Open Ports Before and After UFW
The goal of this experiment was to see how enabling UFW changed the way the play-server responded to network scans.
I used the Kali/Blue-Team workstation to scan the play-server at:
10.170.0.22
Enter fullscreen mode Exit fullscreen mode
Before enabling UFW, I ran:
nmap -sV 10.170.0.22
Enter fullscreen mode Exit fullscreen mode
The first scan showed:
22/tcp open ssh
999 closed tcp ports
Enter fullscreen mode Exit fullscreen mode
Port 22 was running OpenSSH 9.6p1 Ubuntu.
After I configured UFW with a default deny incoming policy and allowed TCP port 22 for SSH, I repeated the exact same Nmap command:
nmap -sV 10.170.0.22
Enter fullscreen mode Exit fullscreen mode
The second scan showed:
22/tcp open ssh
999 filtered tcp ports
Enter fullscreen mode Exit fullscreen mode
This was an important difference.
Before UFW was enabled, the unused ports were reported as closed, meaning the server was directly responding to the scan and indicating that no service was listening on those ports.
After UFW was enabled, those same ports were reported as filtered, meaning Nmap did not receive a response from them. This showed that the firewall was now blocking or dropping unsolicited incoming traffic.
At the same time, TCP port 22 remained open because I had explicitly allowed SSH traffic before enabling the firewall.
Results
The experiment produced a clear before-and-after comparison:
Scan Port 22 Other 999 ports Before UFW Open Closed After UFW Open FilteredThe results confirmed that UFW was working as intended. It protected the server from unnecessary incoming traffic while still allowing the service that was required for administration.
4. Conclusion
4.1 Summary of experimental findings
The three experiments showed how UFW affected the play-server from both a network and logging perspective.
In Experiment #1, I compared Nmap scans before and after enabling UFW on the play-server at 10.170.0.22. Before UFW, port 22 was open for SSH and the other 999 scanned TCP ports were closed. After enabling UFW with a default deny incoming policy, port 22 remained open while the other ports changed to filtered. This confirmed that the firewall was reducing unnecessary network exposure while preserving required access.
In Experiment #2, I tested legitimate SSH access after the firewall was enabled. The SSH connection succeeded, and the Linux logs recorded the authentication with an Accepted password message. I also checked Wazuh and found that the play-server was not listed as an enrolled agent, which showed me that local logs are only useful to a SIEM if they are actually being collected centrally.
In Experiment #3, I tested blocked traffic to TCP port 80. Nmap reported the port as filtered, Netcat timed out, and the UFW logs recorded [UFW BLOCK] entries with DPT=80. This confirmed that the firewall was actively blocking unauthorized traffic and recording the event.
Overall, these experiments showed me how firewall configuration, network testing, and log analysis work together to validate security controls.
5. Final thoughts
5.1 The coolest thing I learned
The coolest thing I learned was seeing the difference between closed and filtered ports in a real scan. Before enabling UFW, Nmap showed 999 ports as closed. After enabling the firewall, those same ports appeared filtered.
5.2 One piece of advice
My advice to someone doing a similar project is to always verify the system you are working on before running commands and to test security changes from more than one angle.
I initially checked the IP address on the Wazuh SIEM instead of the play-server, which caused confusion. Checking the hostname first would have prevented that mistake.
I would also recommend protecting required services before enabling firewall rules. Allowing SSH on port 22 before activating UFW helped me avoid locking myself out of the server.
Finally, do not assume that a change worked just because the command completed successfully. Test it, check the logs, and compare the results.
5.3 My favorite resource
My favorite resource was the Nmap documentation because it helped me understand what the scan results actually meant.
Learning the difference between open, closed, and filtered ports made the before-and-after results much easier to interpret. I was also able to use Nmap together with Netcat and UFW logs to verify that traffic to port 80 was being blocked.
The Ubuntu/UFW documentation was also valuable because it helped me understand how to configure firewall rules safely, preserve SSH access, enable logging, and verify the firewall status.
5.4 Thank you (gratitudes)!
I would especially like to thank Jean Fobe, my TripleTen instructor, for reviewing my project plan and helping me look at the project from a broader perspective. His guidance helped me see how the firewall modification, network experiments, and monitoring results could work together as one complete security story rather than as separate technical tasks.
I am also grateful to the TripleTen instructors and tutors who provided the lab environment and guidance that allowed me to practice these concepts hands-on.
I would also like to recognize Gordon “Fyodor” Lyon and the Nmap Project for creating and documenting Nmap. Their work helped me understand network reconnaissance and the difference between open, closed, and filtered ports.
Finally, I appreciate the contributors to the Ubuntu/UFW and Wazuh documentation. Their documentation helped me configure the firewall safely, interpret the logs, and better understand how endpoint monitoring connects to a SIEM.
6. Annotated resources
- TripleTen Sprint 11 — System Hardening and Security Project
Title: TripleTen Sprint 11 — Deploy a SIEM / System Hardening and Basic Security
Author: TripleTen Curriculum Team
Affiliation: TripleTen
Date published: Not listed
Date accessed: September 3, 2026
Why useful: This course material provided the structure for my project, including the requirement to make a security modification and test it through multiple experiments. It helped me connect firewall configuration, monitoring, and security validation.
2. Nmap Network Scanning
Title: Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning
Author: Gordon “Fyodor” Lyon
Affiliation: Nmap Project / Nmap Software LLC
Date published: January 1, 2009
Date accessed: September 3, 2026
Why useful: This resource helped me understand how Nmap can be used for network discovery and security validation. I used Nmap throughout the project to compare the play-server before and after enabling UFW.
3. Nmap — Port Scanning Basics
Title: Port Scanning Basics
Author: Gordon “Fyodor” Lyon / Nmap Project
Affiliation: Nmap Project
Date published: Not separately listed on the online chapter
Date accessed: September 3, 2026
Why useful: This was especially useful for understanding the difference between open, closed, and filtered ports. It helped me explain why 999 ports changed from closed before UFW to filtered after UFW was enabled.
4. Ubuntu Server — Firewall / UFW Documentation
Title: Firewall — Ubuntu Server Documentation
Author: Ubuntu Documentation contributors
Affiliation: Canonical / Ubuntu
Date updated: June 26, 2026
Date accessed: September 3, 2026
Why useful: This resource explained how UFW works as Ubuntu’s host-based firewall and showed how to enable it and allow required ports. It supported commands such as sudo ufw enable and allowing SSH on TCP port 22.
5. UFW Manual Page
Title: ufw — Program for Managing a Netfilter Firewall
Author: Ubuntu/Linux documentation contributors
Affiliation: Ubuntu / Linux community
Date published: Not listed in the manual used during the lab
Date accessed: September 3, 2026
Why useful: The UFW manual was useful for checking command syntax and understanding options such as allow, enable, and status verbose. It helped me safely configure and verify the firewall during the experiment.
6. Wazuh Agent Enrollment Documentation
Title: Wazuh Agent Enrollment
Author: Wazuh Documentation Team
Affiliation: Wazuh
Date published: Not listed
Date accessed: September 3, 2026
Why useful: This resource helped me understand why the play-server’s SSH activity did not appear as its own agent in Wazuh. Wazuh explains that an endpoint must have an agent enrolled with the manager before it can send security information for centralized analysis.