Scenario
A controlled security assessment of an old windows machine that a couple of years ago was converted into my first Fedora home server. The old Hewlett Packard All in One became very unreliable and was decommissioned as a server, and now is just a TV. SSH, Zerotier and Samba services were disabled recently as hardening measures. The intent of this experiment was to determine whether hardening was successful, and if there were any weak points on this machine. The test followed a defensive workflow: Discovery → Enumeration → Verification → Access Test → Privilege Assessment → Remediation → Re-test.
1. Network discovery
Host discovery across the local subnet identified several active devices, including the Fedora server selected for closer investigation.
sudo nmap -sn 192.168.1.0/242. Initial service enumeration
A restrained scan, rather than a full port sweep, was used first.
sudo nmap -sV --top-ports 20 -T3 192.168.1.111This found Apache HTTP Server running on TCP 80, serving Fedora’s default web content. Most other commonly scanned ports were filtered. In my rush to decommision the old HP server I had not disabled the old web server that used to run a basic home intranet page.
3. Web server enumeration
HTTP scripts and a direct request confirmed the default Fedora Apache test page and disclosed the Apache version.
sudo nmap -p80 -sV --script http-title,http-headers 192.168.1.111
curl -i http://192.168.1.111/4. Directory enumeration
Further enumeration found directory indexing enabled on a default Apache path.
sudo nmap -p80 --script http-enum 192.168.1.111A browser accessible /icons/ directory and a publicly accessible default README were exposed- unnecessary information disclosure, and a sign the server hadn’t been fully hardened.
5. Nikto web assessment
A broader Nikto scan added several hardening findings on top of the manual checks: Apache version disclosure, ETag information disclosure, a missing anti-clickjacking header, TRACE enabled, directory indexing, and default Apache files present. Common Apache diagnostic paths were manually tested and found not exposed; a positive finding.
nikto -h http://192.168.1.111Mostly configuration/hardening issues rather than evidence of active compromise.
6. Full TCP port scan
A full scan of the single target revealed an additional service on TCP 9090.
sudo nmap -p- -T3 192.168.1.111
sudo nmap -sV -p80,9090 --version-all 192.168.1.111Port 9090 was identified as an HTTPS-based administrative service. Probing the service confirmed it as Cockpit, Fedora’s web-based administration console which I remember now setting up but not using as I didn’t really have that much need for it at the time.
7. Authentication test (This!!)
The Cockpit login was tested against a few very old credentials previously associated with the server. It still authenticated, and the same stale credential could elevate the session to administrative access. This was the most significant finding of this cyber-experiment: a credential lifecycle failure, not an exploit. SSH was tested and was blocked showing that other hardening efforts were in place.
8. Remediation and Verification
The stale credential was replaced through Cockpit’s admin interface, and account access was reviewed. The apache web service was also disabled. The old credential was retried and no longer authenticated — administrative elevation via that path was gone. The new credential worked correctly.
Key Lessons
The server was already partially hardened — most ports filtered, SSH blocked, sensitive Apache diagnostics unavailable. But one exposed admin interface combined with an old, forgotten credential created a much more serious weakness than any of the individual configuration gaps. The biggest security improvement wasn’t new software or firewall changes — it was identifying and removing a forgotten credential that still had administrative power. Using very basic tools NMAP, Nikto and Curl was able to follow a workflow that led to a positive security outcome for my Homelab.