Cách gia cố bảo mật VPS chạy Node.js mà không làm gián đoạn ứng dụng

Để bảo vệ VPS chạy Node.js, hãy ưu tiên bốn việc: kiểm soát SSH, chỉ mở cổng cần thiết, chạy ứng dụng bằng tài khoản không có quyền quản trị và giữ bí mật ngoài mã nguồn. Làm từng thay đổi rồi kiểm tra ngay sẽ giảm nguy cơ tự khóa SSH hoặc khiến website ngừng hoạt động.

Hướng dẫn dưới đây dùng ví dụ VPS Ubuntu có systemd, UFW và Nginx. Nếu dùng hệ điều hành khác, bạn cần điều chỉnh lệnh tương ứng. Các tên tài khoản, đường dẫn và tên dịch vụ đều là ví dụ, không phải cấu hình có thể áp dụng nguyên trạng cho mọi máy chủ.

Chuẩn bị đường khôi phục trước khi thay đổi cấu hình

Trước tiên, xác nhận bạn truy cập được console hoặc chế độ cứu hộ trong trang quản trị VPS. Giữ nguyên phiên SSH hiện tại và dùng một cửa sổ khác để thử đăng nhập sau mỗi thay đổi. Đừng đóng phiên đang hoạt động cho đến khi tài khoản mới kết nối thành công.

• Sao lưu cấu hình SSH, reverse proxy và dịch vụ Node.js trước khi sửa.
• Sao lưu cơ sở dữ liệu bằng công cụ phù hợp; snapshot máy chủ không mặc nhiên thay thế bản sao lưu dữ liệu nhất quán.
• Ghi lại cổng SSH thực tế, cổng ứng dụng và các tác vụ nền đang chạy.
• Chọn thời điểm ít truy cập nếu cần khởi động lại dịch vụ.

Kiểm tra phiên bản hệ điều hành và Node.js để lập kế hoạch cập nhật. Ưu tiên phiên bản còn được hỗ trợ; thử bản cập nhật trên môi trường thử nghiệm trước nếu ứng dụng có dependency cũ. Một bản vá tốt vẫn có thể gây lỗi tương thích cần xử lý.

Siết SSH nhưng vẫn giữ được quyền truy cập

Tạo tài khoản quản trị riêng thay vì dùng root cho công việc hằng ngày. Với Ubuntu, có thể thực hiện bằng:

sudo adduser deploy
sudo usermod -aG sudo deploy

Cài khóa SSH công khai của bạn vào tài khoản mới, đặt quyền phù hợp cho thư mục ~/.ssh và tệp authorized_keys. Khóa riêng phải ở thiết bị cá nhân, không tải lên VPS hoặc đưa vào kho mã.

Sau khi đăng nhập bằng khóa và chạy được sudo, cấu hình SSH để tắt đăng nhập root và các phương thức mật khẩu không cần thiết. Các chỉ thị thường dùng là:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Nếu hệ thống dùng xác thực nhiều yếu tố thông qua keyboard-interactive, không tắt phương thức đó một cách máy móc. Đồng thời kiểm tra các tệp cấu hình được include vì giá trị thực tế có thể khác tệp chính.

sudo sshd -t
sudo sshd -T
sudo systemctl reload ssh

Chỉ reload khi kiểm tra cú pháp thành công; tên dịch vụ có thể là sshd trên hệ thống khác. Kết quả cần đạt là tài khoản quản trị mới đăng nhập được bằng khóa, còn root và phương thức mật khẩu đã tắt không đăng nhập được.

Chỉ công khai SSH và reverse proxy

Mô hình đơn giản cho một website là Nginx nhận kết nối HTTPS rồi chuyển tiếp đến Node.js trên loopback. Cơ sở dữ liệu và cổng ứng dụng không cần xuất hiện trực tiếp trên Internet.

Với Express, ví dụ minh họa cách giới hạn địa chỉ lắng nghe:

app.listen(3000, '127.0.0.1');

Không áp dụng nguyên mẫu này cho ứng dụng cần truy cập qua mạng nội bộ hoặc container. Khi đó, phải thiết kế quy tắc mạng phù hợp thay vì chỉ đổi địa chỉ bind.

Nếu SSH thực sự dùng cổng 22 và VPS phục vụ web trên 80, 443, cấu hình UFW cơ bản có thể là:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Phải cho phép đúng cổng SSH trước khi bật firewall. Nếu có firewall tại nhà cung cấp, kiểm tra cả hai lớp. Với Docker, không mặc định UFW đã chặn mọi cổng publish; cần kiểm tra riêng quy tắc mạng và khả năng truy cập từ bên ngoài.

Dùng sudo ss -lntup để xem cổng đang lắng nghe. Trong ví dụ này, cổng 3000 chỉ nên gắn với 127.0.0.1; từ máy khác, website vẫn hoạt động nhưng không truy cập trực tiếp được cổng ứng dụng.

Chạy Node.js bằng tài khoản dịch vụ riêng

Tài khoản chạy ứng dụng không nên có quyền sudo. Tách nó khỏi tài khoản triển khai giúp hạn chế phạm vi thiệt hại nếu ứng dụng bị khai thác. Mã nguồn nên chỉ đọc đối với tiến trình; chỉ thư mục upload, cache hoặc dữ liệu thực sự cần thiết mới được ghi.

