Congratulations! You’ve just completed a fresh install of your favorite Linux distribution on a server. You’ve got a clean slate, the operating system is installed, and you might feel a sense of accomplishment. You might even think, “Great, it’s ready to go!”
Hold that thought for just a second.
While a fresh install is the essential first step, simply booting up the default configuration is like building a house and forgetting to put locks on the doors, install a security system, or stock a basic toolbox. The server is functional, yes, but it’s far from secure, easily managed, or fully prepared for the real world.
Here’s why relying solely on the default fresh install is a risky game, and why those crucial post-installation steps are non-negotiable:
The Default Setup: Generic and Often Vulnerable
Linux distributions aim to provide a working system out-of-the-box for a wide variety of uses. This means the default configuration is often a compromise: it needs to be general enough to work almost anywhere, which can leave security gaps and omit essential tools you’ll need down the line.
Ignoring those first critical steps leaves your server exposed and makes future management harder than it needs to be. Let’s break down why our recommended steps are vital:
- Immediate Updates and Firewall: Because the World is Waiting
Why not default? A fresh install contains the software versions that were current when the installation image was created. This could be months, or even a year or more, old. In the fast-moving world of cybersecurity, known vulnerabilities are constantly being discovered and patched.
Why update NOW? Attackers (and their automated bots) constantly scan the internet for servers with known, unpatched security flaws. Connecting an unpatched server to the internet is like putting a “hack me” sign on it. Applying updates immediately closes these well-known backdoors.
Why a firewall? By default, many services might be running or could be exposed accidentally. A firewall is your server’s bouncer – it explicitly denies all incoming connections except for the ones you explicitly allow (like SSH to manage it, or HTTP/S if it’s a web server). Without it, unnecessary ports are open, increasing your attack surface.
Immediately after installation, the very first thing you should do is update all the system packages. This ensures you have the latest security patches. Then, configure a firewall (like ufw or firewalld) to only allow essential inbound connections (like SSH, HTTP, HTTPS if it’s a web server).
$ sudo apt update && sudo apt upgrade -y # For Debian/Ubuntu based systems
$ sudo yum update -y # For CentOS/RHEL based systems
$ sudo systemctl enable --now ufw # Enable UFW (if using Ubuntu)
$ sudo ufw allow ssh # Allow SSH
# sudo ufw allow http # Allow HTTP (if needed)
# sudo ufw allow https # Allow HTTPS (if needed)
$ sudo ufw enable # Activate the firewall
$ sudo ufw status # Check firewall statusAlso create a “birth certificate” for your server. This way you can always document when you deployed the server.
As root, run the following command in the /etc directory:
# date > birth_certificate- Securing SSH Access: Closing the Most Targeted Door
Why not default? By default, SSH (your remote login tool) often runs on the standard port 22 and allows password authentication, sometimes even for the root user. This is the first place attackers will try to gain access, often using automated “brute force” attacks trying common passwords.
Why secure SSH?
Disabling root login forces attackers to guess a regular user’s credentials and then guess that user’s password again (or exploit a separate vulnerability) to gain root privileges.
Changing the default port adds a layer of obscurity, making your server less likely to be hit by bots specifically targeting port 22.
Switching to SSH key authentication eliminates the risk of password guessing entirely. SSH keys are cryptographically secure and virtually impossible to brute-force. It’s the single most impactful step you can take to secure remote access.
$ sudo nano /etc/ssh/sshd_configMake the following (or similar) changes:
Port <your_new_port_number>
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
# ... other configurations ...After saving, restart the SSH service:
$ sudo systemctl restart sshdImportant: If you change the SSH port, remember to allow the new port in your firewall!
Create a new user and assign it with sudo priviledges. As root user, run these commands:
# adduser <new_user_name>
# usermod -aG sudo <new_user_name>- Installing Essential Management Tools: Your Server’s Toolbox
Why not default? Fresh installs are often minimal. While they have the basics to run, they might lack the tools you’ll use daily for monitoring performance, checking network connections, editing configuration files efficiently, or navigating the file system easily.
Why install these tools? Imagine trying to fix a complex machine with just a screwdriver. Tools like htop (for monitoring processes), vim/nano (powerful editors), wget/curl (for downloading), and tree (for navigation) are your essential wrenches, pliers, and diagnostic equipment. Without them, troubleshooting is a slow, painful guessing game done with only the most basic commands. They save you immense time and frustration and also give you a more successful experience.
Install these tools for easier management (some might be installed per default):
$ sudo apt install -y htop nano wget curl tmux neofetch cmatrix net-tools treeThe list is targeted to be altered when I find other useful tools or helper programs.
- Set Up Automatic Security Updates
Why not default? While you did a manual update initially, new vulnerabilities and patches are released constantly. Manually logging in every day (or even every week) just to check for updates is impractical and easily forgotten.
Why automate security updates? This ensures your server automatically downloads and installs critical security patches shortly after they are released. It’s a crucial layer of defense that operates in the background, keeping your server protected against new threats without constant manual intervention. It significantly reduces the window of vulnerability.
To keep your server protected against emerging threats, configure automatic security updates. This ensures that critical patches are applied without manual intervention.
$ sudo apt install -y unattended-upgrades apt-config-auto-update
$ sudo dpkg-reconfigure --priority=low unattended-upgrades
$ sudo nano /etc/apt/apt.conf.d/50unattended-upgradesEnsure that the Unattended-Upgrade::Allowed-Origins section includes the security repository for your distribution.
- Configuring Time Synchronization: For Accurate Logs and Operations
Why not default? Server clocks can drift over time, especially on virtual machines. A default install might use a basic time source or none at all.
Why time synchronization? Accurate time is fundamental for a server.
- Security: When investigating a security incident, precise timestamps on logs are essential to understand the sequence of events.
- Troubleshooting: Debugging issues across multiple systems (like databases, web servers, and application servers) requires synchronized clocks to correlate log entries correctly.
- Operations: Many network protocols and authentication systems (like Kerberos) rely on accurate time synchronization to function correctly. An unsynchronized clock can make it impossible to piece together what happened or even cause system services to fail.
Accurate timekeeping is crucial for log analysis, security auditing, and various system processes. Ensure your server’s clock is synchronized with a reliable time server. Also that the time-zone matches your local and/or desired time for your server.
Check time-zone:
$ timedatectlWill output similar to this:
Local time: man 2025-05-19 10:12:23 CEST
Universal time: man 2025-05-19 08:12:23 UTC
RTC time: man 2025-05-19 08:12:22
Time zone: Europe/Copenhagen (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: noIf the time-zone needs to be configured, use this command:
$ timedatectl set-timezone <time_zone><time_zone> list can be found here.
To have your server synchronize time automatically, you can install chronyd service.
$ sudo apt install -y chronyEdit chrony config settings here:
$ sudo nano /etc/chrony/chrony.confChange to custom NTP server or use the default:
# server ntp.ubuntu.com iburst
# server 0.debian.pool.ntp.org iburst
# server 1.debian.pool.ntp.org iburst
# server 2.debian.pool.ntp.org iburst
# server 3.debian.pool.ntp.org iburst
server pool.ntp.org iburst
server 0.europe.pool.ntp.org iburst
server 1.europe.pool.ntp.org iburst
server 2.europe.pool.ntp.org iburstOne NTP server is usually enough, but more is better. Check this post for a complete guide how to install chrony.
Building a Solid Foundation
Think of these five steps not as optional add-ons, but as the necessary finishing touches that turn a raw installation into a secure, maintainable, and reliable server environment. By taking these proactive measures from the start, you significantly reduce your risk of compromise, make your life as an administrator much easier, and lay a solid foundation for whatever services you plan to run.
So, after that satisfying fresh install, take a deep breath, roll up your sleeves, and invest a little time in these essential steps. Your future self (and your server’s users) will thank you.