Running a Linux server means taking responsibility for more than the applications it hosts. Administrative access, software updates, network exposure, storage and recovery all need attention. A working website is not proof of a secure machine, and a server that has stayed online for years may still have an impressive collection of unfinished maintenance jobs.
Linux server security works best as a repeatable operating process: expose only the services you need, give each account appropriate permissions, keep supported software patched, watch for failures and prove that backups can be restored. This guide connects those responsibilities, whether you manage a home server, a rented virtual machine or a small business application.
Start With the Server’s Purpose and Recovery Requirements
Define what the server must do before deciding how to configure it. A private file server, a public website and a database have different access requirements. Write down which services belong on the machine, who uses them, what data they hold and which other systems they depend on. Anything outside that description deserves a question before installation.
Choose a distribution release with a support period that fits your maintenance plans. Check whether the packages you need receive security maintenance under the support arrangement you intend to use. Avoid selecting a release solely because its installation image is familiar; the machine needs a manageable upgrade path, not just a successful first boot.
For a hosted server, establish how you would recover access if SSH stopped working. Confirm that you can use the provider’s console or rescue environment, and protect the hosting account with multifactor authentication where available. Keep recovery details somewhere other than the server itself.
Build this foundation before publishing applications. The guide to setting up your first Linux server covers the initial configuration sequence without mixing installation tasks with later application decisions.
Separate Administrative Access From Everyday Work
Use named accounts for people rather than sharing one administrator login. Give administrators a normal account and grant elevated permissions only where their work requires them. This makes access easier to withdraw and avoids making every routine action an action with unrestricted authority.
For SSH, review authentication methods, permitted users and direct root access as separate decisions. Password authentication and keyboard interactive authentication have separate controls; disabling one does not automatically disable the other. The OpenSSH server configuration manual defines these settings and the rules for combining authentication methods.
Prefer public key authentication for administrative access, protect private keys and consider a second factor for higher risk systems. Do not remove a working login method until its replacement has passed a fresh connection test. Keep the current session open during changes, and confirm that the new account can perform the administrative tasks it needs.
The practical sequence matters more than copying a hardening checklist. Follow the guide to securing SSH access with keys and access controls when changing authentication or restricting remote administration.
Give Services Their Own Permissions
Human accounts and application accounts serve different purposes. Avoid making a service account a general administrator, and do not reuse a person’s login for unattended jobs. Review who can change application files, read credentials or alter scheduled tasks. Permissions should reflect those jobs rather than whatever made an installation error disappear.
Be particularly careful with sudo rules. Permission to run a program that can launch a shell or overwrite protected files may grant much more authority than the rule suggests. The guide to managing Linux users, groups and sudo access covers these boundaries in more detail.
Control Network Exposure at Every Layer
Decide which connections should reach the server before opening ports. For a public web application, visitors may need access to the web service, while administration should remain restricted. A database used only by a local application generally has no reason to accept connections from the public internet.
A host firewall controls traffic at the machine, while a provider firewall or network security group applies controls elsewhere in the network. Treat them as separate configurations that need checking. On Ubuntu, UFW provides a management interface for IPv4 and IPv6 host firewall rules; its capabilities and initial state are documented in the Ubuntu Server firewall documentation.
Keep the policy readable. Each allowed connection should have a purpose, an intended audience and someone responsible for it. Check IPv4 and IPv6 exposure separately, and test reachability from outside the server rather than relying only on a local status display.
Before changing remote access rules, allow the required administration path and confirm your recovery route. Then test a new connection before closing the existing session. Accidentally locking yourself out is an outage, even if the firewall is technically doing exactly what you asked.
Choose a firewall management approach that matches the distribution and deployment. Avoid mixing several tools without knowing which rules each controls. The comparison of UFW, firewalld and nftables explains where each fits and how to approach rule changes safely.
Manage Services and Contain Application Failures
Keep an inventory of running services and decide which should start automatically. A temporary troubleshooting service should not become permanent infrastructure through neglect. Record each service’s configuration location, runtime account, data directory and recovery procedure. For systems that use it, managing services with systemd provides the operational starting point.
Service restrictions can reduce what an application can access if it misbehaves or is compromised. Systemd offers controls for filesystem access, temporary directories and privilege changes during program execution. Their availability and behavior depend on the host and service context, so check the installed version rather than assuming every online example applies. The systemd execution and sandboxing manual documents these controls and their constraints.
Apply restrictions gradually. Identify what the application must read, write and contact, then test normal work, scheduled jobs and recovery after a restart. A service that starts successfully may still fail when it tries to upload a file or rotate its logs.
Keep the distribution’s security policy in place during this work. For SELinux systems, investigate denials and incorrect file labels rather than disabling enforcement across the machine. Permissive mode logs policy violations without blocking them, so it is a troubleshooting state, not equivalent protection. The Red Hat SELinux administration documentation covers enforcement modes and denial analysis.
Make Security Updates an Operating Process
Decide how quickly updates should be assessed and installed, who handles failures and when restarts can occur. Security maintenance should not depend on someone remembering to log in during a quiet afternoon. At the same time, unattended changes need monitoring and a recovery plan.
Automatic patching requires a scope check. Ubuntu’s unattended upgrades use configured package origins; adding a third party repository does not automatically include it in that policy. Review repository coverage, exclusions and reboot behavior in the Ubuntu automatic updates documentation before treating automation as complete.
Maintain a software inventory beyond the operating system package manager. Include application dependencies, container images, manually installed binaries and software distributed through other channels. Assign an update method to each. Otherwise, a fully patched host can sit underneath an application nobody has updated.
Do not judge patch status solely by an upstream version number. Red Hat, for example, backports security fixes into older package versions, so a version comparison can produce a misleading result. Check the installed package release against vendor advisories, using Red Hat’s explanation of security backporting as a reference for this distinction.
After maintenance, verify the application from a user’s perspective. Confirm that required services recovered, background work resumed and monitoring remains active. The guide to Linux security updates and automatic patching covers update scheduling, verification and restart planning.
Monitor Service Health, Resources and Logs
Monitor whether the server delivers its intended service, not just whether it responds to a network check. A web server can answer requests while its database is unavailable. A backup job can finish without protecting the newest data. Build checks around the result users depend on.
For resource monitoring, establish a normal operating range before choosing alert thresholds. Track CPU activity, memory pressure, storage capacity, disk activity and network traffic alongside application behavior. A short burst of work does not call for the same response as sustained pressure accompanied by failed requests.
Start with a small set of alerts that require action. Give each alert an owner and a response procedure. The guide to monitoring CPU, memory, disk and network usage connects system measurements with practical troubleshooting decisions.
Keep Enough Log History to Investigate
On systems using the systemd journal, journalctl can filter entries by service and boot, helping separate a current failure from unrelated history. Access depends on the calling user’s permissions. The available filters and access behavior are covered in the journalctl reference manual.
Set retention deliberately, check that the history you need survives restarts and avoid allowing diagnostic output to consume storage unchecked. For important systems, consider storing relevant logs separately from the application host. Do not record passwords, private keys or authentication tokens as a debugging shortcut.
When a service fails, narrow the investigation to the affected unit and time window before changing configuration. The guide to troubleshooting Linux services with journalctl develops that workflow.
Protect Public Web Services Beyond HTTPS
A public website needs both transport encryption and sound application administration. Treat HTTPS, application authentication, software maintenance and file permissions as separate responsibilities. Configuring one should not be used as evidence that the others are finished.
Protect certificate private keys from unnecessary access. Nginx distinguishes the public certificate, which is sent to clients, from the private key, which requires restricted file access while remaining readable by the appropriate server process. Certificate chains and related configuration requirements are covered in the Nginx HTTPS server documentation.
Plan certificate renewal and check the certificate actually served to visitors. Keep administrative interfaces restricted where practical, and make deliberate choices about which application components accept network connections. Test the public path after configuration changes, not just the application on localhost.
For a deployment walkthrough, use the guide to hosting a website on Linux with Nginx and HTTPS. Keep the wider server controls in place as the site grows.
Design Backups Around a Restore, Not a Success Message
Begin with two questions: how much recent work could you afford to lose, and how long could the service remain unavailable? Those answers should drive backup frequency and recovery arrangements. A daily backup may suit a rarely changed document archive but fail the requirements of an application receiving orders throughout the day.
Document what recovery needs. That may include application data, a recoverable database backup, configuration files, deployment instructions and access to encryption credentials. For a database, choose a backup method that produces a consistent recovery point; do not assume copying its live files is sufficient.
Keep protected copies beyond the server’s immediate failure boundary. Offline encrypted backups and regular recovery tests are part of the CISA StopRansomware prevention and recovery guidance, which also addresses isolation and evidence preservation after an incident.
Run a restore test somewhere separate from production. Confirm that the application starts, expected records exist and users can complete a normal task. Measure the time required and record missing dependencies. Reading a backup file is useful, but it is not the same test as rebuilding a working service.
Keep recovery credentials accessible through an appropriately protected route that does not depend on the failed machine. The guide to automated offsite backups and recovery testing covers backup separation, retention and rehearsed restoration.
Use a Maintenance Routine You Can Sustain
Choose review intervals around the service’s exposure and importance. The following is a starting schedule, not a universal requirement. Automate routine checks where practical, but retain a person responsible for investigating exceptions.
| When | Review | Expected result |
|---|---|---|
| Continuously | Service checks and urgent alerts | Failures reach someone who can respond |
| Daily | Backup results and patching failures | Exceptions receive attention |
| Weekly | Capacity trends and outstanding maintenance | Problems have an owner and next action |
| Periodically | Accounts, network exposure and restore tests | Access remains justified and recovery works |
| After changes | Application behavior, monitoring and documentation | The service still meets its requirements |
Keep a short change record: what changed, why, how it was checked and how to reverse it. Useful operational notes beat a lengthy document nobody maintains.
Prepare for Compromise Before It Happens
If compromise is suspected, follow a prepared response plan rather than immediately deleting files or reinstalling the machine. Isolate affected systems where feasible, preserve useful evidence and use a trusted device for response work. Coordinate these actions carefully when other systems may also be affected.
Plan to replace exposed credentials and rebuild from trusted software when system integrity cannot be established. Before returning the service to use, address the original entry point and verify restored data. Include a route to qualified incident response help for systems holding sensitive or business critical information.
The practical standard for a Linux server is straightforward: its purpose is documented, access is controlled, software receives maintenance, failures become visible and recovery has been tested. Security is the work that keeps those conditions true.