Bài 86. (Lab) Quét lỗ hổng bằng Greenbone (OpenVAS) và lập báo cáo

Khóa học CompTIA Security+ SY0-801 · Phần 4: Vận hành bảo mật · Bài 86 · 🎯 Objective 4.3 · ⏱️ Làm khoảng 90 phút (chưa kể thời gian tải feed lần đầu) · 🧪 Có lab (2 máy ảo) · 📝 5 câu bài tập cuối bài

🎯 Mục tiêu bài học

• Cài và khởi động Greenbone Community Edition (OpenVAS) trên Kali Linux.
• Tạo target và task, chạy một đợt quét lỗ hổng vào máy mục tiêu trong lab.
• Đọc báo cáo: severity (CVSS), QoD, nhóm lỗ hổng, giải pháp khuyến nghị; nhận diện false positive.
• Khắc phục một số phát hiện, quét lại và so sánh để kiểm chứng.
• Viết một báo cáo ngắn cho người ra quyết định.

📎 Vị trí trong đề thi: Objective 4.3 nói về quản lý lỗ hổng. Bài này là lab của ba bài lý thuyết: Bài 68 (phát hiện), Bài 69 (phân tích, ưu tiên) và Bài 70 (khắc phục, kiểm chứng). CVSS ở Bài 15. Kết quả quét sẽ trở thành một nguồn dữ liệu điều tra như đã nói ở Bài 83. Lab kế tiếp: Bài 87 phân tích gói tin.

⚠️ An toàn và pháp lý: Chỉ quét máy ảo do chính bạn dựng trong mạng lab cô lập. Quét hệ thống của người khác khi chưa có văn bản cho phép có thể vi phạm quy định hoặc pháp luật, và quét mạnh có thể làm treo dịch vụ. Ngoài đời thật, phạm vi và thời gian quét luôn phải được phê duyệt (xem thêm Bài 100 về phạm vi và rules of engagement).

💡 Liên hệ thực tế: "Máy chủ có lỗ hổng nào không, em?"

Sau sự cố, chị Lan hỏi Nam một câu rất thực tế: "Hôm đó kẻ xấu có thể vào bằng cửa nào? Và hiện giờ máy chủ còn cửa nào mở không?" Nam biết cách trả lời có cơ sở: quét lỗ hổng, đọc kết quả, ưu tiên cái nguy hiểm trước, vá, rồi quét lại để chứng minh đã xử lý. Anh bắt đầu bằng một lab với công cụ miễn phí trước khi đề xuất lịch quét định kỳ cho công ty. Đây là tình huống minh họa, không phải vụ việc có thật.

🔎 Hình 86a. Chuẩn bị, khai báo target và task, chạy quét, rồi đọc báo cáo.

🧰 Chuẩn bị

• Cấu hình cho Kali ở trên là gợi ý thực tế (cơ sở dữ liệu và feed khá nặng), không phải mức tối thiểu của hãng. Máy yếu vẫn chạy được nhưng quét sẽ chậm.
• Đặt cả hai máy vào mạng host-only hoặc mạng nội bộ riêng. Máy target cố ý có lỗ hổng nên tuyệt đối không nối ra Internet.
• Kali cần Internet trong lúc cài đặt và tải feed (dữ liệu lỗ hổng). Sau khi xong có thể ngắt.
• Chụp snapshot cả hai máy trước khi bắt đầu.

⏳ Kiên nhẫn ở lần đầu: Việc tải feed lần đầu (các bài kiểm tra lỗ hổng NVT, dữ liệu CVE và CERT) có thể mất từ vài chục phút đến vài giờ tùy mạng. Chưa tải xong thì scanner chưa dùng được.

🪜 Các bước thực hiện

Bước 1. Cài Greenbone trên Kali

Cách đơn giản nhất cho lab là dùng gói có sẵn trong Kali:

bash

sudo apt update
sudo apt install -y gvm
sudo gvm-setup

gvm-setup cấu hình cơ sở dữ liệu, tải feed và in ra mật khẩu của tài khoản admin ở cuối. Hãy ghi lại mật khẩu này. Sau đó kiểm tra và khởi động:

bash

sudo gvm-check-setup
sudo gvm-start

Nếu gvm-check-setup báo lỗi, đọc kỹ gợi ý (thường do feed chưa đồng bộ xong hoặc dịch vụ chưa chạy). Để cập nhật feed thủ công, dùng sudo gvm-feed-update (tên lệnh có thể khác theo phiên bản Kali; xem hướng dẫn kèm gói bằng gvm-feed-update --help hoặc tài liệu của Greenbone).

