The primary security of the server is not a magic script or a change of SSH port. The goal is to reduce the level of attack, limit the penetration effect, maintain recovery and track changes. The execution order is critical: if you restrict the login password or firewall before testing the key and console, you may be left out of the server yourself.
Quick answer:First, verify the provider's inventory and emergency access; patch the system, create a separate SSH key for each account manager, and test access in the second session. Then set up the firewall, services, permission, secret, TLS, backup, log and alert step by step with rollback.
Security based on the threat model.
Public web servers, internal databases, bastion and runner CI/CD have different threats and accesses. Specify assets, sensitive data, input paths, administrators, dependency, and RPO/RTO. Hardening without knowing the role may disrupt the required service or place important controls.
Step 0: Recovery Access
The console, rescue mode, or out-of-band access of the provider should be tested. The provider account must have MFA, secure credentials, and clear authorized people. The snapshot is useful but does not replace the standalone backup or console.
Inventory and Baseline
cat /etc/os-release
uname -r
ip -br addr
ss -lntup
systemctl --failed
findmntThese commands display the version, interface, listener, failed service, and mount unchanged. Each port and process must have an owner and reason. Clear the output containing the IP and hostname before public subscription.
Patch and source closed.
Install security updates from a valid repository with maintenance policy. Changing the kernel or critical library may require reboot/restart; smoke test and window are required. The third-party repository is a new trust limit and must have a signature key, owner, and specific maintenance cycle.
The account is separate and at least Sudo.
Each account administrator has an independent account to revoke and audit. Shared root password blurs responsibility. Review sudo periodically with limited practical requirements and older accesses. Service account should not have an unnecessary shell or administrative permission.
SSH Key is locked in unlocked order.
- Get the administrator's public key from a valid channel.
- Create the permissions file and folder.
- In the second session, test login and sudo.
- Validate the daemon configuration with the same version tool.
- Limit the root/password login as required by step.
- Hold the previous session and console until final confirmation.
Private key should not be placed on a server, repository, or public message. Secure passphrase and agent make it harder to steal a key file. Changing a port only reduces the scan noise and does not replace key, allowlist, and patch.
Firewall from the real stream.
Restrict access to the required services: The web is public, but the database, Redis, and internal panel should not be public. Before activating the rule, verify the authorized SSH path and console. Cloud firewall, host firewall, and container rules may be in effect at the same time; source of truth is required.
Don't forget about IPv6.
Restricting IPv4 while the service is on public IPv6 is a common gap. If IPv6 is enabled, its DNS, listener, and firewall must also be managed. Blind disabling IPv6 may disrupt dependency or networking; record the actual situation and make informed decisions.
Service and minimum module
The unused service increases the attack level and patch load. After the inventory, manage it using the package/service manager method. Do not manually delete the binary or package database. The panel and new agent will also add privilege and network path and the need for it should be clear.
Do not run the processes with root.
The web server, application and database must be user-specific and limited in access. Separate code, upload, log and secret by ownership.777The treatment is not permission; it allows you to write unnecessarily.
Secret Management
Do not include the database password, API key, or private key in Git, image, history shell, or log. The secret file must have limited owner and permission. Design rotation, revoke, and audit. The disclosed credential will not be secure by removing the last commit; the history and secret itself must be managed.
Web server, TLS and header
TLS must have a valid hostname, chain, and renewal. The protocol and cipher depend on the required library version and clients; do not blindly copy the old configuration. Security header such as HSTS and CSP can crack the site without checking the domain and asset; they run first in staging and with controlled rollout.
Private database and cache
Set the listener database and Redis to a network that needs to be limited and authentication and TLS to fit the architecture. Public connection with strong encryption is also an unnecessary attack level.
Log and Audit
authentication, sudo, firewall, proxy and application event must have a synchronized timestamp, retention and owner. Do not log the secret, cookie and payload of payment. Logs on the same disk can be automatically determined without rotation.
Brute force and rate control.
SSH key and firewall are the main line; log-based blocking tools can limit noise and repetitive attempts. rule must have a valid log, threshold, and unban path. Distributed attackers or credentials cannot be solved with a simple block.
Backup is part of security.
Keep a copy outside the same server and preferably the account boundary; set encryption, retention, and restore access. Backup without restore test is a hypothesis. Ransomware or erroneous deletion may also destroy the connected and writeable backup, so immutability or isolation is important.
Security monitoring and alerting
- Login failed and management account changed.
- New port/listener
- File changes and config sensitive
- Failed service or unusual restart
- CPU, memory, disk and unusual network
- TLS expired and backup failed.
- 4xx/5xx rate and unusual request pattern.
Set the threshold on the same server baseline and keep the alert channel out of the infrastructure that may be disconnected.
Container does not delete the host security
Image, runtime, host kernel, network and secret also require patches and restrictions. Container privileged, host wide mount or socket runtime increases the penetration range.
Safe run order
- Threat, inventory and recovery access
- Backup configuration and appropriate snapshot
- Patch and reboot controlled.
- Separate account, key and second session.
- SSH and the phase firewall.
- Delete service and access.
- permission, secret, TLS and database exposure
- log, backup, monitoring and restore test
- Periodic documentation and review
Checklist of initial configuration of the serverIt also covers the stages of operations and production delivery.
What are we not doing?
- Running unknown script hardening with root
- Shut off SSH before testing the key and console.
- Turn off the firewall to fix an error.
- Putting the database and Redis online.
- Use of
chmod 777 - Secret storage in the repository
- Hard-core header activation without testing
- Relying on snapshot as the only backup
Security is not a one-time thing.
The patch, account review, certificate, dependency, restore test and access review cycles. Infrastructure changes must have code review and audit trail. A new vulnerability or change in server role changes the threat model; review the baseline after any significant change.
When do you need special assistance?
If the server is a production, store, or multi-service, hardening without a network map may disconnect payment or access.Install and configure the Linux serverIt can run baseline security, firewall, backup and monitoring with rollback paths and documentation.
Common Questions
Does changing the SSH port secure the server?
It only reduces the noise of the scan; key, access restriction, patch and monitoring are the main controls.
Should we shut down the root login immediately?
After the management account is created, key/sudo testing in the second session and emergency console confirmation will be restricted, according to the access policy.
Is the software firewall enough?
One layer is important, but cloud firewalls, authentication, patches and security of the application are also necessary.
How long until Hardening is reviewed?
Periodically and also after a change in role, service, network, incident or dissemination of related vulnerabilities.