Linux Patch Management cho Web Server an toàn

Linux Patch Management là quy trình xác định bản vá nào cần áp dụng, ưu tiên theo risk, triển khai có kiểm soát và xác minh hệ thống sau update. Với web server production, patching không chỉ là chạy apt upgrade hoặc dnf upgrade; đội vận hành còn phải biết package nào ảnh hưởng service, update nào cần restart/reboot, rollback nằm ở đâu và sau thay đổi website/API/database có còn hoạt động đúng không.

Ubuntu Security Notices công bố khi lỗ hổng được sửa trong package chính thức, còn Ubuntu Server hỗ trợ unattended-upgrades để tự động cài security update theo cấu hình. CISA duy trì Known Exploited Vulnerabilities Catalog như một đầu vào cho ưu tiên vulnerability management. Vì vậy patch management tốt cần kết hợp vendor advisory + exposure + exploit evidence + business criticality, không chỉ dựa vào một điểm CVSS. Nếu cần xác định exposure nào đang thực sự tồn tại trên host trước khi ưu tiên patch, dùng Attack Surface Web Server làm nguồn inventory thay vì suy đoán từ package list.

Patch Management khác “update server” thế nào?

Update là hành động kỹ thuật; patch management là operating process. Một server có thể “được update” hôm nay nhưng vẫn có risk nếu repository sai, package held back, kernel mới chưa reboot, service đang chạy binary cũ hoặc application không tương thích sau update.

Update đơn lẻ	Patch Management
Chạy package manager	Inventory → prioritize → test → deploy → verify
Không rõ impact	Biết package/service/dependency affected
Không rõ rollback	Có snapshot/backup/change plan
Kết thúc khi command success	Kết thúc khi runtime/service read-back PASS

Quy trình Linux Patch Management

Bước 1: Xác định OS và package source

Trước khi patch, cần biết distro, version, lifecycle và repository đang dùng. Server production không nên nhận package từ repository không rõ owner hoặc PPA/third-party repo không còn được duy trì.

cat /etc/os-release
apt-cache policy 2>/dev/null | head -n 30

Với RHEL-family dùng công cụ tương ứng như dnf repolist. Mục tiêu không phải học thuộc command mà là biết update đến từ nguồn nào và nguồn đó có nằm trong support model của server không.

Bước 2: Xem update đang chờ

Trên Ubuntu/Debian có thể dùng:

sudo apt update
apt list --upgradable 2>/dev/null

apt update chỉ refresh package metadata; nó chưa cài update. Khi review danh sách, cần phân biệt security update, bug fix và package có khả năng tác động tới kernel, OpenSSH, web server, PHP/runtime, database hoặc library critical.

Bước 3: Ưu tiên patch theo risk

Không phải mọi update đều có cùng urgency. Một framework thực dụng có thể xem:

Signal	Câu hỏi
Known exploitation	CVE có bằng chứng exploited in the wild hoặc nằm trong CISA KEV?
Exposure	Package/service có Internet-facing hoặc reachable từ untrusted network?
Privilege	Exploit có thể dẫn tới root/admin hoặc code execution?
Criticality	Service ảnh hưởng website, login, payment, email hay API critical?
Mitigation	Có thể tạm giảm exposure hoặc disable feature trước khi patch?
Operational risk	Patch có yêu cầu restart/reboot hoặc thay đổi behavior?

CISA khuyến nghị dùng KEV như input cho prioritization, không phải danh sách duy nhất. Lỗ hổng không nằm trong KEV vẫn có thể cần xử lý nhanh nếu server Internet-facing và impact cao.

Bước 4: Kiểm tra dependency trước update

Trước patch production, cần biết package nào cung cấp service và dependency nào có thể restart. Với web stack, chú ý Nginx/Apache, PHP-FPM, OpenSSL, OpenSSH, database client/server, systemd và kernel.

Nếu update có khả năng restart service, change plan cần biết health check nào sẽ dùng sau đó. Không nên patch rồi mới nghĩ “kiểm tra gì”. Với server chưa go-live, patch state này nên được đóng như một phần của Server Security Baseline trước Production, thay vì để risk chưa rõ đi vào release.

Bước 5: Snapshot và rollback

Rollback không nhất thiết là downgrade package. Tùy môi trường, rollback có thể là VM snapshot, image rollback, blue/green node, package cache, config backup hoặc restore instance. Snapshot cũng có rủi ro riêng nếu giữ quá lâu hoặc chứa secret; cần quản lý lifecycle của rollback asset.

Trước khi patch nên lưu gì?

OS/package state.
Service đang chạy.
Listening port.
Config quan trọng.
Application version/deploy state.
Backup/snapshot reference.
Health-check baseline.

Bước 6: Chọn chiến lược triển khai

Manual patch trong maintenance window

Phù hợp khi server đơn lẻ, dependency phức tạp hoặc update cần kiểm tra thủ công. Điểm yếu là phụ thuộc con người và dễ bị trì hoãn nếu không có SLA.

Automatic security updates

Ubuntu Server tài liệu hóa unattended-upgrades và cho biết security updates có thể được cài tự động. Tuy nhiên production cần review reboot policy, package blacklist/allow policy, repository source và log. Automation không loại bỏ nhu cầu monitoring.

Rolling/immutable deployment

Với nhiều node, có thể patch từng node hoặc rebuild image rồi thay dần. Cách này giảm blast radius nhưng cần load balancer/health check và image pipeline đáng tin cậy.

