Secure Ubuntu Không Downtime: Tự Động Vá Lỗ Hổng 24/7

Secure Ubuntu Server bằng cập nhật tự động và quản lý bản vá không downtime

Một Ubuntu server “chạy ổn” chưa chắc đã “an toàn”. Lỗ hổng kernel, OpenSSL, OpenSSH, glibc, sudo, nginx, container runtime… xuất hiện liên tục. Chậm vá vài ngày → đủ để bot quét Internet, khai thác CVE, cài miner, đánh cắp khóa, pivot nội bộ.

Vấn đề: cập nhật thủ công dễ quên. Cập nhật tự động sai cách → reboot bất ngờ, downtime, lỗi dependency. Giải pháp thực tế: tự động hóa bản vá bảo mật, kiểm soát reboot, triển khai rolling/blue-green, giám sát sau cập nhật.

Mục tiêu: server luôn được vá nhanh, nhưng dịch vụ vẫn online.

1. Tư duy đúng: patch nhanh, nhưng có kiểm soát

Không downtime không có nghĩa “không bao giờ restart”. Nghĩa đúng hơn:

– Không mất dịch vụ với người dùng – Restart theo thứ tự – Có health check – Có rollback – Có tối thiểu 2 instance nếu workload quan trọng

Một server đơn lẻ chạy app + DB → rất khó “zero downtime” thật. Có thể giảm downtime, nhưng không loại bỏ hoàn toàn. Muốn không downtime → cần kiến trúc:

– Load balancer trước app – Ít nhất 2 app nodes – DB HA hoặc maintenance window – Backup + snapshot – Giám sát + alert

Patch management không chỉ là apt upgrade. Nó là quy trình.

2. Bật cập nhật bảo mật tự động với unattended-upgrades

Ubuntu có sẵn công cụ tốt: unattended-upgrades.

Cài:

sudo apt update
sudo apt install unattended-upgrades apt-listchanges -y

Bật auto update:

sudo dpkg-reconfigure unattended-upgrades

File chính:

/etc/apt/apt.conf.d/50unattended-upgrades

Cấu hình nên có:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
};

Ý nghĩa: chỉ tự động cài security updates, không tự ý kéo mọi package mới từ updates.

Bật xóa package thừa:

Unattended-Upgrade::Remove-Unused-Dependencies "true";

Bật log rõ:

Unattended-Upgrade::SyslogEnable "true";

Không nên auto reboot tùy tiện trên production đơn lẻ:

Unattended-Upgrade::Automatic-Reboot "false";

Lý do: kernel/glibc/systemd update có thể yêu cầu reboot. Nếu reboot lúc peak traffic → downtime.

Kiểm tra timer:

systemctl status apt-daily.timer
systemctl status apt-daily-upgrade.timer

Log:

cat /var/log/unattended-upgrades/unattended-upgrades.log

3. Phân loại bản vá: cái nào tự động, cái nào cần lịch

Không phải patch nào cũng giống nhau.

Nên tự động

– Security fix mức thấp/trung bình – Package ít ảnh hưởng runtime – Dependency không chạm app critical – CVE có exploit public

Cần lịch/kiểm thử

– Kernel – libc/glibc – systemd – OpenSSL – Database engine: PostgreSQL/MySQL/Redis – Web server chính: nginx/apache – Container runtime: Docker/containerd – Kubernetes components – App runtime: Node.js, Python, Java

Rule thực tế:

– Security update thường → auto – Kernel/reboot-required → rolling schedule – DB patch → backup + replica/failover – Major version upgrade → staging trước

4. Phát hiện reboot required

Ubuntu tạo file:

/var/run/reboot-required
/var/run/reboot-required.pkgs

Check:

if [ -f /var/run/reboot-required ]; then
  cat /var/run/reboot-required.pkgs
fi

Cài helper:

sudo apt install needrestart -y

Chạy:

sudo needrestart

needrestart cho biết process nào đang dùng library cũ. Nhiều khi không cần reboot toàn máy; chỉ cần restart service.

Ví dụ:

sudo systemctl restart nginx
sudo systemctl restart php8.3-fpm

Nhưng với kernel update → phải reboot mới active kernel mới.

5. Không downtime với rolling update

Mô hình tối thiểu:

User → Load Balancer → app-1
                    → app-2

Quy trình patch từng node:

1. Đưa node khỏi LB. 2. Chờ request đang chạy xong. 3. Cập nhật package. 4. Reboot nếu cần. 5. Health check. 6. Đưa node vào LB. 7. Lặp lại node tiếp theo.

Ví dụ với nginx upstream hoặc HAProxy, thao tác “drain” tùy stack. Với cloud LB, dùng API/console deregister instance.

Trên node:

sudo apt update
sudo unattended-upgrade -d
sudo reboot

Sau reboot:

systemctl is-system-running
systemctl status your-app
curl -f http://127.0.0.1:8080/health

Chỉ add lại LB khi health OK.

Điểm mấu chốt: không patch toàn bộ node cùng lúc.

6. Livepatch kernel: giảm reboot, không thay thế patching

