Internet-facing servers eventually attract unsolicited login attempts and automated probes. Before deploying application code, start with a supported operating system, a non-root administrator account, and only the services the server actually needs.
Start with a small, maintained system
Choose a reputable Linux distribution with predictable security updates and a support period that matches the server’s expected lifespan. Minimal installation images are often a sensible choice for servers: every extra package adds code, configuration, and maintenance work.
During provisioning, record the hostname, operating system version, server role, owner, and recovery contact. That small inventory is useful when an alert appears months later or a package reaches end of support.
Apply available updates immediately, then set a routine for keeping the system current. On Debian- and Ubuntu-based systems, this commonly starts with sudo apt update followed by sudo apt upgrade. Review the upgrade output, particularly in production, because service changes or configuration prompts may need attention.
Use separate accounts and least privilege
Avoid using root for routine administration. Give each administrator a named account and grant elevated access through sudo. Individual accounts make audit logs useful: they show who made a change instead of recording a shared superuser session.
Grant only the access needed for a specific task. A deployment account may need to restart one application service, while a database administrator may need limited access to database tools. Where practical, avoid shared passwords and generic operational accounts.
Protect credentials and recovery paths
- Use unique, long passwords for local accounts when password authentication is required.
- Store SSH private keys and recovery codes in a protected password manager or another approved secure location.
- Remove accounts promptly when someone leaves a project or no longer needs access.
- Review membership in privileged groups such as
sudo,wheel, and service-specific administrator groups. - Keep an approved console or provider recovery method available before changing remote-access settings.
Secure remote administration deliberately
SSH is usually the main remote entry point on a Linux server. Key-based authentication is generally stronger than reusable passwords and is easier to manage safely when private keys are protected. A separate guide on securing SSH access on a Linux server covers SSH-specific settings and a safe rollout process.
Before disabling password login or root login over SSH, test key-based access in a second terminal session. Leave the existing session open until the new login succeeds. A minor configuration mistake should not turn into a lockout.
Restrict SSH access where possible. A private management network, VPN, or allowlist of known administrative addresses reduces exposure. These measures do not replace strong authentication, but they limit which systems can reach the service.
Expose only necessary network services
Every listening port should correspond to a known service and a clear business need. Check listening sockets after installation and whenever you add software. Commands such as ss -tulpn help administrators identify services bound to network interfaces. Run these checks only on systems you own or are authorized to administer.
Use a host firewall that denies inbound traffic by default: allow required ports, restrict management ports, and block everything else. On a typical web server, public rules might allow HTTPS and, if needed, HTTP for redirects, while SSH is limited to a management network. The blog’s guide to safer UFW and firewalld rules explains the core firewall concepts in more detail.
| Service | Typical exposure | Safer approach |
|---|---|---|
| SSH | Administrators only | Keys, named accounts, restricted source networks |
| Web service | Public users | HTTPS, timely updates, minimal web server modules |
| Database | Application hosts only | Private interface or network rules; never public by default |
| Monitoring agent | Monitoring platform | Authenticated connection and limited inbound access |
Harden services, not just the operating system
A fully patched operating system cannot compensate for an unsafe application configuration. Disable software you do not use and stop unnecessary services from starting at boot. For services that remain active, use dedicated unprivileged accounts, restrictive file permissions, and separate configuration from secrets.
Keep passwords, API tokens, and private keys out of source repositories. Limit read access to the account that needs each secret. Environment files and service-manager credential features can help, but they still require appropriate ownership and backup handling. Never paste secrets into ticket comments, shell history, or public build logs.
For web-facing applications, terminate encrypted connections with current TLS settings and renew certificates before they expire. Protect administrative dashboards with authentication and network restrictions; an obscure URL is not a security control.
Make patching, logs, and backups operational
Security maintenance is ongoing. Enable trusted update mechanisms where appropriate, but know what they update and monitor their results. Kernel updates and critical library upgrades may require a planned reboot, so schedule maintenance windows and communicate the expected impact to users.
Centralized or protected logging can preserve evidence if the server is damaged or misconfigured. At a minimum, review authentication logs, service errors, package-management activity, and disk-space alerts. Set sensible retention periods and confirm log rotation works. A full filesystem can stop applications and prevent useful auditing.
Backups need restoration tests
A backup matters only if it contains the required data and can be restored within the required time. Back up application data, databases, critical configuration, encryption keys where policy permits, and deployment documentation. Encrypt backup storage, restrict access, and keep at least one copy separate from the server and its primary hosting account.
- Define what must be restored: files, databases, configuration, and identity-related data.
- Set a schedule that matches how quickly the data changes.
- Monitor backup jobs for failures and unexpected size changes.
- Restore a sample into an isolated, authorized test environment.
- Document the measured restore time and any manual steps.
Verify the baseline after each change
Keep a short hardening checklist and revisit it after major changes: confirm the supported release, applied updates, privileged accounts, firewall rules, service inventory, backups, and log monitoring. Configuration management can make these checks repeatable, but a maintained document is still better than relying on memory.
After changing remote access, firewall policy, or a critical service, test from an authorized management host. Confirm that the intended service works and unintended access is blocked. Record the change, the configuration file or command used, and a rollback step. Those notes can make the difference between a quick recovery and a prolonged incident.
