Unisphere dla PowerMax 9.2 Zdalny bezpieczny dziennik systemowy

Historia dziennika systemowego

Syslog został opracowany w 1980s przez Erica Paula Allmana (ur. 2 września 1955).
Eric jest amerykańskim programistą komputerowym, który opracował Sendmaila i jego prekursora Delivermail na przełomie lat 70. i 80. na Uniwersytecie Kalifornijskim w Berkeley. W 1998 roku Allman i Greg Olson założyli firmę Sendmail, Inc. Format rejestrowania używany przez agenta transferu komunikatów MTA, znany jako syslog. Syslog był początkowo używany wyłącznie przez Sendmaila, ale ostatecznie stał się nieoficjalnym standardowym formatem używanym przez inne niepowiązane programy do logowania. Później format ten został oficjalnie wprowadzony przez Rfc 3164 w 2001 roku; Jednak oryginalny format stał się przestarzały przez najnowszą wersję, Rfc 5424.

Grupa zadaniowa ds. inżynierii Internetu

Internet Engineering Task Force (IETF) jest organizacją otwartych standardów, która opracowuje i promuje dobrowolne standardy internetowe, w szczególności standardy składające się z pakietu protokołów internetowych (TCP/IP). 
Nie ma formalnej listy członków ani wymagań dotyczących członkostwa. Wszyscy uczestnicy i menedżerowie są wolontariuszami, chociaż ich praca jest finansowana przez ich pracodawców lub sponsorów.

Internet Architecture Board (IAB) nadzoruje zewnętrzne relacje IETF i relacje z edytorem RFC. IAB wyznacza dalekosiężne kierunki techniczne rozwoju Internetu. Rada ds. Oceny Skutków jest również współodpowiedzialna za Komitet Nadzoru Administracyjnego IETF (IAOC), który nadzoruje działalność IETF w zakresie wsparcia administracyjnego (IASA), która zapewnia wsparcie logistyczne itp. 
IAB zarządza również Grupą Zadaniową ds. Badań Internetowych (IRTF), z którą IETF ma kilka relacji międzygrupowych.

Grupa sterująca

Internet Engineering Steering Group (IESG) to organ składający się z przewodniczącego i dyrektorów regionalnych Internet Engineering Task Force (IETF). Zapewnia ostateczny przegląd techniczny standardów internetowych i jest odpowiedzialny za bieżące zarządzanie IETF. Otrzymuje odwołania od decyzji grup roboczych, a IESG podejmuje decyzję o postępach w dokumentach na ścieżce standaryzacyjnej.

Protokół 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)
 +------------------------+  +----------------------+
      ^                                     ^
      |                                     |
          -----------------------------

W jaki sposób transportowany jest syslog?

Istnieją dwa popularne sposoby wysyłania komunikatów syslogu. Mimo że specyfikacja RFC 5424 wymaga, aby wszystkie implementacje dziennika systemowego obsługiwały szyfrowany transport sieciowy TLS przez TCP, większość komunikatów dziennika systemowego jest nadal dostarczana przy użyciu starszej metody UDP. W wersji UDP wiadomości są po prostu umieszczane w części danych pakietu UDP i wysyłane do serwera przez port UDP 514. Każda wiadomość zazwyczaj mieści się w jednym pakiecie. UDP jest bezstanowy i bezsesyjny, więc nie ma potwierdzenia. Pakiety są wysyłane do sieci. Ma to oczywisty problem, że każdy problem z siecią może uniemożliwić dostarczenie pakietu, w którym to przypadku możesz nie wiedzieć, że sieć nie działa, ponieważ nie może ci tego powiedzieć. Oznacza to również, że czasami ważne pakiety mogą zostać utracone lub uszkodzone podczas przesyłania.

Podstawowe zasady

 Do komunikacji syslog mają zastosowanie następujące zasady:
o Protokół syslog nie zapewnia potwierdzenia dostarczenia komunikatu. Chociaż niektóre transporty mogą dostarczać informacji o stanie, koncepcyjnie syslog jest czystym protokołem komunikacyjnym simpleks.
 o Inicjatory i przekaźniki można skonfigurować tak, aby wysyłały ten sam komunikat do wielu kolektorów i przekaźników.
 o Funkcje nadawcy, przekaźnika i kolektora mogą znajdować się w tym samym systemie.

Minimalne wymagane mapowanie transportu

 Wszystkie implementacje tej specyfikacji MUSZĄ obsługiwać transport oparty na TLS, jak opisano w [RFC5425].
 Wszystkie implementacje tej specyfikacji POWINNY również obsługiwać transport oparty na UDP, jak opisano w [RFC5426]. ZALECA się, aby wdrożenia tej specyfikacji korzystały z transportu opartego na protokole TLS.
