Essential Post-Deployment Checklist for New Servers: Security, Base Environment, and Monitoring

The default state of a newly installed server is typically “usable but insecure”—root login is enabled, all ports are open, and there is no monitoring or backup. Deploying business services directly onto such a server means deferring risks to the future.

This checklist covers security, base environment setup, and observability. Completing these steps in order takes about 30 minutes and helps avoid most common foundational issues later on.

1. Login and User Accounts (Most Critical)

# ① Create a standard user with sudo privileges
adduser ops
passwd ops
usermod -aG wheel ops        # CentOS/RHEL
# usermod -aG sudo ops       # Ubuntu/Debian

# ② Configure SSH key-based login (generate keys locally and copy the public key)
ssh-copy-id ops@ServerIP

# ③ Only after confirming key-based login works, disable password login (Order matters!)
# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

systemctl reload sshd

The order of Step ③ is extremely important: You must verify that key-based login works in a new window first, then disable password authentication. Otherwise, you risk locking yourself out—a very common accident during initialization.

# After making changes, test in a separate window without closing the current connection
ssh ops@ServerIP    # Confirm successful login before proceeding to the next step

2. Firewall and Security Groups

# Allow only necessary ports
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

# Check which ports are currently listening (ensure no unnecessary services are exposed)
ss -lntp

Principle: Default deny, allow only as needed. Also, remember that the cloud console’s Security Group is an independent layer; allowing traffic via the system firewall does not guarantee it passes through the security group.

Absolute rule: Do NOT expose database ports (3306) or Redis (6379) to the public internet. They should only listen on the internal network.

# Ensure databases are not listening on public addresses
ss -lntp | grep -E '3306|6379'
# If it shows 0.0.0.0:3306, it is open to the entire internet; change the configuration to bind to the internal IP

3. System Updates and Time Synchronization

# Update the system
yum update -y          # CentOS/RHEL family
# apt update && apt upgrade -y   # Debian/Ubuntu family

# Set timezone
timedatectl set-timezone Asia/Shanghai

# Time synchronization (Incorrect time causes certificate validation failures, log timestamp issues, etc.)
yum install -y chrony
systemctl enable --now chronyd
chronyc sources
date

Time synchronization is often overlooked, but its impact is widespread: Misaligned log timestamps make cross-machine troubleshooting difficult, and significant time deviations can cause certificates to be deemed invalid.

4. Swap Space (For Low-Memory Machines)

# Recommended for machines with ≤ 2GB RAM
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# Verify
free -m

The purpose of Swap is to prevent immediate OOM (Out Of Memory) kills during memory spikes. While it may degrade performance, it is better than processes being terminated abruptly.

5. Basic Software and Common Tools

yum install -y vim curl wget git unzip lsof htop 
               net-tools bind-utils telnet nc rsync

# View logs
journalctl -p err --since today

6. Logs and Monitoring

# Ensure logging services are running
systemctl status rsyslog
systemctl status systemd-journald

# Configure log rotation (to prevent logs from filling up the disk)
cat /etc/logrotate.conf | grep -E 'rotate|daily|weekly'

# Disk alerts (Simple version: Inspection script + cron)
df -h

A server without monitoring is blind. At minimum, you must be able to see: disk usage, memory, load, and service status. The implementation can be simple, but it cannot be absent.

7. Backup Strategy

Define your strategy during the initialization phase; do not wait until data exists:

• What to back up (website files, databases, configurations)
• Where to store backups (Must be off-site)
• Frequency and retention period

Complete Checklist

Decision Tree

