Background
During some of the meetings the principal mentioned that the lyceum had acquired a public server two to three years earlier and its security had never been formally checked. I proposed carrying out this assessment as a natural next step in the internship.
Before starting I made sure the scope was clearly bounded and documented in writing. No exploitation, no brute-forcing (repeatedly guessing passwords until one succeeds) and no configuration changes. This was Blue Team work, meaning the objective was to identify and report weaknesses rather than to attack the server or fix anything directly.
Approach
I used nmap to scan the server and identify which ports were open. A port is essentially a numbered channel the server uses for a specific service, such as web traffic or email. Alongside nmap I used curl, lftp, the mariadb client and dig to examine individual services more closely. Together these tools let me map out what the server actually exposed to the outside world. The machine runs OpenResty, a web server platform, behind a fairly extensive stack of services including HTTP, HTTPS, DNS and MySQL running simultaneously. None of these services are unusual by themselves, but this setup had not been mentioned to me beforehand, so it was not something I expected to find. Each open port raised its own set of questions and needed to be evaluated individually rather than assumed safe by default.
Key Concerns
Two main concerns emerged from this work.
Anonymous FTP accepted connections without requiring any credentials, meaning anyone could log in without a username or password. In addition, MySQL, the database that stores information for the site, was reachable directly from the internet on its default port. The fact that it rejected unencrypted connections was a mitigating factor, not a justification. A database engine should not be exposed on a public interface at all, encrypted or not.
The server disclosed its exact software version through HTTP headers, small pieces of metadata sent with every web page request. Knowing the exact version gives an attacker a head start, since known vulnerabilities for that version can be looked up directly instead of guessed at. There were also unencrypted mail ports left open, alongside two additional ports, 26 and 8888, whose purpose could not be confirmed remotely.
Reporting
I also put effort into the reporting itself. I built a table ranking each finding by severity, explained why each issue mattered rather than simply listing it and included a concrete remediation plan so that whoever acts on this next does not have to guess what to prioritize.
Course Connection
This task drew directly on material from Web Technologies and Introduction to Cyber Security. Those courses shaped how I interpreted the HTTP header findings, how I distinguished plaintext services (unencrypted and readable by anyone intercepting the traffic) from encrypted ones, and why an internet-facing database is a structurally poor decision regardless of how strong its authentication is. This also relates to the concept of cell-level hashing, where individual data fields are combined with additional values to produce a unique fingerprint, making stolen data significantly harder to reuse even if an attacker gains access to it.
Impact by Security Principle
To make the impact clearer, I framed the findings using the three core principles of information security:
- Confidentiality (keeping data private): anonymous FTP combined with unencrypted mail creates a real risk of information exposure.
- Integrity (keeping data accurate and untampered): version disclosure combined with unnecessary open ports increases the risk of server compromise or defacement of the student council site.
- Availability (keeping the service running): a publicly reachable MySQL instance is vulnerable to attacks that could crash the database, potentially taking the student council website offline during election season.
Summary of Findings
| Severity | Port | Finding |
|---|---|---|
| High | 21 | Anonymous FTP authentication accepted |
| High | 3306 | MySQL publicly exposed to the internet |
| Medium | 80 | Server version disclosed in HTTP headers, unencrypted HTTP available |
| Low | 110, 143 | Unencrypted POP3 and IMAP available alongside encrypted versions |
| Informational | 8888 | Service unidentified, connection timed out |
| Informational | 26 | Non-standard port, purpose unconfirmed |
| None | 53 | DNS correctly configured, not an open resolver |
(A part of the security report 2026-28-07)
Applying This to the Student Council Website
These findings also gave me a practical basis for improving the student council website's own security posture:
- Enable HTTP Strict Transport Security (HSTS) on the landing page, so browsers never load the site over plain HTTP and student login credentials are never transmitted unencrypted.
- Add rate-limiting to the login forms, for example five attempts per ten minutes, to slow down and discourage password-guessing attacks.
- Audit the site for headers such as
X-Powered-By: PHPor similar generator tags that reveal the underlying technology stack, and remove them where possible. - Store passwords using bcrypt or Argon2 with unique salts (random values mixed into each password before hashing), so that even if the MySQL exposure I identified were exploited, the stolen password data would remain computationally impractical to crack.
Comments (0)
no comments yet.