Initial Setup Checklist for Server Security

Server security starts with reducing the management surface exposed to the internet and verifying that your changes are actually effective. On a Linux server for which you have administrative access, first prepare a backup or rollback plan; then configure a separate administrator account, key-based SSH access, limited firewall rules, and up-to-date software. Make each change separately and repeat the same access test after each one.

Define the environment and rollback path before you begin

This guide is intended for a VPS or physical Linux server whose operating system and services you can manage. On a shared hosting account, settings such as SSH, the firewall, or system updates may be managed by the provider; in that case, use only the access and security options available in the control panel. You must be able to connect to the server with an administrator account, access the provider’s emergency console, and restore the existing settings.

Do not close your working SSH session before making changes. Record the current SSH port, login method, firewall rules, and service configurations. If possible, use the provider’s snapshot or backup feature. This allows you to restore the previous value from the console if a new setting cuts off the connection. On a production system, do not change several settings at the same time; otherwise, it becomes difficult to determine which change affected the result.

Reduce the access surface for server security

A separate administrator account and key-based login

As a first step, create a personal account with limited privileges for routine administration. This account should use only the administrative permissions it needs; it should not be a shared account used directly on a continuous basis. Logging in with an SSH key reduces attacks based on guessing a password over the network. However, the screen lock, disk encryption, and access controls on the computer storing the key file are also important.

1. Create the new account and grant it the required administrative permission; do not close the existing session until you have verified that you can connect with this account in a new SSH session. If the login succeeds, continue to the next step; if it fails, correct the account’s shell, permissions, and key configuration without changing the SSH settings.
2. In the administrator account’s SSH configuration, restrict password login and direct superuser login only after confirming that key-based access works in your environment. Save an original copy of the configuration file before making the change. Connect to the same server from a new terminal; if key-based login works and a password attempt is rejected as expected, the setting has achieved its purpose.

For example, on a VPS used only for maintenance, if key-based login works with the new administrator account but the old shared account still accepts passwords, the access surface has not been fully reduced. It is safer to determine which automation or team member uses the old account, move that dependency, and then lock the account; deleting it directly could break an unexpected automation process.

Restrict open ports according to service requirements

Apply firewall rules according to the service, not blindly

A firewall accepts or rejects incoming traffic to the server according to port and protocol. First, list the services the server actually provides: a web application generally needs HTTP and HTTPS, while SSH is required for administration; database ports, however, should not be exposed to the public internet in most setups. If you use the provider’s network security group together with the operating system firewall, remember that traffic not permitted at one layer will not be opened by the other layer.

If you can restrict the SSH port to a known administrative network or VPN address range, prefer that approach. If there is no fixed administrative network, changing the port alone does not provide protection; the essential value lies in authentication and source-address restrictions. If web ports must remain open, allow only the ports on which the web service actually listens. Instead of randomly closing unused ports, investigate why the relevant service is running.

The decision at this stage is clear: if no necessary service is listening on a port, remove the rule; if the service is needed, allow only the required source and protocol. If the application’s expected URL works after the restriction but administrative access is lost, correct the proper administrative address for SSH only, without rolling back the web rule. If you accidentally block your own external IP address, restore the previous rule from the provider’s console.

Review updates, services, and logs together

Operating system security updates address known vulnerabilities in the kernel and installed services; however, automatically applying every update in production can also create compatibility risks. First, review pending security updates in the package manager and the provider’s maintenance notes. For critical applications, plan the change if you do not have a backup, test environment, or maintenance window; do not restart the server without explanation merely for a routine check.

After firewall and SSH changes, check the system logs, authentication records, and the logs of the relevant services for new events. Note the time of the same failed connection attempt and make a new attempt after the change. If the new record shows the expected rejection, the rule is working. If a service cannot start or reports a permission error instead, examine that service’s configuration and file permissions separately before assuming that the problem is an access rule.

First verification round and the safe next step

Complete the check in this order: open a second session with the new administrator account; test only the required web addresses from outside; verify that the administrative port is accessible only from the permitted network; then review authentication and service records for the current time range. The expected result is that necessary services work, unnecessary access is rejected, and new connections can be distinguished in the logs. This check does not prove that the application contains no security vulnerabilities or that no account has been compromised.

If a verification fails, restore only the last setting you changed to the original value you recorded and repeat the same test. If the problem continues, compare the provider’s console, network security group, and operating system firewall separately; do not open all rules without evidence of the access path. If your administrative access is limited, you can review suitable management options on the provider’s server rental options page together with your existing configuration notes.

The next safe step is to review this basic configuration at regular intervals using a written change record and to document separately why every newly opened service needs to be exposed to the internet.