Ví dụ unit systemd dưới đây giả định đã có tài khoản nodeapp, mã nguồn tại /srv/nodeapp và Node.js tại /usr/bin/node:

[Unit]
Description=Node.js application
After=network.target

[Service]
User=nodeapp
Group=nodeapp
WorkingDirectory=/srv/nodeapp
Environment=NODE_ENV=production
EnvironmentFile=/etc/nodeapp/app.env
ExecStart=/usr/bin/node /srv/nodeapp/server.js
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

Kiểm tra đường dẫn Node.js thực tế trước khi dùng. Các tùy chọn cô lập có thể ảnh hưởng ứng dụng đang đọc dữ liệu trong thư mục home hoặc dùng chung thư mục tạm. Đây là cấu hình khởi đầu, không phải sandbox hoàn chỉnh.

Sau khi lưu unit với tên phù hợp, chạy systemctl daemon-reload, khởi động dịch vụ rồi xem systemctl status và journalctl -u nodeapp. Kiểm tra cả upload, kết nối dữ liệu và tác vụ nền, không chỉ trang chủ.

Bảo vệ secret, dependency và lớp HTTP

Không commit tệp chứa mật khẩu, token hoặc khóa phiên vào Git. Với ví dụ systemd trên, tệp /etc/nodeapp/app.env có thể thuộc root và đặt quyền 600 để systemd cấp hệ thống đọc khi khởi chạy. Biến môi trường không phải kho bí mật tuyệt đối; vẫn cần hạn chế quyền truy cập máy chủ và tránh ghi chúng vào log.

• Dùng lockfile và npm ci trong quy trình triển khai để cài dependency nhất quán.
• Chạy npm audit để nhận thông tin lỗ hổng đã biết, rồi đánh giá phạm vi ảnh hưởng; không tự động dùng npm audit fix --force trên máy production.
• Giới hạn kích thước request tại reverse proxy và ứng dụng, đặc biệt với upload.
• Bật HTTPS, theo dõi gia hạn chứng chỉ và cấu hình cookie phiên phù hợp với HTTPS.
• Giới hạn tốc độ cho đăng nhập hoặc endpoint tốn tài nguyên theo hành vi sử dụng thực tế.

Nếu Express nằm sau proxy, chỉ cấu hình trust proxy theo đúng số lớp hoặc địa chỉ proxy tin cậy. Tin mọi header chuyển tiếp có thể làm sai IP khách hoặc cách ứng dụng nhận biết HTTPS.

Kiểm tra kết quả và xử lý lỗi thường gặp

Ví dụ giả định một website bán hàng có Node.js, PostgreSQL và Nginx cùng VPS. Sau gia cố, khách vẫn đặt hàng được qua HTTPS; Node.js và PostgreSQL không truy cập trực tiếp từ Internet; tài khoản dịch vụ không sửa được mã nguồn.

• SSH mới không vào được: kiểm tra cổng, firewall hai lớp, quyền tệp khóa và cấu hình SSH hiệu lực từ phiên còn mở hoặc console.
• Nginx báo 502: kiểm tra tiến trình Node.js, địa chỉ bind và cổng upstream trước khi mở thêm cổng công khai.
• Ứng dụng không ghi được upload: cấp quyền đúng thư mục dữ liệu, không dùng chmod -R 777.
• Đĩa đầy vì log: thiết lập xoay vòng, giới hạn lưu trữ và cảnh báo dung lượng.

Cuối cùng, thử phục hồi bản sao lưu trong môi trường tách biệt. Chỉ nhìn thấy tệp backup chưa chứng minh có thể khôi phục dịch vụ.

Giải đáp những băn khoăn thường gặp

Đổi cổng SSH có đủ để bảo vệ VPS không?

Không. Việc này có thể giảm nhiễu quét tự động nhưng không thay thế khóa SSH, cập nhật bảo mật và giới hạn nguồn truy cập khi khả thi.

Có cần cài thêm công cụ chặn đăng nhập sai không?

Có thể cân nhắc khi log ghi nhận nhiều lần thử đăng nhập. Tuy nhiên, cần cấu hình và thử để tránh chặn nhầm; đây chỉ là lớp bổ sung.

Nên chọn VPS thế nào để vận hành Node.js ổn định?

Dựa vào RAM thực dùng, CPU lúc cao điểm, dung lượng dữ liệu và số tác vụ nền. Thử tải đại diện, theo dõi độ trễ, lỗi và tài nguyên trước khi chọn gói. Xác nhận thêm console cứu hộ, sao lưu, phạm vi hỗ trợ và giấy phép phần mềm thương mại nếu có.

Bắt đầu bằng một lần kiểm tra SSH và cổng mạng

Hãy ghi lại các cổng hiện tại, xác nhận console cứu hộ rồi kiểm tra đăng nhập bằng khóa trong phiên mới. Khi bước này ổn định, mới tiếp tục giới hạn mạng và tách quyền ứng dụng. Nếu đang chọn hạ tầng, bạn có thể tham khảo danh mục VPS liên quan tại sieuthicode.com và xác nhận cấu hình, tính năng quản trị cùng điều kiện hỗ trợ trước khi mua.