Задний план: Удаленное агрегирование журналов рассматривается как способ повышения безопасности. Как правило, это снижает риск того, что злоумышленник, взломавший систему, может редактировать или удалять журналы, чтобы помешать криминалистическому анализу. Я исследовал параметры безопасности в инструментах общего журнала.
Но что-то кажется неправильным. Я не вижу, как настроить какие-либо общие удаленные регистраторы (например, rsyslog, syslog-ng, logstash) для проверки подлинности того, что входящее сообщение действительно исходит от предполагаемого хоста. Без каких-либо ограничений политики один создатель журнала может подделывать сообщения от имени другого автора журнала.
Автор rsyslog кажется чтобы предупредить об аутентификации данных журнала:
И последнее предупреждение: transport-tls защищает соединение между отправителем и получателем. Это не обязательно защищает от атак, которые присутствуют в самом сообщении. В частности, в среде ретрансляции сообщение могло быть отправлено вредоносной системой, которая поместила в него недопустимые имена хостов и / или другой контент. Если для таких вещей нет средств защиты, эти записи могут появиться в репозитории получателей. -transport-tls не защищает от этого (но может помочь при правильном использовании). Помните, что syslog-transport-tls обеспечивает пошаговую безопасность. Он не обеспечивает сквозную безопасность и не проверяет подлинность самого сообщения (только последнего отправителя).
Итак, следующий вопрос: какова хорошая / практичная конфигурация (в любом инструменте общего журнала по вашему выбору - rsyslog, syslog-ng, logstash и т. Д.), Которая обеспечивает некоторую степень аутентичности?
Или ... если никто не аутентифицирует данные журнала, тогда почему нет?
-
(Кроме того: при обсуждении / сравнении может оказаться полезным использование некоторых диаграмм или терминологии из RFC 5424: Раздел 4.1: Примеры сценариев развертывания - например, "оригинатор" vs "реле" vs "сборщик")
Для этого лучше всего использовать TLS с сертификатами клиента машины.
rsyslog делает это примерно с 2008 года и содержит отличные инструкции: http://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html
Процесс очень прост, так как следующие вещи:
Тогда ваши компьютеры не смогут олицетворять друг друга, и никто не сможет войти на ваш сервер журналов без одного из ваших сертификатов.
Я вижу, вы это уже нашли, но вас все еще беспокоит их предостережение. Я бы особо не беспокоился об этом. Внедрение журнала, конечно, вещь, но это много вещей, включая внедрение через приложение и внедрение в процесс регистрации. Аутентифицированный rsyslog не защитит вас, если кто-то осуществит атаку внедрения журнала в ваше приложение, но ничто не защитит и не сможет; только исправление приложения может помочь в этом. Это просто защитит вас от подделки журналов.
Остальные предостережения можно легко устранить, если не использовать реле, что в любом случае действительно не имеет смысла. Если у вас нет реле и вы используете параметр x509 / name для драйвера подключения gtls на сервере rsyslog, у вас не должно возникнуть проблем.
См. Также конфигурационный документ gtls: http://www.rsyslog.com/doc/v8-stable/concepts/ns_gtls.html
Это большой вопрос.
Я использую logstash для выполнения чего-то вроде того, что вы предлагаете. Используя logstash (или logstash-forwarder) для отправки журналов в вашу центральную систему сбора, добавьте конфигурацию logstash для добавления ключевого поля в сообщение, значение которого представляет собой длинную случайную строку, уникальную для каждого сервера.
Затем на принимающей стороне вы можете добавить соответствующее правило для отклонения (или предупреждения) любых сообщений, в которых ключ определенного хоста не соответствует тому, что вы ожидаете от его имени хоста.
Это не пуленепробиваемое устройство, но это серьезный шаг в правильном направлении.