New Server Initialization
├─ First: Account and SSH (Highest Priority)
│  └─ Order: Create User → Configure Keys → Verify Login → Disable Password Login
├─ Second: Network Boundaries
│  ├─ System Firewall: Allow only 22/80/443
│  ├─ Cloud Security Group: Minimize similarly (Independent Layer)
│  └─ Ensure 3306/6379 are not open to the public internet
├─ Base Environment
│  ├─ Update System
│  ├─ Timezone + NTP (Incorrect time causes many strange issues)
│  └─ Swap (For low-memory machines)
└─ Observability and Recovery
   ├─ Log Rotation (Otherwise, disk will eventually fill up)
   ├─ Monitoring (Disk/Memory/Load/Services)
   └─ Backup (Off-site)

Scenario Analysis: Server Scanned Within Three Days of Launch

Symptom: A newly provisioned server was put into use after basic deployment. Three days later, security logs showed numerous failed remote login attempts, and unknown scheduled tasks were found written to the system.

1. Check if they got in first, rather than hardening immediately → Check for successful login records,
   new accounts, and unfamiliar processes or tasks. This step determines whether the response is “Cleanup” or “Hardening.”
2. Confirm the exposure surface → Remote login port was open to the entire internet,
   and password authentication was allowed. This was the direct cause of repeated attempts.
3. Stop the bleeding: Narrow the entry point first → Restrict source addresses and switch to key-only login.
4. Clean up what was already written → Remove unrecognized scheduled tasks and accounts.
   Note the order: Remove persistence mechanisms first, then clean other artifacts.
5. Fulfill what should have been done pre-launch → Update system and packages, configure minimal firewall rules,
   and enable basic auditing and alerting.
6. Verify and Document → Re-check open ports and account lists, and solidify this initialization process into a script.

# ① First, confirm if unauthorized access occurred
last -20
awk -F: '$3>=1000 && $7 !~ /nologin|false/ {print $1,$3,$7}' /etc/passwd
crontab -l -u root; ls -la /etc/cron.d/

# ② Narrow entry: Switch to key login + Disable password + Restrict sources
grep -E '^(PasswordAuthentication|PermitRootLogin|PubkeyAuthentication)' /etc/ssh/sshd_config
# Recommendation: PasswordAuthentication no
systemctl reload sshd

# ③ Allow only necessary ports
ss -lntp
firewall-cmd --list-all 2>/dev/null

# ④ Solidify these steps into an initialization script for future servers

Root Cause: No basic hardening was performed upon launch—the remote login port was open to the entire internet and allowed password authentication.
The detection speed exceeded expectations: Hosts exposed to the public internet are typically scanned within a very short time after provisioning.

Two Key Takeaways:

• Initialization is not just “install software and make it work,” but “minimize the exposure surface.”
  Minimizing open ports + Key-based login + Patch updates must be completed before going live.
• Upon detecting attempts, check for successful breaches first, then discuss hardening.
  Reversing this order leads to situations where “the server is hardened, but the attacker is still inside.”

8 Common Pitfalls

1. Disabling password login without verification: Locking yourself out.
2. Always operating as root: High risk, and actions cannot be traced to specific individuals.
3. Configuring only one layer of firewall/security group: Both layers are independent; both must be configured.
4. Exposing 3306/6379 to the public internet: One of the primary entry points for intrusions.
5. Neglecting time synchronization: Chaotic log timestamps and certificate validation errors.
6. Neglecting log rotation: Disks will inevitably fill up with logs.
7. No monitoring: Issues are only detected when users complain.
8. Leaving backup plans to the end: Realizing the need for backups only after data exists leaves a dangerous gap.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (providers include our shop and competitors, provided solely for reference of genuine feedback, not fictitious tickets from this site):

1****n Rating: 5.0 Jan 04, 2018 18:04

d****9 Rating: 5.0 Feb 15, 2023 09:11 a****7 Rating: 5.0 Feb 15, 2023 09:10 d****8 Rating: 5.0 Feb 14, 2023 10:48 d****8 Rating: 5.0 Feb 14, 2023 10:43 a****3 Rating: 5.0 Jan 17, 2023 17:20

9****3 Rating: 5.0 Jul 22, 2021 10:31