Unisphere for PowerMax 9.2 Remote Secure Syslog

Syslog-historikk

Syslog ble utviklet på 1980-tallet av Eric Paul Allman (født 2. september 1955).
Eric er en amerikansk dataprogrammerer som utviklet Sendmail og dens forløper Delivermail på slutten av 1970-tallet og begynnelsen av 1980-tallet ved Uc Berkeley. I 1998 grunnla Allman og Greg Olson selskapet Sendmail, Inc. Loggformatet som brukes av mta Message Transfer Agent, kjent som syslog. Syslog ble først brukt utelukkende av Sendmail, men ble etter hvert et uoffisielt standardformat som ble brukt av andre ikke-relaterte programmer for logging. Senere ble dette formatet gjort offisielt av RFC 3164 i 2001; Det opprinnelige formatet har imidlertid blitt foreldet av den siste revisjonen, RFC 5424.

Internet Engineering Task Force

Internet Engineering Task Force (IETF) er en åpen standardiseringsorganisasjon som utvikler og fremmer frivillige Internett-standarder, spesielt standardene som består av Internet Protocol Suite (TCP/IP). 
Den har ingen formell medlemsliste eller medlemskrav. Alle deltakere og ledere er frivillige, selv om deres arbeid er finansiert av deres arbeidsgivere eller sponsorer.

Internet Architecture Board (IAB) overvåker IETFs eksterne relasjoner og relasjoner med RFC-redaktøren. IAB gir langsiktig teknisk retning for Internett-utvikling. IAB er også medansvarlig for IETF Administrative Oversight Committee (IAOC), som fører tilsyn med IETF Administrative Support Activity (IASA), som gir logistikk, så videre støtte til IETF. 
IAB administrerer også Internet Research Task Force (IRTF), som IETF har flere forbindelser med på tvers av grupper.

Styringsgruppe

Internet Engineering Steering Group (IESG) er et organ som består av IETF-lederen (Internet Engineering Task Force) og områdedirektører. Det gir den endelige tekniske gjennomgangen av Internett-standarder og er ansvarlig for den daglige ledelsen av IETF. Den mottar klager på arbeidsgruppens beslutninger, og IESG tar beslutningen om å 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?

Det er to vanlige måter å sende syslog-meldinger på. Selv om RFC 5424 krever at alle syslog-implementeringer må støtte en kryptert TLS-nettverkstransport over TCP, leveres de fleste syslog-meldinger fortsatt med den eldre UDP-metoden. I UDP-versjonen blir meldinger ganske enkelt satt inn i datadelen av en UDP-pakke og sendt til serveren over UDP-port 514. Hver melding vil vanligvis passe inn i en enkelt pakke. UDP er statsløs og sesjonsløs, så det er ingen anerkjennelse. Pakker sendes inn i nettverket. Dette har det åpenbare problemet at enhver form for nettverksproblem kan forhindre levering av pakken, i så fall vet du kanskje ikke at nettverket er nede fordi det ikke kan fortelle deg. Det betyr også at noen ganger viktige pakker kan gå tapt eller bli skadet under transport.

Grunnleggende prinsipper

 Følgende prinsipper gjelder for syslog-kommunikasjon:
o Syslog-protokollen gir ikke bekreftelse på levering av melding. Selv om noen transporter kan gi statusinformasjon, er syslog konseptuelt en ren simpleks kommunikasjonsprotokoll.
 o Opphavsmenn og releer kan konfigureres til å sende samme melding til flere samlere og releer.
 o Opphavs-, relé- og samlerfunksjonalitet kan ligge på samme system.

Minimumskrav til transportkartlegging

 Alle implementeringer av denne spesifikasjonen MÅ støtte en TLS-basert transport som beskrevet i [RFC5425].
 Alle implementeringer av denne spesifikasjonen BØR også støtte en UDP-basert transport som beskrevet i [RFC5426]. Det anbefales at distribusjoner av denne spesifikasjonen bruker TLS-basert transport.
