Linux server hardening is the process of reducing the ways an attacker can enter, operate within and persist on a server. It is not a single configuration change or a product that can be switched on. It is a sequence of decisions about what the server runs, who can access it, which network connections it accepts, how activity is recorded and how quickly weaknesses are corrected.
For agencies and businesses, hardening should happen before a server reaches production. A newly installed server may contain default accounts, listening services, broad permissions and management interfaces that were convenient during setup but are unnecessary in normal operation. Every unnecessary component increases the attack surface and creates another setting that must be maintained.
This guide presents a practical baseline for Linux server hardening on customer-controlled VPS and dedicated servers. The exact commands differ between distributions such as Debian, Ubuntu, Rocky Linux, AlmaLinux and others, so treat the examples as configuration concepts rather than copy-and-paste instructions. Test changes on a non-production system, keep an out-of-band recovery path and document what has been changed.
Start with a minimal, known installation
The safest server is usually the one that does less. Begin with a supported Linux distribution and a minimal installation that includes only the operating system components and tools required for the intended workload. A web server, database server, application server and monitoring node do not need identical packages or services.
Record the operating system version, repository sources, installed packages, enabled services, network interfaces and intended roles. This inventory establishes a baseline. Without it, an administrator may not notice that a package has been added, a service has started listening or a configuration has drifted.
Remove what the workload does not need
Review installed packages and remove software that is not required. Common examples include unused mail transfer agents, legacy network utilities, graphical components, compilers and temporary administration tools. Do not remove a package merely because its name is unfamiliar: first establish whether another service depends on it and whether it is needed for patching, monitoring or recovery.
Disable services that are not part of the server's role. A service that is installed but not required can still expose a network port, process untrusted input or contain a vulnerability. An unused administrative interface is particularly risky because it may retain default settings while receiving little attention.
On systemd-based distributions, administrators commonly review service state with tools such as systemctl and inspect listening sockets with ss. The objective is not to make the service list as short as possible at any cost. The objective is to make every running service intentional, owned by someone and covered by a patching and monitoring process.
Build a timely patching process
Unpatched software is one of the most reliable ways for attackers to exploit a known weakness. Linux server hardening therefore includes the operating system, kernel, installed packages, language runtimes, web servers, databases, container images and applications. A server can have a carefully configured firewall and still be compromised through a vulnerable service that accepts legitimate network traffic.
Subscribe to security notifications for the distribution and the major software components that you operate. Define who reviews advisories, how severity is assessed and how quickly updates are applied. Critical internet-facing vulnerabilities may require emergency action, while lower-risk changes can follow a scheduled maintenance window.
Balance speed with change control
Automatic security updates can reduce exposure time, but they can also introduce compatibility problems. They are often appropriate for selected operating system security packages, provided that administrators have monitoring, rollback procedures and a way to handle reboots. For application stacks with strict dependencies, a controlled update pipeline may be safer.
Document the trade-off. A policy might state that security patches are applied within a defined period, that kernel reboots occur during an agreed maintenance window and that emergency updates can override normal scheduling. The important point is to avoid an informal process where updates depend on someone remembering to log in.
After patching, verify that services restarted correctly, certificates remain available, application dependencies work and the server is reporting to its monitoring system. A patch that leaves a critical service stopped is technically applied but operationally unsuccessful.
Use separate users and least privilege
Least privilege limits the damage caused when an account, process or application is compromised. Users should receive only the access needed for their responsibilities, for only as long as it is needed. Avoid shared administrator accounts because they make attribution difficult and encourage credentials to be reused.
Create named accounts for administrators and separate service accounts for applications. A web application should not normally run as root, and a database process should not have write access to unrelated application directories. Service accounts should have non-interactive shells where appropriate and should not be members of administrative groups unless there is a specific, documented requirement.
Review users, group memberships, home directories, login shells, SSH keys and last-login data regularly. Remove accounts belonging to people who have left the project, rotate access when responsibilities change and set an owner for every privileged account. Temporary access should have an expiry process rather than becoming permanent by accident.
Control sudo carefully
sudo is safer than giving every administrator the root password, but a broad sudo rule can be almost equivalent to unrestricted root access. Grant administrative permissions to named users or tightly managed groups. Where practical, allow specific commands rather than an unrestricted command prefix, and avoid rules that let a user edit arbitrary configuration files or execute a shell through another program.
Require authentication for privileged actions unless there is a documented operational reason not to. Keep sudo activity in central logs and review it for unusual times, commands or accounts. Be careful with scripts: a permitted script that reads user-controlled input, searches an unsafe path or calls another program without an absolute path may provide an indirect route to privilege escalation.
Least privilege can slow incident response if it is designed without emergency procedures. Administrators should document how to obtain elevated access during an outage, who approves it and how the access is reviewed afterwards. Security controls that nobody can use during a genuine incident tend to be bypassed when pressure is high.
Harden SSH without losing access
SSH is often the primary management path to a Linux server, so SSH hardening should be deliberate and tested. Before changing the daemon configuration, open a second administrative session and keep console or provider-level access available if the platform offers it. Validate the new configuration before restarting the service.
Use SSH keys rather than password authentication for administrative access. Keys make automated attacks against weak passwords less effective, particularly when protected by a passphrase and managed through an agent or approved secrets process. Protect private keys as credentials: do not store them in shared folders, source repositories or unmanaged workstations.
For a customer-controlled server, a basic SSH baseline commonly includes:
- Disabling direct root login over SSH.
- Disabling password authentication after key-based access has been tested.
- Restricting SSH access to named users or an administrative group.
- Using a current SSH protocol and supported cryptographic algorithms.
- Limiting access through a management network, VPN or narrowly defined source addresses where possible.
- Setting sensible connection and authentication timeouts.
- Recording failed and successful authentication events.
Changing the SSH port can reduce noise from unsophisticated scanners, but it is not a security boundary. It should never substitute for key authentication, access restrictions and patching. Similarly, tools that automatically block repeated login attempts can help with brute-force traffic but may block legitimate administrators if thresholds and trusted sources are poorly designed.
Disable root login and test recovery
Direct root login removes accountability and gives an attacker a high-value target. Set PermitRootLogin to no once an alternative administrative account has been tested. The test should include a fresh login with the intended key, sudo access, access from the normal management network and the emergency access procedure.
Do not close the existing session until the new route is confirmed. A small syntax mistake, an incorrect group name or a restrictive AllowUsers rule can lock out the entire team. SSH hardening is successful only when it improves security without removing the ability to administer and recover the server.
Apply a default-deny firewall configuration
Firewall configuration reduces the number of network paths that reach a service. A practical baseline is to deny unsolicited inbound traffic by default, allow only required ports and permit outbound traffic according to the workload and organisational policy. The right policy depends on the service: a public web server may need HTTP and HTTPS, while a database should generally accept connections only from defined application hosts.
Use the host firewall as one layer, even when a cloud provider or network edge also supplies filtering. Multiple layers can limit the impact of a mistake in one location, but they must be documented so that administrators understand where a connection is being allowed or denied. Common Linux firewall tools include nftables, firewalld and distribution-specific front ends.
For each allowed rule, record:
- The source networks or hosts that are permitted.
- The destination port and protocol.
- The service owner and business purpose.
- Whether the rule is temporary or permanent.
- How the rule will be reviewed and removed.
A rule such as “allow the database port from anywhere” creates a broad attack path even if the database requires a password. Restrict administrative services to trusted networks where possible. If remote administrators need access from changing locations, consider a VPN, a controlled bastion host or another managed access route rather than exposing every management port to the internet.
Test firewall changes from an approved external location and from the application network. Confirm that required traffic works and that unauthorised traffic is rejected. Also test after rebooting, because a firewall that is not persistent can leave the server exposed after maintenance.
Protect files, secrets and application data
Secure file permissions prevent one account or service from reading or modifying another service's data. Begin with ownership. System files should normally be owned by root or the appropriate system account, while application directories should be writable only where the application genuinely needs to write.
Avoid using broad permissions such as 777 for directories or files. They allow every local user and compromised process to read, change or execute content. Configuration files containing database credentials, API keys or private certificates should be readable only by the account or group that requires them. Private SSH keys should be protected with restrictive permissions and should not be placed in web-accessible directories.
Separate code, configuration, uploads, logs and temporary files where practical. User-uploaded content should not automatically be executable. Web server document roots should not contain deployment secrets, source control metadata, backup archives or environment files. If an application needs to write uploads, give it a dedicated directory and consider controls that prevent uploaded scripts from being executed.
Manage secrets deliberately
Do not put passwords in shell history, tickets, source repositories or ad hoc scripts. Use a secrets manager or another controlled mechanism appropriate to the organisation. Rotate credentials when staff leave, when exposure is suspected and according to the risk of the system. Record which services depend on each secret so that rotation does not become an outage exercise.
File permissions are not a substitute for encryption. If an attacker obtains root access, local permission boundaries may no longer protect data. They remain important because many incidents begin with a lower-privileged application account, a stolen user credential or an overly permissive local process.
Isolate services and reduce lateral movement
Service isolation limits what an exploited component can reach. Run each major service under its own account and restrict its filesystem, network access and Linux capabilities. Depending on the workload, isolation may use systemd sandboxing options, containers, virtual machines, mandatory access controls such as SELinux or AppArmor, chroot-like mechanisms and network segmentation.
Isolation should match the threat and the operational capability of the team. A container is not automatically a complete security boundary, and a complicated policy that nobody understands may be weaker in practice than a simpler, well-monitored design. Keep the host, container runtime, images and orchestration components patched as well.
For internet-facing applications, separate the public-facing tier from databases and internal services. Permit only the required application-to-database connections. Prevent a compromised web process from making arbitrary outbound connections where the workload allows it. This can restrict command-and-control traffic and make exploitation harder to extend into other systems.
Document the dependencies between services before applying isolation. Overly restrictive policies can break updates, DNS resolution, time synchronisation, log forwarding or health checks. The trade-off is between a smaller blast radius and the additional effort needed to test, operate and troubleshoot the boundaries.
Log activity and monitor for change
Hardening without visibility leaves administrators unable to tell whether controls are working. Enable authentication, privilege escalation, service and firewall logging. Capture application and web server logs as well, while taking care not to record passwords, session tokens or other sensitive values.
Forward important logs away from the server where possible. An attacker with administrative access may delete or alter local evidence. Centralised logging also makes it easier to correlate events across servers, such as a suspicious login followed by a new account and an unusual outbound connection.
Define alerts for events that deserve attention rather than sending every message to an inbox that nobody reads. Useful signals can include:
- Repeated failed logins followed by a successful login.
- New privileged users, group membership changes or unexpected SSH keys.
- Direct root activity or unusual sudo commands.
- Changes to firewall rules, SSH configuration or critical system files.
- Unexpected listening ports or services starting at boot.
- Abnormal CPU, memory, disk or outbound network usage.
- Security agents, log forwarding or monitoring checks becoming inactive.
Monitoring must have an owner and a response process. An alert that is not reviewed, triaged and linked to an action is only a record. Establish normal operating patterns so that the team can distinguish a deployment from an unexplained configuration change.
Run automated vulnerability and configuration checks
Manual reviews are useful but inconsistent. Automated vulnerability scanners, package audits and configuration checks can identify missing patches, exposed services, weak cryptographic settings, outdated libraries and deviations from the approved baseline. Run them regularly and after significant changes, not only immediately before an audit.
Use a severity-based workflow. Confirm findings first because scanners can report false positives or misunderstand a backported distribution patch. Then assign an owner, a remediation deadline and evidence of closure. A vulnerability that cannot be fixed immediately should have a documented compensating control, such as network restriction, service disablement or increased monitoring.
Configuration management can prevent drift by defining the intended state for users, packages, services, firewall rules and permissions. Review changes through version control or an equivalent approval process. Avoid storing secrets in ordinary configuration repositories, and ensure that automation itself uses narrowly scoped credentials.
Before production, validate the baseline with a practical Linux server hardening checklist and adapt it to the distribution, workload and risk profile. A checklist is a starting point, not proof of security. The administrator still needs to confirm that the controls are relevant and that the business can operate them.
Understand VPS, dedicated servers and shared hosting
These controls apply when the customer controls the operating system and server configuration, such as on a customer-managed VPS or dedicated server. The customer can normally choose the distribution, manage users, configure SSH, install a host firewall, patch packages, isolate services and decide how logs and monitoring are handled.
Shared hosting is different. Multiple customers use an environment managed by the hosting provider, and customers generally cannot change the host firewall, disable system services, configure the SSH daemon, update the operating system or define kernel-level isolation. The hosting provider may offer its own security controls, but those are not equivalent to customer-controlled Linux server hardening.
When comparing hosting options, distinguish between a customer-controlled VPS or dedicated environment and shared hosting and other managed hosting arrangements. Do not assume that a hardening checklist can be applied to a site simply because the site runs on Linux. If the customer does not control the server, the relevant questions are what the provider secures, what the customer can configure, how incidents are handled and how data can be recovered.
Safenix protects servers the customer controls. It does not provide a backup plan for a website running on shared hosting. That distinction matters when defining a backup scope: identify the actual server, its operating system and the level of access available before selecting a recovery approach.
Hardening reduces risk but does not guarantee recovery
Even a well-hardened server can be compromised. Credentials can be stolen, an application can contain an unknown vulnerability, an administrator can make a destructive mistake, a privileged insider can abuse access or ransomware can encrypt data through a legitimate account. Hardening aims to reduce the probability and impact of compromise; it does not make the server indestructible.
Recovery therefore belongs in the same resilience plan. Keep backups separate from the production server and from the credentials used to administer it. If an attacker can delete, alter or encrypt both the live data and its backups, the backup process may exist on paper but fail during the incident that matters.
After hardening the server, protect recoverability with encrypted, off-site Safenix backups for customer-controlled business servers. Safenix stores backup data in Germany, encrypts it using a key that Safenix never holds and keeps it immutable for the length of the retention window. Those properties address different risks: off-site storage separates backup copies from local failure, encryption protects confidentiality and immutability helps prevent alteration or deletion during the defined retention period.
Backup design still requires decisions from the customer. Identify which servers and data are essential, how much data loss the business can tolerate, how quickly systems must return to service and which dependencies are needed for a usable recovery. A backup of application files without the database, configuration, credentials or a documented rebuild process may not produce a working service.
Test restoration, not just backup completion
A successful backup job proves that data was written. It does not prove that the business can restore it. Schedule restoration tests using a representative server or isolated recovery environment. Verify file integrity, database consistency, permissions, application startup, DNS changes, certificates and the ability of users to work normally.
Record the result of each test, including the time required, problems encountered and actions assigned. Test both a small file recovery and a full server or service recovery where appropriate. Include scenarios such as accidental deletion, server failure, ransomware and loss of the primary hosting location.
Do not rely on a single administrator's memory. Store recovery procedures where they remain available during a server incident, but protect them from unauthorised access. They should identify contacts, dependencies, credentials retrieval, recovery order, validation checks and the decision authority for switching back to production.
Document the operational trade-offs
Security controls always interact with availability, performance, cost and administrative effort. A hardened baseline should explain those decisions instead of presenting them as universal rules. This makes the environment easier to operate and helps the next administrator understand why an exception exists.
Document at least:
- Which services and ports are required, and who owns each one.
- Which users and groups have administrative access, how keys are issued and how access is revoked.
- How quickly security patches are applied and when reboots are permitted.
- Which firewall, SSH, sudo and permission settings differ from the standard baseline.
- How service isolation affects deployments, troubleshooting and performance.
- Which logs are retained, where they are sent and who responds to alerts.
- How vulnerability findings are assessed, prioritised and closed.
- Which data is backed up, the retention requirements and the tested restoration process.
- What happens if the primary server, credentials or administrator is unavailable.
Examples of trade-offs include disabling password login, which improves resistance to password attacks but requires reliable key management and an emergency access procedure. A default-deny firewall reduces exposure but can interrupt a newly deployed integration. Aggressive automatic patching reduces the window of vulnerability but may require better testing and rollback. Strong service isolation limits lateral movement but increases configuration complexity.
Exceptions should have an owner, a reason, an expiry or review date and compensating controls. “Temporary” firewall access that remains for years is no longer an exception; it is undocumented infrastructure. Regular reviews should remove obsolete accounts, packages, services, ports and permissions.
A practical pre-production hardening sequence
Teams often achieve better results by applying controls in a repeatable order:
- Define the server's role, data classification, dependencies and recovery requirements.
- Install a supported operating system using the smallest practical package set.
- Apply current updates and record the resulting version baseline.
- Create named administrative accounts and configure carefully scoped sudo access.
- Install and test SSH keys, then disable direct root login and password authentication where suitable.
- Remove unnecessary packages and disable services that are not required.
- Configure a persistent default-deny firewall with narrowly scoped exceptions.
- Set ownership and permissions for system files, application code, secrets, uploads and logs.
- Isolate services and restrict their filesystem, network and capability access.
- Enable central logging, monitoring and alerts for authentication, privilege and configuration changes.
- Run vulnerability and configuration checks, then resolve or document findings.
- Configure off-site backups and perform a restoration test before declaring the server ready.
Run the sequence again after major changes. Production hardening is not a one-time ceremony because packages, applications, users, integrations and business requirements change. A server that was secure at launch can drift into a different risk profile months later.
A baseline that supports resilience
Linux server hardening works best as part of a wider operational discipline. Minimal installations reduce unnecessary attack paths. Patching removes known weaknesses. Least privilege limits what a compromised account can do. SSH controls protect administration, firewalls restrict network exposure and permissions protect data from unrelated processes. Isolation limits lateral movement, while logging and monitoring improve detection. Automated checks help the team find drift before an attacker does.
None of these controls removes the need for tested recovery. Prevention and recovery address different failure modes. Harden the server to make compromise harder, monitor it to make suspicious activity visible and maintain protected off-site backups so that a serious incident does not become a permanent loss of business data.