Как настроить агрегатор журналов для аутентификации данных?

Предыстория : удаленное объединение журналов рассматривается как способ повышения безопасности. Как правило, это устраняет риск того, что злоумышленник, взломавший систему, сможет редактировать или удалять журналы, чтобы сорвать судебный анализ. Я изучал параметры безопасности в общих инструментах журнала.

Но что-то не так. Я не вижу, как настроить какой-либо из распространенных удаленных регистраторов (например, rsyslog, syslog-ng, logstash) для аутентификации того, что входящее сообщение действительно исходит от предполагаемого хоста. Без какого-либо ограничения политики один отправитель журнала может подделывать сообщения от имени другого отправителя журнала.

Автор rsyslog, похоже, предупреждает об аутентификации данных журнала :

Последнее слово предостережения: transport-tls защищает соединение между отправителем и получателем. Он не обязательно защищает от атак, которые присутствуют в самом сообщении. Особенно в среде ретрансляции сообщение могло быть отправлено вредоносной системой, которая поместила в него недопустимые имена хостов и / или другой контент. Если против таких вещей нет предоставления, эти записи могут появиться в хранилище получателей. -transport-tls не защищает от этого (но может помочь при правильном использовании). Имейте в виду, что syslog-transport-tls обеспечивает безопасность переходов по шагам. Он не обеспечивает сквозную безопасность и не аутентифицирует само сообщение (только последний отправитель).

Итак, следующий вопрос: что такое хорошая / практичная конфигурация (в любом обычном инструменте журналов по вашему выбору - rsyslog, syslog-ng, logstash и т. Д.), Который обеспечивает некоторую степень аутентичности?

Или ... если никто не аутентифицирует данные журнала, то почему бы и нет ?

-

(Помимо: при обсуждении / сравнении может помочь использование некоторых диаграмм или терминологии из RFC 5424: Раздел 4.1: Примеры сценариев развертывания - например, «источник» против «реле» против «сборщик»)

Это большой вопрос.

Я использую logstash для выполнения чего-то вроде того, что вы предлагаете. Используя logstash (или logstash-forwarder) для отправки журналов в вашу центральную систему сбора данных, добавьте конфигурацию logstash, чтобы добавить ключевое поле к сообщению, значение которого представляет собой длинную случайную строку, уникальную для каждого сервера.

Затем на принимающей стороне вы можете добавить соответствующее правило для отклонения (или оповещения) любых сообщений, в которых ключ определенного хоста не соответствует ожидаемому для его имени хоста.

Это не пуленепробиваемый, но это твердый шаг в правильном направлении.

Для этого нужно использовать TLS с сертификатами клиентских компьютеров.

rsyslog делает это примерно с 2008 года и имеет отличные инструкции: http://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Процесс чрезвычайно прост, поскольку эти вещи идут:

1. Настройте CA
2. Выпуск сертификатов на все ваши компьютеры, с которых вы хотите журналы
3. Настройте rsyslog для использования этой аутентификации

Тогда ваши компьютеры не смогут выдать себя за другого, и никто не сможет войти на ваш сервер регистрации без одного из ваших сертификатов.

Я вижу, вы уже нашли это, но вы все еще беспокоитесь об их предостережении. Я бы не стал сильно беспокоиться об этом. Внедрение журналов, конечно, вещь, но это много вещей, включая внедрение через приложение и внедрение в процесс регистрации. Аутентифицированный rsyslog не защитит вас, если у кого-то есть атака с использованием инъекции в ваше прикладное программное обеспечение, но ничего не сможет или не сможет; в этом может помочь только исправление приложения. Это только защитит вас от поддельных логов.

Другие предостережения могут быть легко смягчены, если не использовать реле, что в любом случае не имеет особого смысла. Если у вас нет реле и вы используете опцию x509 / name для драйвера соединения gtls на сервере rsyslog, у вас не должно возникнуть никаких проблем.

Смотрите также документацию по конфигурации gtls: http://www.rsyslog.com/doc/v8-stable/concepts/ns_gtls.html.