Vzdálený zabezpečený syslog Unisphere for PowerMax 9.2

Historie syslogu

Syslog byl vyvinut v roce 1980 Ericem Paulem Allmanem (narozen 2. září 1955).
Eric je americký počítačový programátor, který vyvinul Sendmail a jeho předchůdce Delivermail na konci 70. a začátku 1980. let na UC Berkeley. V roce 1998 Allman a Greg Olson spoluzaložili společnost Sendmail, Inc. Formát protokolování používaný agentem pro přenos zpráv MTA, označovaný jako syslog. Syslog byl zpočátku používán pouze Sendmailem, ale nakonec se stal neoficiálním standardním formátem používaným jinými nesouvisejícími programy pro protokolování. Později byl tento formát oficiálně schválen Rfc 3164 v roce 2001; Původní formát se však stal zastaralým nejnovější revizí RFC 5424.

Pracovní skupina pro internetové inženýrství

Internet Engineering Task Force (IETF) je organizace zabývající se otevřenými standardy, která vyvíjí a prosazuje dobrovolné internetové standardy, zejména standardy, které se skládají ze sady internetových protokolů (TCP/IP). 
Nemá žádný formální seznam členů ani požadavky na členství. Všichni účastníci a manažeři jsou dobrovolníci, i když jejich práce je financována jejich zaměstnavateli nebo sponzory.

Rada pro internetovou architekturu (IAB) dohlíží na vnější vztahy IETF a vztahy s editorem RFC. IAB poskytuje dlouhodobé technické vedení pro vývoj Internetu. IAB je také společně zodpovědná za Výbor pro administrativní dohled IETF (IAOC), který dohlíží na administrativní podpůrnou činnost IETF (IASA), která poskytuje logistickou podporu IETF. 
IAB také řídí Internet Research Task Force (IRTF), se kterou má IETF několik vztahů napříč skupinami.

Řídící skupina

Internet Engineering Steering Group (IESG) je orgán, který se skládá z předsedy Internet Engineering Task Force (IETF) a oblastních ředitelů. Poskytuje závěrečnou technickou revizi internetových standardů a je zodpovědná za každodenní správu IETF. Přijímá odvolání proti rozhodnutím pracovních skupin a IESG rozhoduje o pokroku v dokumentech týkajících se norem.

Protokol 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)
 +------------------------+  +----------------------+
      ^                                     ^
      |                                     |
          -----------------------------

Jak se syslog přenáší?

Existují dva běžné způsoby odesílání zpráv syslog. I když RFC 5424 vyžaduje, aby všechny implementace syslogu podporovaly šifrovaný síťový přenos TLS přes TCP, většina zpráv syslog je stále doručována pomocí starší metody UDP. Ve verzi UDP jsou zprávy jednoduše vloženy do datové části paketu UDP a odeslány na server přes port UDP 514. Každá zpráva se obvykle vejde do jednoho balíčku. UDP je bezstavový a bez relace, takže nedojde k žádnému potvrzení. Pakety jsou odesílány do sítě. To má zřejmý problém, že jakýkoli druh problému se sítí by mohl zabránit doručení paketu, v takovém případě nemusíte vědět, že je síť mimo provoz, protože vám to nemůže říct. Znamená to také, že někdy mohou být důležité pakety při přenosu ztraceny nebo poškozeny.

Základní principy

 Pro komunikaci syslogem platí následující zásady:
o Protokol syslog neposkytuje potvrzení o doručení zprávy. I když některé přenosy mohou poskytovat informace o stavu, koncepčně je syslog čistě simplexní komunikační protokol.
 o Původci a relé mohou být nakonfigurováni tak, aby odesílali stejnou zprávu více kolektorům a relé.
 o Funkce původce, relé a kolektoru mohou být umístěny ve stejném systému.

Minimální požadované mapování transportu

 Všechny implementace této specifikace MUSÍ podporovat přenos založený na protokolu TLS, jak je popsáno v [RFC5425].
 Všechny implementace této specifikace by měly také podporovat přenos založený na UDP, jak je popsáno v [RFC5426]. Doporučuje se, aby nasazení této specifikace používala přenos založený na protokolu TLS.
