Firewall và cập nhật tự động: UFW + unattended-upgrades 2026

Trong series VPS Ubuntu LTS, bài này là bài nối tiếp sau bài “Quản lý user, sudo, permission và SSH keys theo nhóm 2026“: khi user, sudo, permission và SSH keys đã được dọn sạch, tôi mới bắt đầu khóa lớp mạng bằng firewall host-based và chuẩn hóa cách nhận security updates tự động.

Với Ubuntu 24.04 LTS, đây là thời điểm phù hợp để làm theo hướng dẫn trong bài này vì 24.04 là nhánh LTS được Canonical khuyến nghị cho production và được standard security maintenance đến ngày 31/05/2029. Trong hệ sinh thái Ubuntu Server hiện tại, ufw vẫn là công cụ firewall mặc định, còn unattended-upgrades là cơ chế Ubuntu dùng để áp dụng security updates tự động.

Mục tiêu của bài này không phải là bật thật nhiều rule hoặc auto-update “cho có”, mà là dựng một baseline an toàn, dễ kiểm soát và ít gây tự khóa máy. Nếu làm đúng, bạn sẽ giảm được bề mặt tấn công ngay từ host, đồng thời vá các gói bảo mật quan trọng mà không phải nhớ đăng nhập vào server mỗi ngày.

1. Vì sao “Firewall và cập nhật tự động: UFW + unattended-upgrades” quan trọng trên VPS public

Khi một VPS đã public IP ra Internet, hai rủi ro xuất hiện gần như ngay lập tức. Một là cổng dịch vụ mở quá rộng và không được lọc ở tầng host. Hai là hệ điều hành bị chậm vá lỗi vì phụ thuộc hoàn toàn vào thao tác thủ công. Ubuntu Server docs xem firewall và secure remote access là các thực hành nền về network security, còn automatic security updates được Canonical bật mặc định sau cài đặt vì họ đánh giá rủi ro không vá thường lớn hơn rủi ro áp dụng security updates.

Điều tôi muốn nhấn mạnh là UFW và unattended-upgrades không thay thế cho nhau. UFW kiểm soát lưu lượng vào và ra ở tầng host. unattended-upgrades kiểm soát việc hệ điều hành có tự nhận và áp dụng cập nhật hay không. Một cái giảm bề mặt tấn công, một cái giảm thời gian phơi nhiễm trước lỗ hổng đã có bản vá.

2. UFW là gì và vì sao tôi vẫn ưu tiên nó cho VPS nhỏ và vừa

Ubuntu Server docs mô tả ufw là frontend mặc định của Ubuntu để quản lý firewall host-based, được tạo ra để đơn giản hóa việc cấu hình iptables, và nó hỗ trợ cả IPv4 lẫn IPv6. Một chi tiết rất quan trọng là UFW mặc định ban đầu bị tắt. Điều đó có nghĩa là trên VPS mới, bạn không nên giả định firewall host-based đã bảo vệ mình sẵn.

Trên server nhỏ và vừa, tôi thích UFW vì nó đủ đơn giản để audit bằng mắt. Một rule sai trong UFW thường dễ phát hiện hơn nhiều so với khi tự chồng một đống rule netfilter thủ công mà không có quy ước rõ ràng.

3. unattended-upgrades là gì và hiện Ubuntu xử lý nó ra sao

Theo tài liệu Ubuntu Server mới, Ubuntu sẽ áp dụng security updates tự động thông qua gói unattended-upgrades, và gói này được cài mặc định. Ngay sau cài đặt, automatic installation of security updates được bật, bao gồm cả ESM nếu hệ thống có quyền dùng, và mặc định unattended-upgrades chạy mỗi ngày một lần.

Điểm này rất dễ bị viết sai trong các bài cũ. Nhiều bài vẫn hướng dẫn như thể unattended-upgrades là thứ “chưa có gì, phải bật từ đầu”, trong khi tài liệu hiện tại của Ubuntu nói rõ automatic security updates đã được bật right after installation. Vì vậy, với Ubuntu 24.04 LTS, việc đúng hơn không phải là “bật bừa”, mà là kiểm tra lại trạng thái, phạm vi cập nhật, log và cách reboot sau update.

