Chọn điểm quan sát phù hợp cho lần quét VPN trên điện thoại
Bộ lắng nghe VPN của điện thoại, một dịch vụ trên điện thoại và một máy chủ LAN được định tuyến là ba bề mặt. Đi qua năm bước này và dừng lại ở nơi phạm vi kết thúc.
Một đánh giá được cấp phép đối với VPN chạy trên điện thoại sẽ thất bại âm thầm khi máy quét nằm ở phía sai của đường hầm. Bạn nhận được kết quả, chúng trông hợp lý và chúng trả lời một câu hỏi mà không ai đặt ra. Hãy đi qua năm kiểm tra dưới đây theo thứ tự. Mỗi kiểm tra có một điều kiện dừng, và dừng sớm rẻ hơn là kiểm thử lại từ đầu sau khi báo cáo đã viết xong.
Bước 1: đặt tên cho bề mặt bạn định tiếp cận
Ba bề mặt thường bị nhầm lẫn vì một thiết bị duy nhất kết nối chúng. Chúng chạy mã và chính sách khác nhau, nên hãy ghi ra bề mặt nào nằm trong phạm vi trước khi bắt đầu bất cứ điều gì.
| Assessment target | What the path exercises |
|---|---|
| Public VPN listener on the handset | Reachability before login, plus the exposed VPN daemon |
| A service on the handset, by its tunnel address | Access after admission to something hosted locally |
| A LAN host behind the handset gateway | Forwarding, the return path and downstream access policy |
Nếu phạm vi đã được phê duyệt không nói rõ là bề mặt nào trong ba, hãy dừng lại và hỏi. Việc root điện thoại không trả lời câu hỏi này, và nó thay đổi thứ được kiểm thử chứ không phải điểm quan sát.
Ghi lại mục tiêu, địa chỉ nguồn được phép, cửa sổ thời gian và giới hạn cường độ cùng một lúc. Đường hầm đưa bạn đến phạm vi đó; nó không cấp phép để thăm dò mọi thứ nó có thể định tuyến.
Bước 2: chọn nguồn có thể nhìn thấy bề mặt đó
Một máy quét nằm bên trong VPN không thể tái tạo một người quan sát internet chưa được xác thực. Nó đã có sẵn các tuyến, thông tin đăng nhập và quyền mà người quan sát bên ngoài không có, nên kết quả của nó mô tả góc nhìn sau khi được chấp nhận ngay cả khi bề mặt mục tiêu là như nhau. Sai lầm ngược lại cũng phổ biến tương tự. Quét công khai cổng VPN hầu như không nói gì về một dịch vụ riêng tư phía sau đăng nhập, và trình bày nó như thể có nói sẽ phóng đại mức phơi nhiễm theo một hướng và đánh giá thấp theo hướng khác.
Hãy dừng lại nếu nguồn bạn có thể có được không khớp với bề mặt. Một đánh giá chạy từ một máy ngang hàng bên trong đường hầm không nên được trình bày như kết quả trước xác thực, và một bài kiểm thử cần nguồn bên ngoài được phê duyệt không nên bị âm thầm chuyển vào trong để tránh giấy tờ.
Bước 3: xác nhận tuyến và đường phản hồi qua điện thoại
Khi thiết bị chuyển tiếp sang một mạng con khác, máy quét cần một tuyến được phép và mục tiêu cần một đường quay về hoạt động. Hãy xác nhận cả hai thay vì giả định rằng một phản hồi ping nghĩa là đường đi đã đầy đủ.
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8NAT nguồn thay đổi những gì dịch vụ phía dưới nhìn thấy. Nếu điện thoại dịch địa chỉ của máy quét, các quy tắc truy cập và nhật ký tại mục tiêu áp dụng cho địa chỉ đã dịch, nên một dịch vụ có vẻ chấp nhận bạn có thể đang chấp nhận điện thoại chứ không phải máy quét.
Cũng hãy chú ý đến sự chồng lấn với mạng của chính máy quét. Nếu điện thoại định tuyến 192.168.1.0/24 và máy quét nằm trên một LAN được đánh số theo cùng cách, các đầu dò sẽ chạm vào thiết bị cục bộ và báo cáo mô tả chúng là mục tiêu. Kiểm tra tuyến mà chính máy quét sẽ dùng trước khi gửi dù chỉ một gói.
Quét địa chỉ thật của mục tiêu và giữ lại tên máy chủ mà ứng dụng cần cho danh tính TLS và lưu trữ ảo. Tiếp cận một cổng vào chứng minh cổng vào phản hồi; nó không kiểm thử dịch vụ phía sau.
Bước 4: coi việc khám phá là một đầu dò có giả định
Khám phá máy chủ là nơi kết quả đánh giá hay đi sai nhất. Khám phá cục bộ qua Ethernet không vượt qua một VPN đã định tuyến, nên những đầu dò hoạt động trên một LAN phẳng đơn giản là không đến. Các đầu dò khám phá bị chặn khi đó khiến một dịch vụ có thể tiếp cận và được cấp phép trông như không tồn tại.
Hãy quyết định một cách có ý thức xem có bỏ qua khám phá và quét trực tiếp các địa chỉ đã biết hay không, rồi nói điều đó trong báo cáo. Một cổng phản hồi không phải bằng chứng rằng xác thực VPN đã thành công, và một phản hồi bị lọc không phải bằng chứng rằng không có gì đang lắng nghe. Tốc độ cũng là một phần của cùng vấn đề. Một điện thoại bóp hoặc bỏ gói dưới lần quét nhanh sẽ tạo ra các trạng thái bị lọc thuộc về điện thoại chứ không phải dịch vụ, nên hãy giảm mức song song và quét lại trước khi ghi một cổng là đã đóng.
Điều kiện dừng ở đây là diễn giải, không phải kỹ thuật: nếu bạn không thể nói một trạng thái có nghĩa gì cho đường đi này, kết quả thuộc về phụ lục chứ không phải phần phát hiện.
Bước 5: giữ cửa sổ, rồi đóng nó lại
Một chiếc điện thoại là máy chủ kém vì nó được thiết kế để ngủ. Tối ưu hóa pin, doze và quản lý nguồn Wi-Fi có thể tạm dừng ứng dụng giữa lúc đánh giá, và việc kết nối lại đường hầm có thể thay đổi địa chỉ mà mục tiêu dùng. Một lần chạy kéo dài qua một trong những sự kiện đó có cửa sổ kết quả không hợp lệ.
Giữ vai trò cổng vào trong phạm vi nhỏ nhất mà nhiệm vụ đã được phê duyệt cho phép, theo dõi đường hầm trong khi lần chạy còn sống, và ghi lại điểm bắt đầu và kết thúc của mỗi cửa sổ bạn báo cáo. Khi đánh giá kết thúc, hãy gỡ bỏ quyền truy cập tạm thời thông qua chủ sở hữu của nó, giữ lại bản ghi nguồn và tuyến, và bảo vệ đầu ra như mọi tạo tác kiểm thử khác.
Nếu bạn cần một điểm quan sát có thể lặp lại thay vì một thành công một lần, đó chính là kết quả cần tranh luận.tài liệu tham khảo về khám phá máy chủ giải thích những đầu dò nào giả định một phân đoạn cục bộ, và chính chi tiết đó biến một kết quả trống thành một phát biểu có thể bảo vệ.