Swobodna natura komunikatów syslog jest największą siłą syslogu, ale jest również największym problemem syslogu. Bardzo trudno jest przeanalizować dziennik zawierający zdarzenia z dziesiątek różnych systemów od różnych dostawców i jednocześnie nadać im sens. Które komunikaty reprezentują jakie funkcje? A które z nich reprezentują krytyczne wydarzenia, a które zwykłe komunikaty informacyjne?
Aby odpowiedzieć na te pytania, protokół syslog (zdefiniowany w RFC 5424) udostępnia te komunikaty o swobodnej formie ze specjalnymi polami o nazwach "facility" i "severity".
(Należy pamiętać, że RFC 5424 jest standardem dla syslogu, ale nie wszystkie implementacje syslog są zgodne ze specyfikacją RFC 5424. Protokół syslog istnieje już od bardzo dawna i nadal używane są pewne implementacje przedstandardowe.)

Wymagania dotyczące zabezpieczeń dla syslogu

Komunikaty dziennika systemowego mogą przechodzić przez kilka przeskoków, aby dotrzeć do zamierzonego modułu zbierającego. Niektóre sieci pośredniczące mogą nie być zaufane przez nadawcę, przekaźnik lub odbiorcę, ponieważ sieć znajduje się w innej domenie zabezpieczeń lub na innym poziomie zabezpieczeń niż nadawca, przekaźnik lub moduł zbierający. Innym problemem związanym z bezpieczeństwem jest to, że sam nadawca, przekaźnik lub odbiornik znajduje się w niezabezpieczonej sieci.
Istnieje kilka zagrożeń, którymi należy się zająć, aby zapewnić bezpieczeństwo syslogu.

Głównymi zagrożeniami są:

  o Maskarada. Nieautoryzowany nadawca transportu może wysyłać komunikaty do uprawnionego odbiorcy transportu lub nieautoryzowany odbiorca transportu może próbować oszukać uprawnionego nadawcę transportu w celu wysłania do niego komunikatów dziennika systemowego. 
 
  o Modyfikacja. Osoba atakująca między nadawcą transportu a odbiorcą transportu może zmodyfikować komunikat dziennika systemowego w tranzycie, a następnie przesłać komunikat dalej do odbiorcy transportu. Taka modyfikacja może spowodować, że odbiorca transportu źle zrozumie komunikat lub będzie się zachowywał w niepożądany sposób.

  o Ujawnienie. Nieuprawniony podmiot może zbadać zawartość komunikatów syslogu, uzyskując nieuprawniony dostęp do informacji. Niektóre dane w komunikatach dziennika systemowego są poufne i mogą być przydatne dla osoby atakującej, takie jak hasło autoryzowanego administratora lub użytkownika.

Zagrożeniem wtórnym jest

o Modyfikacja strumienia komunikatów. Osoba atakująca może usunąć jeden lub więcej komunikatów dziennika systemowego z serii komunikatów, odtworzyć komunikat lub zmienić sekwencję dostarczania. Sam protokół syslog nie jest oparty na kolejności komunikatów. Jednak zdarzenie w komunikacie dziennika systemowego może być semantycznie powiązane ze zdarzeniami w innych komunikatach, więc kolejność komunikatów może być ważna dla zrozumienia sekwencji zdarzeń.

Następujące zagrożenia są uważane za mniej istotne dla syslogu i nie zostały omówione w tym dokumencie:
  o Odmowa usługi

o Analiza ruchu

Używanie protokołu TLS do zabezpieczania syslogu

Protokół TLS może być używany jako bezpieczny transport w celu przeciwdziałania wszystkim podstawowym zagrożeniom dla syslogu opisanym powyżej

  o Poufność w celu przeciwdziałania ujawnieniu treści wiadomości.

  o Sprawdzanie integralności w celu przeciwdziałania modyfikacjom komunikatu na zasadzie hop-by-hop.

  o Serwer lub wzajemne uwierzytelnianie w celu przeciwdziałania maskaradzie.

Uwaga: Ten bezpieczny transport (tj. TLS) zabezpiecza tylko transport syslog w sposób hop-by-hop i nie jest związany z zawartością komunikatów syslog. W szczególności uwierzytelniona tożsamość nadawcy transportu (np. nazwa podmiotu w certyfikacie) nie musi być związana z polem NAZWAHOSTA komunikatu syslog. Gdy wymagane jest uwierzytelnienie źródła komunikatu dziennika systemowego, można użyć funkcji [SYS-SIGN].

Szyfrowanie ruchu Syslog za pomocą protokołu TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Dziennik systemowy i SIEM serwera Dell Security ManagementServer https://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide przewodnika

https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html rejestrowania
RSYS

 Podręcznik użytkownika zdarzeń i alertów dotyczących PowerMax i VMAX 9.2

Podręcznik referencyjny interfejsu CLI dla Solutions Enabler 9.2

Pomoc online dla Unisphere dla PowerMax 9.2.0