Tất cả hệ thống hoạt động bình thường 21 tiền mã hóa được chấp nhận · Hoan nghênh Monero Chính sách không KYC
ChainVPS

Bảo mật

Cách Bảo Mật Một VPS Mới: Danh Sách Tăng Cường

Một danh sách kiểm tra có thứ tự, sẵn sàng sao chép cho giờ đầu tiên trên một máy chủ mới — từ khóa SSH đến tường lửa mặc định-từ-chối — bịt những lỗ hổng mà kẻ tấn công thực sự khai thác.

Bảo mật8 phút đọc readĐội ngũ ChainVPS

Cách Bảo Mật Một VPS Mới: Danh Sách Tăng Cường

Một VPS mới hoàn toàn sẽ bị các cuộc tấn công tự động dò quét chỉ vài phút sau khi lên mạng — checklist này sẽ hướng dẫn bạn qua giờ đầu tiên gia cố bảo mật để giữ server thực sự là của bạn.

Mọi server mới đều khởi đầu với cùng những điểm yếu: đăng nhập root mặc định, cửa SSH chỉ dùng mật khẩu, firewall mở toang, và không có vá lỗi tự động. Các bot quét liên tục toàn bộ không gian địa chỉ IPv4, nên suy nghĩ "chưa ai biết IP của tôi" chưa bao giờ đúng.

Hướng dẫn này là một checklist gia cố bảo mật theo thứ tự, có thể copy dùng ngay. Thực hiện lần lượt từ trên xuống dưới trên một server Debian hoặc Ubuntu mới cài, bạn sẽ bịt kín những lỗ hổng mà kẻ tấn công thực sự khai thác, chứ không phải những thứ chỉ mang tính hình thức bảo mật.

Trước khi động vào server

Hai quyết định được đưa ra trước lần đăng nhập đầu tiên sẽ giúp bạn tiết kiệm hàng giờ về sau. Chuẩn bị sẵn SSH key và chọn tên cho tài khoản người dùng không phải root.

  1. 1

    Tạo một SSH key hiện đại

    Trên máy của bạn, chạy lệnh ssh-keygen -t ed25519 -C "you@device". Key Ed25519 ngắn gọn, nhanh, và mạnh hơn chuẩn RSA-2048 cũ.

  2. 2

    Không đưa private key lên server

    Nửa private không bao giờ được rời khỏi laptop của bạn. Bạn chỉ copy file .pub lên các host. Vi phạm quy tắc này chính là cách người dùng tự khóa mình, buộc phải khởi tạo lại server từ đầu.

  3. 3

    Ghi lại thông tin đăng nhập khởi tạo

    Hầu hết nhà cung cấp sẽ gửi email mật khẩu root tạm thời hoặc tự động chèn key của bạn ngay khi khởi tạo. Nếu key đã được chèn sẵn, bạn có thể bỏ qua và chuyển thẳng sang bước tạo user.

Nếu nhà cung cấp chèn sẵn SSH key của bạn ngay khi triển khai, bạn sẽ không bao giờ có một khoảng thời gian đăng nhập bằng mật khẩu — bề mặt tấn công lớn nhất đã biến mất ngay cả trước khi server khởi động.

Bước 1 — Vá toàn bộ hệ thống, rồi duy trì việc vá lỗi

Một kernel hoặc OpenSSL chưa được vá là lỗ hổng duy nhất mà không luật firewall nào có thể khắc phục. Hãy cập nhật trước khi cấu hình bất cứ thứ gì khác.

  • Debian/Ubuntu: apt update && apt full-upgrade -y, sau đó reboot nếu kernel đã thay đổi.
  • Bật unattended-upgrades để các bản vá bảo mật được cài tự động: apt install unattended-upgrades && dpkg-reconfigure unattended-upgrades.
  • Reboot theo lịch bạn tự kiểm soát — đặt Unattended-Upgrade::Automatic-Reboot vào một khung giờ ít hoạt động thay vì để kernel bị áp dụng nửa vời.

Bước 2 — Tạo một user thực sự và ngừng dùng root

Đăng nhập bằng root có nghĩa là chỉ cần một phiên bị xâm nhập cũng đủ để chiếm toàn bộ máy chủ, mà lại không để lại dấu vết kiểm tra nào. Hãy tự tạo cho mình một tài khoản sudo có tên riêng thay vì dùng root.

  1. 1

    Thêm user

    adduser deploy, sau đó usermod -aG sudo deploy (dùng nhóm wheel trên các hệ thống họ RHEL).

  2. 2

    Cài key cho user đó

    Từ laptop của bạn: ssh-copy-id deploy@your-server-ip. Lệnh này ghi public key của bạn vào ~/.ssh/authorized_keys với đúng quyền truy cập cần thiết.

  3. 3

    Kiểm tra trước khi khóa cửa

    Mở một terminal thứ hai và xác nhận bạn có thể ssh deploy@server rồi chạy sudo -v. Đừng bao giờ vô hiệu hóa root hay mật khẩu cho tới khi một phiên đăng nhập mới hoạt động ổn.

