Paano i-secure ang bagong VPS sa loob ng 10 min

Ang unang 10 minuto ang magtatakda kung gaano kaligtas ang iyong server

Hindi ligtas ang isang brand-new na VPS. Mula sa sandaling magkaroon ito ng public IP, sinusubukan na ng mga scanner na mag-log in. Ang default image ay nagbibigay sa kanila ng malaking target: madalas na reachable ang root, madalas na pinapayagan ang passwords, walang firewall, at walang naka-schedule na patching. Ang magandang balita ay ang pag-close sa lahat ng ito ay tatagal lamang ng sampung minuto gamit ang ilang commands. Ito ang runbook na ginagamit ko sa bawat bagong server bago ako maglagay ng kahit ano.

Sundin ito nang sunod-sunod dahil ang bawat step ay nakadepende sa nauna. Ang bawat isa ay may sariling guide na naka-link habang nagbabasa ka; ang page na ito ang mabilis na paraan para pag-isahin sila.

Minute 1: I-update ang lahat

Mag-log in bilang root gamit ang credentials na ibinigay ng iyong provider, at i-update nang buo ang system bago ang anuman:

apt update && apt upgrade -y

Ang unpatched na box ang pinakamadaling target, kaya ito ang dapat unahin. Pagkatapos nito, i-set up ang automatic security updates para manatiling patched ang system nang hindi mo na kailangang tandaan.

Minute 2: Gumawa ng normal na user na may sudo

Huwag nang magpatuloy sa pagtatrabaho bilang root. Gumawa ng user para sa iyong sarili at bigyan ito ng sudo:

adduser matt
usermod -aG sudo matt

Mula rito, mag-log in gamit ang user na ito at gamitin ang sudo para sa mga admin tasks. Ang laging pagtakbo bilang root ay nangangahulugang ang bawat pagkakamali at bawat compromise ay mangyayari nang may unlimited power, na siyang gustong iwasan ng pagtakbo bilang isang unprivileged user.

Minute 4: I-set up ang SSH keys

Ang mga password ay nahuhulaan; ang mga key ay hindi. Sa iyong sariling laptop, kung wala ka pang key, gumawa ng isa:

ssh-keygen -t ed25519

Pagkatapos ay i-copy ang public half nito sa server:

ssh-copy-id matt@YOUR_SERVER

Kailangan ng ssh-copy-id na naka-on ang password login para sa bagong user; kung naka-off na ito, i-copy ang ~/.ssh/authorized_keys ng root sa /home/matt/.ssh/authorized_keys (owned ng matt), o i-paste nang manual ang iyong public key sa file na iyon.

Ang konsepto sa likod ng step na ito—isang key bawat device, ang mga permission na sumisira sa key login, at ang pag-revoke ng nawalang key—ay covered sa SSH key management basics.

Mag-log out at mag-log in muli bilang matt gamit ang key, at kumpirmahin na gumagana ito bago galawin ang susunod na step. Ang pag-lock down sa SSH bago ka pa makapasok gamit ang key ang dahilan kung bakit na-lo-lock out ang mga tao.

Minute 6: I-off ang root login at passwords

Ngayong gumagana na ang iyong key, i-close ang dalawang pinto na ginagamit ng mga scanner. Gumamit ng drop-in file para hindi ito ma-overwrite ng mga package upgrade. Pangalanan itong 00- para mauna ito sa 50-cloud-init.conf, na kasama sa mga Ubuntu cloud images na may PasswordAuthentication yes; itinatago ng sshd ang unang value na mababasa nito, kaya ang file na mas huling naka-sort ay mawawalan ng effect nang tahimik:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Pagkatapos ay i-reload ang SSH:

sudo systemctl restart ssh

Pagkatapos ay i-check ang settings na aktwal na ginagamit ng sshd, para hindi ka maloko ng isang maling drop-in file:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Dahil naka-off na ang passwords at wala na ang root login, ang constant brute-force traffic laban sa iyong server ay hindi na magtatagumpay. Ang buong proseso, kasama ang optional na pagpapalit ng port, ay nasa SSH hardening on a VPS.

Minute 8: I-on ang firewall

