Bagong VPS: Ano ang Gagawin sa Unang 10 Minuto

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

Hindi ligtas ang bagong VPS. Mula sa sandaling magkaroon ito ng public IP, may mga scanner nang sumusubok mag-log in. Malaking target ang default image dahil madalas na naaabot ang root, pinapayagan ang mga password, walang firewall, at walang regular na patching. Ang mabuting balita, matatapos ang mga ito sa loob ng humigit-kumulang 10 minuto gamit ang ilang command. Ito ang runbook na ginagamit ko sa bawat bagong server bago ako maglagay ng anuman dito.

Sundin ito ayon sa pagkakasunod-sunod dahil nakabatay ang bawat hakbang sa mga nauna. May sariling guide ang bawat isa at may link habang nagpapatuloy ka. Ang page na ito ang mabilis na daloy na nag-uugnay sa lahat ng ito.

Minuto 1: I-update ang lahat

Mag-log in bilang root gamit ang credentials na ibinigay ng provider, at ganap na i-update ang system bago gawin ang iba pa:

apt update && apt upgrade -y

Ang system na walang patch ang pinakamadaling target, kaya ito ang unang hakbang. Kapag tapos na, mag-set up ng automatic security updates para patuloy itong ma-update nang hindi mo kailangang tandaan.

Minuto 2: Gumawa ng normal na user na may sudo

Huwag magpatuloy na root ang ginagamit. Gumawa ng user para sa iyong sarili at bigyan ito ng sudo:

adduser matt
usermod -aG sudo matt

Mula rito, mag-login bilang user na ito at gamitin ang sudo para sa mga administrative task. Kapag palaging root ang ginagamit, bawat pagkakamali at bawat pag-breach ay nangyayari nang may walang limitasyong privilege. Ito mismo ang pinipigilan ng paggamit bilang unprivileged user.

Minuto 4: I-set up ang SSH keys

Nai-guess ang mga password; hindi ang mga key. Sa sarili mong laptop, kung wala ka pang key, gumawa ng isa:

ssh-keygen -t ed25519

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

ssh-copy-id matt@YOUR_SERVER

Kailangang naka-on ang password login ng ssh-copy-id para sa bagong user; kung naka-off na ito, i-copy ang ~/.ssh/authorized_keys ng root sa /home/matt/.ssh/authorized_keys (na pagmamay-ari ng matt), o manu-manong i-paste ang public key mo sa file na iyon.

Ang modelong nasa likod ng hakbang na ito—isang key bawat device, ang mga permission na sumisira sa key login, at ang pag-revoke ng nawawalang key—ay saklaw sa Mga pangunahing kaalaman sa SSH key management.

Mag-log out at mag-log in muli bilang matt gamit ang key, at tiyaking gumagana ito bago mo gawin ang susunod na hakbang. Kung i-lock down mo ang SSH bago ka makapasok gamit ang key, maaari mong ma-lock out ang sarili mo. Kung bumalik ang login na iyon na may Permission denied (publickey), ayusin ito ngayon sa halip na bumalik sa paggamit ng password, dahil saklaw ng mensaheng iyon ang limang magkakaibang fault at ipinapakita ng output ng ssh -v kung alin sa mga ito ang aktuwal mong nararanasan.

Minuto 6: I-off ang root login at mga password

Ngayong gumagana na ang key mo, isara ang dalawang daanang 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 sorting kaysa sa 50-cloud-init.conf, na kasama sa Ubuntu cloud images bilang PasswordAuthentication yes; ginagamit ng sshd ang unang value na nababasa nito, kaya tahimik na hindi gagana ang drop-in file na mas huli sa sorting:

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

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Pagkatapos, i-reload ang SSH:

sudo systemctl restart ssh

Suriin naman ang aktuwal na settings na ginagamit ng sshd para hindi ka malinlang ng drop-in file na hindi nanalo sa configuration:

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

Kapag naka-off na ang mga password at wala na ang root login, hindi na magtatagumpay ang tuloy-tuloy na brute-force traffic laban sa server mo. Nasa Pagpapatibay ng SSH sa isang VPS ang kumpletong gabay, kasama ang opsyonal na pagpapalit ng port.

Ika-8 Minuto: I-on ang firewall

I-set ang default na deny para sa lahat ng inbound traffic, pagkatapos ay payagan lamang ang kailangan mo. Payagan ang SSH bago mo ito i-enable; kung hindi, mawawala ang sarili mong koneksyon:

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

