Proxmox bị tấn công mã hoá dữ liệu 2026

Sáng thứ Hai, bạn mở dashboard Proxmox và thấy toàn bộ VM đã tắt. Trong thư mục storage xuất hiện một file lạ tên README_DESTROY.txt. Backup thì biến mất hoặc bị đổi đuôi .onyx. Log gần như trống rỗng. Đó không phải kịch bản dựng lên để hù bạn, mà là đúng những gì hàng loạt quản trị viên đã gặp trong tuần cuối tháng 8 và đầu tháng 9 năm 2026.

Làn sóng Proxmox bị tấn công lần này không nhắm vào lỗi cao siêu nào cả. Kẻ tấn công đi vào bằng cửa chính: cổng quản trị 8006 phơi thẳng ra Internet, cộng với một lỗ hổng đã âm thầm nằm đó hơn ba năm. Trong bài này tôi sẽ đi trọn một vòng: chuyện gì thực sự đang diễn ra, hacker vào bằng cách nào, bạn tự kiểm tra mức phơi nhiễm ra sao (cả từ bên ngoài lẫn trên host), và phải làm gì để xử lý cũng như phòng thủ. Không lý thuyết dài dòng, chỉ những thứ tôi sẽ tự làm nếu đó là server của tôi.

Chuyện gì đang thực sự xảy ra

Mọi thứ vỡ ra công khai vào ngày 31/08/2026, khi một chủ đề trên diễn đàn Proxmox có tiêu đề đại ý "PVE 7 đang dính một dạng 0day/RCE không cần xác thực" bắt đầu nóng lên. Trước đó vài ngày, từ khoảng 28/08, đã có nạn nhân đầu tiên báo bị chiếm quyền. Đến 01/09, Proxmox phát hành cảnh báo bảo mật chính thức mã PSA-2026-00043-1. Ngày 02 đến 03/09, báo chí an ninh mạng quốc tế đồng loạt đưa tin, và mã khai thác (PoC) đã được công bố rộng rãi.

Nạn nhân trải rộng và rất thật:

• Một kỹ thuật viên báo trên BleepingComputer rằng chỉ trong hai ngày, năm khách hàng của anh bị mã hoá, và điểm chung là tất cả đều chạy Proxmox.
• Nhiều nhà cung cấp máy chủ (kể cả server đặt tại OVH) báo các node Proxmox 7.2 phơi ra Internet bị đòi tiền chuộc gần như đồng loạt.
• Một quản trị viên trên diễn đàn Trung Quốc mô tả server PVE 8 của mình bị chiếm dù đã đặt mật khẩu rất phức tạp: hacker đổi luôn mật khẩu Proxmox rồi SSH vào bằng quyền root.

Điểm chung của mọi ca Proxmox bị tấn công đợt này: Web UI nghe ở cổng 8006 mở ra Internet. Đây là mẫu số chung, và cũng là điều tốt, vì nó có nghĩa là bạn hoàn toàn có thể phòng được.

Kẻ tấn công đi vào bằng cách nào

Đây là phần tôi thấy nhiều người hiểu sai nhất, nên xin nói thật kỹ.

Lỗ hổng chính: CVE-2023-54391

Thủ phạm của làn sóng mã hoá lần này là một lỗi authentication bypass (vượt qua xác thực) mang mã CVE-2023-54391, điểm nghiêm trọng CVSS 9.8. Nó nằm trong gói libpve-access-control, tức là phần xử lý đăng nhập của chính Proxmox.

Cơ chế của nó đơn giản đến mức đáng sợ. Khi bạn đăng nhập Proxmox, hệ thống gọi tới API POST /api2/json/access/ticket. Trong luồng xử lý xác thực hai lớp (2FA), có một tham số tên tfa-challenge. Lỗi ở chỗ: nếu tài khoản chưa bật 2FA, server lại không kiểm tra tính hợp lệ của tham số này. Kẻ tấn công chỉ cần gửi một yêu cầu đăng nhập kèm tfa-challenge với giá trị bất kỳ, và server sẽ bỏ qua luôn bước kiểm tra mật khẩu, rồi cấp cho hắn một vé đăng nhập hợp lệ.

