Unisphere voor PowerMax 9.2 Remote Secure Syslog

Syslog-geschiedenis

Syslog werd in de jaren 1980 ontwikkeld door Eric Paul Allman (geboren op 2 september 1955).
Eric is een Amerikaanse computerprogrammeur die Sendmail en zijn voorloper Delivermail ontwikkelde in de late jaren 1970 en vroege jaren 1980 aan Uc Berkeley. In 1998 richtten Allman en Greg Olson samen het bedrijf Sendmail, Inc. op. De logboekindeling die wordt gebruikt door de MTA Message Transfer Agent, ook wel syslog genoemd. Syslog werd in eerste instantie alleen door Sendmail gebruikt, maar werd uiteindelijk een onofficieel standaardformaat dat door andere niet-verwante programma's werd gebruikt voor logging. Later werd dit formaat officieel gemaakt door Rfc 3164 in 2001; Het oorspronkelijke formaat is echter achterhaald door de meest recente revisie, Rfc 5424.

Internet Engineering Task Force

De Internet Engineering Task Force (IETF) is een organisatie voor open standaarden, die vrijwillige internetstandaarden ontwikkelt en promoot, in het bijzonder de standaarden die bestaan uit de Internet Protocol Suite (TCP/IP). 
Het heeft geen formeel lidmaatschapsrooster of lidmaatschapsvereisten. Alle deelnemers en managers zijn vrijwilligers, hoewel hun werk wordt gefinancierd door hun werkgevers of sponsors.

De Internet Architecture Board (IAB) houdt toezicht op de externe relaties van de IETF en de relaties met de RFC Editor. Het IAB geeft technische richting op lange termijn voor de ontwikkeling van internet. De IAB is ook medeverantwoordelijk voor het IETF Administrative Oversight Committee (IAOC), dat toezicht houdt op de IETF Administrative Support Activity (IASA), die logistieke ondersteuning biedt aan de IETF. 
Het IAB beheert ook de Internet Research Task Force (IRTF), waarmee de IETF verschillende groepsoverschrijdende relaties onderhoudt.

Stuurgroep

De Internet Engineering Steering Group (IESG) is een orgaan dat bestaat uit de voorzitter van de Internet Engineering Task Force (IETF) en gebiedsdirecteuren. Het zorgt voor de laatste technische beoordeling van internetstandaarden en is verantwoordelijk voor het dagelijkse beheer van de IETF. Het ontvangt beroepen tegen de beslissingen van de werkgroepen en de IESG neemt de beslissing om documenten in het standaardentraject voort te zetten.

Het Syslog-protocol

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

Hoe wordt syslog getransporteerd?

Er zijn twee veelgebruikte manieren om syslog-berichten te verzenden. Hoewel RFC 5424 vereist dat alle syslog-implementaties een versleuteld TLS-netwerktransport via TCP moeten ondersteunen, worden de meeste syslog-berichten nog steeds afgeleverd met behulp van de oudere UDP-methode. In de UDP-versie worden berichten eenvoudig in het gegevensgedeelte van een UDP-pakket geplaatst en via UDP-poort 514 naar de server verzonden. Elk bericht past over het algemeen in één pakket. UDP is stateless en sessieloos, dus er is geen bevestiging. Pakketten worden naar het netwerk gestuurd. Dit heeft het voor de hand liggende probleem dat elk soort netwerkprobleem de levering van het pakket kan verhinderen, in welk geval u misschien niet weet dat het netwerk niet beschikbaar is omdat het u dat niet kan vertellen. Het betekent ook dat soms belangrijke pakketten verloren kunnen gaan of beschadigd kunnen raken tijdens het transport.

Basisprincipes

 De volgende principes zijn van toepassing op syslog-communicatie:
o Het syslog-protocol biedt geen bevestiging van de aflevering van berichten. Hoewel sommige transporten statusinformatie kunnen opleveren, is syslog conceptueel gezien een puur simplex-communicatieprotocol.
 o Initiators en relais kunnen worden geconfigureerd om hetzelfde bericht naar meerdere verzamelaars en relais te sturen.
 o De functionaliteit van de initiator, het relais en de collector kan zich op hetzelfde systeem bevinden.

Minimaal vereiste transporttoewijzing

 Alle implementaties van deze specificatie MOETEN een op TLS gebaseerd transport ondersteunen zoals beschreven in [RFC5425].
 Alle uitvoeringen van deze specificatie MOETEN ook een op UDP gebaseerd transport ondersteunen, zoals beschreven in [RFC5426]. Het wordt AANBEVOLEN dat implementaties van deze specificatie gebruik maken van op TLS gebaseerd transport.