💡 Phương án khác: Greenbone cung cấp Community Containers chạy bằng Docker Compose, thích hợp nếu bạn không dùng Kali. Làm theo hướng dẫn chính thức của Greenbone vì tệp compose thay đổi theo phiên bản.

Bước 2. Mở giao diện web

Giao diện Greenbone Security Assistant (GSA) mặc định chỉ lắng nghe ở localhost. Vì vậy hãy mở trình duyệt trong chính máy Kali:

https://127.0.0.1:9392

Chấp nhận chứng chỉ tự ký và đăng nhập bằng admin cùng mật khẩu ở bước 1. Vào Administration → Feed Status và chờ đến khi các feed (NVT, SCAP, CERT) đều hiện thời, đã đồng bộ.

Bước 3. Khai báo mục tiêu (Target)

Vào Configuration → Targets → New Target:

Quét có xác thực (authenticated scan, tùy chọn): vào Configuration → Credentials tạo thông tin đăng nhập SSH (tài khoản tạm trong lab) rồi gắn vào target. Khi quét có xác thực, scanner đăng nhập vào máy để đọc danh sách gói đã cài, nên kết quả thường chính xác hơn và ít false positive hơn quét không đăng nhập.

Bước 4. Tạo và chạy tác vụ (Task)

Vào Scans → Tasks → New Task:

Lưu lại rồi bấm nút Start (biểu tượng phát). Theo dõi tiến độ ở cột trạng thái. Quét máy lab có thể mất vài phút đến vài chục phút.

⚠️ Lưu ý khi ngoài đời: quét mạnh có thể gây tải hoặc làm treo dịch vụ nhạy cảm. Ở môi trường thật cần lên lịch ngoài giờ cao điểm, báo trước cho chủ hệ thống và bắt đầu bằng cấu hình nhẹ.

🔁 Hình 86b. Quét nền, ưu tiên, khắc phục, quét lại: lỗ hổng chỉ coi là xong khi quét lại không còn thấy.

Bước 5. Đọc báo cáo

Khi task xong, vào Scans → Reports và mở báo cáo mới nhất. Chú ý các cột và khái niệm:

Thực hành đọc theo trình tự:

1. Lọc Severity cao trước (High), xem QoD. Mặc định giao diện thường chỉ hiện các kết quả có QoD đủ cao; thử hạ ngưỡng để thấy các phát hiện kém chắc chắn hơn.
2. Với mỗi phát hiện, mở chi tiết: đọc Summary, Impact, Solution.
3. Phân loại từng phát hiện: chắc chắn có thật, cần xác minh thủ công, hay nghi false positive. Ghi lý do.
4. Ghi lại số lượng theo mức độ và các dịch vụ lỗi thời (ví dụ giao thức truyền văn bản thuần như Telnet hoặc FTP cũ, phiên bản phần mềm quá cũ).

Điền bảng ưu tiên (Bài 69). Cột "Ưu tiên" không chỉ dựa trên điểm: hãy cân nhắc khả năng khai thác, máy có phơi ra Internet không, giá trị tài sản và có biện pháp bù hay không.

Bước 6. Khắc phục (Remediation)

Chọn 2 đến 3 phát hiện có thể xử lý trong lab và thực hiện theo mức độ phù hợp (Bài 70):

🧠 Phần khắc phục luôn đi cùng kế hoạch thay đổi và rollback (Bài 7, 8): vá trên máy thật cần được phê duyệt và có đường quay lại.

Bước 7. Quét lại và so sánh (Verification)

Chạy lại cùng task (hoặc tạo task giống hệt) để có báo cáo thứ hai. Trong Scans → Reports, dùng chức năng so sánh báo cáo (delta report) để thấy phát hiện nào đã biến mất, phát hiện nào còn lại và có phát hiện mới không.

Kết quả cần chứng minh được: các phát hiện bạn đã xử lý không còn xuất hiện trong báo cáo mới. Nếu vẫn còn, kiểm tra xem bản vá đã áp dụng đúng chưa, dịch vụ đã khởi động lại chưa, hoặc đó là false positive cần ghi chú riêng. Nguyên tắc: một lỗ hổng chỉ được coi là xong khi quét lại xác nhận.

Bước 8. Lập báo cáo ngắn cho người ra quyết định

Xuất báo cáo từ GSA (PDF hoặc định dạng khác), rồi tự viết một trang tóm tắt cho chị Lan, theo khung sau:

Báo cáo tốt nói rủi ro bằng ngôn ngữ kinh doanh, không chỉ dán danh sách CVE.