Tôi hay ví von thế này cho dễ hình dung: giống như bạn tới cửa toà nhà, thay vì xuất trình thẻ, bạn chỉ nói "tôi nhập mã OTP xong rồi nhé", và anh bảo vệ mở cửa luôn mà không kiểm tra xem bạn là ai. Với root@pam, tài khoản quản trị mặc định của Proxmox, hậu quả là toàn quyền trên toàn bộ hạ tầng ảo hoá chỉ trong một request.

Vì sao một lỗi ba năm tuổi giờ mới bùng nổ

Đây là chi tiết thú vị nhất. Chính Proxmox thừa nhận đoạn code lỗi đã được vá từ ngày 20/07/2023 trong bản libpve-access-control 8.0.4. Nhưng ở thời điểm đó, không ai nhận ra đó là một lỗ hổng bảo mật. Nó chỉ được xem là một bước cải tổ (rework) phần 2FA, vá đi một cách vô tình. Lỗi không được tìm thấy nội bộ, cũng không ai báo cáo.

Kết quả là những hệ thống không nâng cấp, đặc biệt là Proxmox VE 7 (đã hết vòng đời hỗ trợ từ tháng 7/2024), cứ thế mang lỗ hổng suốt hơn ba năm. Đến khi có người phát hiện và mã khai thác lan ra, hàng loạt server cũ trở thành mục tiêu ngon ăn trong vài ngày. Bài học ở đây rất phũ phàng: một bản vá bạn bỏ lỡ ba năm trước hôm nay có thể quay lại thành thảm hoạ.

Ba lỗ hổng đang bị nhắc lẫn lộn: phân biệt cho đúng

Trong lúc hoảng loạn, tôi thấy nhiều bài viết trộn ba lỗ hổng khác nhau vào làm một, khiến người đọc lo sai chỗ. Bạn cần tách bạch ba cái tên này:

Nói ngắn gọn: CVE-2023-54391 mới là cái mở toang cánh cửa cho ransomware. Nó không cần bất cứ tài khoản nào, chỉ cần chạm được vào cổng 8006. Còn CVE-2026-51080 là lỗi XXE trong lúc xử lý file OVA khi bạn import máy ảo, muốn khai thác thì kẻ tấn công phải đã có quyền import, nghĩa là đã chui vào bên trong rồi. CVE-2026-51083 thì chỉ làm rò rỉ hash mật khẩu cloud-init cho người dùng quyền thấp. Cả hai lỗi 2026 này đều đáng vá, nhưng đừng nhầm chúng là nguyên nhân server bạn bị khoá.

Sau khi vào được, hacker đã làm gì

Phần này tôi tổng hợp từ các dấu hiệu xâm nhập (IOC) mà chính nạn nhân chia sẻ trên diễn đàn. Trong hầu hết các ca Proxmox bị tấn công lần này, kẻ xâm nhập đi theo một kịch bản khá giống nhau, nên nắm được quy trình của chúng giúp bạn biết cần soi vào đâu.

Kịch bản điển hình diễn ra theo sáu bước:

1. Mở shell trên host. Ngay sau khi vượt qua đăng nhập, kẻ tấn công dùng chớc năng shell/console của Web UI để mở quyền root trực tiếp trên máy chủ.
2. Xoá dấu vết. Chúng biến các file log thành liên kết rỗng, ví dụ trỏ auth.log, wtmp, btmp, lastlog sang /dev/null, và dọn journal của systemd. Đó là lý do khi bạn vào xem thì log gần như trống.
3. Cài backdoor và ẩn mình. Xuất hiện file lạ như /var/lib/systemd/PVE-1 (thực chất là miner), service giả PVE-1.service, và thư viện ẩn tiến trình /var/lib/systemd/.hide/libhide.so được nạp qua biến LD_PRELOAD cắm trong /etc/environment, /etc/profile.d/ hoặc /root/.bashrc.
4. Săn lùng backup. Chúng chủ động tìm các điểm mount có chữ "backup" trong tên, đặc biệt là NFS, để xoá sạch trước khi mã hoá. Đây là điểm khiến rất nhiều người mất luôn cả bản sao lưu.
5. Đào tiền ảo. Miner XMRig kết nối tới gulf.moneroocean.stream:20004, chạy dưới các tên tiến trình nguỵ trang như kworker/3:0 hay PVE-1-maintain để bạn tưởng là tiến trình hệ thống.
6. Mã hoá và tống tiền. Cuối cùng, các ổ đĩa máy ảo định dạng QCOW2 bị mã hoá tại chỗ rồi đổi đuôi .onyx, kèm file README_DESTROY.txt đòi tiền chuộc. Mức tiền được ra giá theo "quy mô công ty", từ khoảng 2.000 tới 60.000 USD, kèm lời đe doạ rao bán dữ liệu lên dark web sau bảy ngày, đàm phán qua một địa chỉ .onion.

