Cảnh báo lưu lượng vào trên máy chủ VPN: đọc điểm quan sát

Một máy chủ sau VPN vẫn giữ các mục dịch vụ công khai của mình, và người ta cứ tìm ra chúng. Thứ đến trong hàng đợi cảnh báo không phải một phát hiện mà là ba khả năng, và chúng mang ý nghĩa khác nhau. Việc đầu tiên là tách một dịch vụ bị lộ khỏi một thông tin đăng nhập bị lộ.

Đi qua các điểm quan sát theo thứ tự. Dừng lại khi bằng chứng đổi loại, vì giai đoạn tiếp theo trả lời một câu hỏi khác.

Giai đoạn một: bản bắt gói thực sự đã thấy gì

Một lần bắt gói ghi lại những gì nhìn thấy tại chính điểm của nó trên đường đi. Điểm đó có thể nằm trước một quyết định lọc về sau. Gói bắt được chứng minh lưu lượng đã đến đó. Nó không chứng minh gì về những gì xảy ra sau đó.

Cũng hãy chú ý đến giao diện. Một lần bắt trên card mạng công cộng và một lần bắt bên trong đường hầm mô tả các điểm đến khác nhau, và một cảnh báo dẫn sai điểm sẽ dẫn đến kết luận sai.

Windows cũng lọc ở nhiều tầng của ngăn xếp, nên mô hình gọn gàng trong đó công cụ bắt gói nằm ở tầng hai và tường lửa ở tầng ba không sống nổi khi gặp một sản phẩm thật. Tổng quan về Windows Filtering Platform mô tả việc lọc xuyên các tầng của ngăn xếp, vì thế thứ tự quan sát phải được xác lập chứ không phải giả định.

Giai đoạn hai: bản ghi chặn xác lập điều gì

Một bản ghi chặn nói rằng một ranh giới chính sách đã từ chối gói đó. Đó là bằng chứng mạnh. Nó cũng là bằng chứng hẹp, vì nó chỉ bao một quyết định tại một ranh giới. Không có gì khác trong ngăn xếp được nó mô tả.

Đối chiếu theo bộ giá trị và dấu thời gian. Cùng nguồn, cùng đích, cùng cổng, trong cùng một giây. Không có sự khớp đó, một sự kiện trông tương tự trong nhật ký khác chỉ là một sự kiện khác, và ghép chúng lại tạo ra một câu chuyện không ai bảo vệ được.

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

Một cổng đóng và một gói bị chặn trông giống hệt nhau từ bên ngoài và hoàn toàn khác nhau trong hai kết quả này. Chính sự khác biệt đó là toàn bộ lý do để đọc bản ghi cục bộ.

Giai đoạn ba: sự kiện xác thực chứng minh điều gì

Một sự kiện xác thực nói rằng một thành phần đã xử lý yêu cầu đủ xa để ghi lại một kết quả. Đây là giai đoạn duy nhất trong ba giai đoạn nói về danh tính, và nó không nói gì về việc đã có bao nhiêu gói đến trước đó.

Hãy đọc bối cảnh thực của sự kiện. Một lần đăng nhập thất bại cho một tài khoản không tồn tại là tiếng ồn từ việc quét. Một lần đăng nhập thất bại cho một tài khoản thật với nguồn hợp lý là một ưu tiên khác. Một phiên thành công là một loại sự cố hoàn toàn khác.

Cũng để ý tên giao thức. RPC và RDP là hai dịch vụ riêng với cổng riêng. Một bộ phát hiện chỉ theo dõi một trong hai không bao phủ cái kia. Các công cụ tóm tắt hoạt động mạng không phải lúc nào cũng nói cái nào trong hai đã tạo ra sự kiện.

Một mẫu đã đối chiếu tốt hơn một bảng điều khiển

Chọn một bài kiểm tra được phép, chạy nó có chủ đích và lần theo từ đầu đến cuối: địa chỉ đích và giao diện, địa chỉ nguồn thật, cổng dịch vụ, hồ sơ và quy tắc tường lửa đang hiệu lực, và kết quả dịch vụ tương ứng. Hãy đưa mọi ánh xạ phía trên hoặc tường lửa đám mây vào chuỗi đó, vì một quy tắc cho phép ở đó có thể lấn át một quy tắc cục bộ gọn gàng.

Sau đó tách hai nghĩa vụ. Nếu việc quản trị chỉ nên qua VPN, hãy áp đặt điều đó trên cả đường công cộng lẫn đường hầm trong khi vẫn giữ một tuyến khôi phục đã được phê duyệt. Giám sát một lần thử bị từ chối không phải cùng một việc với quyết định máy chủ nên chấp nhận gì.

Một quy tắc địa lý hay một giao thức không liên quan bị chặn không thay thế cho việc tìm ra mục đã quan sát và quyết định mà nó nhận được. VPN cũng không: định tuyến lưu lượng đi ra qua đường hầm không ghi lại gì về việc cho phép lưu lượng đi vào.