Unisphere til PowerMax 9.2 Remote Secure Syslog

Syslog-historik

Syslog blev udviklet i 1980'erne af Eric Paul Allman (født 2. september 1955).
Eric er en amerikansk computerprogrammør, der udviklede sendmail og dens forløber Delivermail i slutningen af 1970'erne og begyndelsen af 1980'erne på UC Berkeley. I 1998 grundlagde Allman og Greg Olson virksomheden Sendmail, Inc. Logføringsformatet, der bruges af MTA Message Transfer Agent, kendt som Syslog. Syslog blev først brugt udelukkende af sendmail, men blev til sidst et uofficielt standardformat, der blev brugt af andre ikke-relaterede programmer til logning. Senere blev dette format officielt af Rfc 3164 i 2001; Det originale format er imidlertid blevet forældet ved den seneste revision, RFC 5424.

Internet Engineering Task Force

Internet Engineering Task Force (IETF) er en åben standardiseringsorganisation, der udvikler og fremmer frivillige internetstandarder, især de standarder, der består af Internet Protocol Suite (TCP / IP). 
Det har ingen formel medlemsliste eller medlemskrav. Alle deltagere og ledere er frivillige, selvom deres arbejde finansieres af deres arbejdsgivere eller sponsorer.

Internet Architecture Board (IAB) fører tilsyn med IETF's eksterne relationer og forbindelser med RFC Editor. IAB giver langsigtet teknisk retning for internetudvikling. IAB er også medansvarlig for IETF's Administrative Oversight Committee (IAOC), som fører tilsyn med IETF's administrative støtteaktivitet (IASA), som yder logistisk støtte osv. til IETF. 
IAB forvalter også Internet Research Task Force (IRTF), som IETF har flere relationer på tværs af grupper.

Styringsgruppe

Internet Engineering Steering Group (IESG) er et organ, der består af Internet Engineering Task Force (IETF) formand og områdedirektører. Det giver den endelige tekniske gennemgang af internetstandarder og er ansvarlig for den daglige ledelse af IETF. Det modtager appeller af arbejdsgruppernes afgørelser, og IESG træffer beslutning om at gå videre med dokumenter i standardsporet.

Syslog-protokollen

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

Hvordan transporteres syslog?

Der er to almindelige måder at sende syslog-meddelelser på. Selvom RFC 5424 kræver, at alle syslog-implementeringer skal understøtte en krypteret TLS-netværkstransport over TCP, leveres de fleste syslog-meddelelser stadig ved hjælp af den ældre UDP-metode. I UDP-versionen sættes meddelelser simpelthen i datadelen af en UDP-pakke og sendes til serveren via UDP-port 514. Hver meddelelse passer generelt ind i en enkelt pakke. UDP er statsløs og sessionsløs, så der er ingen anerkendelse. Pakker sendes til netværket. Dette har det åbenlyse problem, at enhver form for netværksproblem kan forhindre levering af pakken, i hvilket tilfælde du måske ikke ved, at netværket er nede, fordi det ikke kan fortælle dig. Det betyder også, at vigtige pakker nogle gange kan gå tabt eller blive beskadiget under transporten.

Grundprincipper

 Følgende principper gælder for syslog-kommunikation:
o Syslog-protokollen anerkender ikke leveringen af meddelelser. Selvom nogle transporter kan give statusoplysninger, er syslog konceptuelt en ren simplekskommunikationsprotokol.
 o Ophavsmænd og relæer kan konfigureres til at sende den samme besked til flere samlere og relæer.
 o Ophavsmands-, relæ- og kollektorfunktionaliteten kan være placeret på det samme system.

Mindste påkrævede transportkortlægning

 Alle implementeringer af denne specifikation SKAL understøtte en TLS-baseret transport som beskrevet i [RFC5425].
 Alle implementeringer af denne specifikation BØR også understøtte en UDP-baseret transport som beskrevet i [RFC5426]. Det ANBEFALES, at implementeringer af denne specifikation benytter den TLS-baserede transport.
