İçeriğe geç
SSHBULUT

SECURITY

Five things to do in the first ten minutes on a new server

A server starts getting scanned the moment it reaches the internet. A handful of steps taken right after provisioning close most of the attack surface.

Author: Hamza Yağız2 min read

The first minutes after a server boots matter. A machine with a public IP becomes a target for automated scanners within minutes. These scans are not personal; bots continuously try known username and password combinations.

The five steps below close most of the attack surface without building an elaborate security architecture.

1. Turn off password authentication for SSH

Move to key-based authentication and disable passwords entirely. Generate a key on your local machine:

ssh-keygen -t ed25519 -C "you@your-machine"
ssh-copy-id user@server-ip

After confirming that key authentication works, set the following in /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no

Keep a second terminal session open while applying changes. If the configuration is wrong, that open session is what keeps you from locking yourself out.

2. Stop working as root

Create a separate user with sudo rights for administration. A mistyped command in a root shell usually cannot be undone.

adduser operator
usermod -aG sudo operator

3. Set the firewall to deny by default

The right approach is not to open the ports you need, but to close everything and then open only what is required.

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

Never expose database ports (MySQL 3306, PostgreSQL 5432, MSSQL 1433) on the public interface. Use an SSH tunnel or a private network for remote access.

4. Enable unattended security updates

Waiting to apply patches by hand means, in practice, not applying them.

apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

5. Rate-limit failed sign-in attempts

fail2ban temporarily blocks a source IP after repeated failures. Even with key-based authentication in place, it cuts log noise substantially.

apt install fail2ban
systemctl enable --now fail2ban

What comes next

These five steps lay the foundation. Before going to production, verify your backups, set up monitoring and centralise logs — topics for separate posts.

On SSHBULUT servers, firewalling and DDoS filtering already run at the network edge; the steps above cover your side at the operating system level.

RELATED POSTS

All posts