Reducing the Attack Surface Without Rebuilding the Server

The situation

A client had a Linux server running core business services. The server was accessible over the internet and was running SSH, a web application, and several internal services. The client was concerned about security but unsure where to start.

I reviewed the server configuration. The initial checks revealed a pattern that was common and also risky:

• SSH password authentication was enabled.
• The firewall was configured with broad rules.
• Several services were exposed to the internet that did not need to be.
• System updates were not being applied regularly.

The server was not compromised. It was also not secured.

The investigation

I mapped the server's exposure and current configuration. The goal was to understand what was accessible and what the potential risks were.

The SSH configuration was the first concern. Password authentication over the internet is a known risk. Automated scanning tools regularly probe for weak passwords. The server logs showed repeated failed login attempts from multiple IP addresses.

The firewall rules were also too permissive. Services that should have been limited to internal access were exposed externally, increasing the attack surface unnecessarily.

The DNS configuration contained stale records that could have been used for subdomain takeover or misrouting. The server also had outdated packages with known vulnerabilities.

The changes

I implemented the following changes:

• SSH was reconfigured to use key-only authentication, and password authentication was disabled.
• The firewall rules were reviewed and refined so only necessary services were exposed externally.
• System updates were applied and a regular patching schedule was established.
• DNS records were audited, and stale or unnecessary records were removed.
• A monitoring process was put in place to track future changes and detect unusual activity.

The result

The server's attack surface was reduced significantly. The changes were verified using before and after configuration comparisons and scanning tools to confirm that the exposed services had been reduced.

The client received a documented summary of what was changed, why it was changed, and what should be monitored going forward.

What I learned

This case reinforced something I have observed across many environments: small configuration decisions accumulate into larger security posture.

Enabling SSH password authentication over the internet is a single configuration option. Leaving it enabled indefinitely is a habit, and that habit creates unnecessary risk.

Hardening a system does not always require rebuilding it. It can also involve reviewing existing configurations, removing what is not needed, and establishing regular maintenance habits.

Technical takeaway

The investigation and changes involved:

• SSH configuration review and hardening
• Firewall rule analysis and refinement
• Package management and system update scheduling
• DNS record audit
• Before and after verification

The same approach can be applied to most infrastructure environments: map the exposure, reduce the attack surface, and establish ongoing maintenance processes.