Cấu hình unattended-upgrades cần hiểu gì?

Trên Ubuntu, file quan trọng gồm /etc/apt/apt.conf.d/50unattended-upgrades và /etc/apt/apt.conf.d/20auto-upgrades. Ubuntu hiện tài liệu hóa rằng unattended-upgrades thường chạy theo systemd timer và log tại /var/log/unattended-upgrades.

systemctl status apt-daily-upgrade.timer --no-pager
cat /etc/apt/apt.conf.d/20auto-upgrades
ls -lah /var/log/unattended-upgrades/

Đừng bật auto-reboot trên production chỉ vì tính năng tồn tại. Quyết định reboot phải dựa trên service architecture, maintenance policy và khả năng failover/recovery.

Bước 7: Thực hiện patch theo change plan

Ví dụ trên Ubuntu/Debian:

sudo apt update
sudo apt upgrade

Trước khi xác nhận, review package sẽ được cài/remove và service có thể bị restart. Không nên dùng các tùy chọn “force” hoặc tự động đồng ý mọi thay đổi trên server critical nếu chưa hiểu outcome.

Bước 8: Kiểm tra server có cần reboot không?

Một số update kernel hoặc core library chỉ có hiệu lực đầy đủ sau reboot hoặc service restart. Trên Ubuntu có thể quan sát file:

test -f /var/run/reboot-required && cat /var/run/reboot-required

Không có file này không chứng minh mọi process đã dùng binary/library mới. Với service quan trọng, cần kiểm tra runtime state và restart guidance từ package/vendor.

Bước 9: Validation sau patch

Patch chỉ được xem là hoàn tất khi observed state và business function đều PASS.

Kiểm tra package version/state.
Kiểm tra service active và không restart loop.
Kiểm tra listening port intended.
Kiểm tra web/API health.
Kiểm tra PHP/runtime/database dependency.
Kiểm tra log cho error mới.
Kiểm tra monitoring/backup agent.
Nếu reboot, xác minh service tự khởi động đúng.

systemctl --failed
sudo ss -lntup
journalctl -p err --since '30 minutes ago' --no-pager

Các command trên là điểm bắt đầu, không phải bằng chứng duy nhất. Health check của application phải phản ánh chức năng thực tế. Sau go-live, patch gap và reboot/restart requirement nên được theo dõi định kỳ trong Server Security Maintenance để tránh baseline cũ dần trở thành configuration drift.

Patch failure xử lý thế nào?

Service không start

Không vội restore snapshot nếu chưa xác định nguyên nhân. Đọc unit status/log, kiểm tra config syntax và package migration note. Nếu rollback cần thiết, dùng rollback path đã chuẩn bị thay vì thao tác ngẫu nhiên.

Website 200 nhưng chức năng lỗi

HTTP 200 không đủ. Update PHP/library có thể làm login, upload, queue, cron hoặc API fail. Validation phải có functional path phù hợp.

Update bị held back

Package held/phased/dependency conflict cần được giải thích và theo dõi. Không coi “apt upgrade không báo lỗi” là mọi security patch đã áp dụng.

Patch SLA nên thiết kế thế nào?

Không có một SLA duy nhất phù hợp mọi tổ chức. Có thể phân tầng theo exploit evidence, exposure và criticality. Điều quan trọng là SLA có owner, exception process và measurement, thay vì một số ngày cố định nhưng không ai chịu trách nhiệm.

Risk class	Ví dụ trigger	Response direction
Emergency	Known exploitation + Internet-facing + high impact	Contain/patch nhanh theo incident/change process
High	Critical service, exploit plausible	Ưu tiên maintenance sớm
Routine	Không public, exploitability thấp hơn	Patch trong cycle định kỳ
Deferred	Compatibility issue có compensating control	Exception có owner và expiry

Patch Management Record mẫu

Đây là template evidence, không phải lịch sử patch thực tế của SecureWebOps.

Field	Giá trị cần ghi
Server/environment	Host và scope
Advisory/CVE/package	Issue được xử lý
Risk signals	Exposure, exploitation, criticality
Before-state	Version/service/health baseline
Rollback	Snapshot/image/config backup
Change action	Package/update command hoặc automation
Restart/reboot	Required/Not required/Unknown
Validation	Package + service + functional checks
Result	PASS / FAIL / ROLLBACK / FOLLOW-UP

Checklist Linux Patch Management cho Web Server

OS còn support.
Repository/package source có owner.
Pending security update được inventory.
Exploit evidence/exposure được xem xét.
Service criticality được gắn.
Dependency/restart impact được hiểu.
Snapshot/rollback sẵn sàng.
Patch theo change window phù hợp.
Review reboot requirement.
Read-back package state.
Kiểm tra service/process.
Kiểm tra website/API/database functional path.
Review log sau update.
Ghi evidence PASS/FAIL.
Exception có owner và expiry.

Nguồn kỹ thuật tham khảo

Kết luận

Linux Patch Management là một quy trình quản trị risk, không phải một command. Cần biết update nào quan trọng, server nào exposed, patch ảnh hưởng service nào và cách chứng minh runtime sau update đã đúng.

Workflow bền vững là inventory → prioritize → snapshot → patch → restart/reboot khi cần → read-back → functional test → record. Khi patching có owner, SLA và rollback rõ, đội vận hành có thể cập nhật nhanh mà không biến security update thành một nguồn outage mới.