4. Tư duy đúng trước khi bắt đầu cấu hình “Firewall và cập nhật tự động: UFW + unattended-upgrades”

Tôi luôn giữ một nguyên tắc ở bài firewall: mở đúng cổng cần dùng, không mở vì “có thể sau này cần”. Với VPS mới, cổng gần như chắc chắn cần mở đầu tiên là SSH, và nếu bạn đã triển khai web server thì mới thêm HTTP hoặc HTTPS. Những cổng khác chỉ nên mở khi có dịch vụ thật sự đang lắng nghe và bạn biết rõ lý do. UFW application integration trong tài liệu Ubuntu cũng đi theo đúng hướng đó: dùng app profiles như OpenSSH hoặc Nginx Full khi phù hợp để tránh nhầm cổng.

Còn với automatic updates, tư duy đúng không phải là “bật hết cho tiện”, mà là để unattended-upgrades ở phạm vi bảo mật trước, rồi mới cân nhắc mở rộng sang -updates nếu bạn thật sự chấp nhận rủi ro thay đổi hành vi package giữa các lần chạy tự động. Ubuntu docs nói rõ mặc định là security-focused origins, và nếu muốn áp dụng non-security updates tự động thì phải chỉnh Allowed-Origins.

5. Quy trình cấu hình UFW an toàn trên VPS

Bước 1: Kiểm tra trạng thái hiện tại của firewall và dịch vụ đang lắng nghe

Trước khi thêm bất kỳ rule nào, tôi luôn chụp lại baseline.

sudo ufw status verbose
ss -tulpn

ufw status verbose cho biết firewall hiện bật hay tắt và policy mặc định đang là gì. ss -tulpn cho tôi thấy service nào thực sự đang mở cổng. Làm vậy giúp tránh kiểu mở cổng theo trí nhớ rồi cuối cùng server vừa dư rule vừa khó audit.

Bước 2: Mở SSH trước khi bật UFW

Đây là bước chống tự khóa máy quan trọng nhất của cả bài A7.

sudo ufw allow OpenSSH

Ubuntu docs dùng chính profile OpenSSH như ví dụ chuẩn. Vì UFW mặc định disabled, rất nhiều người có tâm lý “cứ enable rồi sửa tiếp”, nhưng nếu bạn bật UFW trước khi allow SSH, bạn có thể tự cắt đường vào server. Cách làm an toàn là allow SSH trước, rồi mới chuyển sang bước bật firewall.

Nếu bạn đã đổi SSH sang port khác ở bài trước, tôi không khuyên vẫn gọi mù profile OpenSSH. Khi đó nên kiểm tra service thực tế đang nghe cổng nào rồi mở đúng cổng đó, hoặc chỉnh app profile cho khớp.

Bước 3: Đặt default policy tối thiểu

Với VPS public chạy web hoặc API, baseline mà tôi thấy hợp lý nhất là từ chối incoming và cho phép outgoing.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Đây là hai lệnh kinh điển, nhưng điều làm chúng có giá trị không phải vì “tutorial nào cũng viết”, mà vì chúng tạo ra một chính sách dễ hiểu: mọi lưu lượng vào phải được khai báo rõ, còn lưu lượng đi ra được cho phép trừ khi bạn có nhu cầu siết chặt hơn.

Bước 4: Bật UFW và xác nhận lại ngay

sudo ufw enable
sudo ufw status verbose

Sau khi enable, tôi luôn kiểm tra lại trạng thái ngay và vẫn giữ phiên SSH cũ đang hoạt động cho đến khi đã thử mở một phiên mới thành công. Đây là một thói quen rất đáng giữ vì firewall là lớp có khả năng làm bạn mất quyền truy cập nhanh chẳng kém gì SSH config sai.

Bước 5: Mở đúng profile ứng dụng đang dùng

Nếu server chỉ chạy SSH, đến đây là đủ. Nếu đã có web server, bạn có thể liệt kê app profiles rồi mở đúng profile cần thiết.

sudo ufw app list
sudo ufw allow 'Nginx Full'