I-deny ang lahat ng inbound traffic by default, pagkatapos ay payagan lamang ang mga kailangan mo. I-allow ang SSH bago i-enable ang firewall, kundi mapuputol ang iyong sariling connection:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Magdagdag ng allow rules para sa anumang service na iyong pinapatakbo, gaya ng 80/tcp at 443/tcp para sa isang website. Siguraduhin na covered ang IPv4 at IPv6, dahil ang firewall na IPv4 lang ang fina-filter ay nag-iiwan sa IPv6 side na bukas. Ang buong walkthrough ay Firewalls 101 on a VPS.

Minute 10: Bagalan ang mga scanner gamit ang Fail2ban

Sa huli, i-add ang Fail2ban para i-evict ang mga address na nagha-hammer sa iyong mga port:

sudo apt install -y fail2ban

Sa Ubuntu 24.04, ang stock install ay protektado na ang SSH mula sa unang boot. Dahil required na ang mga key, ito ay nagsisilbing backstop para bawasan ang log noise at i-block ang mga paulit-ulit na offender, sa halip na ito ang iyong main defence.

Ang iyong checklist

Iyan ang runbook. Gamitin ang generator sa ibaba para i-tick ang bawat control at gumawa ng personalized checklist na maaari mong itabi sa server, kasama ang eksaktong command para sa bawat step:

Gawin ito sa bawat bagong server at magiging muscle memory na ito. Ang sampung minuto ngayon ay makakatipid sa iyo sa napakasamang hapon na kasunod ng pagka-compromise ng isang server.

Kapag nasa lugar na ang mga essentials, ang automatic security updates sa Ubuntu ang magpapanatiling updated sa server nang hindi mo na kailangang mag-log in muli.

FAQ

Ano ang dapat kong unahin sa isang bagong VPS?

I-update ang system gamit ang apt update && apt upgrade -y, pagkatapos ay gumawa ng normal na user na may sudo at itigil ang pagtatrabaho bilang root. Mula rito, i-set up ang SSH keys, i-disable ang root login at password authentication, i-enable ang isang default-deny firewall, at i-install ang Fail2ban. Ang paggawa sa mga ito sa pagkakasunod-sunod na iyon ay nangangahulugang ligtas ang bawat step nang hindi ka na-lo-lock out.

Paano ko maiiwasang ma-lock out habang hina-harden ang SSH?

I-set up at i-test ang iyong SSH key login bago i-disable ang passwords o root. Mag-log out at mag-log in muli gamit ang key para kumpirmahin na gumagana ito, at saka lamang i-off ang PasswordAuthentication at PermitRootLogin. Kapag i-e-enable mo ang firewall, i-allow ang port 22 bago patakbuhin ang ufw enable. Kung ma-lock out ka man, ang web console ng iyong provider ang magbabalik sa iyo nang hindi gumagamit ng SSH.

Kailangan ko ba talaga ang lahat ng ito sa isang maliit na server?

Oo, dahil walang pakialam ang mga scanner kung gaano kaliit ang iyong server. Sinusubukan nila ang bawat public IP sa parehong paraan. Ang buong runbook ay tumatagal lamang ng sampung minuto at inaalis ang mga madaling daan: walang root login, walang password guessing, walang exposed na hindi mo pinili, at ang mga kilalang bugs ay awtomatikong naka-patch.

Ano ang pinaka-importanteng step?

SSH na key-only at disabled ang root login. Karamihan sa mga attack sa isang bagong VPS ay automated password guesses laban sa root, at ang pag-off sa dalawang ito ay ginagawang imposible ang buong kategorya ng attack na iyon. Ang firewall at Fail2ban naman ang naglilimita sa kung ano ang exposed at nagpapabagal sa anumang natitira.

Paano ko makukumpirma na talagang locked down ang server?

I-check nang manual ang tatlong bagay bago ito pagkatiwalaan. Patakbuhin ang sudo ss -tlnp at kumpirmahin na ang mga port na gusto mong buksan lang ang nakikinig sa isang public address, nang walang 0.0.0.0 o [::] service na nakalimutan mo. Patakbuhin ang sudo ufw status verbose at kumpirmahin na ang default incoming policy ay deny at ang parehong plain at (v6) rules ay naroon. At laging magbukas ng pangalawang SSH session bago isara ang una, para ang pagkakamali sa SSH configuration ay hindi ka ma-lock out sa server. Kung ang tatlong ito ay tama, nasa lugar na ang mga basics.