Cara Selamatkan VPS Baru Dalam 10 Minit

10 minit pertama menentukan tahap keselamatan pelayan anda

VPS yang baru dibeli tidak selamat. Sebaik sahaja ia mempunyai IP awam, pengimbas akan cuba untuk log masuk. Imej lalai memberikan mereka sasaran yang besar: akaun root sering boleh dicapai, kata laluan sering dibenarkan, tiada firewall, dan tiada jadual kemas kini tampalan. Berita baiknya ialah menutup semua kelemahan ini hanya mengambil masa kira-kira sepuluh minit dengan beberapa arahan sahaja. Ini adalah buku panduan (runbook) yang saya jalankan pada setiap pelayan baharu sebelum meletakkan sebarang aplikasi di atasnya.

Lakukan langkah-langkah ini mengikut urutan, kerana setiap langkah membina asas bagi langkah seterusnya. Setiap langkah mempunyai panduan tersendiri yang dipautkan semasa anda melaluinya; halaman ini merupakan laluan pantas yang menggabungkan kesemuanya.

Minit 1: Kemas kini segala-galanya

Log masuk sebagai root menggunakan kelayakan yang diberikan oleh penyedia anda, dan kemas kini sistem sepenuhnya sebelum melakukan perkara lain:

apt update && apt upgrade -y

Pelayan yang tidak ditampal (unpatched) merupakan sasaran paling mudah, jadi langkah ini perlu diutamakan. Setelah selesai, sediakan kemas kini keselamatan automatik supaya sistem kekal ditampal tanpa perlu anda mengingatinya.

Minit 2: Cipta pengguna biasa dengan sudo

Jangan terus bekerja sebagai root. Cipta pengguna untuk diri anda dan berikan akses sudo:

adduser matt
usermod -aG sudo matt

Mulai sekarang, log masuk sebagai pengguna ini dan gunakan sudo untuk tugasan pentadbiran. Menjalankan proses sebagai root sepanjang masa bermakna setiap kesilapan dan setiap pencerobohan berlaku dengan kuasa tanpa had, iaitu perkara yang sebenarnya ingin dielakkan oleh menjalankan proses sebagai pengguna tanpa keistimewaan.

Minit 4: Sediakan kunci SSH

Kata laluan mudah diteka; kunci tidak. Pada komputer riba anda, jika anda belum mempunyai kunci, cipta satu:

ssh-keygen -t ed25519

Kemudian salin bahagian awam (public key) ke pelayan:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id memerlukan log masuk kata laluan diaktifkan untuk pengguna baharu; jika ia sudah dimatikan, salin ~/.ssh/authorized_keys milik root ke dalam /home/matt/.ssh/authorized_keys (yang dimiliki oleh matt), atau tampal kunci awam anda ke dalam fail tersebut secara manual.

Model di sebalik langkah ini, iaitu satu kunci bagi setiap peranti, kebenaran (permissions) yang menyebabkan log masuk kunci gagal, dan cara membatalkan kunci yang hilang, dihuraikan dalam asas pengurusan kunci SSH.

Log keluar dan log masuk semula sebagai matt menggunakan kunci tersebut, dan pastikan ia berfungsi sebelum anda menyentuh langkah seterusnya. Mengunci SSH sebelum anda boleh masuk menggunakan kunci adalah punca pengguna terkunci daripada pelayan sendiri. Jika log masuk tersebut memaparkan Permission denied (publickey), selesaikan masalah itu sekarang dan jangan kembali menggunakan kata laluan, kerana mesej tersebut merangkumi lima kerosakan berbeza dan output ssh -v akan memberitahu anda yang mana satu sebenarnya berlaku.

Minit 6: Matikan log masuk root dan kata laluan

Setelah kunci anda berfungsi, tutup dua pintu yang sering disasarkan oleh pengimbas. Gunakan fail drop-in supaya naik taraf pakej tidak menimpa konfigurasi anda. Namakannya 00- supaya ia disusun sebelum 50-cloud-init.conf, yang disertakan dalam imej awan Ubuntu dengan PasswordAuthentication yes; sshd mengekalkan nilai pertama yang dibacanya, jadi fail yang disusun kemudian akan diabaikan secara senyap:

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

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Kemudian muat semula SSH:

sudo systemctl restart ssh

Seterusnya, semak tetapan yang sebenarnya digunakan oleh sshd, supaya anda tidak terpedaya dengan fail drop-in yang tidak berkesan:

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

Dengan kata laluan dimatikan dan log masuk root dilumpuhkan, trafik brute-force yang berterusan terhadap pelayan anda tidak akan berjaya. Langkah lengkap, termasuk pilihan untuk menukar port, terdapat dalam pengukuhan SSH pada VPS.

Minit 8: Hidupkan firewall

Tetapkan dasar default-deny untuk semua trafik masuk, kemudian benarkan hanya apa yang diperlukan. Benarkan SSH sebelum anda mengaktifkannya, atau anda akan memutuskan sambungan anda sendiri:

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