Den frie form af syslog-meddelelser er syslogs største styrke, men det er også syslogs største problem. Det er meget vanskeligt at analysere gennem en log, der inkluderer hændelser fra snesevis af forskellige systemer fra forskellige leverandører og give mening om dem samtidigt. Hvilke meddelelser repræsenterer hvilke funktioner? Og hvilke repræsenterer kritiske begivenheder versus blot informative meddelelser?
For at håndtere disse spørgsmål giver syslog-protokollen (som er defineret i RFC 5424) disse friformsmeddelelser med specielle felter kaldet "facilitet" og "alvorsgrad".
(Bemærk, at RFC 5424 er standarden for syslog, men ikke alle syslog-implementeringer er RFC 5424-kompatible. Syslog-protokollen har eksisteret i meget lang tid, og der er nogle implementeringer før standard stadig i brug.)

Sikkerhedskrav til Syslog

Syslog-meddelelser kan passere flere humle for at nå frem til den tilsigtede samler. Nogle mellemliggende netværk har opretteren, relæet eller modtageren muligvis ikke tillid til, fordi netværket er i et andet sikkerhedsdomæne eller på et andet sikkerhedsniveau end afsenderen, relæet eller indsamleren. En anden sikkerhedsbekymring er, at selve ophavsmanden, relæet eller modtageren er i et usikkert netværk.
Der er flere trusler, der skal håndteres af syslog-sikkerhed.

De primære trusler er

  o Maskerade. En uautoriseret transportafsender kan sende meddelelser til en legitim transportmodtager, eller en uautoriseret transportmodtager kan forsøge at narre en legitim transportafsender til at sende syslog-meddelelser til den. 
 
  o Ændring. En hacker mellem transportafsenderen og transportmodtageren kan ændre en syslog-meddelelse under overførslen og derefter videresende meddelelsen til transportmodtageren. En sådan ændring kan få transportmodtageren til at misforstå meddelelsen eller få den til at opføre sig på uønskede måder.

  o Offentliggørelse. En uautoriseret enhed kan undersøge indholdet af syslog-meddelelserne og få uautoriseret adgang til oplysningerne. Nogle data i syslog-meddelelser er følsomme og kan være nyttige for en hacker, f.eks. adgangskoden til en autoriseret administrator eller bruger.

Den sekundære trussel er

o Ændring af meddelelsesstrøm. En hacker kan slette en eller flere syslog-meddelelser fra en række meddelelser, afspille en meddelelse igen eller ændre leveringssekvensen. Selve syslog-protokollen er ikke baseret på meddelelsesrækkefølge. En hændelse i en syslog-meddelelse kan dog relatere semantisk til hændelser i andre meddelelser, så meddelelsesrækkefølge kan være vigtig for at forstå en sekvens af hændelser.

Følgende trusler anses for at være af mindre betydning for syslog og behandles ikke i dette dokument:
  o Denial of Service

o Trafikanalyse

Brug af TLS til at sikre Syslog

TLS kan bruges som en sikker transport til at imødegå alle de primære trusler mod syslog, der er beskrevet ovenfor

  o Fortrolighed for at imødegå videregivelse af meddelelsens indhold.

  o Integritetskontrol for at imødegå ændringer af en meddelelse på hop-for-hop-basis.

  o Server eller gensidig godkendelse for at imødegå maskerade.

Bemærk: Denne sikre transport (dvs. TLS) sikrer kun syslog-transport på en hop-by-hop-måde og beskæftiger sig ikke med indholdet af syslog-meddelelser. Navnlig er transportafsenderens autentificerede identitet (f.eks. emnenavn i certifikatet) ikke nødvendigvis relateret til feltet HOSTNAME i syslog-meddelelsen. Når godkendelse af syslog-meddelelsens oprindelse er påkrævet, kan [SYS-SIGN] bruges.

Kryptering af syslogtrafik med TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Vejledning
til Dell Security Management Server Syslog og SIEMhttps://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

Rsys-logføring
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

 Hændelser og advarsler for PowerMax og VMAX 9.2 – Brugervejledning

Solutions Enabler 9.2 CLI-referencevejledning

Onlinehjælp til Unisphere til PowerMax 9.2.0