Bật Firewall UFW Mà Không Tự Nhốt Mình Ngoài VPS: Mở SSH, HTTP Và HTTPS Chuẩn Chỉnh

Trong giới quản trị server có một nghi thức trưởng thành khá đau thương: gõ lệnh bật UFW Firewall đầy khí thế, rồi nhận ra mình vừa khóa trái cửa phòng máy trong khi chìa khóa SSH vẫn nằm bên ngoài. Để không gia nhập hội “tự hủy” này, nguyên tắc bất di bất dịch là phải xác định chính xác cổng SSH đang lắng nghe, thêm rule cho phép cổng đó trước khi kích hoạt tường lửa. Sau khi bật UFW, bạn bắt buộc phải mở một cửa sổ Terminal thứ hai để đăng nhập thử nghiệm thành công rồi mới được phép đóng phiên làm việc cũ. Việc cửa sổ SSH cũ vẫn gõ được lệnh hoàn toàn không chứng minh rằng tường lửa đang cho phép các kết nối mới đi vào.

Quy trình kích hoạt tường lửa từ đầu dưới đây được thiết kế cho máy chủ thử nghiệm Ubuntu 24.04 độc lập, tách biệt hoàn toàn với hệ thống production đang chạy khách thật. Trên máy LAB-CF-01 vào ngày 30/09/2026, kịch bản thực nghiệm đã mở trước cổng 22/tcp, kích hoạt UFW và mở kết nối đăng nhập mới trơn tru. Riêng máy LAB-CF-02 đã dựng sẵn web stack, nên các đợt rà soát ngày 01/10 chỉ đọc trạng thái hiện hành, đối chiếu các cổng lắng nghe (listener) và thử tạo kết nối SSH/web mới từ máy Mac mà không chạy lại lệnh kích hoạt tường lửa trên máy đang vận hành.

Điều kiện cần có trước khi đụng vào Firewall

Trước khi gõ bất kỳ lệnh thay đổi tường lửa nào, hành trang của bạn phải có đủ ba món: một tài khoản user có quyền sudo đã được xác nhận hoạt động ở cửa sổ SSH thứ hai, đường vào VNC Console hoặc chế độ cứu hộ (rescue mode) của đúng máy VPS đó trên bảng điều khiển, và danh sách rõ ràng các dịch vụ mạng cần mở cổng. Hãy đối chiếu kỹ tên máy, mã định danh và địa chỉ IP trên Cloud Panel. Đặc biệt, đừng chỉ nhìn thấy nút “Console” sáng đèn trên web mà yên tâm — hãy bấm vào và đăng nhập thử xem bàn phím ảo cùng tài khoản cứu hộ có thực sự hoạt động hay không.

Tuyệt đối giữ nguyên cửa sổ SSH hiện tại đang mở trên màn hình. Hãy làm từng bước một cách tuần tự; đừng bao giờ nổi hứng gom cả combo “đổi Port SSH, cấm root login, tắt mật khẩu và bật Firewall” vào chung một lần nhấn Enter. Nếu lỡ đứt kết nối, bạn sẽ không biết thủ phạm thực sự là bước nào. Bài thực hành này áp dụng trên môi trường Ubuntu tiêu chuẩn, chưa cài đặt Docker hay các phần mềm quản lý mạng phức tạp. Nếu VPS của bạn đang chạy Docker, hãy cẩn thận vì Docker có thói quen tự viết thẳng vào iptables và đi đường vòng qua mặt UFW đấy.

Sơ đồ quy trình chuẩn bị trước khi bật UFW do localhost.vn biên soạn nhằm tóm tắt các chốt an toàn cần rà soát.

Bước 1: Kiểm tra cổng SSH thực tế và trạng thái tường lửa hiện tại

Trên phiên làm việc của VPS, bạn hãy chạy cụm lệnh chỉ đọc (read-only) dưới đây để khám sức khỏe hệ thống mạng:

sudo ss -lntp
sudo sshd -T
sudo ufw status verbose

Hãy nhìn vào danh sách socket đang lắng nghe để tìm tiến trình sshd và đối chiếu với số cổng bạn vừa dùng để nối vào máy. Trên các bản Ubuntu Server đời mới như 24.04, dịch vụ SSH thường chạy theo cơ chế socket activation của systemd, nên đôi khi bạn cần xem thêm cả systemctl status ssh.socket ssh.service để thấy bức tranh toàn cảnh. Đừng bao giờ chỉ đọc mỗi dòng Port trong file cấu hình bằng mắt thường rồi đinh ninh dịch vụ đang chạy ở cổng đó — cấu hình trên đĩa và tiến trình đang chạy trong RAM đôi khi là hai câu chuyện hoàn toàn khác nhau.