Den frie formen til syslog-meldinger er syslogs største styrke, men det er også syslogs største problem. Det er veldig vanskelig å analysere gjennom en logg inkludert hendelser fra dusinvis av forskjellige systemer fra forskjellige leverandører og gi mening om dem samtidig. Hvilke meldinger representerer hvilke funksjoner? Og hvilke representerer kritiske hendelser versus bare informasjonsmeldinger?
For å håndtere disse spørsmålene gir syslog-protokollen (som er definert i RFC 5424) disse frihåndsmeldingene spesielle felt kalt "anlegg" og "alvorlighetsgrad".
(Merk at RFC 5424 er standarden for syslog, men ikke alle syslog-implementeringer er RFC 5424-kompatible. Syslog-protokollen har eksistert i svært lang tid, og det er noen forhåndsstandardimplementeringer som fortsatt er i bruk.)

Sikkerhetskrav for Syslog

Syslog-meldinger kan sende flere humler for å komme frem til den tiltenkte samleren. Noen mellomliggende nettverk er kanskje ikke klarert av avsenderen, reléet eller mottakeren fordi nettverket er i et annet sikkerhetsdomene eller på et annet sikkerhetsnivå enn opphavsmannen, reléet eller samleren. Et annet sikkerhetsproblem er at opphavsmannen, reléet eller mottakeren selv er i et usikkert nettverk.
Det er flere trusler som må håndteres for syslog-sikkerhet.

De primære truslene er:

  o Maskerade. En uautorisert transportavsender kan sende meldinger til en legitim transportmottaker, eller en uautorisert transportmottaker kan prøve å lure en legitim transportavsender til å sende syslog-meldinger til den. 
 
  o Endring. En angriper mellom avsenderen og transportmottakeren kan endre en syslog-melding under transport og deretter videresende meldingen til transportmottakeren. Slike endringer kan få transportmottakeren til å misforstå meldingen eller føre til at den oppfører seg på uønskede måter.

  o Avsløring. En uautorisert enhet kan undersøke innholdet i syslog-meldingene, og få uautorisert tilgang til informasjonen. Noen data i syslog-meldinger er sensitive og kan være nyttige for en angriper, for eksempel passordet til en autorisert administrator eller bruker.

Den sekundære trusselen er

o Endring av meldingsstrøm. En angriper kan slette én eller flere Syslog-meldinger fra en serie meldinger, spille av en melding på nytt eller endre leveringssekvensen. Selve syslog-protokollen er ikke basert på meldingsrekkefølge. En hendelse i en syslog-melding kan imidlertid forholde seg semantisk til hendelser i andre meldinger, så meldingsrekkefølge kan være viktig for å forstå et hendelsesforløp.

Følgende trusler anses å være av mindre betydning for syslog, og er ikke adressert i dette dokumentet:
  o Tjenestenekt

o Trafikkanalyse

Bruke TLS til å sikre syslog

TLS kan brukes som en sikker transport for å motvirke alle de primære truslene mot syslog som er beskrevet ovenfor

  o Konfidensialitet for å motvirke avsløring av meldingsinnholdet.

  o Integritetskontroll for å motvirke endringer i en melding på hop-by-hop-basis.

  o Server eller gjensidig godkjenning for å motvirke maskerade.

Merk: Denne sikre transporten (dvs. TLS) sikrer bare syslog-transport på en hop-by-hop-måte og er ikke opptatt av innholdet i syslog-meldinger. Spesielt er den autentiserte identiteten til transportavsenderen (f.eks. emnenavn i sertifikatet) ikke nødvendigvis knyttet til HOSTNAME-feltet i syslog-meldingen. Når godkjenning av syslog-meldingens opprinnelse er nødvendig, kan [SYS-SIGN] brukes.

Kryptere syslog-trafikk med TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

System- og SIEM-veiledning
for Dell Security Management Serverhttps://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

 Brukerveiledning for hendelser og varsler for PowerMax og VMAX 9.2

Referanseveiledning for Solutions Enabler 9.2 CLI

Elektronisk hjelp for Unisphere for PowerMax 9.2.0