Nguyên tắc vàng của việc gia cố SSH: giữ phiên hiện tại đang mở và chứng minh đăng nhập mới hoạt động trong một cửa sổ thứ hai trước khi thay đổi bất kỳ thiết lập xác thực nào. Chỉ một thói quen này thôi cũng ngăn được gần như mọi trường hợp bị khóa ngoài.

Bước 3 — Gia cố SSH, phần quan trọng nhất

SSH là cửa chính của mọi VPS, và đây cũng là nơi phần lớn các lượt đăng nhập tự động liên tục dội vào. Hãy chỉnh sửa /etc/ssh/sshd_config (hoặc một file drop-in trong /etc/ssh/sshd_config.d/) và thiết lập các key sau.

PermitRootLoginno — root không bao giờ được đăng nhập qua mạng
PasswordAuthenticationno — chỉ dùng key, triệt tiêu hoàn toàn tấn công brute-force
KbdInteractiveAuthenticationno — đóng phương án dự phòng mật khẩu qua PAM
PubkeyAuthenticationyes — phương thức bạn thực sự sử dụng
AllowUsersdeploy — chỉ cho phép các tài khoản thực sự cần quyền truy cập shell
X11Forwardingno — tắt trừ khi bạn thực sự cần tunnel ứng dụng GUI

Áp dụng bằng sshd -t để kiểm tra cú pháp, sau đó systemctl restart ssh. Nếu sshd -t báo lỗi, hãy sửa trước khi restart, nếu không bạn có thể làm daemon ngừng hoạt động.

Đổi cổng SSH khỏi 22 là tùy chọn và chỉ giúp giảm nhiễu log — đó là làm khó nhìn thấy, không phải bảo mật thực sự. Một khi PasswordAuthentication đã tắt, các bot quét cổng không còn gì để đoán, vì vậy hãy dồn công sức vào key thay vì trò chơi đổi cổng.

Bước 4 — Bật firewall mặc định từ chối tất cả (default-deny)

Một daemon SSH đã được gia cố vẫn phải chia sẻ máy chủ với mọi dịch vụ khác đang lắng nghe. Firewall biến nguyên tắc "đóng trừ khi tôi tự mở" thành mặc định.

  1. 1

    Thiết lập baseline

    Với ufw: ufw default deny incoming và ufw default allow outgoing.

  2. 2

    Chỉ cho phép những gì bạn thực sự phục vụ

    ufw allow OpenSSH, cộng thêm ufw allow 80,443/tcp chỉ khi server này thực sự phục vụ lưu lượng web.

  3. 3

    Kích hoạt và kiểm tra

    ufw enable rồi ufw status verbose. Bất cứ thứ gì không có trong danh sách giờ đây đều không thể truy cập được từ internet.

Thêm luật cho phép SSH vào firewall trước khi bật ufw. Bật một firewall default-deny mà không có luật cho phép cổng của chính bạn sẽ cắt đứt phiên làm việc của bạn.

Bước 5 — Làm chậm tấn công brute force bằng Fail2ban

Ngay cả khi đã tắt mật khẩu, các bot vẫn tiếp tục gõ cửa và làm phình to log của bạn. Fail2ban sẽ chặn những kẻ tái phạm ngay ở tầng firewall.

  • apt install fail2ban — jail sshd có sẵn hoạt động ngay mà không cần cấu hình thêm.
  • Copy jail.conf thành jail.local rồi tăng bantime (ví dụ 1h) và giảm maxretry (ví dụ 3) theo ý bạn.
  • Kiểm tra xem nó có hoạt động không bằng fail2ban-client status sshd để xem số lượng IP đã bị chặn.

Bước 6 — Thu hẹp bề mặt tấn công

Dịch vụ an toàn nhất là dịch vụ không chạy. Hãy kiểm tra những gì đang lắng nghe và loại bỏ những gì bạn không cần.

Kiểm tra các cổng đang mở

ss -tulpn liệt kê mọi socket đang lắng nghe cùng tiến trình đứng sau nó. Hãy điều tra bất cứ thứ gì bạn không chủ động khởi chạy.

Gỡ bỏ các gói không dùng

Vô hiệu hóa hoặc gỡ cài đặt các dịch vụ bạn không dùng đến — một cơ sở dữ liệu hay mail agent bị bỏ chạy chỉ là gánh nặng rủi ro thuần túy.

Cô lập các dịch vụ

