Phát hiện lỗ hổng đó đụng đến tiến trình VPN nào?

Kết quả quét nêu một địa chỉ, một cổng và thứ gì đó đã được thương lượng ở đó. Nó không nêu tiến trình đứng sau ổ cắm đó, và trên một máy chủ VPN, nhiều tiến trình có thể chia sẻ máy trong khi chỉ một trong số chúng là đường hầm. Đọc chuỗi phiên bản từ một tiện ích phụ hoặc tìm thấy tệp thư viện trên đĩa sẽ thêm bằng chứng về máy chủ, không phải về trình lắng nghe. Phát hiện chỉ trở nên khả thi khi nó được gắn với một thành phần đang chạy và sau đó đối chiếu với phạm vi mà một bản tin thực sự nêu.

Thứ tự quan trọng: thành phần trước, bản tin thứ hai, khắc phục thứ ba.

Báo cáo nêu một cổng, không phải một chương trình

Hãy bắt đầu từ điểm cuối thực sự được đánh giá. Một lần thăm dò cổng quản trị HTTPS đã đo dịch vụ web, ngăn xếp TLS của nó và bất kỳ proxy nào đứng trước nó; nó không học được gì về trình lắng nghe OpenVPN hoặc WireGuard trên một cổng khác. Proxy ngược và tác nhân quản lý làm tình hình tệ hơn, vì chứng chỉ và biểu ngữ có thể thuộc về phần giao diện trong khi thư viện dễ bị tổn thương nằm phía sau trong một tiến trình phụ trợ.

Ghi lại đích đến, giao vận, cổng và tên dịch vụ cùng với kết quả để phạm vi đi cùng phát hiện.

Bản dựng đang chạy thực sự là gì

Trên một máy chủ đa dụng, gói đã cài và thư viện đã nạp là hai câu hỏi riêng. Cơ sở dữ liệu gói có thể liệt kê một phiên bản đã vá trong khi một daemon chạy lâu vẫn giữ đối tượng chia sẻ cũ trong bộ nhớ, và một ảnh thiết bị đóng gói có thể mang thư viện riêng mà không trình quản lý gói nào báo cáo. Hỏi trình quản lý dịch vụ xem cái gì đang chạy, sau đó kiểm tra tiến trình và các liên kết của nó.

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

Thời gian khởi động trong danh sách tiến trình là chi tiết mà mọi người bỏ qua. Một daemon khởi động trước lần nâng cấp gói cuối cùng vẫn chạy bản dựng đã nạp lúc khởi động, và đó chính là trường hợp bản kiểm kê nói đã vá còn ổ cắm nói khác.

Đối chiếu bản dựng với phạm vi của một bản tin

Bản tin mô tả sản phẩm, phiên bản và đôi khi cả điều kiện bắt buộc, và ba trường đó không phải lúc nào cũng khớp với phiên bản gói. Bản tin Heartbleed của OpenVPN tháng Tư năm 2014 là một ví dụ lịch sử hữu ích vì nó tách các bản phát hành Access Server bị ảnh hưởng khỏi dịch vụ web và daemon VPN, vốn có mức phơi nhiễm khác nhau. Bài học là đọc xem văn bản bao quát thành phần nào thay vì khớp mẫu từ OpenSSL.

Bản tin đó cũng đã lỗi thời. Số bản phát hành đã vá của nó giờ không còn là lời khuyên cài đặt, và một lỗi được sửa năm 2014 không nói gì về các vấn đề sau này trong nhánh bạn chạy hôm nay.

Giải quyết bất đồng, rồi đóng phơi nhiễm

Khi kiểm kê và đánh giá không khớp, hãy kiểm tra xem cả hai có mô tả cùng điểm cuối và cùng môi trường chạy không: địa chỉ khác, proxy giao diện, dịch vụ thứ hai, tiến trình cũ vẫn gắn với cổng, hoặc thư viện đóng gói mà trình quản lý gói chưa từng thấy. Hãy giải quyết điều đó ở ranh giới trước khi viết lại báo cáo.

Áp dụng bản sửa được hỗ trợ, khởi động lại dịch vụ bị ảnh hưởng và xác nhận rằng bản dựng mới là bản đang chạy. Một tệp đã vá trên đĩa trong khi tiến trình cũ vẫn phục vụ lưu lượng không phải là khắc phục.

Sau đó xử lý những gì thành phần có thể đã giữ trong cửa sổ phơi nhiễm. Vá và thay thông tin đăng nhập trả lời các câu hỏi khác nhau, và một chứng chỉ lưu gần máy chủ bị ảnh hưởng tự nó không phải là danh sách những gì đã rò rỉ. Hãy theo quy trình của chủ sự cố về thu hồi, xóa phiên và cập nhật máy khách, và ghi lại thành phần nào bị ảnh hưởng, tại sao bằng chứng áp dụng và điều gì đã đóng nó. Bản ghi đó là thứ một lần đánh giá sau này sẽ đọc.