Unisphere для PowerMax 9.2 Удаленный безопасный системный журнал

История Syslog

Syslog был разработан в 1980-х годах Эриком Полом Оллманом (родился 2 сентября 1955 года).
Эрик — американский программист, разработавший Sendmail и его предшественника Delivermail в конце 1970-х и начале 1980-х годов в Калифорнийском университете в Беркли. В 1998 году Оллман и Грег Олсон основали компанию Sendmail, Inc. Формат ведения журнала, используемый агентом передачи сообщений MTA, известный как syslog. Сначала Syslog использовался исключительно Sendmail, но в конечном итоге стал неофициальным стандартным форматом, используемым другими несвязанными программами для ведения журналов. Позже, в 2001 году, этот формат был официально оформлен RFC 3164; Однако исходный формат устарел в последней редакции, RFC 5424.

Инженерная целевая группа Интернета

Internet Engineering Task Force (IETF) — это организация по разработке и продвижению добровольных стандартов Интернета, в частности стандартов, состоящих из пакета протоколов Интернета (TCP/IP). 
У него нет официального списка членов или требований к членству. Все участники и менеджеры являются волонтерами, хотя их работа финансируется их работодателями или спонсорами.

Совет по архитектуре Интернета (IAB) осуществляет надзор за внешними связями IETF и с редактором RFC. IAB обеспечивает долгосрочное техническое направление развития Интернета. IAB также несет совместную ответственность за Комитет по административному надзору IETF (IAOC), который осуществляет надзор за деятельностью по административной поддержке IETF (IASA), который обеспечивает материально-техническую и т.д. поддержку IETF. 
IAB также руководит Целевой группой по интернет-исследованиям (IRTF), с которой IETF поддерживает несколько межгрупповых отношений.

Координационная группа

Руководящая группа по инженерному развитию Интернета (IESG) — это орган, состоящий из председателя Инженерной целевой группы Интернета (IETF) и региональных директоров. Он обеспечивает окончательный технический обзор стандартов Интернета и отвечает за повседневное управление IETF. В него поступают апелляции на решения рабочих групп, и IESG принимает решение о продвижении документов по стандартному треку.

Протокол Syslog

Syslog utilizes three layers
  o "syslog content" is the management information contained in a syslog message.
  o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.
  o The "syslog transport" layer puts messages on the wire and takes them off the wire.
  o An "originator" generates syslog content to be carried in a message.
  o A "collector" gathers syslog content for further analysis.
  o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays.
  o A "transport sender" passes syslog messages to a specific transport protocol.
  o A "transport receiver" takes syslog messages from a specific transport protocol.

Diagram 1 shows the different entities separated by layer.