Nếu kết quả trả về cho thấy UFW vốn đã ở trạng thái active và đang chứa hàng loạt quy tắc mạng, bạn hãy dừng tay ngay lập tức. Hãy xuất toàn bộ danh sách rule hiện có ra một bản ghi chú riêng, rà soát xem ứng dụng nào đang cần cổng nào và ai là người thiết lập trước đó. Tuyệt đối không ngứa tay gõ ufw reset để “xóa bàn làm lại từ đầu” trên một máy đang chạy dịch vụ, bởi hành động đó sẽ cuốn bay các quy tắc mạng sống còn của hệ thống.

Bước 2: Mở đường sống cho cổng SSH trước tiên

Kịch bản dưới đây áp dụng cho máy chủ đã xác nhận chắc chắn OpenSSH đang lắng nghe ở cổng mặc định TCP 22 (giống như máy LAB-CF-01). Nếu VPS của bạn đã được chuyển sang một cổng tùy chỉnh (ví dụ 2222), hãy thay con số 22 bằng đúng cổng thực tế vừa đọc được ở Bước 1. Xin nhắc nhẹ: việc bạn mở cổng 22 trên UFW sẽ chẳng giúp ích gì nếu Daemon SSH đang ngồi đợi khách ở một cổng khác.

sudo ufw allow 22/tcp &&
  sudo ufw show added

Nhờ toán tử nối lệnh &&, câu lệnh phía sau chỉ được thực thi khi câu lệnh phía trước hoàn tất suôn sẻ. Nguyên tắc vàng rất đơn giản: chưa nhìn thấy rule SSH nằm chễm chệ trong danh sách show added thì tuyệt đối không bật UFW. Bạn hãy đọc kỹ lại cả giao thức (tcp) lẫn số cổng vừa thêm. Tất nhiên, UFW cũng hỗ trợ dùng tên định danh ứng dụng như OpenSSH, nhưng profile dựng sẵn đó sẽ bó tay nếu bạn đã đổi cổng SSH sang số khác. Việc gõ thẳng con số 22/tcp giúp bạn nhìn thấy rõ ràng, minh bạch từng cổng đang được cấp phép.

Trong bài hướng dẫn này, quy tắc mở cổng cho phép kết nối SSH từ mọi địa chỉ IP nguồn (Anywhere) nhằm tránh tình trạng người mới tự khóa mình ngay khi cục modem cáp quang ở nhà khởi động lại và đổi IP WAN. Trong tương lai, nếu bạn muốn siết chặt chỉ cho phép truy cập từ một IP văn phòng cố định (Static IP), hãy chuẩn bị sẵn đường VPN hoặc VNC Console dự phòng, thêm rule mới và thử nghiệm kỹ trước khi xóa rule cũ. Và nhớ đừng lấy nhầm địa chỉ IP mạng LAN nội bộ kiểu 192.168.1.x trên laptop để đưa vào rule tường lửa VPS nhé — lỗi kinh điển đấy!

Bước 3: Thiết lập chính sách mặc định và kích hoạt UFW

Trên một máy VPS mới tinh chưa gánh các dịch vụ đặc thù, triết lý bảo mật chuẩn mực nhất là: cho phép máy chủ thoải mái gọi ra ngoài (allow outgoing) để tải gói cập nhật, nhưng chặn toàn bộ các kết nối lạ tự ý đi vào (deny incoming), ngoại trừ những cổng đã được bạn điểm danh cho phép rõ ràng:

sudo ufw default deny incoming &&
  sudo ufw default allow outgoing &&
  sudo ufw enable &&
  sudo ufw status verbose

Khi UFW hiện dòng cảnh báo hỏi xác nhận rằng việc bật tường lửa có thể làm gián đoạn kết nối SSH, bạn hãy tận dụng giây phút đó để liếc mắt rà soát lại dòng rule mở cổng SSH phía trên một lần nữa. Chúng ta cố tình chạy ở chế độ tương tác (interactive) thay vì nhét cờ --force chính là để giữ lại nhịp phanh an toàn này. Nếu máy chủ của bạn còn đang chạy thêm dịch vụ riêng nào khác, hãy bổ sung rule cho đúng cổng đó trước khi gõ y, và tuyệt đối tránh kiểu mở toang cả dải port rộng mênh mông cho tiện.