Ràng buộc các daemon nội bộ như cơ sở dữ liệu vào 127.0.0.1 để chúng không bao giờ bị lộ ra ngoài, kể cả khi firewall có sơ suất.

Siết chặt quyền truy cập

Đảm bảo ~/.ssh có quyền 700 và authorized_keys có quyền 600. Quyền sai sẽ khiến sshd âm thầm bỏ qua key của bạn.

Bước 7 — Ghi log, giám sát, và nắm rõ baseline của bạn

Gia cố bảo mật không phải là việc làm một lần. Bạn cần nhận ra ngay khi có điều gì đó thay đổi.

  • Xem lại hoạt động xác thực bằng journalctl -u ssh hoặc lastb để kiểm tra các lần đăng nhập thất bại.
  • Cân nhắc dùng auditd để có một bản ghi chống giả mạo cho các hành động có đặc quyền.
  • Giữ một bản sao lưu /etc và dữ liệu của bạn ở nơi khác ngoài server, để nếu máy chủ bị xâm nhập, bạn có thể dựng lại từ đầu một cách sạch sẽ thay vì tiếp tục tin tưởng nó sau sự cố.

Khi bản thân nhà cung cấp cũng quan trọng

Gia cố phần mềm bảo vệ hệ điều hành, nhưng chính nhà cung cấp mới quyết định những gì nằm bên dưới nó — việc lọc mạng, dấu vết thanh toán, và việc danh tính của bạn có bị gắn với server hay không. Trên ChainVPS, mọi gói đều đi kèm lọc DDoS và băng thông không giới hạn, và server được thanh toán từ số dư crypto nạp trước trên 21 loại coin bao gồm Monero, không cần KYC. Nếu mô hình rủi ro của bạn bao gồm việc không để lộ danh tính gắn với server, các gói VPS offshore của chúng tôi được xây dựng chính xác cho mục đích đó.

Vị trí đặt server cũng là một phần của việc gia cố bảo mật: sáu trong số mười lăm khu vực của chúng tôi là các khu vực pháp lý ưu tiên quyền riêng tư (NL, CH, RO, IS, MD, LU). Kết hợp một hệ điều hành đã được gia cố với một dedicated server offshore giúp siết chặt cả bề mặt phần mềm lẫn bề mặt pháp lý.

Checklist một giờ, rút gọn

  • Cập nhật toàn bộ hệ thống + đã bật vá bảo mật tự động
  • Đã tạo user sudo có tên riêng, đã cài key, đã kiểm tra đăng nhập
  • Đã vô hiệu hóa cả đăng nhập SSH bằng root lẫn xác thực bằng mật khẩu
  • Đã kiểm tra cấu hình SSH bằng sshd -t và reload
  • Firewall default-deny đang hoạt động, chỉ mở các cổng cần thiết
  • Fail2ban đang chạy trên jail sshd
  • Đã kiểm tra các cổng đang mở, đã gỡ bỏ các dịch vụ không dùng
  • Đã có sao lưu ngoài server và quy trình xem lại log
Tôi có nên đổi cổng SSH sang một cổng khác 22 không?

Đây là việc tùy chọn và chỉ giúp giảm nhiễu log, không giảm rủi ro thực sự. Một khi xác thực bằng mật khẩu đã tắt và bắt buộc dùng key, việc đổi cổng chỉ thêm tính che giấu chứ không phải bảo mật thực sự — hãy ưu tiên tắt mật khẩu trước.

Tắt xác thực bằng mật khẩu có an toàn không nếu tôi chỉ có một key?

Có, miễn là bạn đã kiểm tra đăng nhập bằng key trong một phiên riêng và giữ một bản sao lưu của private key. Nhiều nhà cung cấp cũng có console web hoặc chế độ recovery, nên bạn sẽ không bao giờ thực sự bị khóa hoàn toàn khỏi phần cứng.

Tôi có còn cần firewall không nếu SSH là dịch vụ duy nhất?

Có. Một firewall default-deny bảo vệ bạn khỏi những dịch vụ bạn quên mất là đã cài, và khỏi bất cứ gói phần mềm nào trong tương lai âm thầm bắt đầu lắng nghe. Nó không tốn gì cả và loại bỏ được những bất ngờ khó chịu.

Tôi nên xem lại việc gia cố bảo mật bao lâu một lần?

Cập nhật bảo mật tự động xử lý công việc hàng ngày, nhưng hãy xem lại các cổng đang lắng nghe và log xác thực sau bất kỳ lần cài đặt phần mềm lớn nào, và ít nhất mỗi tháng một lần. Hãy coi một baseline đã gia cố là thứ cần được xác minh liên tục, chứ không phải thứ thiết lập một lần rồi quên đi.

Áp dụng vào thực tế.

Triển khai máy chủ offshore từ $3.49/mo · 21 loại tiền điện tử · Không KYC.