Danh sách IOC gọn để bạn dò nhanh:

• File: README_DESTROY.txt, các file đuôi .onyx
• File và thư mục: /var/lib/systemd/PVE-1, /var/lib/systemd/.hide/libhide.so
• Cấu hình: dòng LD_PRELOAD lạ trong /etc/environment
• Mạng: kết nối ra gulf.moneroocean.stream cổng 20004, hoặc từ khoá moneroocean
• Tiến trình giả: PVE-1, PVE-1-maintain, kworker bất thường

Proxmox bị tấn công: kiểm tra xem bạn có nằm trong vùng nguy hiểm

Đến đây thì câu hỏi quan trọng nhất là: liệu tôi có đang trong tầm ngắm không? Tôi sẽ đưa bạn kiểm tra từ hai phía. Trước hết là từ bên ngoài, đúng bằng con mắt của kẻ tấn công, vì đó cũng là cách chúng lọc mục tiêu. Sau đó là trên chính host, để có kết luận chắc chắn.

Nhìn từ bên ngoài, đúng góc nhìn kẻ tấn công

Kẻ tấn công trong làn sóng này không đăng nhập hợp lệ vào server của bạn để dò. Chúng quét cả dải Internet, lọc ra IP nào mở cổng 8006, rồi mới nhắm vào. Nếu bạn nhìn hệ thống của mình đúng bằng con mắt đó, bạn sẽ thấy trước điều chúng thấy.

Trước khi đi tiếp, tôi nói thẳng một điều để tránh hiểu lầm. Tôi sẽ không đưa mã khai thác (PoC) hoàn chỉnh để thực hiện đòn vượt xác thực và lấy quyền root@pam. Lỗ hổng này đang bị khai thác thật ngoài kia, còn hàng nghìn server chưa vá đang phơi mặt ra Internet. Phát tán một script bấm phát ăn ngay chỉ giúp kẻ xấu nhanh hơn người phòng thủ. Thứ tôi đưa cho bạn là các cách phát hiện và đánh giá mức phơi nhiễm hoàn toàn hợp pháp, không phá hoại. Và một nguyên tắc bất di bất dịch: chỉ kiểm tra hệ thống của chính bạn, hoặc hệ thống bạn được phép kiểm tra bằng văn bản.

Bước 1: Cổng 8006 có thật sự lộ ra Internet không. Đây là yếu tố khuếch đại rủi ro lớn nhất. Bạn phải kiểm tra từ bên ngoài mạng của mình, bằng một máy chủ khác hoặc điện thoại phát 4G và tắt Wi-Fi:

# Chay tu mot may NGOAI mang cua ban
nmap -Pn -p 8006 IP_PUBLIC_CUA_BAN

Nếu kết quả là open, cả thế giới đang gõ được vào cổng quản trị của bạn. Không có máy ngoài thì dùng một dịch vụ port checker trực tuyến và nhập IP công khai cùng cổng 8006.

Bước 2: Nhìn hệ thống bằng mắt của Shodan. Đây là mẹo tôi thích nhất, vì nó cho bạn đúng góc nhìn của kẻ tấn công mà không phải tự tay quét gì. Shodan và Censys đã quét sẵn gần như toàn bộ Internet; kẻ tấn công dùng chúng để lọc mục tiêu, và bạn cũng dùng được để tra chính mình. Mở trình duyệt và vào:

https://www.shodan.io/host/IP_PUBLIC_CUA_BAN

Hoặc với Censys: https://search.censys.io/hosts/IP_PUBLIC_CUA_BAN. Nếu Proxmox của bạn đã bị lập chỉ mục, bạn sẽ thấy cổng 8006 đang mở, banner nhận diện là "Proxmox Virtual Environment", và thường kèm cả thông tin phiên bản mà máy chủ tự khoe ra. Cách này hoàn toàn thụ động: Shodan đã quét từ trước, bạn chỉ đang đọc lại hồ sơ về chính tài sản của mình.