Ngay khi UFW báo đã kích hoạt thành công, hãy đọc kỹ bảng trạng thái verbose để xác nhận ba điểm: trạng thái là active, chính sách mặc định đúng như thiết kế, và cổng SSH có mặt đầy đủ trong danh sách cho phép. Nếu VPS của bạn có bật IPv6, hãy kiểm tra xem các dòng rule có xuất hiện cặp đôi cho cả IPv4 lẫn IPv6 (v6) hay không, đồng thời ngó qua cấu hình trong /etc/default/ufw. Ở chặng này chúng ta giữ nguyên cấu hình IPv6 mặc định của hệ điều hành để không tạo thêm biến số ngoài ý muốn khi đang nghiệm thu tường lửa.

Sơ đồ thứ tự thao tác giữ kết nối an toàn do localhost.vn biên soạn để minh họa luồng thực hành chuẩn.

Bước 4: Mở cửa sổ Terminal thứ hai trên laptop để nghiệm thu SSH

Bây giờ là khoảnh khắc quyết định: hãy để nguyên cửa sổ Terminal thứ nhất ở đó, đừng đóng nó! Mở một cửa sổ Terminal thứ hai hoàn toàn mới trên laptop của bạn, sử dụng cặp SSH Key và tài khoản quản trị đã thiết lập ở bài trước để tạo một phiên kết nối mới tinh vào VPS:

ssh -i ~/.ssh/localhost-lab -o IdentitiesOnly=yes tutorial@IP_LAB

Nhớ thay thế IP_LAB cùng đường dẫn file khóa mẫu bằng địa chỉ IP thực tế và đường dẫn Private Key trên máy của bạn. Khi đã vào được dấu nhắc lệnh ở cửa sổ thứ hai, hãy gõ nhanh whoami và sudo whoami để chắc chắn quyền quản trị viên vẫn nguyên vẹn. Và dù chỉ vừa chỉnh sửa tường lửa, thói quen đối chiếu dấu vân tay máy chủ (host fingerprint) vẫn luôn phải được duy trì nghiêm túc.

Tại sao phải mất công mở cửa sổ thứ hai như vậy? Bởi vì UFW (dựa trên netfilter/conntrack) thường giữ nguyên các luồng kết nối đã được thiết lập từ trước (ESTABLISHED). Nghĩa là kể cả khi bạn gõ nhầm rule chặn sạch cổng 22, cửa sổ SSH cũ vẫn gõ lệnh bình thường như chưa hề có cuộc chia ly — cho đến khi bạn tắt máy đi ngủ và sáng hôm sau không tài nào vào lại được nữa! Nếu cửa sổ thứ hai bị treo rồi báo Connection timed out, hãy thở phào vì bạn vẫn còn cửa sổ thứ nhất đang mở để sửa lại rule UFW, kiểm tra cổng lắng nghe thực tế hoặc ngó lên lớp Cloud Firewall trên bảng điều khiển của nhà cung cấp.

Bước 5: Mở cổng HTTP (80) và HTTPS (443) đón luồng truy cập Web

Sau khi đường quản trị SSH đã chắc cốp, chúng ta mới bắt đầu mở cửa đón khách cho dịch vụ web bằng cách cho phép cổng TCP 80 (HTTP) và TCP 443 (HTTPS):

sudo ufw allow 80/tcp &&
  sudo ufw allow 443/tcp &&
  sudo ufw status numbered

Một hiểu lầm khá phổ biến của các bạn mới làm quen VPS là cứ tưởng gõ lệnh mở port 80/443 xong thì gõ IP lên trình duyệt sẽ lập tức thấy trang web. Thực tế, UFW chỉ là bác bảo vệ gác cổng: bác ấy mở cổng rào cho khách đi qua, nhưng bên trong sân chưa xây nhà (chưa cài NGINX, chưa cấu hình virtual host hay chứng chỉ TLS/SSL) thì khách đi vào cũng chỉ gặp khoảng sân trống và nhận thông báo Connection refused mà thôi. Sau khi cài web server ở các bài tiếp theo, bạn mới kết hợp lệnh ss và curl từ bên ngoài để nghiệm thu trọn vẹn.

Ngoài ra, hãy luôn nhớ rằng nhiều nhà cung cấp hạ tầng đám mây có thêm một lớp Cloud Firewall (Security Group) nằm ở phía ngoài máy ảo. Lệnh ufw status bên trong Ubuntu hoàn toàn mù tịt về sự tồn tại của lớp tường lửa ngoài biên này. Và một quy tắc bảo mật cực kỳ quan trọng khác: khi cả PHP-FPM lẫn cơ sở dữ liệu MariaDB cùng chung sống trên một VPS, chúng giao tiếp với nhau qua localhost (127.0.0.1) hoặc Unix socket nội bộ, nên tuyệt đối không mở cổng 3306 ra ngoài Internet.

