Làm cách nào để định cấu hình trình tổng hợp nhật ký để xác thực dữ liệu?


8

Bối cảnh : Tổng hợp nhật ký từ xa được coi là một cách để cải thiện bảo mật. Nói chung, điều này giải quyết rủi ro kẻ tấn công xâm phạm hệ thống có thể chỉnh sửa hoặc xóa nhật ký để làm thất vọng phân tích pháp y. Tôi đã nghiên cứu các tùy chọn bảo mật trong các công cụ đăng nhập phổ biến.

Nhưng một cái gì đó cảm thấy sai. Tôi không thể xem cách định cấu hình bất kỳ trình ghi nhật ký từ xa phổ biến nào (ví dụ: rsyslog, syslog-ng, logstash) để xác thực rằng một tin nhắn đến thực sự bắt nguồn từ máy chủ lưu trữ có mục đích. Nếu không có một số ràng buộc chính sách nào đó, một người khởi tạo nhật ký có thể giả mạo các thông điệp thay mặt cho một người khởi tạo nhật ký khác.

Tác giả của rsyslog dường như cảnh báo về việc xác thực dữ liệu nhật ký :

Một lời cảnh báo cuối cùng: Transport-tls bảo vệ kết nối giữa người gửi và người nhận. Nó không nhất thiết bảo vệ chống lại các cuộc tấn công có trong chính thông điệp. Đặc biệt là trong môi trường chuyển tiếp, tin nhắn có thể đã được bắt nguồn từ một hệ thống độc hại, đặt tên máy chủ không hợp lệ và / hoặc nội dung khác vào đó. Nếu không có quy định chống lại những điều đó, những hồ sơ này có thể hiển thị trong kho lưu trữ của người nhận. -transport-tls không bảo vệ chống lại điều này (nhưng nó có thể giúp, được sử dụng đúng cách). Hãy nhớ rằng syslog-Transport-tls cung cấp bảo mật hop-by-hop. Nó không cung cấp bảo mật đầu cuối và nó không xác thực chính thông điệp (chỉ người gửi cuối cùng).

Vì vậy, câu hỏi tiếp theo là: một cấu hình tốt / thực tế (trong bất kỳ công cụ nhật ký phổ biến nào bạn chọn - rsyslog, syslog-ng, logstash, v.v.) cung cấp một số lượng xác thực?

Hoặc ... nếu không ai xác thực dữ liệu nhật ký, thì tại sao không ?

-

(Ngoài ra: Trong thảo luận / so sánh, có thể giúp sử dụng một số sơ đồ hoặc thuật ngữ từ RFC 5424: Phần 4.1: Kịch bản triển khai ví dụ - ví dụ "người khởi tạo" so với "chuyển tiếp" so với "người thu thập")


Phần nào bạn đang cố gắng để bảo mật? Nhật ký tổng hợp nhận dữ liệu từ một máy chủ chính xác, hoặc chính dữ liệu?
Shane Andrie

Nhận từ máy chủ chính xác. Nếu Alice và Bob đều là người khởi tạo nhật ký và Trent là người thu thập nhật ký, Alice sẽ có thể cung cấp nhật ký của Trent với "hostname = alice" chứ không phải "hostname = bob". Nhưng tôi nghĩ rằng thiết lập mặc định được thiết kế để cho rằng Alice có thể là một rơle đăng nhập, vì vậy họ sẽ cho phép cô ấy gửi bất cứ điều gì.
Tim Otten

Câu trả lời:


1

Đâ là một câu hỏi tuyệt vời.

Tôi sử dụng logstash để thực hiện một cái gì đó giống như những gì bạn đang đề xuất. Sử dụng logstash (hoặc logstash-Forwarder) để gửi nhật ký đến hệ thống thu thập trung tâm của bạn, thêm cấu hình logstash để thêm trường khóa vào thông báo, với giá trị của nó là một chuỗi dài, ngẫu nhiên duy nhất cho mỗi máy chủ.

Sau đó, ở phía bên nhận, bạn có thể thêm một quy tắc tương ứng để loại bỏ (hoặc cảnh báo về) bất kỳ thư nào trong đó khóa của một máy chủ cụ thể không khớp với những gì bạn mong đợi cho tên máy chủ của nó.

Đây không phải là chống đạn, nhưng đó là một bước đi vững chắc theo đúng hướng.


3

Điều đúng đắn để sử dụng cho việc này là TLS với chứng chỉ máy khách.

rsyslog đang làm điều này từ khoảng năm 2008 và có những hướng dẫn tuyệt vời: http://www.rsyslog.com/doc/v8-urdy/tutorials/tls_cert_summary.html

Quá trình này cực kỳ đơn giản, vì những điều này diễn ra:

  1. Thiết lập CA
  2. Cấp chứng chỉ cho tất cả các máy tính mà bạn muốn đăng nhập từ
  3. Định cấu hình rsyslog để sử dụng xác thực đó

Sau đó, các máy tính của bạn không thể mạo danh lẫn nhau và không ai có thể đăng nhập vào máy chủ nhật ký của bạn mà không có một trong các chứng chỉ của bạn.

Tôi thấy bạn đã tìm thấy điều đó rồi, nhưng bạn vẫn lo lắng về sự cảnh báo của họ. Tôi sẽ không lo lắng quá nhiều về điều đó. Nhật ký tiêm chắc chắn là một điều, nhưng nó là nhiều thứ, bao gồm tiêm thông qua ứng dụng và tiêm vào quá trình đăng nhập. Rsyslog xác thực sẽ không bảo vệ bạn nếu ai đó có một cuộc tấn công tiêm log trong phần mềm ứng dụng của bạn, nhưng sẽ không có gì hoặc có thể; chỉ sửa chữa ứng dụng có thể giúp điều đó. Điều này sẽ chỉ bảo vệ bạn chống lại các bản ghi giả mạo.

Các cảnh báo khác có thể được giảm nhẹ một cách dễ dàng bằng cách không sử dụng rơle, điều này thực sự có rất ít lý do để làm. Nếu bạn không có rơle và bạn sử dụng tùy chọn x509 / name cho trình điều khiển kết nối gtls trong máy chủ rsyslog, bạn sẽ không gặp khó khăn gì.

Xem thêm tài liệu cấu hình gtls: http://www.rsyslog.com/doc/v8-urdy/con accept / ns_gtls.html

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.