Cách kiểm tra công tắc khẩn cấp bao phủ những gì trên một máy chủ bị xâm nhập

Bật công tắc khẩn cấp, đưa máy chủ đường hầm ra khỏi mạng và quan sát những gì máy vẫn làm. Bài kiểm tra đáng chạy vì nó tách những gì tường lửa thực sự thi hành khỏi những gì bạn giả định, và kết quả hẹp hơn hầu hết các trang sản phẩm gợi ý. Công tắc khẩn cấp quản lý các đường đi mạng; nó không quản lý phần mềm đã chạy trên thiết bị. Tôi chạy trình tự này trên mọi máy mà ứng dụng khách tuyên bố là fail-closed, và mất khoảng mười phút.

Bắt đầu từ ứng dụng khách, không phải từ máy chủ

Điểm thi hành là máy chủ bạn đang ngồi: tường lửa của hệ điều hành, một dịch vụ phụ trợ hoặc trình điều khiển của chính ứng dụng VPN. Điều này quan trọng vì mọi thứ công tắc có thể làm đều bị giới hạn bởi những gì lớp đó nhìn thấy. Nếu ứng dụng triển khai chặn bằng một quy tắc định tuyến và dấu, bất cứ thứ gì có đủ đặc quyền đều có thể thêm quy tắc riêng; nếu nó dùng bảng tường lửa của nhân, cùng đặc quyền đó có thể sửa bảng. Độ mạnh của mật mã không bao giờ đi vào câu hỏi này.

Vì vậy việc đầu tiên cần xác lập là ai sở hữu chính sách trên thiết bị này và được phép ghi đè điều gì. Trên một máy làm việc được quản lý, câu trả lời thường là tác nhân điểm cuối của tổ chức, và VPN cá nhân không loại bỏ những khả năng đó, dù đường hầm được cấu hình thế nào.

Bước một: xác nhận việc chặn trên những đường bạn tin là nó bao phủ

Hạ đường hầm ở đầu xa thay vì ở ứng dụng khách, để ứng dụng vẫn tin rằng nó nên được kết nối. Sau đó thử điều một người thực sự sẽ thử:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Bạn muốn một ứng dụng thất bại nhanh và sạch, không phải loại treo đến khi trình duyệt hết thời gian chờ. Treo thường có nghĩa là gói bị một quy tắc không từ chối âm thầm bỏ đi, điều này chấp nhận được, nhưng cũng có thể nghĩa là ứng dụng đã để lại một tuyến mặc định cũ trỏ tới giao diện đã chết. Đọc bảng định tuyến khi đường hầm đã hạ: một tuyến mặc định vẫn trỏ tới thiết bị đường hầm và một quy tắc tường lửa chỉ chặn các kết nối đi ra mới là hai trạng thái khác nhau, và chỉ một trong hai là fail-closed.

Lặp lại các lệnh tương tự với tùy chọn cho phép LAN của ứng dụng bật và tắt. Chính nút gạt đó là nơi phần lớn bất ngờ trú ngụ, vì nó mở lại một đường mà phần còn lại của chính sách được viết để đóng.

Bước hai: kiểm tra DNS và IPv6 như những đường riêng biệt

Phân giải tên là lỗ hổng tồn tại qua phần lớn triển khai, vì truy vấn có thể đi ra bằng thứ khác ngoài trình phân giải của hệ thống. Hỏi bằng công cụ bỏ qua cấu hình trình phân giải của bạn, và kiểm tra phía v6 ngay tại đó:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Câu trả lời rỗng cho cả hai truy vấn tên khi đường hầm đã hạ là kết quả bạn muốn. Nếu truy vấn thứ hai trả lời, địa chỉ trình phân giải được mã hóa cứng vẫn tới được và đường hầm không phải lối ra duy nhất khỏi máy. Nếu chỉ yêu cầu v6 thành công, chính sách bao phủ IPv4 và bỏ qua IPv6, đó là cùng một rò rỉ ở một họ địa chỉ khác.

Trình duyệt làm điều này khó đọc từ bên ngoài hơn, vì trình duyệt được cấu hình cho DNS qua HTTPS phân giải truy vấn bằng một yêu cầu HTTPS: truy vấn chỉ bị chặn trong chừng mực cổng 443 tới điểm cuối đó bị chặn. Trên một máy mà chính sách cho phép mạng con cục bộ, yêu cầu đó vẫn có thể tới một trình phân giải trong LAN.

Bước ba: tách phơi nhiễm mạng khỏi phơi nhiễm điểm cuối

Giờ là phần không quy tắc tường lửa nào chạm tới. Công tắc khẩn cấp chặn các đường ra khỏi máy; nó không ngăn phần mềm trên máy đọc dữ liệu trước khi được mã hóa, và không ngăn phần mềm đó dùng đường hầm một cách hợp pháp. Một keylogger, một tiện ích độc hại, một màn hình bị bỏ quên không khóa, một ứng dụng đồng bộ có quyền rộng: tất cả đều chuyển thông tin qua một kết nối mà công tắc sẵn lòng cho phép.

Điều tương tự đúng với phần mềm giám sát mà một chủ lao động cố ý cài đặt. Chặn tuyến không loại bỏ nó, và mua máy chủ VPN mới không phải là cách sửa, vì phơi nhiễm nằm trước đường hầm.

Một trình quản lý clipboard tải lên tài khoản đám mây cho thấy điều này một cách sắc bén. Lưu lượng được mã hóa, đích được cho phép, và công tắc khẩn cấp báo trạng thái khỏe mạnh suốt thời gian.

Bước bốn: viết tuyên bố mà bài kiểm tra của bạn ủng hộ

Sau bài kiểm tra ngắt kết nối, bạn có thể nêu các sự kiện cụ thể: ứng dụng nào thất bại, đường nào dừng, DNS và IPv6 hành xử ra sao, và việc chặn có giữ được khi đường hầm sụp không. Bạn không thể nói hệ điều hành sạch, và không thể nói một dịch vụ ở đầu xa sẽ giữ đăng nhập của bạn riêng tư.

Giữ hai vấn đề tách biệt và cho mỗi vấn đề quyền kiểm soát riêng:

• Công tắc khẩn cấp: yêu cầu thất bại đã định nghĩa, được xác minh bằng bài kiểm tra ngắt kết nối mà bạn lặp lại sau mỗi lần nâng cấp ứng dụng.
• Tin cậy thiết bị: các bản cập nhật được hỗ trợ, bảo vệ điểm cuối từ nguồn đáng tin cậy, rà soát các quyền và yêu cầu xác thực không giải thích được.
• Sự cố: tuân theo quy trình của nền tảng hoặc tổ chức khi nghi ngờ bị xâm nhập; một máy chủ mới không phải bước dọn dẹp.
• Công bố: khi nhờ giúp đỡ, đừng dán khóa riêng hoặc toàn bộ kho chẩn đoán, vì nhật ký và ảnh chụp màn hình mang cùng những bí mật như kết nối.

Chạy lại trình tự sau bản cập nhật tiếp theo, vì công tắc khẩn cấp là cấu hình di chuyển cùng phiên bản. Bài kiểm tra là bằng chứng duy nhất rằng hành vi bạn dựa vào vẫn là hành vi bạn nhận được.