Cảnh báo đăng nhập VPN: sự kiện nào thực sự nên kích hoạt chúng?
Xác thực thành công, một đường hầm đã thiết lập và một RADIUS accounting Start là ba khẳng định khác nhau. Hãy chọn khẳng định mà người nhận có thể hành động, rồi tương quan chúng.
Xác thực thành công, một đường hầm đã thiết lập và một RADIUS accounting Start là ba khẳng định khác nhau, và một email đăng nhập chỉ có ý nghĩa khi bạn chọn một trong số đó. Hầu hết các thiết kế cảnh báo VPN trộn cả ba và tạo ra một hộp thư mà không ai tin tưởng. Quyết định phụ thuộc vào việc ai đọc cảnh báo và họ có thể làm gì trong năm phút tiếp theo. Làm sai điều này thì cảnh báo trở thành tiếng ồn che khuất sự kiện duy nhất mà bạn cần.
Ba câu hỏi quyết định yếu tố kích hoạt
Hỏi ai sẽ nhận, họ sẽ làm gì và hành động phải diễn ra nhanh đến mức nào. Một nhóm bảo mật theo dõi việc lạm dụng thông tin đăng nhập muốn thấy mô hình thất bại rồi thành công từ một tài khoản trong vài phút. Một nhóm vận hành theo dõi dung lượng muốn thời lượng phiên và lý do ngắt kết nối, không phải các lần đăng nhập. Bộ phận trợ giúp muốn danh tính phiên để có thể đối chiếu với một phiếu yêu cầu.
Những câu trả lời đó chỉ vào các sự kiện khác nhau, và không có quy tắc đơn lẻ nào thỏa mãn cả ba. Nếu hành động của người nhận là «gọi cho người dùng», xác thực là đủ. Nếu hành động là «giải phóng một giấy phép» hoặc «xác minh đường hầm có mang lưu lượng», chỉ việc thiết lập hoặc accounting Start mới dùng được. Nếu hành động là «xuất hóa đơn theo thời gian», bạn cần bản ghi Stop chứ không phải lần đăng nhập.
Viết câu trả lời thành một câu trước khi cấu hình bất cứ thứ gì. «Email này cho kỹ sư trực biết rằng tài khoản X đã mở một đường hầm từ mạng Y lúc Z, để anh ta có thể kiểm tra xem cửa sổ bảo trì có được dùng hay không.» Nếu bạn không điền được mọi chỗ, yếu tố kích hoạt vẫn chưa được chọn.
Khớp sự kiện với khẳng định bạn đang đưa ra
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
Bảng này ẩn một phụ thuộc: mỗi hàng chỉ đáng tin nếu cổng phát ra nó một cách đáng tin cậy và bộ thu của bạn giữ trường bạn cần. Hãy đọc định nghĩa sự kiện cho đúng bản phát hành bạn đang chạy, vì tên «phiên đã thiết lập» thay đổi giữa các phiên bản và ý nghĩa thay đổi thường xuyên hơn tên gọi. Khi định nghĩa mơ hồ, hãy yêu cầu bản ghi phiên thay vì đoán từ nhãn.
Coi một Access-Accept là sự hoàn tất của mọi thứ sau đó là sai lầm phổ biến nhất. Đó là phán quyết về thông tin đăng nhập, không phải một phiên. Sai lầm ngược lại là đọc một khớp chính sách như bằng chứng ủy quyền, trong khi quy tắc có thể khớp và bước tiếp theo vẫn có thể thất bại.
Một phiên, một thông báo
Một tài khoản, nhiều thiết bị, truyền lại và kết nối lại: một email cho mỗi sự kiện sẽ sai theo cả hai hướng, nhân đôi một phiên trong khi chia tách một phiên khác. Đặt khóa thông báo trên cổng cộng với định danh phiên, và coi tên tài khoản là thuộc tính chứ không phải khóa. Một người dùng có laptop và điện thoại có thể giữ hai đường hầm cùng lúc, và cả hai đều xứng đáng có dòng riêng.
Các bản ghi kế toán truyền lại là bình thường, vì vậy hãy loại trùng theo id phiên và dấu thời gian trước khi hiển thị thông điệp. Các phiên liên tiếp từ cùng một thiết bị nên được giữ riêng, và một lần kết nối lại trong cửa sổ bảo trì nên vẫn hiển thị thay vì gộp vào phiên trước. Nếu bộ thu của bạn ghi lại dấu thời gian khi nhập, hãy loại trùng theo các trường của bản ghi gốc, không phải các trường đã lưu.
Thiếu bản ghi Stop là sự không chắc chắn, không phải một phiên vĩnh viễn. Khởi động lại cổng, sự cố bộ thu và mất gói UDP đều để lại khoảng trống, nên cảnh báo cần một đường đối soát truy vấn bảng phiên đang hoạt động trước khi ai đó kết luận rằng một đường hầm vẫn còn mở.
Tách kiểm toán khỏi thông báo
Luồng kiểm toán và luồng cảnh báo có nhiệm vụ khác nhau. Hãy giữ các bản ghi thô, bao gồm tài khoản, cổng, id phiên, dấu thời gian và lý do kết thúc, ngay cả khi email thường được nhóm, chặn hoặc gửi đến một danh sách trực nhỏ. Ngưỡng nghiêm trọng là bộ lọc phân phối, không phải việc chọn sự kiện vòng đời mà bạn muốn công bố.
Gửi ngữ cảnh tối thiểu mà người nhận cần để tìm bản ghi được bảo vệ. Tên tài khoản, địa chỉ nội bộ và chi tiết phiên là nhạy cảm, và một email chuyển tiếp tốt là một email rò rỉ tốt.
Sau đó hãy chứng minh từ đầu đến cuối. Chạy đăng nhập và đăng xuất bình thường, một lần kết nối lại, hai phiên đồng thời và một sự cố phân phối bị ép buộc, rồi theo dõi một sự kiện từ cổng qua bộ thu đến thông điệp đã phân phối. Nếu email đến mà không có id phiên, hợp đồng chưa hoàn chỉnh. Nếu hai email mô tả cùng một phiên, tương quan bị hỏng. Không vấn đề nào trong hai vấn đề đó xuất hiện khi thứ duy nhất bạn kiểm tra là việc phân phối thư hoạt động.