+-------------------------+  +----------------------+
 | content                |  | content              |
 |------------------------|  |----------------------|
 | syslog application     |  | syslog application   |
 |                        |  |                      | (originator,
 |                        |  |                      | (collector, relay)
 |------------------------|  |----------------------|
 | syslog transport       |  | syslog transport     | (transport sender,
 |                        |  |                      | (transport receiver)
 +------------------------+  +----------------------+
      ^                                     ^
      |                                     |
          -----------------------------

Как передается syslog?

Существует два распространенных способа отправки сообщений системного журнала. Несмотря на то, что RFC 5424 требует, чтобы все реализации syslog поддерживали зашифрованный сетевой транспорт TLS по протоколу TCP, большинство сообщений syslog по-прежнему доставляются с использованием более старого метода UDP. В UDP-версии сообщения просто помещаются в часть данных UDP-пакета и отправляются на сервер через UDP-порт 514. Каждое сообщение, как правило, помещается в один пакет. UDP не имеет состояния и не требует сеансов, поэтому подтверждение отсутствует. Пакеты отправляются в сеть. Это имеет очевидную проблему, так как любая проблема в сети может помешать доставке пакета, и в этом случае вы можете не знать, что сеть не работает, потому что она не может сообщить вам об этом. Это также означает, что иногда важные пакеты могут быть потеряны или повреждены при передаче.

Основные принципы

 Для обмена данными в syslog действуют следующие принципы:
o Протокол syslog не обеспечивает подтверждение доставки сообщений. Несмотря на то, что некоторые транспорты могут предоставлять информацию о состоянии, концептуально syslog является чистым симплексным протоколом связи.
 o Оригинаторы и ретрансляторы могут быть настроены на отправку одного и того же сообщения нескольким коллекторам и ретрансляторам.
 o Функции источника, реле и сборщика могут находиться в одной системе.

Минимально необходимое сопоставление транспорта

 Все реализации данной спецификации ДОЛЖНЫ поддерживать транспорт на основе TLS, как описано в [RFC5425].
 Все реализации этой спецификации должны также поддерживать транспорт на основе UDP, как описано в [RFC5426]. При развертывании с этой спецификацией РЕКОМЕНДУЕТСЯ использовать транспорт на основе TLS.
Свободная форма сообщений syslog — это самая сильная сторона syslog, но это также и самая большая проблема syslog. Очень сложно проанализировать журнал, включающий события от десятков различных систем от разных поставщиков, и разобраться в них одновременно. Какие сообщения представляют те или иные функции? И какие из них представляют собой критически важные события, а какие просто информационные сообщения?
Чтобы ответить на эти вопросы, протокол syslog (который определен в RFC 5424) предоставляет эти сообщения в свободной форме со специальными полями, называемыми «facility» и «severity».
(Обратите внимание, что RFC 5424 является стандартом для syslog, но не все реализации syslog совместимы с RFC 5424. Протокол syslog существует уже очень давно, и до сих пор используются некоторые достандартные реализации.)

Требования безопасности для Syslog

Сообщения системного журнала могут пройти через несколько переходов, прежде чем попадут к предполагаемому сборщику. Некоторые промежуточные сети могут не доверять инициатору, ретранслятору или приемнику, так как сеть находится в другом домене безопасности или на другом уровне безопасности, чем инициатор, ретранслятор или сборщик. Еще одна проблема безопасности заключается в том, что сам источник, ретранслятор или приемник находятся в небезопасной сети.
Существует несколько угроз, которые необходимо устранить для обеспечения безопасности syslog.

Основные угрозы:

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

  o Раскрытие информации. Неавторизованный субъект может изучить содержимое сообщений системного журнала, получив несанкционированный доступ к информации. Некоторые данные в сообщениях syslog являются конфиденциальными и могут быть полезны злоумышленнику, например пароль авторизованного администратора или пользователя.

Вторичная угроза —

o Модификация потока сообщений. Злоумышленник может удалить одно или несколько сообщений системного журнала из серии сообщений, воспроизвести сообщение или изменить последовательность доставки. Сам протокол syslog не зависит от порядка сообщений. Однако событие в сообщении syslog может семантически соотноситься с событиями в других сообщениях, поэтому порядок сообщений может быть важен для понимания последовательности событий.

Следующие угрозы считаются менее важными для syslog и не рассматриваются в этом документе:
  o Отказ в обслуживании

o Анализ трафика

Использование TLS для защиты Syslog

TLS можно использовать в качестве безопасного транспорта для противодействия всем основным угрозам syslog, описанным выше

  o Конфиденциальность для противодействия разглашению содержания сообщения.

  o Проверка целостности для противодействия изменениям сообщения на основе hop by hop.

  o Серверная или взаимная аутентификация для противодействия маскараду.

Примечание. Этот безопасный транспорт (т. е. TLS) защищает транспорт syslog только по однопрыжковому режиму и не имеет отношения к содержимому сообщений системного журнала. В частности, аутентифицированная идентификация отправителя транспортного протокола (например, имя субъекта в сертификате) не обязательно связана с полем HOSTNAME сообщения syslog. Если требуется аутентификация источника сообщения syslog, можно использовать [SYS-SIGN].

Шифрование трафика syslog с помощью TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Руководство по
Dell Security Management Server Syslog и SIEMhttps://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

Журнал Rsyshttps://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

 Руководство пользователя по событиям и оповещениям для PowerMax и VMAX 9.2

Справочное руководство по интерфейсу командной строки Solutions Enabler 9.2

Онлайн-справка по Unisphere для PowerMax 9.2.0