Hồ sơ thực nghiệm trên hệ thống Lab và phạm vi ghi nhận

Vào ngày 30/09/2026, máy chủ LAB-CF-01 đã được thực nghiệm trọn vẹn chu trình: từ trạng thái UFW inactive → thêm rule mở 22/tcp → kích hoạt sang active → mở phiên đăng nhập mới bằng tài khoản tutorial thành công. Máy LAB-CF-02 cũng đã được mở các cổng tương ứng trong đợt dựng môi trường cùng ngày. Đến 04:05:36 ngày 01/10/2026 (giờ Việt Nam), đợt rà soát chỉ đọc (read-only) trên LAB-CF-02 ghi nhận bức tranh cấu hình thực tế như bảng dưới đây mà không can thiệp sửa đổi bất kỳ rule nào:

Các lượt kiểm tra kết nối từ bên ngoài được thực hiện độc lập. Lúc 03:43 ngày 01/10, trình duyệt Chrome từ mạng ngoài VPS truy cập thành công vào trang chào mừng mặc định của NGINX qua giao thức HTTP và tải mượt mà biểu mẫu đăng nhập WordPress qua HTTPS. Đến 03:55, phiên kết nối SSH mới từ xa bằng tài khoản tutorial cũng thông suốt. Xin lưu ý đây là số liệu nghiệm thu trên hệ thống đã bật sẵn tường lửa từ trước, không phải nhật ký của một lần bấm nút kích hoạt UFW mới. Xuyên suốt đợt kiểm tra lúc 04:05, toàn bộ tệp quy tắc UFW, trạng thái các gói cài đặt và mã định danh phiên khởi động (boot ID) đều được bảo toàn nguyên trạng.

Bằng chứng trên màn hình Console và đợt nghiệm thu chiều 01/10

Vào lúc 08:17:04 ngày 01/10, chúng tôi thực hiện đăng nhập trực tiếp vào màn hình VNC Console của LAB-CF-02 bằng tài khoản root. Tên máy (hostname) cùng chuỗi vân tay khóa ED25519 trùng khớp hoàn toàn với bản ghi lưu trong tệp known_hosts trên máy Mac điều khiển. Bước này xác nhận đường vào Console hoạt động trơn tru trên thực tế, sẵn sàng đóng vai trò đường cứu hộ nếu chẳng may gặp sự cố mạng.

Tiếp đó, lúc 13:50:46 cùng ngày (UTC+7), một script đọc trạng thái được chạy trực tiếp ngay trên giao diện Console để lấy thông số UFW và danh sách các cổng đang mở. Kết quả hiển thị rõ nét: UFW 0.36.2 active, chính sách mặc định chặn chiều vào (deny incoming), mở chiều ra (allow outgoing) và tắt định tuyến chuyển tiếp (disabled (routed)). Ba cổng TCP 22, 80, 443 được cấp phép cho cả IPv4 lẫn IPv6. Về phía ứng dụng thực tế, socket IPv4 lắng nghe đủ ở 22/80/443, IPv6 lắng nghe ở 22/80 (chưa có listener IPv6 cho cổng 443), và MariaDB nằm gọn trong 127.0.0.1:3306.

Ảnh chụp trực tiếp màn hình Console lúc 13:54:16 ngày 01/10/2026 (UTC+7), hiển thị kết quả đọc trạng thái hệ thống lúc 13:50:46. Hình ảnh giữ nguyên độ phân giải gốc của vùng hiển thị và chỉ gắn thêm nhãn nhận diện ở chân ảnh. Bạn có thể bấm vào ảnh để phóng to từng dòng lệnh.

Toàn bộ đợt rà soát buổi chiều hoàn toàn không làm thay đổi quy tắc tường lửa, tệp cấu hình hay trạng thái dịch vụ của máy chủ. Lưu ý rằng việc truy cập web thành công chỉ chứng minh đường truyền thông suốt tại thời điểm đó, chứ lệnh trong OS không tự đọc được bảng cấu hình Cloud Firewall của nhà cung cấp. Khi tự tay thực hành trên máy của mình, bạn hãy tập thói quen lưu lại trạng thái trước khi sửa, danh sách rule trước khi bấm enable và kết quả đăng nhập ở cửa sổ thứ hai.

Sơ đồ phân tầng hai lớp tường lửa và tiến trình lắng nghe do localhost.vn biên soạn giúp bạn khoanh vùng lỗi nhanh chóng.