🛠️ Lỗi thường gặp

🧹 Dọn dẹp

• Chạy sudo gvm-stop khi dùng xong.
• Lưu báo cáo cần giữ, rồi hoàn nguyên snapshot của máy target hoặc hủy máy ảo; không để máy cố ý có lỗ hổng chạy lâu trong mạng có thiết bị khác.

📘 Nối lý thuyết với lab

🎯 Mẹo làm bài

"Tìm điểm yếu đã biết của hệ thống bằng công cụ tự động" → vulnerability scan. "Quét có đăng nhập, ít báo sai hơn" → authenticated (credentialed) scan. "Báo có lỗ hổng nhưng thật ra không có" → false positive. "Có lỗ hổng nhưng quét không thấy" → false negative. "Điểm chuẩn hóa mức độ nghiêm trọng" → CVSS. "Chưa vá được nên chặn bằng firewall" → compensating control. "Xác nhận đã vá xong" → rescan hoặc validation. "Chấp nhận rủi ro, ghi rõ lý do, người duyệt, hạn" → exception. "Quét phản ánh thời điểm nào?" → thời điểm quét, không phải thời điểm tấn công. "Đảm bảo có phép và phạm vi trước khi quét" → ủy quyền bằng văn bản.

📌 Tóm tắt nhanh

• Greenbone (OpenVAS) là bộ quét lỗ hổng mã nguồn mở; cần feed đầy đủ trước khi quét.
• Quy trình: target → task → quét → đọc báo cáo → ưu tiên → khắc phục → quét lại → báo cáo.
• Đọc báo cáo bằng severity (CVSS) và QoD, rồi xác minh thủ công, không tin máy móc.
• Quét có xác thực chính xác hơn; luôn có phép và phạm vi khi quét.
• Chỉ coi lỗ hổng là xong khi quét lại xác nhận; báo cáo nên nói rủi ro bằng ngôn ngữ kinh doanh.

📝 Bài tập đánh giá

Tự chọn đáp án cho từng câu, rồi đối chiếu với phần đáp án ở cuối bài.

Câu 1. Trong báo cáo của Greenbone, QoD (Quality of Detection) cho biết điều gì?

• A. Tốc độ quét của máy
• B. Dung lượng báo cáo
• C. Độ tin cậy của phát hiện, giúp nhận diện các kết quả có thể là false positive
• D. Số cổng đang mở trên máy mục tiêu

Câu 2. So với quét không xác thực, quét có xác thực (credentialed scan) thường có ưu điểm nào?

• A. Nhanh hơn rất nhiều và không cần feed
• B. Đọc được cấu hình và gói đã cài bên trong máy, nên kết quả chính xác hơn và ít false positive hơn
• C. Không cần phép của chủ hệ thống
• D. Tự động vá mọi lỗ hổng

Câu 3. Sau khi vá một lỗ hổng, bước nào xác nhận việc xử lý đã thành công?

• A. Đóng báo cáo cũ lại
• B. Xóa máy mục tiêu
• C. Quét lại và so sánh báo cáo mới với báo cáo cũ
• D. Tắt công cụ quét

Câu 4. Điểm Severity trong báo cáo quét lỗ hổng thường dựa trên hệ thống chấm điểm nào?

• A. CVSS
• B. SLE
• C. RTO
• D. SPF

Câu 5. Vì sao chỉ được quét các hệ thống mà bạn đã được ủy quyền rõ ràng?

• A. Vì công cụ quét chỉ chạy được trên máy của mình
• B. Vì quét làm tăng dung lượng ổ đĩa
• C. Vì quét không để lại dấu vết nào
• D. Vì quét có thể gây gián đoạn dịch vụ và quét trái phép có thể vi phạm quy định hoặc pháp luật

👉 Đáp án

Câu 1: C — QoD là độ tin cậy của phát hiện; giá trị thấp gợi ý có thể là false positive cần xác minh.

Câu 2: B — Quét có xác thực đăng nhập vào máy để đọc gói và cấu hình, nên chính xác hơn.

Câu 3: C — Quét lại và so sánh báo cáo là cách kiểm chứng phát hiện đã được xử lý.

Câu 4: A — Severity dựa trên CVSS.

Câu 5: D — Quét có thể làm gián đoạn dịch vụ và quét trái phép có thể vi phạm quy định hoặc pháp luật; cần ủy quyền và phạm vi rõ ràng.

📚 Bài viết thuộc khóa học CompTIA Security+ của VNExperts

🧭 Điều hướng