Ubuntu Pro có Canonical Livepatch. Nó vá một số lỗ hổng kernel mà không reboot.

Bật Ubuntu Pro:

sudo pro attach <TOKEN>
sudo pro enable livepatch

Check:

canonical-livepatch status

Lợi ích:

– Giảm số lần reboot – Vá nhanh kernel CVE nghiêm trọng – Hữu ích cho server cần uptime cao

Giới hạn:

– Không vá mọi kernel change – Không thay thế reboot định kỳ – Không xử lý user-space packages – Không thay thế HA architecture

Best practice: dùng livepatch + reboot theo lịch, ví dụ 1 lần/tháng hoặc sau kernel update quan trọng.

7. Quản lý bản vá cho database không downtime

DB khó hơn app. Restart DB sai thời điểm → outage hoặc data loss.

PostgreSQL

Mô hình tốt:

– Primary + replica – Backup WAL – Monitoring replication lag – Failover có kiểm soát

Quy trình:

1. Patch replica trước. 2. Restart replica. 3. Verify replication. 4. Switchover primary → replica. 5. Patch primary cũ. 6. Đưa lại cụm.

Với managed DB, dùng maintenance window + multi-AZ.

MySQL/MariaDB

Tương tự:

– Primary/replica – Semi-sync nếu cần – Kiểm tra replication delay – Backup trước patch

Không nên auto-restart DB production bằng unattended-upgrades nếu DB là thành phần critical. Dùng hold hoặc exclude.

8. Giữ gói nhạy cảm khỏi auto upgrade

Nếu cần chặn package tự cập nhật:

sudo apt-mark hold postgresql-16
sudo apt-mark hold mysql-server
sudo apt-mark hold docker-ce

Bỏ hold:

sudo apt-mark unhold postgresql-16

Kiểm tra:

apt-mark showhold

Có thể blacklist trong unattended-upgrades:

Unattended-Upgrade::Package-Blacklist {
    "postgresql-*";
    "mysql-*";
    "docker-ce";
};

Dùng cẩn thận. Hold quá lâu → tích tụ rủi ro bảo mật. Hold phải đi kèm lịch patch riêng.

9. Snapshot, backup, rollback

Trước patch lớn:

– Snapshot VM/disk – Backup DB – Export config – Ghi lại version hiện tại – Có plan rollback

Lệnh hữu ích:

apt list --upgradable
dpkg -l > /root/packages-before.txt
uname -a
systemctl list-units --failed

Sau patch:

dpkg -l > /root/packages-after.txt
journalctl -p err -b
systemctl list-units --failed

Rollback package bằng apt không phải lúc nào sạch. Snapshot cấp hạ tầng thường nhanh hơn. Với app, dùng artifact/version rollback. Với DB, rollback phức tạp hơn vì schema/data migration có thể irreversible.

10. Giám sát sau cập nhật

Patch xong chưa phải hết. Cần verify:

– CPU/RAM/disk/network – Error rate – Latency – HTTP 5xx – DB connection – Queue length – Log bất thường – Failed services

Lệnh nhanh:

uptime
free -h
df -h
systemctl --failed
journalctl -p warning -b --no-pager

Health endpoint nên kiểm tra thật:

– App process sống – DB connect OK – Cache connect OK – Migration status OK – Dependency critical OK

Không dùng health check kiểu “return 200” giả.

11. Lịch patch thực tế

Một lịch hợp lý cho production nhỏ/vừa:

– Hằng ngày: auto security updates – Hằng ngày: alert nếu reboot required – Hằng tuần: rolling restart service nếu cần – Hằng tháng: rolling reboot toàn bộ node – Khẩn cấp: patch CVE critical trong 24h – Hằng quý: kiểm tra package hold, version EOL – Trước major upgrade: staging + test

Với Ubuntu LTS:

– Theo dõi EOL – Bật Ubuntu Pro/ESM nếu cần kéo dài support – Không chạy release hết hạn support trên Internet

Check release:

lsb_release -a
ubuntu-security-status

12. Checklist cấu hình an toàn

– unattended-upgrades bật – Chỉ auto security repo – Auto reboot tắt hoặc được điều phối – Alert khi /var/run/reboot-required – Có needrestart – Có staging – Có snapshot/backup – Có HA cho dịch vụ quan trọng – Rolling update, không patch đồng loạt – Package critical có quy trình riêng – Monitoring + alert sau patch – Tài liệu runbook rõ

Kết luận thực tế

Secure Ubuntu server không phải một lệnh. Đó là hệ thống: tự động vá cái an toàn, lên lịch cái rủi ro, rolling update để giữ dịch vụ online, backup để có đường lui, monitoring để phát hiện lỗi sớm.

Nếu chỉ có một server: bật unattended-upgrades, tắt auto reboot, theo dõi reboot-required, đặt maintenance window. Nếu có production nghiêm túc: thêm load balancer, tối thiểu 2 app nodes, DB replica, livepatch, rolling reboot.

Nguyên tắc cuối: patch chậm → rủi ro bị khai thác. Patch ẩu → rủi ro downtime. Patch đúng quy trình → an toàn + ổn định.