Volná povaha zpráv syslogu je největší předností syslogu, ale je to také největší problém syslogu. Je velmi obtížné analyzovat protokol obsahující události z desítek různých systémů od různých dodavatelů a porozumět jim současně. Které zprávy představují jaké funkce? A které z nich představují kritické události a které pouhé informační zprávy?
Aby bylo možné se s těmito otázkami vypořádat, protokol syslog (který je definován v RFC 5424) poskytuje těmto zprávám volného tvaru speciální pole nazvaná "zařízení" a "závažnost".
(Všimněte si, že RFC 5424 je standard pro syslog, ale ne všechny implementace syslogu jsou kompatibilní s RFC 5424. Protokol syslog existuje již velmi dlouho a stále se používají některé předstandardní implementace.)

Bezpečnostní požadavky pro syslog

Zprávy syslog mohou procházet několika segmenty směrování, aby dorazily do zamýšleného kolektoru. Původce, přenos nebo přijímač nemusí důvěřovat některým zprostředkujícím sítím, protože síť je v jiné doméně zabezpečení nebo na jiné úrovni zabezpečení než původce, přenos nebo kolektor. Dalším bezpečnostním problémem je, že samotný původce, přenos nebo přijímač je v nezabezpečené síti.
Pro zabezpečení syslogu je třeba vyřešit několik hrozeb.

Primárními hrozbami jsou

  o Maškaráda. Neoprávněný odesílatel přenosu může odesílat zprávy legitimnímu příjemci přenosu nebo se neautorizovaný příjemce přenosu může pokusit oklamat legitimního odesílatele přenosu, aby mu odeslal zprávy syslog. 
 
  o Modifikace. Útočník mezi odesílatelem přenosu a příjemcem přenosu může upravit přenášenou zprávu syslog a pak ji předat příjemci přenosu. Taková úprava může způsobit, že transportní příjemce zprávu špatně pochopí nebo způsobí, že se bude chovat nežádoucím způsobem.

  o Zveřejnění. Neoprávněná entita může prozkoumat obsah zpráv syslog a získat neoprávněný přístup k informacím. Některá data ve zprávách syslogu jsou citlivá a mohou být pro útočníka užitečná, například heslo autorizovaného správce nebo uživatele.

Sekundární hrozbou je

o Modifikace toku zpráv. Útočník může odstranit jednu nebo více zpráv syslog z řady zpráv, přehrát zprávu nebo změnit pořadí doručení. Samotný protokol syslog není založen na pořadí zpráv. Událost ve zprávě syslog však může sémanticky souviset s událostmi v jiných zprávách, takže řazení zpráv může být důležité pro pochopení posloupnosti událostí.

Následující hrozby jsou pro syslog považovány za méně důležité a nejsou v tomto dokumentu řešeny:
  o Odmítnutí služby

o Analýza provozu

Použití protokolu TLS k zabezpečení protokolu Syslog

Protokol TLS je možné použít jako zabezpečený přenos, který čelí všem primárním hrozbám pro syslog popsaným výše

  o Důvěrnost proti vyzrazení obsahu zprávy.

  o Kontrola integrity pro zabránění úpravám zprávy na bázi hop-by-hop.

  o Server nebo vzájemná autentizace proti maškarádě.

Poznámka: Tento zabezpečený přenos (tj. TLS) zabezpečuje pouze přenos syslogu způsobem směrování po segmentu směrování a nezabývá se obsahem zpráv syslog. Zejména ověřená identita odesílatele přenosu (např. název subjektu v certifikátu) nemusí nutně souviset s polem HOSTNAME zprávy syslog. Pokud je vyžadováno ověření původu zprávy syslog, lze použít [SYS-SIGN].

Šifrování provozu Syslog pomocí protokolu TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Příručka k
nástroji Dell Security Management Server Syslog aSIEM https://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

Rsys Logging
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

 Uživatelská příručka k událostem a výstrahám pro úložiště PowerMax a VMAX 9.2

Referenční příručka k nástroji Solutions Enabler 9.2 CLI

Online nápověda k rozhraní Unisphere for PowerMax 9.2.0