{"id":3173,"date":"2025-12-08T15:10:14","date_gmt":"2025-12-08T12:10:14","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/first-24-hours-on-a-new-vps-updates-firewall-and-users-step-by-step\/"},"modified":"2025-12-08T15:10:14","modified_gmt":"2025-12-08T12:10:14","slug":"first-24-hours-on-a-new-vps-updates-firewall-and-users-step-by-step","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/first-24-hours-on-a-new-vps-updates-firewall-and-users-step-by-step\/","title":{"rendered":"First 24 Hours on a New VPS: Updates, Firewall and Users Step\u2011by\u2011Step"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_the_First_24_Hours_on_a_VPS_Matter\"><span class=\"toc_number toc_depth_1\">1<\/span> Why the First 24 Hours on a VPS Matter<\/a><\/li><li><a href=\"#Step_1_Connect_Safely_to_Your_New_VPS\"><span class=\"toc_number toc_depth_1\">2<\/span> Step 1: Connect Safely to Your New VPS<\/a><ul><li><a href=\"#Gather_your_access_details\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Gather your access details<\/a><\/li><li><a href=\"#Connect_from_your_computer_via_SSH\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Connect from your computer via SSH<\/a><\/li><li><a href=\"#Immediately_change_the_root_password\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Immediately change the root password<\/a><\/li><\/ul><\/li><li><a href=\"#Step_2_Fully_Update_the_Operating_System\"><span class=\"toc_number toc_depth_1\">3<\/span> Step 2: Fully Update the Operating System<\/a><ul><li><a href=\"#Debian_Ubuntu_Update_with_apt\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Debian \/ Ubuntu: Update with apt<\/a><\/li><li><a href=\"#AlmaLinux_Rocky_Other_RHELlike_Update_with_dnf_or_yum\"><span class=\"toc_number toc_depth_2\">3.2<\/span> AlmaLinux \/ Rocky \/ Other RHEL\u2011like: Update with dnf or yum<\/a><\/li><li><a href=\"#Install_essential_tools\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Install essential tools<\/a><\/li><li><a href=\"#Set_timezone_and_basic_system_identity\"><span class=\"toc_number toc_depth_2\">3.4<\/span> Set timezone and basic system identity<\/a><\/li><li><a href=\"#Configure_automatic_security_updates_optional_but_recommended\"><span class=\"toc_number toc_depth_2\">3.5<\/span> Configure automatic security updates (optional but recommended)<\/a><\/li><\/ul><\/li><li><a href=\"#Step_3_Create_a_NonRoot_User_and_SSH_Keys\"><span class=\"toc_number toc_depth_1\">4<\/span> Step 3: Create a Non\u2011Root User and SSH Keys<\/a><ul><li><a href=\"#Create_a_new_user\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Create a new user<\/a><\/li><li><a href=\"#Generate_SSH_keys_on_your_local_machine\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Generate SSH keys on your local machine<\/a><\/li><li><a href=\"#Add_your_public_key_to_the_new_user\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Add your public key to the new user<\/a><\/li><li><a href=\"#Disable_direct_root_and_password_logins_in_SSH\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Disable direct root and password logins in SSH<\/a><\/li><\/ul><\/li><li><a href=\"#Step_4_Set_Up_a_Simple_but_Solid_Firewall\"><span class=\"toc_number toc_depth_1\">5<\/span> Step 4: Set Up a Simple but Solid Firewall<\/a><ul><li><a href=\"#UbuntuDebian_Use_UFW_Uncomplicated_Firewall\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Ubuntu\/Debian: Use UFW (Uncomplicated Firewall)<\/a><\/li><li><a href=\"#AlmaLinuxRockyRHEL_Use_firewalld\"><span class=\"toc_number toc_depth_2\">5.2<\/span> AlmaLinux\/Rocky\/RHEL: Use firewalld<\/a><\/li><li><a href=\"#Planning_for_nftables_and_more_advanced_setups\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Planning for nftables and more advanced setups<\/a><\/li><\/ul><\/li><li><a href=\"#Step_5_Add_Basic_Protection_Against_BruteForce_Attacks\"><span class=\"toc_number toc_depth_1\">6<\/span> Step 5: Add Basic Protection Against Brute\u2011Force Attacks<\/a><ul><li><a href=\"#Install_Fail2ban\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Install Fail2ban<\/a><\/li><li><a href=\"#Configure_a_simple_SSH_jail\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Configure a simple SSH jail<\/a><\/li><\/ul><\/li><li><a href=\"#Step_6_Log_Monitor_and_Baseline_Your_VPS\"><span class=\"toc_number toc_depth_1\">7<\/span> Step 6: Log, Monitor and Baseline Your VPS<\/a><ul><li><a href=\"#Check_basic_system_logs\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Check basic system logs<\/a><\/li><li><a href=\"#Baseline_CPU_disk_and_network_performance\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Baseline CPU, disk and network performance<\/a><\/li><li><a href=\"#Plan_simple_monitoring_and_alerts\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Plan simple monitoring and alerts<\/a><\/li><\/ul><\/li><li><a href=\"#Step_7_Enable_IPv6_and_Network_Hygiene_If_Available\"><span class=\"toc_number toc_depth_1\">8<\/span> Step 7: Enable IPv6 and Network Hygiene (If Available)<\/a><ul><li><a href=\"#Check_IPv6_connectivity\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Check IPv6 connectivity<\/a><\/li><\/ul><\/li><li><a href=\"#Step_8_Checklist_Recap_for_the_First_24_Hours\"><span class=\"toc_number toc_depth_1\">9<\/span> Step 8: Checklist Recap for the First 24 Hours<\/a><\/li><li><a href=\"#Beyond_Day_One_Where_to_Go_Next\"><span class=\"toc_number toc_depth_1\">10<\/span> Beyond Day One: Where to Go Next<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_the_First_24_Hours_on_a_VPS_Matter\">Why the First 24 Hours on a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> Matter<\/span><\/h2>\n<p>When you power up a brand\u2011new VPS, it usually comes in a very open, very generic state. Packages may be a few months out of date, the firewall is often disabled, and you are dropped straight into the server as the all\u2011powerful <strong>root<\/strong> user. That combination is perfect for speed during installation, but terrible for long\u2011term security and reliability. The first 24 hours are your chance to shape this blank machine into a hardened, predictable environment that you trust with your projects, clients and data.<\/p>\n<p>In this guide we\u2019ll walk through a practical, opinionated checklist that we also apply on our own infrastructure at dchost.com: fully updating the system, creating safe user accounts, setting up SSH keys, locking down root access, configuring a basic firewall, and adding a few protective layers like automatic updates and brute\u2011force protection. You don\u2019t need to be a Linux expert; we\u2019ll explain each step in simple terms, with copy\u2011and\u2011paste commands you can adapt for your distribution. By the end of this first day, your VPS will be far closer to \u201cproduction\u2011ready\u201d than most servers ever are.<\/p>\n<h2><span id=\"Step_1_Connect_Safely_to_Your_New_VPS\">Step 1: Connect Safely to Your New VPS<\/span><\/h2>\n<h3><span id=\"Gather_your_access_details\">Gather your access details<\/span><\/h3>\n<p>After ordering a VPS from us at dchost.com, you\u2019ll receive (or see in your control panel) key information:<\/p>\n<ul>\n<li>Server IP address (IPv4, and often IPv6)<\/li>\n<li>SSH port (usually 22, unless you customised it)<\/li>\n<li>Root username (often <code>root<\/code>)<\/li>\n<li>Root password or SSH key, depending on what you chose<\/li>\n<\/ul>\n<p>Keep these somewhere safe. You\u2019ll use them only for the initial connection and for emergencies later; routine work will move to a non\u2011root user.<\/p>\n<h3><span id=\"Connect_from_your_computer_via_SSH\">Connect from your computer via SSH<\/span><\/h3>\n<p><strong>SSH (Secure Shell)<\/strong> is the standard secure way to manage a Linux VPS. On macOS and Linux you can use the built\u2011in terminal; on Windows 10+ you can use Windows Terminal or PowerShell.<\/p>\n<p>From macOS\/Linux terminal or Windows PowerShell:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh root@YOUR_SERVER_IP<\/code><\/pre>\n<p>If your VPS uses a non\u2011standard SSH port, include it:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh -p 2222 root@YOUR_SERVER_IP<\/code><\/pre>\n<p>On first connect, SSH shows a message like \u201cThe authenticity of host can\u2019t be established\u2026\u201d. This is normal for a new server; verify you\u2019re connecting to the correct IP from your dchost.com panel, then type <code>yes<\/code> to trust it.<\/p>\n<h3><span id=\"Immediately_change_the_root_password\">Immediately change the root password<\/span><\/h3>\n<p>If your server was provisioned with a password, change it right away to something strong and unique:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">passwd<\/code><\/pre>\n<p>You\u2019ll be prompted to enter the new password twice. Use a password manager, not something you can easily memorise.<\/p>\n<p>If the server was provisioned with SSH keys only, you can skip this, but it\u2019s still good practice to ensure root login is later disabled over SSH (we\u2019ll do that in a later step).<\/p>\n<h2><span id=\"Step_2_Fully_Update_the_Operating_System\">Step 2: Fully Update the Operating System<\/span><\/h2>\n<p>Fresh VPS images are often a few weeks or months behind on package updates and security fixes. Before you install anything, bring the entire system up to date so you\u2019re building on a clean base.<\/p>\n<h3><span id=\"Debian_Ubuntu_Update_with_apt\">Debian \/ Ubuntu: Update with apt<\/span><\/h3>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">apt update\napt upgrade -y<\/code><\/pre>\n<p>On some systems you may also see <code>apt dist-upgrade<\/code> recommended to handle kernel and dependency changes. If prompted to restart services, accept the defaults. After a major kernel update, reboot:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">reboot<\/code><\/pre>\n<h3><span id=\"AlmaLinux_Rocky_Other_RHELlike_Update_with_dnf_or_yum\">AlmaLinux \/ Rocky \/ Other RHEL\u2011like: Update with dnf or yum<\/span><\/h3>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">dnf update -y<\/code><\/pre>\n<p>or on older systems:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">yum update -y<\/code><\/pre>\n<p>Again, reboot if the kernel is updated:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">reboot<\/code><\/pre>\n<h3><span id=\"Install_essential_tools\">Install essential tools<\/span><\/h3>\n<p>After reconnecting (now to the updated system), install some baseline tools that make day\u2011to\u2011day work easier:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Debian\/Ubuntu\napt install -y vim htop curl wget git unzip\n\n# AlmaLinux\/Rocky\/RHEL\ndnf install -y vim htop curl wget git unzip<\/code><\/pre>\n<p>You can replace <code>vim<\/code> with <code>nano<\/code> if you prefer.<\/p>\n<h3><span id=\"Set_timezone_and_basic_system_identity\">Set timezone and basic system identity<\/span><\/h3>\n<p>Correct time is crucial for logs, <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a>s and security tools.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">timedatectl list-timezones | grep Europe\nsudo timedatectl set-timezone Europe\/Istanbul<\/code><\/pre>\n<p>Replace with your actual timezone. Verify:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">timedatectl status<\/code><\/pre>\n<p>Also check the hostname, which appears in prompts and logs:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">hostnamectl status\nhostnamectl set-hostname myproject-vps-1<\/code><\/pre>\n<p>Use something descriptive, especially if you plan to manage multiple servers through your dchost.com account.<\/p>\n<h3><span id=\"Configure_automatic_security_updates_optional_but_recommended\">Configure automatic security updates (optional but recommended)<\/span><\/h3>\n<p>Most distributions support some form of automatic security updates. On Debian\/Ubuntu:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">apt install -y unattended-upgrades\nsudo dpkg-reconfigure unattended-upgrades<\/code><\/pre>\n<p>Enable at least automatic security patches. For more advanced TLS and protocol tuning later, you can refer to our detailed guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-tls-guvenlik-guncellemeleri-ne-zaman-nasil-ve-neyi-degistirmelisiniz\/\">SSL\/TLS security updates and what to keep in sync on your servers<\/a>.<\/p>\n<h2><span id=\"Step_3_Create_a_NonRoot_User_and_SSH_Keys\">Step 3: Create a Non\u2011Root User and SSH Keys<\/span><\/h2>\n<p>Running everything as <strong>root<\/strong> is convenient but dangerous. If any command or application is compromised, an attacker immediately has full control of the machine. Instead, use an unprivileged user, and grant it sudo (admin) rights only when needed.<\/p>\n<h3><span id=\"Create_a_new_user\">Create a new user<\/span><\/h3>\n<p>Choose a username that matches who will use the server, for example <code>deploy<\/code> or your own name.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">adduser deploy<\/code><\/pre>\n<p>Follow the prompts for password and optional details (you can leave those blank). Then add the user to the <code>sudo<\/code> or <code>wheel<\/code> group:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Debian\/Ubuntu\nusermod -aG sudo deploy\n\n# AlmaLinux\/Rocky\/RHEL\nusermod -aG wheel deploy<\/code><\/pre>\n<p>Test the user by switching to it:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">su - deploy<\/code><\/pre>\n<p>Then test sudo:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo whoami<\/code><\/pre>\n<p>If everything is configured correctly, it should output <code>root<\/code> after you enter the user\u2019s password.<\/p>\n<h3><span id=\"Generate_SSH_keys_on_your_local_machine\">Generate SSH keys on your local machine<\/span><\/h3>\n<p><strong>SSH keys<\/strong> are safer and more convenient than passwords. They use a pair of cryptographic keys: one private key that stays on your computer, and one public key that you upload to the server.<\/p>\n<p>On your laptop\/desktop (not on the VPS), generate a key pair:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh-keygen -t ed25519 -C &quot;my-laptop-key&quot;<\/code><\/pre>\n<p>Press Enter to accept the default path (usually <code>~\/.ssh\/id_ed25519<\/code>) and set a strong passphrase when asked.<\/p>\n<p>This creates:<\/p>\n<ul>\n<li>Private key: <code>~\/.ssh\/id_ed25519<\/code> (keep this secret)<\/li>\n<li>Public key: <code>~\/.ssh\/id_ed25519.pub<\/code> (safe to share with servers)<\/li>\n<\/ul>\n<h3><span id=\"Add_your_public_key_to_the_new_user\">Add your public key to the new user<\/span><\/h3>\n<p>Still on your local machine, copy the public key to the server:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh-copy-id deploy@YOUR_SERVER_IP<\/code><\/pre>\n<p>If <code>ssh-copy-id<\/code> is not available, you can manually copy the contents of <code>id_ed25519.pub<\/code> and paste into the server:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># On the VPS as root (or via sudo)\nmkdir -p \/home\/deploy\/.ssh\nnano \/home\/deploy\/.ssh\/authorized_keys<\/code><\/pre>\n<p>Paste the public key line, save and exit, then fix permissions:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">chown -R deploy:deploy \/home\/deploy\/.ssh\nchmod 700 \/home\/deploy\/.ssh\nchmod 600 \/home\/deploy\/.ssh\/authorized_keys<\/code><\/pre>\n<p>Now, from your local machine, test logging in as the new user:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssh deploy@YOUR_SERVER_IP<\/code><\/pre>\n<p>If it logs in without asking for the user\u2019s password (but may ask for your key passphrase), SSH keys are working.<\/p>\n<p>If you want to go further and use hardware security keys or an SSH certificate authority later, we\u2019ve written a deeper, practical guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/vpste-ssh-guvenligi-nasil-saglamlasir-fido2-anahtarlari-ssh-ca-ve-rotasyonun-sicacik-yolculugu\/\">VPS SSH hardening with FIDO2 keys and safe key rotation<\/a>.<\/p>\n<h3><span id=\"Disable_direct_root_and_password_logins_in_SSH\">Disable direct root and password logins in SSH<\/span><\/h3>\n<p>Once you can log in as the non\u2011root user with SSH keys, lock down SSH so that:<\/p>\n<ul>\n<li>Root cannot log in directly<\/li>\n<li>Password\u2011based logins are disabled for everyone<\/li>\n<\/ul>\n<p>On the VPS, edit the SSH config as root (or with sudo):<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo nano \/etc\/ssh\/sshd_config<\/code><\/pre>\n<p>Find and update (or add) the following lines:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">PermitRootLogin no\nPasswordAuthentication no\nChallengeResponseAuthentication no\nUsePAM yes<\/code><\/pre>\n<p>If you plan to allow some password logins temporarily, change only <code>PermitRootLogin<\/code> to <code>no<\/code> first, test, and then later disable passwords entirely when you are confident with keys.<\/p>\n<p>Optionally, you can also change the default SSH port:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Port 2222<\/code><\/pre>\n<p>If you do, remember to adjust firewall rules (next step) and update your SSH commands accordingly.<\/p>\n<p>Restart SSH to apply changes:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl restart sshd<\/code><\/pre>\n<p>Open a <strong>new<\/strong> terminal window and confirm you can still log in with your key. Only after verifying should you close the original root session.<\/p>\n<h2><span id=\"Step_4_Set_Up_a_Simple_but_Solid_Firewall\">Step 4: Set Up a Simple but Solid Firewall<\/span><\/h2>\n<p>A <strong>firewall<\/strong> controls which network ports are reachable from the internet. By default, your VPS may accept connections on many ports that you never intend to use. We want a very simple rule set for the first 24 hours:<\/p>\n<ul>\n<li>Allow SSH (your chosen port)<\/li>\n<li>Allow HTTP (80) and HTTPS (443) if you are hosting websites<\/li>\n<li>Deny or drop everything else by default<\/li>\n<\/ul>\n<h3><span id=\"UbuntuDebian_Use_UFW_Uncomplicated_Firewall\">Ubuntu\/Debian: Use UFW (Uncomplicated Firewall)<\/span><\/h3>\n<p>On Ubuntu, UFW is often installed out of the box, but not always enabled.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo apt install -y ufw<\/code><\/pre>\n<p>Allow SSH first (adjust if you changed port):<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo ufw allow 22\/tcp   # or your custom port<\/code><\/pre>\n<p>If you plan to host websites:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo ufw allow 80\/tcp\nsudo ufw allow 443\/tcp<\/code><\/pre>\n<p>Then set default policies and enable:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo ufw default deny incoming\nsudo ufw default allow outgoing\nsudo ufw enable<\/code><\/pre>\n<p>Check the status:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo ufw status verbose<\/code><\/pre>\n<p>Always ensure your current SSH port is allowed <strong>before<\/strong> enabling the firewall; otherwise you can lock yourself out.<\/p>\n<h3><span id=\"AlmaLinuxRockyRHEL_Use_firewalld\">AlmaLinux\/Rocky\/RHEL: Use firewalld<\/span><\/h3>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo dnf install -y firewalld\nsudo systemctl enable --now firewalld<\/code><\/pre>\n<p>Allow SSH and web traffic:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo firewall-cmd --permanent --add-service=ssh\nsudo firewall-cmd --permanent --add-service=http\nsudo firewall-cmd --permanent --add-service=https\nsudo firewall-cmd --reload<\/code><\/pre>\n<p>For a non\u2011standard SSH port, open it explicitly:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo firewall-cmd --permanent --add-port=2222\/tcp\nsudo firewall-cmd --reload<\/code><\/pre>\n<h3><span id=\"Planning_for_nftables_and_more_advanced_setups\">Planning for nftables and more advanced setups<\/span><\/h3>\n<p>Once you\u2019re comfortable with the basics, you may want to move beyond UFW\/firewalld and use <strong>nftables<\/strong> directly for fine\u2011grained rules (rate limiting, port knocking, IPv6 tuning, etc.). When you reach that stage, our cookbook on <a href=\"https:\/\/www.dchost.com\/blog\/en\/nftables-ile-vps-guvenlik-duvari-rehberi-rate-limit-port-knocking-ve-ipv6-kurallari-nasil-tatli-tatli-kurulur\/\">building nftables firewalls for VPS servers<\/a> will help you move step\u2011by\u2011step without drama.<\/p>\n<h2><span id=\"Step_5_Add_Basic_Protection_Against_BruteForce_Attacks\">Step 5: Add Basic Protection Against Brute\u2011Force Attacks<\/span><\/h2>\n<p>Even on a completely empty VPS, you\u2019ll see constant automated login attempts on SSH within minutes of going online. With keys and a firewall you are already in a good position, but adding a tool like <strong>Fail2ban<\/strong> gives you an extra safety net by blocking IPs that repeatedly fail to authenticate.<\/p>\n<h3><span id=\"Install_Fail2ban\">Install Fail2ban<\/span><\/h3>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Debian\/Ubuntu\nsudo apt install -y fail2ban\n\n# AlmaLinux\/Rocky\/RHEL\nsudo dnf install -y fail2ban\nsudo systemctl enable --now fail2ban<\/code><\/pre>\n<h3><span id=\"Configure_a_simple_SSH_jail\">Configure a simple SSH jail<\/span><\/h3>\n<p>Create a local configuration file so your changes are not overwritten by updates:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo mkdir -p \/etc\/fail2ban\/jail.d\nsudo nano \/etc\/fail2ban\/jail.d\/ssh.conf<\/code><\/pre>\n<p>Example minimal config (assuming SSH on port 22):<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">[sshd]\nenabled  = true\nport     = ssh\nlogpath  = \/var\/log\/auth.log\nmaxretry = 5\nfindtime = 600\nbantime  = 3600<\/code><\/pre>\n<p>On RHEL\u2011like systems the SSH log path is often <code>\/var\/log\/secure<\/code>, so adjust accordingly.<\/p>\n<p>Restart Fail2ban:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl restart fail2ban<\/code><\/pre>\n<p>Check status:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo fail2ban-client status sshd<\/code><\/pre>\n<p>Over time you\u2019ll see banned IPs accumulate. This is normal; it shows Fail2ban is actively blocking repeated failed logins.<\/p>\n<p>If you later build more complex stacks with web application firewalls or CDN\u2011side protection, you can combine those with host\u2011level protections. For example, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/waf-ve-bot-korumasi-cloudflare-modsecurity-ve-fail2bani-ayni-masada-baristirmanin-sicacik-hikayesi\/\">layered WAF and bot protection using Cloudflare, ModSecurity and Fail2ban together<\/a> shows how these tools complement each other in real\u2011world setups.<\/p>\n<h2><span id=\"Step_6_Log_Monitor_and_Baseline_Your_VPS\">Step 6: Log, Monitor and Baseline Your VPS<\/span><\/h2>\n<p>The first 24 hours are also a good time to create a \u201cbefore anything runs\u201d baseline, so you can later spot when something is off.<\/p>\n<h3><span id=\"Check_basic_system_logs\">Check basic system logs<\/span><\/h3>\n<p>System logs live primarily under <code>\/var\/log<\/code>. A few important ones to glance at after your initial setup:<\/p>\n<ul>\n<li><code>\/var\/log\/auth.log<\/code> or <code>\/var\/log\/secure<\/code> \u2013 SSH logins, sudo activity<\/li>\n<li><code>\/var\/log\/syslog<\/code> or <code>\/var\/log\/messages<\/code> \u2013 general system messages<\/li>\n<li><code>journalctl -xe<\/code> \u2013 recent systemd errors and warnings<\/li>\n<\/ul>\n<p>Spend a few minutes checking for repeated errors or suspicious entries. This helps you get used to normal noise levels so anomalies stand out later.<\/p>\n<h3><span id=\"Baseline_CPU_disk_and_network_performance\">Baseline CPU, disk and network performance<\/span><\/h3>\n<p>While not strictly security\u2011related, a quick benchmark in the first 24 hours gives you a reference for your VPS\u2019s health over time. If, months later, everything becomes slow, you\u2019ll know what \u201cfast\u201d looked like on day one. We\u2019ve covered this in detail in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yeni-vps-aldiginizda-ilk-yapmaniz-gerekenler-cpu-disk-ve-ag-performansini-benchmark-ile-test-etmek\/\">what to test when you buy a new VPS (CPU, disk and network benchmarking)<\/a>.<\/p>\n<h3><span id=\"Plan_simple_monitoring_and_alerts\">Plan simple monitoring and alerts<\/span><\/h3>\n<p>Even a tiny setup benefits from basic monitoring. At minimum, consider:<\/p>\n<ul>\n<li>Uptime monitoring (HTTP checks to your site)<\/li>\n<li>CPU, RAM, disk usage and network traffic graphs<\/li>\n<li>Alerts for high load, low disk space or service failures<\/li>\n<\/ul>\n<p>When you are ready to go beyond \u201clog in and check manually\u201d, our practical starter guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-izleme-ve-alarm-kurulumu-prometheus-grafana-ve-uptime-kuma-ile-baslangic\/\">VPS monitoring and alerts with Prometheus, Grafana and Uptime Kuma<\/a> walks through a simple, modern setup that still fits on a single VPS.<\/p>\n<h2><span id=\"Step_7_Enable_IPv6_and_Network_Hygiene_If_Available\">Step 7: Enable IPv6 and Network Hygiene (If Available)<\/span><\/h2>\n<p>Many modern VPS plans at dchost.com include IPv6 connectivity. Enabling and testing it on day one prevents headaches later, especially as global IPv6 adoption keeps climbing.<\/p>\n<h3><span id=\"Check_IPv6_connectivity\">Check IPv6 connectivity<\/span><\/h3>\n<p>From your VPS, run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ip addr | grep inet6<\/code><\/pre>\n<p>If you see a global (non\u2011<code>fe80::<\/code>) IPv6 address, you\u2019re likely good. Test outbound connectivity:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ping6 google.com<\/code><\/pre>\n<p>If that works, also ensure your firewall rules cover IPv6 as well as IPv4. UFW and firewalld support both; just confirm that <code>v6<\/code> rules are enabled.<\/p>\n<p>For a more detailed, end\u2011to\u2011end walkthrough, we have a dedicated article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucunuzda-ipv6-kurulum-ve-yapilandirma-rehberi-2\/\">IPv6 setup and configuration on a VPS server<\/a>, including DNS AAAA records and practical real\u2011world checks.<\/p>\n<h2><span id=\"Step_8_Checklist_Recap_for_the_First_24_Hours\">Step 8: Checklist Recap for the First 24 Hours<\/span><\/h2>\n<p>Let\u2019s summarise the core tasks you should aim to complete on day one:<\/p>\n<ol>\n<li><strong>Connect securely:<\/strong> Use SSH, verify host key, immediately change the root password if applicable.<\/li>\n<li><strong>Update the OS:<\/strong> Run full package upgrades, install essential tools, set timezone and hostname.<\/li>\n<li><strong>Create a non\u2011root user:<\/strong> Add a normal user, grant sudo\/wheel access, test sudo.<\/li>\n<li><strong>Set up SSH keys:<\/strong> Generate keys locally, add the public key to your user, test key\u2011based login.<\/li>\n<li><strong>Lock down SSH:<\/strong> Disable root SSH login, consider disabling password logins, optionally change the SSH port.<\/li>\n<li><strong>Configure a firewall:<\/strong> Use UFW or firewalld to allow SSH and web ports, deny everything else.<\/li>\n<li><strong>Add brute\u2011force protection:<\/strong> Install and configure Fail2ban for SSH (and later, web services).<\/li>\n<li><strong>Review logs and baseline performance:<\/strong> Check system logs for errors, run a simple benchmark.<\/li>\n<li><strong>Enable IPv6 (if available):<\/strong> Confirm connectivity, ensure firewall rules cover IPv6.<\/li>\n<\/ol>\n<p>This may look like a long list, but in practice, once you get used to it, most of these steps can be completed in under an hour. The security and stability benefit you gain is far greater than the time investment.<\/p>\n<h2><span id=\"Beyond_Day_One_Where_to_Go_Next\">Beyond Day One: Where to Go Next<\/span><\/h2>\n<p>After the first 24 hours, you\u2019ll move from \u201cmake the VPS safe\u201d to \u201cmake it serve real workloads\u201d. That means installing your web stack (Nginx\/Apache, PHP, Node.js, databases), configuring HTTPS certificates, setting up backups, and building proper deployment workflows. We\u2019ve covered many of these topics across the dchost.com blog, from <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucu-guvenligi-pratik-olceklenebilir-ve-dogrulanabilir-yaklasimlar\/\">deeper VPS security hardening<\/a> to stack\u2011specific tuning for WordPress, Laravel and more.<\/p>\n<p>The important thing is that you now start from a known\u2011good, hardened baseline: updates applied, firewall in place, SSH locked down, and basic protection against automated attacks. Every minute you invest at this stage makes your later architecture decisions easier and your incidents rarer.<\/p>\n<p>If you\u2019re planning your next project, or looking to move up from shared hosting, our VPS plans at dchost.com are designed with this workflow in mind: clean images, up\u2011to\u2011date kernels, IPv6 support and data centres optimised for real\u2011world hosting. Combine that with the checklist you\u2019ve just followed, and you\u2019ll have a solid, professional foundation for whatever you build next\u2014without turning your first 24 hours on a new VPS into a stressful experience.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>\u0130&ccedil;indekiler1 Why the First 24 Hours on a VPS Matter2 Step 1: Connect Safely to Your New VPS2.1 Gather your access details2.2 Connect from your computer via SSH2.3 Immediately change the root password3 Step 2: Fully Update the Operating System3.1 Debian \/ Ubuntu: Update with apt3.2 AlmaLinux \/ Rocky \/ Other RHEL\u2011like: Update with dnf [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3174,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3173","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3173","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3173"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3173\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3174"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3173"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3173"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3173"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}