Ubuntu docs có phần riêng về application integration trong UFW. Điểm tôi thấy hữu ích nhất là profile giúp tránh nhầm lẫn cổng khi làm các dịch vụ phổ biến. Tuy nhiên, bạn vẫn phải hiểu mình đang mở cái gì. Ví dụ Nginx Full phù hợp khi bạn cần cả HTTP và HTTPS; nếu mới chỉ chạy HTTP, mở profile full ngay từ đầu có thể là quá rộng so với nhu cầu hiện tại.

Bước 6: Chỉ cho IP hoặc subnet cụ thể khi cần

Nếu có dịch vụ quản trị nội bộ, dashboard hoặc exporter không nên public, thay vì mở cho toàn Internet, tôi ưu tiên allow theo nguồn.

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow from 10.0.0.0/24 to any port 9100 proto tcp

Ubuntu docs có phần “Allow access from specific hosts”, và đây chính là kiểu rule tạo khác biệt lớn về bề mặt tấn công. Với các cổng như SSH, Node Exporter, database hoặc admin panel, allow theo IP/subnet gần như luôn tốt hơn mở cả thế giới.

Bước 7: Dùng --dry-run khi muốn kiểm tra trước

Một chi tiết hay nhưng thường bị bỏ qua là Ubuntu docs có nhắc riêng đến ufw --dry-run. Khi cần xem rule dự kiến mà chưa muốn commit ngay, đây là cách đáng dùng hơn là áp dụng xong rồi mới sửa.

Ví dụ:

sudo ufw --dry-run allow from 203.0.113.10 to any port 22 proto tcp

Trên production, những tính năng kiểu này rất đáng giá vì chúng cho bạn thêm một nhịp kiểm tra trước khi chạm vào lớp mạng.

6. Cách kiểm tra và duy trì UFW sau khi đã bật

Sau khi hoàn tất cấu hình ban đầu, tôi luôn chạy ba lệnh sau:

sudo ufw status verbose
sudo ufw status numbered
ss -tulpn

status verbose cho policy tổng quát. status numbered hữu ích khi cần xóa đúng rule theo số thứ tự. ss -tulpn giúp đối chiếu lại: service nào đang lắng nghe mà UFW chưa mở, hoặc ngược lại, cổng nào đã mở nhưng không còn service nào dùng.

Nếu cần xóa rule:

sudo ufw delete allow OpenSSH
sudo ufw delete 2

Cách numbered rất tiện khi bạn đang dọn rule trên máy đã được chỉnh nhiều lần.

7. Quy trình cấu hình unattended-upgrades theo hướng an toàn

Bước 1: Kiểm tra package và layout cấu hình

Ubuntu docs nêu rất rõ ba vị trí quan trọng của unattended-upgrades.

/etc/apt/apt.conf.d/50unattended-upgrades chứa hành vi của công cụ, như origins được phép, auto reboot hay blacklist.

/etc/apt/apt.conf.d/20auto-upgrades quyết định nó có bật hay không và chạy với tần suất nào.

/var/log/unattended-upgrades chứa log chi tiết của từng lần chạy.

Tôi thường kiểm tra như sau:

dpkg -l unattended-upgrades
sudo grep -R "Unattended-Upgrade\|Update-Package-Lists" /etc/apt/apt.conf.d/20auto-upgrades
sudo sed -n '1,220p' /etc/apt/apt.conf.d/50unattended-upgrades
sudo ls -la /var/log/unattended-upgrades/

Bước 2: Hiểu mặc định trước khi chỉnh

Theo Ubuntu docs, 20auto-upgrades mặc định dùng:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Giá trị 1 nghĩa là chạy hằng ngày; 0 là tắt. Đây là chi tiết đáng hiểu rõ vì rất nhiều người chỉnh file này theo thói quen mà không biết ý nghĩa số ngày.

Tôi thường giữ mặc định daily cho VPS công khai, trừ khi có lý do rất rõ để đưa nó về mô hình cập nhật thủ công hoàn toàn.

Bước 3: Giữ automatic updates ở phạm vi bảo mật trước

Ubuntu docs nói mặc định Allowed-Origins của unattended-upgrades tập trung vào official Ubuntu repositories và security-related origins. Nếu muốn mở rộng sang non-security updates từ -updates, bạn phải bỏ comment hoặc thêm origin tương ứng.