Het vrije karakter van syslog-berichten is de grootste kracht van syslog, maar het is ook het grootste probleem van syslog. Het is erg moeilijk om een logboek te ontleden met gebeurtenissen van tientallen verschillende systemen van verschillende leveranciers en ze tegelijkertijd te begrijpen. Welke berichten vertegenwoordigen welke functies? En welke vertegenwoordigen kritieke gebeurtenissen versus louter informatieve berichten?
Om deze vragen te beantwoorden, voorziet het syslog-protocol (dat is gedefinieerd in RFC 5424) deze vrije berichten van speciale velden genaamd "faciliteit" en "ernst".
(Merk op dat RFC 5424 de standaard is voor syslog, maar niet alle syslog-implementaties zijn RFC 5424-compatibel. Het syslog-protocol bestaat al heel lang en er zijn nog steeds enkele pre-standaard implementaties in gebruik.)

Beveiligingsvereisten voor Syslog

Syslog-berichten kunnen meerdere hops doorvoeren om bij de beoogde verzamelaar aan te komen. Sommige intermediaire netwerken worden mogelijk niet vertrouwd door de initiator, het relais of de ontvanger omdat het netwerk zich in een ander beveiligingsdomein of op een ander beveiligingsniveau bevindt dan de initiator, het relais of de verzamelaar. Een ander beveiligingsprobleem is dat de afzender, het relais of de ontvanger zelf zich in een onveilig netwerk bevindt.
Er zijn verschillende bedreigingen die moeten worden aangepakt voor de beveiliging van syslog.

De belangrijkste bedreigingen zijn:

  o Maskerade. Een niet-geautoriseerde transportverzender kan berichten verzenden naar een legitieme transportontvanger, of een niet-geautoriseerde transportontvanger kan proberen een legitieme transportafzender te misleiden om syslog-berichten naar hem te verzenden. 
 
  o Wijziging. Een aanvaller tussen de transportverzender en de transportontvanger kan een in-transit syslog-bericht wijzigen en het bericht vervolgens doorsturen naar de transportontvanger. Een dergelijke wijziging kan ertoe leiden dat de ontvanger van het vervoer het bericht verkeerd begrijpt of zich op een ongewenste manier gedraagt.

  o Openbaarmaking. Een onbevoegde entiteit kan de inhoud van de syslog-berichten onderzoeken en ongeoorloofde toegang krijgen tot de informatie. Sommige gegevens in syslog-berichten zijn gevoelig en kunnen nuttig zijn voor een aanvaller, zoals het wachtwoord van een geautoriseerde beheerder of gebruiker.

De secundaire bedreiging is

o Wijziging van de berichtenstroom. Een aanvaller kan een of meer syslog-berichten uit een reeks berichten verwijderen, een bericht opnieuw afspelen of de bezorgingsvolgorde wijzigen. Het syslog-protocol zelf is niet gebaseerd op de volgorde van de berichten. Een gebeurtenis in een syslog-bericht kan echter semantisch verband houden met gebeurtenissen in andere berichten, dus de volgorde van berichten kan belangrijk zijn voor het begrijpen van een opeenvolging van gebeurtenissen.

De volgende bedreigingen worden van minder belang geacht voor syslog en worden niet behandeld in dit document:
  o Denial of Service

o Verkeersanalyse

TLS gebruiken om Syslog te beveiligen

TLS kan worden gebruikt als een veilig transport om alle primaire bedreigingen voor syslog die hierboven zijn beschreven, tegen te gaan

  o Vertrouwelijkheid om openbaarmaking van de inhoud van het bericht tegen te gaan.

  o Integriteitscontrole om wijzigingen in een bericht hop-by-hop tegen te gaan.

  o Server of wederzijdse authenticatie om maskerade tegen te gaan.

Opmerking: Dit beveiligde transport (d.w.z. TLS) beveiligt syslog-transport alleen op een hop-by-hop-manier en houdt zich niet bezig met de inhoud van syslog-berichten. Met name de geverifieerde identiteit van de afzender van het transport (bijv. de naam van het onderwerp in het certificaat) is niet noodzakelijkerwijs gerelateerd aan het veld HOSTNAME van het syslog-bericht. Wanneer verificatie van de oorsprong van syslog-berichten vereist is, kan [SYS-SIGN] worden gebruikt.

Syslog-verkeer versleutelen met TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Dell Security Management Server Syslog- en SIEM-handleiding
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

 Gebeurtenissen en waarschuwingen voor PowerMax en VMAX 9.2 Gebruikershandleiding

Solutions Enabler 9.2 CLI-naslaggids

Unisphere voor PowerMax 9.2.0 Online Help