Unisphere för PowerMax 9.2 Säker Syslog på distans

Syslog-historik

Syslog utvecklades på 1980-talet av Eric Paul Allman (född 2 september 1955).
Eric är en amerikansk datorprogrammerare som utvecklade Sendmail och dess föregångare Delivermail i slutet av 1970-talet och början av 1980-talet vid UC Berkeley. År 1998 grundade Allman och Greg Olson tillsammans företaget Sendmail, Inc. Loggningsformatet som används av MTA-meddelandeöverföringsagenten, som kallas syslog. Syslog användes till en början enbart av Sendmail, men blev så småningom ett inofficiellt standardformat som användes av andra orelaterade program för loggning. Senare gjordes detta format officiellt av Rfc 3164 2001; Det ursprungliga formatet har dock blivit föråldrat genom den senaste versionen, Rfc 5424.

Arbetsgruppen för internetteknik

Internet Engineering Task Force (IETF) är en organisation för öppna standarder som utvecklar och främjar frivilliga Internetstandarder, särskilt de standarder som består av Internet Protocol Suite (TCP/IP). 
Den har ingen formell medlemslista eller medlemskrav. Alla deltagare och chefer är volontärer, men deras arbete finansieras av deras arbetsgivare eller sponsorer.

Internet Architecture Board (IAB) övervakar IETF:s externa relationer och relationer med RFC-redaktören. IAB ger långsiktig teknisk vägledning för Internetutveckling. IAB är också gemensamt ansvarig för IETF:s administrativa tillsynskommitté (IAOC), som övervakar IETF:s administrativa stödverksamhet (IASA), som tillhandahåller logistiskt och så vidare stöd till IETF. 
IAB leder också Internet Research Task Force (IRTF), med vilken IETF har flera tvärgruppsförbindelser.

Styrgrupp

Internet Engineering Steering Group (IESG) är ett organ som består av ordföranden för Internet Engineering Task Force (IETF) och områdeschefer. Den tillhandahåller den slutliga tekniska granskningen av Internetstandarder och ansvarar för den dagliga förvaltningen av IETF. Den tar emot överklaganden av arbetsgruppernas beslut, och IESG fattar beslut om att gå vidare med dokument i standardspåret.

Syslog-protokollet

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

Hur transporteras syslog?

Det finns två vanliga sätt att skicka syslog-meddelanden. Även om RFC 5424 kräver att alla syslog-implementeringar måste ha stöd för en krypterad TLS-nätverkstransport via TCP, levereras de flesta syslog-meddelanden fortfarande med den äldre UDP-metoden. I UDP-versionen placeras meddelanden helt enkelt i datadelen av ett UDP-paket och skickas till servern via UDP-port 514. Varje meddelande får vanligtvis plats i ett enda paket. UDP är tillståndslöst och sessionslöst, så det finns ingen bekräftelse. Paket skickas till nätverket. Detta har det uppenbara problemet att alla typer av nätverksproblem kan förhindra leverans av paketet, i vilket fall du kanske inte vet att nätverket är nere eftersom det inte kan berätta det för dig. Det innebär också att viktiga paket ibland kan försvinna eller skadas under transporten.

Grundprinciper

 Följande principer gäller för syslog-kommunikation:
o Syslog-protokollet ger inte bekräftelse på meddelandeleverans. Även om vissa transporter kan ge statusinformation är syslog konceptuellt ett rent simplex-kommunikationsprotokoll.
 o Upphovsmän och reläer kan konfigureras för att skicka samma meddelande till flera insamlare och reläer.
 o Originator-, relä- och kollektorfunktioner kan finnas på samma system.

Minsta nödvändiga transportmappning

 Alla implementeringar av den här specifikationen MÅSTE ha stöd för en TLS-baserad transport enligt beskrivningen i [RFC5425].
 Alla implementeringar av den här specifikationen BÖR också stödja en UDP-baserad transport enligt beskrivningen i [RFC5426]. Det rekommenderas att distributioner av den här specifikationen använder TLS-baserad transport.
