Unisphere для PowerMax 9.2 Віддалений захищений Syslog

Історія Syslog

Syslog був розроблений у 1980-х роках Еріком Полом Олманом (народився 2 вересня 1955 року).
Ерік — американський програміст, який розробив Sendmail та його попередника Delivermail наприкінці 1970-х і на початку 1980-х років у UC Berkeley. У 1998 році Оллман і Грег Олсон спільно заснували компанію Sendmail, Inc. Формат логування, який використовує агент передачі повідомлень MTA, відомий як Syslog. Спочатку Syslog використовувався виключно Sendmail, але згодом став неофіційним стандартним форматом, який використовували інші не пов'язані програми для ведення журналу. Пізніше цей формат був офіційно затверджений Rfc 3164 у 2001 році; Однак оригінальний формат став застарілим через останню версію RFC 5424.

Робоча група з інтернет-інженерії

Робоча група з інженерії Інтернету (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?

Існує два поширені способи надсилання 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» та «sentity».
(Зверніть увагу, що RFC 5424 є стандартом для syslog, але не всі реалізації syslog сумісні з RFC 5424. Протокол syslog існує вже дуже давно, і деякі достандартні реалізації досі використовуються.)

Вимоги до безпеки для Syslog

Повідомлення Syslog можуть проходити кілька переходів до призначеного колектора. Деякі проміжні мережі можуть не бути довіреними ініціатором, ретранслятором або приймачем, оскільки мережа знаходиться в іншому домені безпеки або на іншому рівні безпеки, ніж ініціатор, ретранслятор чи колектор. Ще одна проблема безпеки полягає в тому, що сам ініціатор, ретранслятор або приймач знаходяться в незахищеній мережі
.Існує кілька загроз, які потрібно вирішити для безпеки syslog.

Основні загрози такі:

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

  o Розкриття інформації. Несанкціонована організація може перевірити вміст syslog-повідомлень, отримуючи несанкціонований доступ до інформації. Деякі дані в повідомленнях syslog є чутливими і можуть бути корисними для зловмисника, наприклад, пароль уповноваженого адміністратора або користувача.

Другорядна загроза —

o Модифікація потоку повідомлень. Зловмисник може видалити одне або кілька syslog-повідомлень із серії повідомлень, відтворити повідомлення або змінити послідовність доставки. Сам протокол syslog не базується на порядку повідомлень. Однак подія в повідомленні syslog може семантично пов'язатися з подіями в інших повідомленнях, тому порядок повідомлень може бути важливим для розуміння послідовності подій.

Наступні загрози вважаються менш важливими для syslog і не розглядаються в цьому документі:
  o Відмова в обслуговуванні

o Аналіз трафіку

Використання TLS для захисту Syslog

TLS можна використовувати як безпечний транспорт для протидії всім основним загрозам для syslog, описаних вище

  o Конфіденційність для протидії розголошенню вмісту повідомлення.

  o Перевірка цілісності для протидії змінам повідомлення покроково.

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

Примітка: Цей безпечний транспорт (тобто TLS) забезпечує безпеку syslog-транспорту лише покроково і не стосується вмісту 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

Лісозаготівля
Rsys https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

 Події та сповіщення для PowerMax та VMAX 9.2 Посібник користувача

Довідковий посібник Solutions Enabler 9.2 CLI

Онлайн-допомога з Unisphere для PowerMax 9.2.0