Đây là chỗ tôi khuyên giữ bình tĩnh. Với đa số VPS nhỏ và vừa, security updates tự động là baseline tốt. Còn non-security updates tự động nên là quyết định có chủ đích, vì chúng có thể làm thay đổi hành vi package thường xuyên hơn.

Nói ngắn gọn, baseline tôi tin dùng là:

• Giữ automatic security updates
• Chưa mở rộng sang tất cả non-security updates nếu không có lý do mạnh
• Review log định kỳ thay vì coi automatic updates là “đã xong”

Bước 4: Hiểu chuyện timer và startup behavior

Ubuntu docs có một chi tiết rất thực tế: nếu máy đang tắt vào thời điểm timer chạy, unattended-upgrades có thể được kích hoạt ngay khi máy khởi động lại, còn bị ảnh hưởng bởi RandomizedDelaySec. Điều này có thể làm bạn thấy server vừa boot lên đã chạy update ngay, khóa luôn các thao tác apt khác trong chốc lát. Ubuntu còn hướng dẫn rằng nếu muốn đổi hành vi này, có thể override apt-daily.timer và apt-daily-upgrade.timer bằng systemctl edit và chỉnh Persistent=false.

Điểm này cực kỳ hữu ích nếu bạn quản lý nhiều VM chỉ bật lên để làm việc ngắn rồi tắt, hoặc image lab/staging.

Bước 5: Quyết định có cho auto reboot hay không

Ubuntu docs nói rất rõ: unattended-upgrades có thể reboot hệ thống khi cần nếu bạn bật tùy chọn đó. Nhưng docs cũng nhấn mạnh reboots can be very disruptive, especially if the system fails to come back. Vì vậy, đây không phải là thứ tôi bật theo phản xạ trên mọi VPS.

Với VPS một máy, không có HA, không có monitoring ngoài băng và không có rescue flow bạn đã quen dùng, tôi thường không khuyên auto reboot ngay lập tức. Tôi thích để hệ thống tự cập nhật security packages, còn reboot thì làm trong khung chủ động sau khi đọc /var/run/reboot-required và log.

Nếu bạn thật sự muốn auto reboot, hãy chỉnh trong 50unattended-upgrades và phải chấp nhận rõ trade-off của nó.

Bước 6: Kiểm tra log thay vì đoán

Một trong những giá trị lớn nhất của Ubuntu docs mới là minh họa khá rõ log của unattended-upgrades, bao gồm cả trường hợp phát hiện /var/run/reboot-required và lên lịch reboot. Log mặc định nằm trong /var/log/unattended-upgrades.

Các lệnh tôi dùng thường xuyên là:

sudo ls -la /var/log/unattended-upgrades/
sudo tail -n 100 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 100 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
test -f /var/run/reboot-required && echo "Reboot required"
test -f /var/run/reboot-required.pkgs && cat /var/run/reboot-required.pkgs

Ngoài ra, Ubuntu pam_motd docs cho biết unattended-upgrades cũng có thể hiện thông tin liên quan trong motd, cụ thể qua script 92-unattended-upgrades, nên đôi khi chỉ cần đăng nhập SSH bạn đã thấy manh mối ban đầu nếu có vấn đề với automatic updates.

8. Khi nào tôi sẽ cân nhắc không dùng hoặc giới hạn unattended-upgrades

Ubuntu docs dành hẳn một mục “When to consider disabling automatic updates”, và tôi thấy phần này rất đáng đọc. Họ nêu một số trường hợp hợp lý như hệ thống được tái tạo thường xuyên từ image mới, hệ thống mà cập nhật cần thêm manual steps không thể tự động hóa an toàn, hoặc môi trường fleet lớn cần công cụ quản lý cập nhật chuyên nghiệp hơn.

Điều này có nghĩa là unattended-upgrades rất hợp cho VPS đơn lẻ hoặc số lượng nhỏ, nhưng nó không phải thuốc chữa bách bệnh. Nếu bạn đang vận hành nhiều node và cần kiểm soát đợt rollout, snapshot archive, hay homogeneity chặt chẽ, Ubuntu cũng đã có tài liệu về snapshot service để xây structured update workflow hơn là phó mặc toàn bộ cho auto-update.