Nếu bạn quản trị nhiều IP, có thể tra cả dải mình sở hữu bằng các bộ lọc:

Xin nhắc lại: chỉ áp các bộ lọc này lên dải IP mà bạn sở hữu hoặc được ủy quyền. Đây là để kiểm kê tài sản của chính mình, không phải để đi săn máy chủ người khác.

Bước 3: Banner nói gì. Từ một mạng bên ngoài, xác nhận panel có trả lời hay không bằng một yêu cầu HTTP đọc thuần, không đụng tới phần đăng nhập:

curl -ksI https://IP_PUBLIC_CUA_BAN:8006/

Nếu nhận được phản hồi, trang đăng nhập nhận diện là Proxmox, và Shodan cho thấy đây là bản 7.x hoặc 8.0 đời đầu, hãy coi như bạn đang trong vùng nguy hiểm. Proxmox vốn có đặc điểm để lộ thông tin build cho cả người dùng chưa đăng nhập, nên đừng ngạc nhiên khi thấy phiên bản hiện rõ. Tôi thành thật một điểm: chốt chính xác mức vá thì vẫn cần chạy pveversion trên host, nhưng mục tiêu của bước bên ngoài chỉ là rung chuông báo động, "panel lộ + phiên bản đời cũ = đi chặn 8006 ngay".

Kiểm tra trên chính host

Khi đã vào được host, bạn có kết luận chắc chắn. Các lệnh sau chỉ đọc thông tin, không thay đổi gì hệ thống.

Trước hết là phiên bản:

pveversion -v

dpkg-query -W -f='${Package} ${Version}\n' \
  libpve-storage-perl libpvestorage-perl libpve-access-control 2>/dev/null

Với lỗi authentication bypass, dải phiên bản dính là libpve-access-control >= 7.0-7 và < 8.0.4. Để máy tự so sánh cho chắc:

V=$(dpkg-query -W -f='${Version}' libpve-access-control 2>/dev/null)
echo "libpve-access-control: ${V:-chua cai}"
dpkg --compare-versions "$V" ge 7.0-7 && \
dpkg --compare-versions "$V" lt 8.0.4 && \
echo ">>> DINH LO HONG" || echo ">>> khong dinh"

Với CVE-2026-51080, phiên bản dính là libpve-storage-perl 8.3.7 và libpvestorage-perl 9.1.1, đã được vá ở 8.3.8 và 9.1.2.

Kiểm tra cổng 8006 đang nghe ở đâu:

ss -lntup | grep ':8006'

Tìm dấu hiệu đã bị mã hoá và các file IOC:

find / -xdev \( -name 'README_DESTROY.txt' -o -name '*DESTROY*' \) 2>/dev/null

find /var/lib/vz -type f \( -name '*.onyx' -o -name 'README_DESTROY.txt' \) 2>/dev/null

Và cuối cùng, bằng chớng không thể chối cãi nhất là log. Tìm các request đăng nhập mang tham số tfa-challenge đến từ IP lạ:

grep 'access/ticket' /var/log/pveproxy/access.log
journalctl -u pvedaemon | grep -i ticket

Một loạt request tới /access/ticket từ địa chỉ bạn không nhận ra, đặc biệt nếu theo sau là hoạt động của root@pam mà không khớp với thao tác quản trị nào của bạn, là dấu hiệu rất đáng ngờ. Kèm theo đó, hãy rà soát các thay đổi tài khoản, phân quyền, cron hoặc hook mà bạn không tự tạo, vì đó thường là cửa hậu được cài lại để bám trụ. Nếu các lệnh trên trả về kết quả đáng ngờ, hãy chuyển thẳng xuống phần "Nếu đã bị mã hoá".

Muốn tận mắt xem cơ chế tấn công? Hãy dựng một phòng lab cô lập

Tôi biết nhiều bạn đọc bài này không chỉ muốn biết mình có dính không, mà còn muốn hiểu tường tận đòn đánh vận hành ra sao, đúng kiểu tư duy của người làm bảo mật. Đó là bản năng tốt. Nhưng nơi để thỏa trí tò mò đó phải là phòng lab của bạn, tuyệt đối không phải một máy chủ đang chạy thật, càng không phải máy của người khác.

Cách dựng một lab an toàn để nghiên cứu:

• Tạo một node Proxmox VE 7.4 (hoặc đúng phiên bản libpve-access-control dính lỗi) trong một máy ảo riêng, chạy lồng (nested virtualization) trên máy lab của bạn.
• Đặt nó vào một mạng hoàn toàn cô lập: host-only hoặc internal network, không nối ra Internet, không bắc cầu sang mạng production. Đây là điều quan trọng nhất. Một máy cố ý để lỗ hổng mà vô tình mở ra Internet thì chính bạn vừa dựng bia cho kẻ tấn công.
• Chụp snapshot trước khi thử nghiệm, để tua lại được sau mỗi lần.
• Trong không gian kín đó, bạn có thể quan sát toàn bộ chuỗi hành vi: dòng log POST /access/ticket xuất hiện trong /var/log/pveproxy/access.log, việc một ticket được cấp, một shell root mở ra, rồi các dấu vết IOC như PVE-1, libhide.so, kết nối moneroocean lần lượt hiện lên.

Với cách này, ai muốn chạy mã PoC đang lưu hành công khai để nghiên cứu thì làm trong lab của mình, nhắm vào chính máy ảo dùng một lần của mình. Ranh giới giữa người phòng thủ và kẻ tấn công đôi khi chỉ là một câu hỏi: bạn chĩa công cụ đó vào hệ thống của ai.

Xử lý ngay trong 30 phút đầu

Nếu bạn kiểm tra và thấy mình đang dùng phiên bản dính nhưng chưa bị mã hoá, hãy làm theo thứ tự sau. Càng làm sớm càng tốt, vì ransomware nhắm vào Proxmox đang lan theo ngày, không phải theo tuần.

1. Kéo cổng 8006 khỏi Internet

Đây là việc quan trọng nhất và cũng nhanh nhất. Chỉ cho phép truy cập Web UI qua VPN, qua danh sách IP tin cậy (IP whitelist), hoặc qua một mạng quản trị riêng. Nếu chưa kịp dựng VPN, tạm thời chặn cổng 8006 ở firewall của nhà cung cấp là đã cắt đứt được đường vào chính.

2. Bật 2FA cho tài khoản quản trị

Điều thú vị của CVE-2023-54391 là lỗi chỉ khai thác được với tài khoản chưa bật 2FA. Vì vậy, bật xác thực hai lớp cho root@pam và mọi tài khoản quản trị vừa là biện pháp phòng thủ lâu dài, vừa vô hiệu hoá đúng con đường mà kẻ tấn công đang dùng.

3. Cập nhật Proxmox

apt update
apt full-upgrade

Sau khi cập nhật, libpve-access-control sẽ lên bản vá và lỗ hổng biến mất.

4. Nếu đang chạy PVE 7 chưa thể nâng cấp ngay

Proxmox có đưa ra một bản vá tạm để bịt đúng lỗi này trong khi bạn thu xếp nâng cấp. Bản vá chèn lại bước kiểm tra vé xác thực vào file AccessControl.pm:

sed -i.bck 's/^\t# This is the 2nd factor, use the password for the OTP response.$/\tverify_ticket($tfa_challenge, 0, $username);\n\t# This is the 2nd factor, use the password for the OTP response./' /usr/share/perl5/PVE/AccessControl.pm

Kiểm tra bản vá đã áp đúng (kết quả phải in ra số 3):

grep -n 'verify_ticket($tfa_challenge, 0, $username)' /usr/share/perl5/PVE/AccessControl.pm | wc -l

Rồi nạp lại dịch vụ:

systemctl reload-or-restart pvedaemon pveproxy

Này là cứu cánh thôi chớ Proxmox VE 7 đã hết hỗ trợ, nên kế hoạch đúng đắn là dựng node mới trên bản đang được hỗ trợ và di chuyển VM sang.

Nếu đã bị mã hoá: làm gì và không làm gì

Nếu bạn đã thấy .onyx và README_DESTROY.txt, hãy hít thở sâu và bình tĩnh. Thứ tự xử lý quan trọng hơn tốc độ.

Những việc cần làm, theo thứ tự:

• Cô lập host khỏi Internet ngay, nhưng đừng vội tắt máy nếu bạn cần giữ bằng chớng trong bộ nhớ.
• Giữ nguyên hiện trường: sao lưu lại ổ đĩa, log còn sót, và file ghi chú tống tiền để phục vụ điều tra.
• Kiểm tra xem đĩa VM và backup còn nguyên vẹn ở đâu không, đặc biệt là các bản backup nằm ngoài host.
• Dựng một máy Proxmox mới hoàn toàn sạch, không tái sử dụng máy đã nhiễm.
• Khôi phục hoặc import lại VM từ nguồn mà bạn tin tưởng.
• Đổi toàn bộ mật khẩu, API token, SSH key. Coi như mọi thứ trên máy cũ đều đã bị lộ.

Những việc tuyệt đối tránh:

• Đừng vội start lại VM hay rollback lung tung. Bạn có thể ghi đè lên chính dữ liệu còn cứu được.
• Đừng tin rằng cứ trả tiền là lấy lại được. Với biến thể dùng mã hoá X25519 như .onyx, gần như không có công cụ giải mã miễn phí, và trả tiền cũng không có gì bảo đảm.
• Đừng dọn dẹp máy nhiễm rồi dùng lại. Backdoor và cơ chế ẩn mình rất khó bóc hết.

Bài học đắt giá nhất: backup phải sống sót được qua một cuộc tấn công

Nếu bạn chỉ nhớ một điều từ cả bài này, hãy nhớ điều này: câu hỏi không phải là "tôi có backup không", mà là "khi tài khoản root của host bị chiếm, kẻ tấn công có xoá được backup của tôi không".

Rất nhiều nạn nhân lần này có backup, nhưng backup nằm ngay trên host hoặc trên NFS mount chung, nên bị xoá sạch cùng lúc với dữ liệu gốc. Ngược lại, tôi đọc được một ca ở Việt Nam kể lại: một node bị chiếm quyền root cuối tuần, hơn 400 file vzdump local bị xoá, nhưng toàn bộ backup trên một Proxmox Backup Server riêng vẫn còn nguyên. Lý do rất đơn giản mà cực kỳ hiệu quả: cái token mà node dùng để đẩy backup lên không được cấp quyền xoá. Kẻ tấn công có toàn quyền trên host, nhưng vẫn không thể ra lệnh cho PBS xoá đi lịch sử backup.

Đó chính là nguyên tắc vàng. Một bản backup an toàn phải nằm ở hệ thống khác, tài khoản khác, và quan trọng nhất là ở nơi mà host Proxmox chính không có quyền tự xoá. Vài gợi ý thực tế:

• Đặt Proxmox Backup Server trên phần cứng riêng, dùng bộ thông tin đăng nhập riêng, không chung cụm với node production.
• Cấp cho node quyền ghi backup nhưng không cấp quyền xoá. Việc dọn backup cũ (prune) hãy để chính PBS làm theo lịch, không để node điều khiển.
• Có thêm một bản sao ở địa điểm khác, đồng bộ một chiều theo kiểu PBS phụ kéo dữ liệu về, chớ không để node đẩy ngược lên.

Kết luận

Làn sóng Proxmox bị tấn công lần này là một lời nhắc thẳng thắn: đa số sự cố nghiêm trọng không đến từ kỹ thuật tấn công tinh vi, mà đến từ những thứ cơ bản bị bỏ quên. Một cổng quản trị mở ra Internet, một bản vá lỡ mất, một tài khoản chưa bật 2FA, một chiến lược backup mà chính kẻ tấn công có thể xoá.

Tin tốt là mọi mắt xích đó đều nằm trong tầm tay bạn, và bạn kiểm chớng được toàn bộ một cách hợp pháp mà không cần tới bất kỳ exploit nào. Ngay hôm nay, hãy tra chính mình trên Shodan để nhìn bằng mắt kẻ tấn công, kéo cổng 8006 vào sau VPN, bật 2FA cho tài khoản quản trị, cập nhật Proxmox lên bản vá, và dựng lại lớp backup theo nguyên tắc "host không có quyền tự xoá". Ba mươi phút bỏ ra bây giờ rẻ hơn rất nhiều so với một sáng thứ Hai mở dashboard lên và thấy tất cả đã biến thành .onyx.

Nếu bài viết này giúp ích cho bạn, hãy dành ra mười phút chạy các lệnh kiểm tra ở trên cho chính hệ thống của mình, và chia sẻ cho những đồng nghiệp đang quản trị Proxmox mà bạn biết. Đôi khi một cảnh báo đúng lúc là thứ cứu được cả một hệ thống.