Den fria karaktären hos syslog-meddelanden är syslogs största styrka, men det är också syslogs största problem. Det är mycket svårt att analysera en logg som innehåller händelser från dussintals olika system från olika leverantörer och förstå dem samtidigt. Vilka meddelanden representerar vilka funktioner? Och vilka representerar kritiska händelser kontra bara informationsmeddelanden?
För att hantera dessa frågor tillhandahåller syslog-protokollet (som definieras i RFC 5424) dessa friformsmeddelanden med specialfält som kallas "anläggning" och "allvarlighetsgrad".
(Observera att RFC 5424 är standard för syslog, men alla syslog-implementeringar är inte RFC 5424-kompatibla. Syslog-protokollet har funnits under en mycket lång tid och det finns några förstandardimplementeringar som fortfarande används.)

Säkerhetskrav för Syslog

Syslog-meddelanden kan överföra flera hopp för att komma fram till den avsedda insamlaren. Vissa mellanliggande nätverk kanske inte är betrodda av avsändaren, reläet eller mottagaren eftersom nätverket finns i en annan säkerhetsdomän eller på en annan säkerhetsnivå än avsändaren, reläet eller insamlaren. Ett annat säkerhetsproblem är att avsändaren, reläet eller mottagaren själv befinner sig i ett osäkert nätverk.
Det finns flera hot att ta itu med för syslog-säkerhet.

De främsta hoten är

  o Maskerad. En obehörig transportavsändare kan skicka meddelanden till en legitim transportmottagare, eller så kan en obehörig transportmottagare försöka lura en legitim transportavsändare att skicka syslog-meddelanden till den. 
 
  o Modifiering. En angripare mellan transportavsändaren och transportmottagaren kan ändra ett syslog-meddelande under överföring och sedan vidarebefordra meddelandet till transportmottagaren. En sådan ändring kan leda till att transportmottagaren missförstår meddelandet eller får det att bete sig på ett oönskat sätt.

  o Utlämnande av uppgifter. En obehörig entitet kan undersöka innehållet i syslog-meddelandena och få obehörig åtkomst till informationen. Vissa data i syslog-meddelanden är känsliga och kan vara användbara för en angripare, till exempel lösenordet för en behörig administratör eller användare.

Det sekundära hotet är

o Modifiering av meddelandeström. En angripare kan ta bort ett eller flera syslog-meddelanden från en serie meddelanden, spela upp ett meddelande igen eller ändra leveranssekvensen. Själva syslog-protokollet baseras inte på meddelandeordning. En händelse i ett syslog-meddelande kan dock relatera semantiskt till händelser i andra meddelanden, så meddelandeordningen kan vara viktig för att förstå en sekvens av händelser.

Följande hot anses vara av mindre betydelse för Syslog och tas inte upp i det här dokumentet:
  o Funktionsförlust

o Trafikanalys

Använda TLS för att skydda Syslog

TLS kan användas som en säker transport för att motverka alla primära hot mot syslog som beskrivs ovan

  o Konfidentialitet för att motverka utlämnande av meddelandets innehåll.

  o Integritetskontroll för att motverka ändringar av ett meddelande på hopp-för-hopp-basis.

  o Server eller ömsesidig autentisering för att motverka maskerad.

Obs! Den här säkra transporten (d.v.s. TLS) skyddar endast syslog-transport på ett hop-by-hop-sätt och berör inte innehållet i syslog-meddelanden. I synnerhet är den autentiserade identiteten för transportavsändaren (t.ex. ämnesnamnet i certifikatet) inte nödvändigtvis relaterad till fältet VÄRDNAMN i syslog-meddelandet. När autentisering av syslog-meddelandets ursprung krävs kan [SYS-SIGN] användas.

Kryptera Syslog-trafik med TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Syslog- och SIEM-manual
för Dell Security Management Serverhttps://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

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

 Händelser och varningar för PowerMax och VMAX 9.2 Användarhandbok

Solutions Enabler 9.2 CLI Referensmanual

Onlinehjälp för Unisphere för PowerMax 9.2.0