Cách xử lý khi lỡ tay tự chặn mình và quy trình hoàn tác

Nếu cửa sổ SSH mới không vào được nhưng cửa sổ SSH cũ vẫn đang sống khỏe, bạn vẫn đang nắm đằng chuôi! Hãy bình tĩnh dùng ngay cửa sổ cũ đó để đọc lại bảng ufw status, bổ sung đúng rule mở cổng SSH còn thiếu rồi thử kết nối lại. Trong trường hợp xấu nhất — cả cửa sổ cũ cũng đã đóng và bạn bị nhốt hoàn toàn ở ngoài — hãy bình tĩnh mở VNC Console trên trang quản trị VPS để đăng nhập trực tiếp vào máy. Tại đây, hãy ưu tiên sửa hoặc thêm đúng dòng rule đang thiếu thay vì tắt bừa toàn bộ tường lửa. Chỉ nên tạm thời gõ ufw disable như giải pháp tình thế cuối cùng khi cần khôi phục kết nối khẩn cấp, và nhớ phải tìm nguyên nhân rồi bật lại tường lửa ngay sau khi xử lý xong.

Khi muốn thu hồi hoặc xóa bớt một quy tắc mở cổng không còn sử dụng (chẳng hạn xóa rule mở cổng thử nghiệm), hãy dùng lệnh ufw status numbered để xem số thứ tự chính xác của từng dòng. Một mẹo nhỏ nhưng cực kỳ quan trọng: mỗi khi bạn xóa một dòng theo số thứ tự, danh sách phía dưới sẽ tự động đôn số lên! Vì vậy, hãy luôn in lại bảng danh sách mới sau mỗi lệnh xóa thay vì nhắm mắt xóa liên tiếp nhiều số một lúc, kẻo xóa nhầm luôn cả rule SSH đang giữ mạng sống cho server.

Câu hỏi thường gặp (FAQ)

Có cần mở luôn cổng UDP 443 ngay lúc này không?

Chưa cần thiết. Cấu hình HTTP và HTTPS tiêu chuẩn hiện tại hoạt động trên nền giao thức TCP (cổng 80 và 443). Giao thức UDP 443 chỉ phục vụ cho chuẩn HTTP/3 (QUIC) và đòi hỏi bạn phải cấu hình thêm khá nhiều ở phía Web Server cũng như chứng chỉ bảo mật. Nguyên tắc của người làm hệ thống thực chiến là: dịch vụ nào chưa chạy thì cổng đó chưa mở.

Thấy UFW báo active là yên tâm kê cao gối ngủ được chưa?

Chưa đâu nhé! Tường lửa UFW chỉ đóng vai trò người gác cổng giúp chặn bớt các kết nối quét cổng trái phép vào những dịch vụ nội bộ. Để VPS thực sự vững vàng, bạn vẫn phải kết hợp đồng bộ các lớp bảo vệ khác: dùng SSH Key thay cho mật khẩu, cập nhật bản vá bảo mật hệ điều hành định kỳ, phân quyền người dùng chặt chẽ và luôn có bản sao lưu (backup) dự phòng.

Tại sao tôi đã mở cổng 80/443 trên UFW mà vào web vẫn báo lỗi?

Mở cổng tường lửa mới chỉ là thông chốt kiểm soát đầu tiên. Nếu trình duyệt vẫn không tải được trang, bạn cần rà soát tiếp các mắt xích còn lại: dịch vụ NGINX đã cài và đang chạy (listen) ở cổng đó chưa, tên miền đã trỏ đúng IP chưa, cấu hình Virtual Host và chứng chỉ TLS có hợp lệ không, và lớp Cloud Firewall bên ngoài bảng điều khiển của nhà cung cấp có đang chặn cổng 80/443 hay không.

Tài liệu tham khảo và chặng tiếp theo

Hướng dẫn chính thức về Ubuntu Firewall (UFW) được chúng tôi rà soát và đối chiếu lại vào ngày 01/10/2026; tài liệu về Ubuntu OpenSSH Server giữ mốc tham chiếu ngày 30/09/2026. Sau khi bạn đã nghiệm thu phiên SSH mới ngon lành và mở sẵn cổng web theo đúng chuẩn, bước tiếp theo là thiết lập quy trình cập nhật gói phần mềm an toàn cho Ubuntu Server. Đừng quên lưu lại sơ đồ cổng mạng và phương án truy cập Console vào sổ tay vận hành chung với lộ trình cài đặt WordPress trên VPS từ A đến Z để bất kỳ ai tiếp quản máy chủ cũng nắm rõ đường đi nước bước.