When a new server is provisioned — whether it is a VPS, a dedicated machine, or a cloud instance — it ships with defaults designed for broad compatibility, not for security. Those defaults are well-known to every automated scanner and attacker tooling available today. Leaving them in place is not a neutral choice: it is an open invitation.
At Solvanta, a significant portion of the infrastructure audits we perform reveal the same class of problems, regardless of the provider or the team that set the server up. This article covers the most common ones and why they matter.
SSH on Port 22 with Password Authentication
Port 22 is the first port every brute-force scanner checks. Within minutes of a new server going online, automated bots are already attempting logins using dictionaries of common passwords and usernames. If password authentication is enabled, the only thing standing between your server and a successful compromise is the quality of that password — and the patience of the attacker.
The correct configuration is straightforward: disable password authentication entirely, enforce SSH key-based access only, and move SSH to a non-standard port. Add Fail2Ban or equivalent to block repeated failed attempts, and restrict SSH access by IP where possible. None of this is complex — but it is almost never the default.
Open Ports with No Firewall Policy
A fresh Linux install exposes a variety of services that listen on open ports. Database servers, monitoring agents, and application runtimes often bind to all interfaces by default. Without an explicit firewall policy, every one of those ports is reachable from the public internet.
A correct firewall posture starts with a deny-all default rule and adds explicit allow rules only for the ports and source IPs that actually need access. Nginx on port 443? Allow it. MySQL on port 3306? Bind it to localhost only, or to a private network interface — it should never be reachable from the internet.
Unpatched System Packages
Operating systems and server software receive security patches continuously. A server that was hardened at deployment but never patched becomes progressively more vulnerable over time. The most damaging breaches in recent years — including major ransomware campaigns — exploited vulnerabilities for which patches had been publicly available for months.
Automated, tested patch management is not optional infrastructure. It is baseline hygiene. Unattended-upgrades for security patches on Debian/Ubuntu, or equivalent tooling for RHEL-based systems, keeps the attack surface from growing passively.
Root Login and Weak Privilege Boundaries
Running application processes as root, or allowing direct root SSH access, means that a single exploited vulnerability in any application gives an attacker full control of the entire machine. The principle of least privilege exists precisely to contain the blast radius of a compromise.
Every service should run under its own dedicated system user with the minimum permissions required to operate. Application directories, configuration files, and log paths should be owned appropriately. Root SSH access should be disabled. Privilege escalation via sudo should be explicit and logged.
Missing TLS or Misconfigured Certificates
Serving traffic over plain HTTP in 2025 is not just a trust signal failure — it exposes session tokens, credentials, and application data to anyone positioned between the client and server. Misconfigured TLS — expired certificates, weak cipher suites, SSLv3 still enabled — provides false assurance while leaving real vulnerabilities in place.
A correctly configured Nginx or Caddy instance with a valid certificate, strong cipher suites, HSTS enabled, and OCSP stapling is the minimum acceptable baseline. Certificate expiry should be automated — Let’s Encrypt with automated renewal is a solved problem that eliminates an entire class of outages.
No Intrusion Detection or Log Monitoring
A server with no alerting is a server where attacks succeed silently. Log files that are never reviewed offer no value. Without intrusion detection — even simple rules-based tooling like Suricata or OSSEC — lateral movement and data exfiltration can proceed undetected for weeks.
Effective monitoring does not require a large security operations budget. It requires structured log collection, alert rules for anomalous authentication patterns, and a clear escalation path when something triggers. The goal is shortening the time between a breach and detection.
What a Security Audit Actually Finds
When we perform a full infrastructure security audit at Solvanta, we approach it the way an attacker would: passive reconnaissance first, then active scanning, then manual review of configurations and access controls. The findings are risk-ranked and delivered with specific remediation steps — not a generic checklist.
The most common finding is not a sophisticated zero-day exploit. It is a combination of the defaults described above, left unchanged because no one was specifically tasked with changing them. Hardening a server is not technically complex — but it requires deliberate attention and expertise that most teams do not dedicate to it.
If your infrastructure has grown without a formal security review, or if you have servers that were set up years ago and have never been audited, contact us to request a security assessment. The audit process takes a few days and produces a clear picture of where you actually stand.