VaralLinux
ITA ENG
HowTo Admin

Post-install checklist for a Linux server

Users, SSH, firewall, updates, backups, and monitoring: a practical baseline to secure the system.

Guide written by Alessio Varalla
Before tightening SSH/firewall on a remote server, keep a second session open. A wrong rule can lock you out.

1. Network and hostname

  • Set a clear hostname (e.g. web01, backup01)
  • Verify IP, gateway, DNS
  • Check name resolution and reachability
hostnamectl status   # if available
hostname
ip a
ip r
cat /etc/resolv.conf
ping -c 3 1.1.1.1
ping -c 3 google.com
On some minimal distros hostnamectl may not be present (e.g. without systemd): use the distro config files.

2. Users and privileges

Avoid using root directly for daily tasks.

  1. Create an administrative user
  2. Add it to sudo/wheel group
  3. Test privileges
useradd -m -s /bin/bash adminuser
passwd adminuser

# Slackware (if sudo configured via wheel)
usermod -aG wheel adminuser

Verify:

su - adminuser
id
sudo -v   # if sudo is configured
Do not disable root SSH login before verifying that the admin user can log in and elevate privileges.

3. SSH security

Configure key-based access and reduce attack surface.

Recommended steps

  • Use public key authentication
  • Disable root login via SSH (after testing)
  • Consider changing port (only useful against scans, not strong security)
  • Limit allowed users
mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Example options in /etc/ssh/sshd_config (adapt to your case):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers adminuser

After editing:

sshd -t
systemctl restart sshd   # or service sshd restart
Before closing the current session, open a new SSH connection and verify that access really works.

4. Firewall

Open only the ports required by the server role.

Common ports (example)

  • 22/tcp SSH
  • 80/tcp HTTP
  • 443/tcp HTTPS
  • 25/587 SMTP (only if mail server)

Checks

  • Block everything else inbound
  • Allow loopback
  • Allow established/related traffic
  • Document each exception

Verify listening ports:

ss -tulpen
netstat -tulpen   # if available
Use the firewall tool of your distro: nftables, iptables, ufw, firewalld. The key is to apply the least-privilege principle.

5. Updates and repositories

  • Update the system right after installation
  • Use official and trusted repositories
  • Plan a regular update routine
  • Consider reboot after critical updates (kernel, libc, sshd)

Slackware (example with slackpkg)

slackpkg update
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-system   # caution: review carefully before confirming

On Slackware, pay attention to changelog, core packages, and new configs/merging .new files.

6. Date/time and synchronization (NTP)

Correct time is essential for logs, TLS certificates, authentication, and cron.

date
timedatectl status   # if available

Install/enable an NTP service (chrony or ntpd) depending on your distro.

7. Services and ports: initial cleanup

Disable unnecessary services.

  • Demo servers, legacy services, unused daemons
  • Admin interfaces exposed publicly without reason

Check running processes and active units:

ps aux
systemctl list-units --type=service --state=running   # if systemd
Fewer active services = smaller attack surface and lower resource usage.

8. Logs and basic auditing

  • Check where logs go (syslog, journald, app files)
  • Configure log rotation
  • Periodically check boot/auth errors
journalctl -p err -b   # systemd
journalctl -u sshd -b
tail -n 100 /var/log/messages
tail -n 100 /var/log/secure   # or auth.log

For basic auditing, at least monitor failed SSH logins and repeated attempts.

9. Backups and restore tests

An untested backup is not a reliable backup.

What to save at minimum

  • Configurations (/etc)
  • Application data
  • Databases (consistent dumps)
  • Custom scripts / cron / required keys

Practical backup checklist

[ ] Backup destination separate from the server
[ ] Automatic scheduling (cron/systemd timer)
[ ] Retention defined (e.g. 7/30 days)
[ ] Backup integrity verification
[ ] Periodic restore test
If the backup is always mounted and writable by the same server, ransomware or operational mistakes can easily hit it.

10. Monitoring and alerts

Even basic monitoring is better than nothing.

  • CPU, RAM, disk, load average
  • Disk space and inodes
  • Critical services (web, db, sshd)
  • Expiring TLS certificates
uptime
free -h
df -h
df -i

At least set an alert via email/Telegram/monitoring tool when disk exceeds a threshold.

11. Extra hardening (recommended)

  • fail2ban to block brute-force attempts (if supported and useful in your stack)
  • sudo with minimal, auditable policies
  • 2FA for admin panels where possible
  • SSH keys with passphrase for sensitive access
  • service separation (dedicated user for app and database)
  • file permissions correct on configs and keys
Perfect hardening depends on the server role (web, mail, DB, backup, VPN). This guide is a solid base, not a universal policy.

12. Final quick checklist

[ ] Hostname, IP, DNS, and routing verified
[ ] Admin user created and privileges tested
[ ] SSH with keys working
[ ] Root SSH login disabled (after testing)
[ ] Firewall active with only required ports
[ ] System updated
[ ] NTP active
[ ] Unneeded services disabled
[ ] Logs checked and rotation configured
[ ] Backup configured and restore tested
[ ] Minimal monitoring/alerts active

Back to the Linux HowTo section