Hello folks my name is David, and before I found myself staring at a computer for hours happy and giggling like a middle schooler I was a chef. People pleasing and long hours was the name of the game. As a kid I was shown IT concepts and actual wiring by my father for his enjoyment. I took interest in it but later on wanted my own path, which went from cooking and now back here, therefore I kind of went in a circle. However this is not what I was shown specifically and I'm currently working my way into the cybersecurity community. This blog is one of my big steps to completing that goal.
I'm currently attending Tripleten courses and with the pace I'm on, I have no doubt about my accomplishments. Therefore I chose the modification and experiments due to either not experiencing them yet or to dive deeper into the field and learn more. System hardening is a crucial cybersecurity practice aimed at reducing a system's vulnerability surface and closing security gaps as a main line of defense. The core strategy rests on four key objectives: reducing the attack surface by removing unnecessary software and ports, enforcing the principle of least privilege for users and processes, removing predictable default credentials, and applying a robust defense-in-depth framework using layered controls like firewalls, encryption, MFA, and EDR.
Therefore in order to turn these concepts into practical execution, this baseline transitions into three specialized hands-on experiments: configuring granular network traffic boundaries with UFW, running automated compliance and security posture checks using Lynis, and establishing deep, correlation-ready system logging through Auditd. All together, these layers ensure a comprehensively locked-down, actively monitored, and highly resilient infrastructure.
Implementing foundational System Hardening and Basic Security prior to SIEM deployment creates a secure, clean-log baseline that prevents alert fatigue and protects log integrity. It took four steps. Step one is minimizing the attack surface by auditing server packages and running services. Unhitching unused software and disabling non-required daemons eliminates software vulnerabilities that automated bots target before they ever reach your SIEM ingestion pipeline. In doing this, I made my first mistake by not knowing which software to keep in CloudShare, assuming standard cleanup was already handled.
The second step enforces least privilege, strictly restricting user and service account permissions. This ensures accounts running SIEM forwarders only possess read access to target logs, preventing full-system compromise via lateral movement. Step three eliminates default credentials by changing factory defaults and removing hardcoded credentials from config files, blocking unauthorized administrative access. Finally, step four applies defense in depth by layering independent security controls, such as deploying host firewalls like UFW for network boundaries, enforcing disk encryption, and requiring multi-factor authentication.
Experiment #1: The Uncomplicated Firewall (UFW) experiment on the CloudShare blue team workstation, I initiated the process by installing and checking the initial status of the firewall using sudo apt install ufw and sudo ufw status, which correctly showed an inactive status. I then successfully secured incoming and outgoing traffic by setting default policies to deny incoming connections via sudo ufw default deny incoming and allow outgoing traffic with sudo ufw default allow outgoing to ensure system updates could proceed. Next, I implemented explicit, granular allow rules by opening TCP port 22 for secure SSH access (sudo ufw allow 22/tcp) and TCP port 80 for application services (sudo ufw allow 80/tcp). Afterward, I enabled the firewall with sudo ufw enable and verified the active configuration using sudo ufw status verbose.
While the experiment completed successfully, I noted a few key areas for improvement and minor conceptual mistakes. First, I mistook the default inactive status of UFW as an emerging problem before realizing it was simply the expected initial state prior to enablement. Second, I reflected that my hardening goals were overly basic and lacked the depth required for production-level security. For future implementations, I plan to move beyond generic configurations and establish more specific, threat-informed objectives to make the security posture more robust and aligned with serious operational environments.
Experiment #2: This labs first step involved opening the terminal in the Blueteam workshop to install the security auditing tool using the command sudo apt install lynis and confirming the prompt with "y". Next, a standard system scan was initiated with sudo lynis audit system, which created real-time output detailing current configurations and settings, concluding with a summary of findings and prioritized recommendations.
Though despite encountering initial issues with Cloudshare, the experiment proceeded smoothly, and all commands performed as expected. The system scan returned more recommendations than anticipated. Therefore I chose the randomized selection of OpenSSH hardening recommendation 7408 as an illustrative example to expand the practical exercise. Implementing this hardening involved opening the SSH configuration file, applying key settings, verifying the configuration, restarting the SSH service, and testing a new SSH connection in a separate terminal to ensure successful login access.
Although the notes read that the final step is defining success criteria and documentation, it was tailored for an experimental framework. The objective was simply to achieve successful implementation. In the event of a failure, the plan was to document and theorize the potential causes. Overall, the experiment required no corrections to mistakes regarding execution, as all steps and the subsequent OpenSSH hardening follow-through were carried out successfully without operational errors, providing valuable hands-on growth for future cybersecurity career readiness.
Experiment #3: The lab exercise I began, by launching CloudShare and opening the blue team workstation terminal to configure the auditing service. My first attempt to enable the service using sudo systemctl enable --now auditd failed because the package was not pre-installed on the system. To resolve this, I then tried the incorrect command sudo dnf install -y audit audit-libs audi, which resulted in a "package not found" error because of a syntax typo and package manager mismatch. Once I realized the mistake, I switched to the correct package manager command, sudo apt install auditd audispd-plugins. This prompted for download permissions and installed the required dependencies.
Once the installation was complete, I retried the original command, sudo systemctl enable --now auditd, which successfully enabled and started the service. Moving to the second phase, I configured the audit rules and file monitoring using sudo augenrules --load. Then to verify log generation and test event triggers, I successfully executed sudo ausearch -i -ts recent to review the generated logs. Finally, I concluded the experiment by defining my success criteria and documenting the results.
After I had found the right install command in order to enable the auditd after two more attempts.
In summary of experiment 3, my first two attempts encountered hurdles due to a missing package and an incorrect installation command. Once these initial setup mistakes were corrected, the workflow proceeded smoothly, allowing me to successfully monitor logs, trigger test events, and confirm that all installations and changes were correctly applied.
In conclusion across these three security experiments, the procedures involved configuring the Uncomplicated Firewall (UFW), auditing the system with Lynis, and setting up the Auditd service. While each experiment ultimately reached its objectives, several mistakes and hurdles occurred during the initial setup phases.
In the UFW lab, a minor conceptual mistake involved temporarily misinterpreting the firewall's default inactive state as a system error, alongside utilizing basic hardening goals that lacked production depth. The Lynis audit progressed smoothly without execution errors, even though it returned an unexpectedly high volume of security recommendations. It prompted me to choose the OpenSSH hardening recommendation during that exercise. Finally, the Auditd experiment encountered immediate roadblocks due to a missing pre-installed package. This led to a syntax and package manager error, using dnf instead of apt, which was quickly corrected by utilizing the correct package manager.
Therefore, resolving these initial setup mistakes, installation typos, and baseline misunderstandings allowed each security control to be successfully deployed, verified, and documented. The best way to avoid the mistakes I made was to slow down and read carefully. This doesn't mean missing deadlines at the cost of mistakes, but instead looking for any details within your notes or directions that will ensure you are on the right path. Taking a breath and keeping a level head helps ensure you input the correct commands or stop yourself before entering the wrong ones.
The coolest thing I learned during this was how to maneuver and play with these system hardening techniques. Despite two including audits, the commands and logs that appeared showed me how to engage differently for protecting against different issues. For anyone new entering this field or just trying to learn for personal use, it is important to take your time. There may be problems down the line that require immediate attention and solutions. However, if you are able to breathe and analyze, you'll find better solutions and make fewer mistakes.
My favorite resource throughout this project was cisofy, despite me needing this for only one experiment. It showed different valuable steps and information that allowed me to stay organized with a clear plan to follow through. I'd like to thank two of the Tripleten staff who helped me throughout the project: Mrs. Abygayle Ivey, who initially answered my concerns on how to go about the blog and gave me great references to look at, and Mr. Rick Rhabum, who helped fix my CloudShare blue team workstation so that I could continue my experiments as well as gave me alternative options if my setups were to fail.
Lastly, I'd like to thank Nate and Scott from Red Hat Enterprise Linux; the video Understanding Linux logs and audits Opens in a new window I watched was deeply informational and easy to follow along with thanks to the visuals and clear explanations.
References (used)
Title: 1:1 Zoom Mentorship Lesson Author: Abygayle Ivey (TripleTen) Date: Course Session Date
How it helped: Helpful for clarifying initial blog formatting structure and receiving reliable academic and technical references to guide the project.
Title: Group Office Hours Troubleshooting Session Author: Rick Rhaburn (TripleTen) Date: Course Session Date
How it helped: Needed for fixing CloudShare Blue Team workstation issues and providing backup options to keep the security experiments moving forward.
Title: Lynis Security Control SSH-7408 (OpenSSH Hardening) Author: CISOfy Date: Accessed 2026
How it helped: Provides specific compliance checks and actionable guidance for hardening SSH configurations during system audits.
Title: Lynis Documentation Author: CISOfy Date: Accessed 2026
How it helped: Serves as a comprehensive manual for understanding Lynis commands, automated compliance checks, and security posture scanning.
Title: Understanding Linux logs and audits | Into the Terminal 140 Opens in a new window Author: Red Hat Enterprise Linux (Nate and Scott) Date: Published 2025
How it helped: Offers clear, step-by-step visual explanations of Linux system logs and Auditd rule configurations that make complex terminal tools easy to follow.
Title: Stop Flying Blind: Why You Need to Supercharge Your Windows Event Logs Author: 0x2A Security Date: 2026
How it helped: Provides great referencing on how blog should go. Also context on log management and ingestion pipelines, highlighting the importance of capturing high-fidelity security telemetry.
Title: How to: Secure My Firewall in Linux
Author: LinuxSecurity
Date: December 10, 2025
How it helped: It provides a clear, foundational guide on how to approach Linux firewall configuration with UFW, making it easier to understand basic network boundaries and initial setup logic.
Top comments (0)