9. Baseline mà tôi khuyên dùng cho phần lớn VPS Ubuntu 24.04 LTS

Nếu đang tự host website, API, blog hoặc staging trên một VPS public, baseline A7 mà tôi thấy cân bằng nhất là như sau.

UFW:

• Allow SSH trước
• Default deny incoming
• Default allow outgoing
• Mở thêm đúng cổng thật sự cần, ưu tiên app profiles chuẩn
• Với cổng quản trị, ưu tiên allow theo IP/subnet

Automatic updates:

• Giữ unattended-upgrades bật cho security updates hằng ngày
• Chưa mở rộng toàn bộ non-security updates nếu chưa cần
• Chưa bật auto reboot nếu bạn chưa có monitoring, rescue flow hoặc maintenance strategy đủ tốt
• Kiểm tra log và reboot-required định kỳ

Cách làm này không màu mè, nhưng nó đủ thực tế cho đa số VPS và rất dễ audit về sau.

10. Lỗi thường gặp và cách tránh

• Lỗi thứ nhất là bật UFW trước khi allow SSH. Đây là lỗi cũ nhưng vẫn luôn nguy hiểm.

• Lỗi thứ hai là mở quá nhiều cổng vì nghĩ “để đó sau này dùng”. Một cổng mở mà không cần thiết là một bề mặt tấn công dư thừa.

• Lỗi thứ ba là tin rằng unattended-upgrades chỉ cần bật là xong. Trên Ubuntu hiện nay, automatic security updates đã được bật ngay sau cài đặt, nên thứ bạn cần làm hơn là hiểu nó đang cập nhật gì, log ở đâu và chuyện reboot được xử lý thế nào.

• Lỗi thứ tư là bật auto reboot trên VPS không có phương án cứu hộ. Ubuntu docs đã cảnh báo rõ reboot có thể disruptive; trên một máy public đơn lẻ, điều đó càng đáng cân nhắc.

• Lỗi thứ năm là không biết vì sao apt bị khóa ngay sau boot. Trong nhiều trường hợp, nguyên nhân là apt-daily hoặc unattended-upgrades vừa được kích hoạt do timer. Ubuntu docs đã nói rất rõ điều này.

11. FAQ

11.1. Có cần cài UFW không nếu cloud provider đã có security group?

Có. Security group ở tầng provider rất hữu ích, nhưng UFW vẫn đáng dùng như lớp kiểm soát tại chính host. Ubuntu cũng coi ufw là công cụ firewall mặc định của server.

11.2. Ubuntu 24.04 LTS có cần tự bật unattended-upgrades nữa không?

Thông thường không. Ubuntu Server docs hiện nói automatic installation of security updates được bật right after installation, và unattended-upgrades chạy hằng ngày theo mặc định.

11.3. Có nên cho unattended-upgrades cài luôn non-security updates không?

Chỉ khi bạn chấp nhận trade-off của việc thay đổi package ngoài phạm vi security. Mặc định của Ubuntu hướng đến security-focused origins; mở rộng sang -updates là quyết định chủ động, không phải mặc định an toàn nhất cho mọi VPS.

11.4. Có nên bật auto reboot sau update không?

Không có một đáp án chung cho mọi server. Ubuntu docs xác nhận unattended-upgrades có thể reboot nếu cấu hình như vậy, nhưng cũng nhấn mạnh reboot có thể gây gián đoạn lớn. Với VPS đơn lẻ, tôi chỉ bật khi đã có đường cứu hộ và monitoring rõ ràng.

11.5. Kiểm tra nhanh unattended-upgrades lỗi hay không ở đâu?

Hãy xem /var/log/unattended-upgrades và kiểm tra motd khi SSH vào máy. Ubuntu docs nêu rõ thư mục log này, còn pam_motd docs cho biết script 92-unattended-upgrades có thể hiển thị thông tin liên quan khi đăng nhập.

Gợi ý

Cài Nginx trên Ubuntu và hiểu cấu trúc config đúng chuẩn 2026