Tambah peraturan allow untuk sebarang servis yang anda jalankan, seperti 80/tcp dan 443/tcp untuk laman web. Jika sesi SSH baharu gagal bersambung selepas ini, baca ralat tersebut sebelum mengubah apa-apa, kerana penolakan bermakna sshd menjawab dan timeout biasanya bermakna firewall telah menelan paket tersebut. Pastikan kedua-dua IPv4 dan IPv6 dilindungi, kerana firewall yang hanya menapis IPv4 akan membiarkan sisi IPv6 terdedah sepenuhnya. Panduan lengkap boleh didapati di Firewalls 101 pada VPS. Perintah ufw ini mengandaikan penggunaan Ubuntu atau Debian; pada pelayan Rocky atau AlmaLinux, matlamat default-deny adalah sama tetapi alat yang digunakan ialah firewalld, jadi ikuti versi firewalld untuk langkah ini sebagai gantinya.

Minit 10: Perlahankan pengimbas dengan Fail2ban

Akhir sekali, tambahkan Fail2ban untuk menyingkirkan alamat yang menyerang port anda secara berterusan:

sudo apt install -y fail2ban

Pada Ubuntu 24.04, pemasangan standard melindungi SSH sejak but pertama. Memandangkan kunci sudah diperlukan, ini merupakan langkah sokongan yang mengurangkan gangguan log dan menyekat pelaku berulang, bukannya pertahanan utama anda.

Senarai semak anda

Ini ialah runbook anda. Gunakan penjana di bawah untuk menandakan setiap kawalan dan hasilkan senarai semak peribadi yang boleh anda simpan bersama pelayan, termasuk arahan tepat bagi setiap langkah:

Lakukan langkah ini sekali bagi setiap pelayan baharu sehingga ia menjadi kebiasaan. Sepuluh minit masa anda sekarang akan menyelamatkan anda daripada situasi buruk yang berlaku apabila pelayan diceroboh.

Setelah perkara penting disediakan, kemas kini keselamatan automatik pada Ubuntu akan memastikan pelayan sentiasa terkini tanpa perlu anda log masuk semula. Setiap servis yang anda pasang selepas itu memerlukan pemeriksaan tersendiri, dan titik kelemahan akan berubah: dengan peti simpanan kata laluan yang dihoskan sendiri, pelayan tidak akan menyimpan teks biasa, jadi risiko sebenar Vaultwarden terletak pada token pentadbir dan fail sandaran.

FAQ

Apakah perkara pertama yang perlu saya lakukan pada VPS baharu?

Kemas kini sistem dengan apt update && apt upgrade -y, kemudian cipta pengguna biasa dengan sudo dan berhenti bekerja sebagai root. Seterusnya, sediakan kunci SSH, nyahdayakan log masuk root dan pengesahan kata laluan, aktifkan firewall default-deny, serta pasang Fail2ban. Melakukan langkah-langkah ini mengikut urutan tersebut memastikan setiap langkah selamat diambil tanpa risiko terkunci daripada pelayan.

Bagaimanakah cara untuk mengelakkan diri daripada terkunci semasa mengeraskan SSH?

Sediakan dan uji log masuk kunci SSH anda sebelum anda menyahdayakan kata laluan atau root. Log keluar dan log masuk semula menggunakan kunci tersebut untuk mengesahkan ia berfungsi, dan hanya selepas itu matikan PasswordAuthentication dan PermitRootLogin. Apabila anda mengaktifkan firewall, benarkan port 22 sebelum menjalankan ufw enable. Jika anda terkunci, konsol web pembekal anda membolehkan anda masuk semula tanpa SSH.

Adakah saya benar-benar memerlukan semua ini pada pelayan kecil?

Ya, kerana pengimbas tidak mempedulikan saiz pelayan anda. Mereka mencuba setiap IP awam dengan cara yang sama. Keseluruhan buku panduan ini mengambil masa kira-kira sepuluh minit dan menghapuskan laluan mudah: tiada log masuk root, tiada tekaan kata laluan, tiada pendedahan yang tidak disengajakan, dan pepijat yang diketahui ditampal secara automatik.

Apakah langkah tunggal yang paling penting?

SSH berasaskan kunci sahaja dengan log masuk root dinyahdayakan. Kebanyakan serangan ke atas VPS baharu adalah tekaan kata laluan automatik terhadap root, dan mematikan kedua-duanya menjadikan kategori serangan tersebut mustahil. Firewall dan Fail2ban kemudian mengehadkan apa yang terdedah dan melambatkan sebarang serangan yang masih ada.

Bagaimanakah cara untuk mengesahkan pelayan benar-benar telah dikunci dengan selamat?

Periksa tiga perkara secara manual sebelum anda mempercayainya. Jalankan sudo ss -tlnp dan sahkan hanya port yang anda ingin buka sedang mendengar pada alamat awam, tanpa sebarang servis 0.0.0.0 atau [::] yang anda terlupa. Jalankan sudo ufw status verbose dan sahkan polisi masuk lalai adalah deny serta kedua-dua peraturan biasa dan (v6) telah wujud. Sentiasa buka sesi SSH kedua sebelum anda menutup sesi pertama, supaya kesilapan dalam konfigurasi SSH tidak menyebabkan anda terkunci daripada pelayan. Jika ketiga-tiganya kelihatan betul, asas keselamatan telah tersedia.