Magdagdag ng mga panuntunang allow para sa bawat serbisyong aktuwal mong pinapatakbo, gaya ng 80/tcp at 443/tcp para sa isang website. Kung hindi na makakonekta ang isang bagong SSH session pagkatapos nito, basahin muna ang error bago ka gumawa ng anumang pagbabago, dahil ang refusal ay nangangahulugang sumagot ang sshd, samantalang ang timeout ay karaniwang nangangahulugang hinarang ng firewall ang packet. Tiyaking saklaw ang IPv4 at IPv6, dahil ang firewall na IPv4 lamang ang sinasala ay iniiwang ganap na bukas ang IPv6 side. Nasa Firewalls 101 sa isang VPS ang buong walkthrough. Ipinapalagay ng mga command na ufw na Ubuntu o Debian ang ginagamit; sa isang Rocky o AlmaLinux box, pareho ang layunin na default-deny, ngunit firewalld ang tool, kaya sundin sa halip ang bersyon ng hakbang na ito para sa firewalld.

Minuto 10: Pabagalin ang mga scanner gamit ang Fail2ban

Panghuli, idagdag ang Fail2ban upang i-block ang mga address na paulit-ulit na kumokonekta sa iyong mga port:

sudo apt install -y fail2ban

Sa Ubuntu 24.04, pinoprotektahan ng default na installation ang SSH mula sa unang boot. Dahil kailangan na ang mga key, nagsisilbi itong karagdagang proteksiyon na nagpapababa ng ingay sa logs at nagba-block ng mga paulit-ulit na umaatake, sa halip na maging pangunahing depensa mo.

Ang checklist mo

Iyan ang runbook. Gamitin ang generator sa ibaba upang markahan ang bawat control at gumawa ng personalized na checklist na maaari mong itago kasama ng server, kabilang ang eksaktong command para sa bawat hakbang:

Isagawa ito nang isang beses para sa bawat bagong server, at magiging muscle memory ang buong proseso. Ang sampung minuto ngayon ay makapagliligtas sa iyo sa napakasamang hapon kapag na-breach ang server.

Kapag nailagay na ang mahahalagang control, mapananatiling updated ng automatic security updates sa Ubuntu ang server nang hindi mo kailangang mag-log in muli. Kailangan pa ring dumaan sa sarili nitong pagsusuri ang bawat service na idinadagdag mo. Nagbabago ang mga mahinang punto: sa isang self-hosted password vault, hindi nagtatago ang server ng plaintext, kaya ang mga tunay na panganib sa Vaultwarden ay ang admin token at ang backup file.

FAQ

Ano ang dapat kong gawin muna sa bagong VPS?

I-update ang system gamit ang apt update && apt upgrade -y, pagkatapos ay gumawa ng normal na user na may sudo at huwag nang magtrabaho bilang root. Mula roon, mag-set up ng SSH keys, i-disable ang root login at password authentication, mag-enable ng default-deny firewall, at mag-install ng Fail2ban. Ang pagsunod sa ganitong pagkakasunod-sunod ay nagbibigay-daan para maisagawa nang ligtas ang bawat hakbang nang hindi nawawalan ng access.

Paano ko maiiwasang ma-lock out ang sarili ko habang pinapatibay ang SSH?

I-set up at subukan muna ang SSH key login bago i-disable ang mga password o root. Mag-log out at mag-log in muli gamit ang key upang makumpirmang gumagana ito, at saka lamang i-off ang PasswordAuthentication at PermitRootLogin. Kapag nag-enable ng firewall, payagan muna ang port 22 bago patakbuhin ang ufw enable. Kung ma-lock out ka, makakapasok kang muli gamit ang web console ng provider nang hindi gumagamit ng SSH.

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

Oo, dahil walang pakialam ang mga scanner kung gaano kaliit ang server mo. Pareho nilang sinusubukan ang bawat public IP. Tumatagal nang humigit-kumulang sampung minuto ang buong runbook at inaalis nito ang madaling paraan ng pag-atake: walang root login, walang paghula ng password, walang nakalantad na hindi mo piniling ilantad, at awtomatikong napapatungan ang mga kilalang bug.

Ano ang pinakamahalagang hakbang?

Key-only SSH na naka-disable ang root login. Karamihan ng mga pag-atake sa bagong VPS ay mga automated na paghula ng password laban sa root, at kapag parehong naka-disable ang mga ito, nagiging imposible ang buong kategoryang iyon ng pag-atake. Nililimitahan ng firewall at Fail2ban ang nakalantad na access at pinapabagal ang mga pag-atakeng makalusot pa rin.

Paano ko makukumpirmang talagang secured na ang server?

Manu-manong suriin ang tatlong bagay bago mo ito pagkatiwalaan. Patakbuhin ang sudo ss -tlnp at kumpirmahing ang mga port lamang na nilayon mong buksan ang nakikinig sa public address, at walang 0.0.0.0 o [::] service na nakalimutan mong i-check. Patakbuhin ang sudo ufw status verbose at kumpirmahing deny ang default incoming policy at naroon ang plain at (v6) rules. Palaging magbukas ng pangalawang SSH session bago isara ang una, upang hindi ka ma-lock out sa server ng maling SSH configuration. Kung tama ang lahat ng tatlo, nasa lugar na ang mga pangunahing proteksyon.