Unisphere for PowerMax 9.2 Remote Secure Syslog
Résumé: Unisphere for PowerMax Secure Syslog, wie und wann es verwendet werden sollte. Design und Branchenstandard
Symptômes
Syslog-Verlauf
Syslog wurde in den 1980er Jahren von Eric Paul Allman (geboren am 2. September 1955) entwickelt.
Eric ist ein amerikanischer Computerprogrammierer, der in den späten 1970er und frühen 1980er Jahren an der Uc Berkeley Sendmail und seinen Vorläufer Delivermail entwickelte. 1998 gründeten Allman und Greg Olson gemeinsam das Unternehmen Sendmail, Inc. Das Protokollierungsformat, das vom MTA Message Transfer Agent verwendet wird, als Syslog bezeichnet. Syslog wurde zunächst nur von Sendmail verwendet, wurde aber schließlich zu einem inoffiziellen Standardformat, das von anderen, nicht verwandten Programmen für die Protokollierung verwendet wurde. Später wurde dieses Format durch Rfc 3164 im Jahr 2001 offiziell gemacht; Das ursprüngliche Format wurde jedoch durch die neueste Überarbeitung, RFC 5424, obsolet gemacht.
Taskforce Internettechnik
Die Internet Engineering Task Force (IETF) ist eine Organisation für offene Standards, die freiwillige Internetstandards entwickelt und fördert, insbesondere die Standards, die aus der Internet Protocol Suite (TCP/IP) bestehen.
Es gibt keine formelle Mitgliederliste oder Mitgliedschaftsanforderungen. Alle Teilnehmer und Manager sind ehrenamtlich tätig, ihre Arbeit wird jedoch von ihren Arbeitgebern oder Sponsoren finanziert.
Das Internet Architecture Board (IAB) überwacht die externen Beziehungen der IETF und die Beziehungen zum RFC-Editor. Das IAB gibt die langfristige technische Richtung für die Entwicklung des Internets vor. Das IAB ist auch mitverantwortlich für das IETF Administrative Oversight Committee (IAOC), das die IETF Administrative Support Activity (IASA) beaufsichtigt, die logistische usw. Unterstützung für die IETF bietet.
Das IAB leitet auch die Internet Research Task Force (IRTF), mit der die IETF mehrere gruppenübergreifende Beziehungen unterhält.
Lenkungsgruppe
Die Internet Engineering Steering Group (IESG) ist ein Gremium, das sich aus dem Vorsitzenden der Internet Engineering Task Force (IETF) und den Bereichsleitern zusammensetzt. Sie bietet die abschließende technische Überprüfung der Internetstandards und ist für die tägliche Verwaltung der IETF verantwortlich. Sie nimmt Einsprüche gegen die Entscheidungen der Arbeitsgruppen entgegen, und die IESG trifft die Entscheidung, Dokumente im Normen-Track voranzubringen.
Das Syslog-Protokoll
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) +------------------------+ +----------------------+ ^ ^ | | -----------------------------
Wie wird Syslog transportiert?
Es gibt zwei gängige Methoden zum Senden von Syslog-Meldungen. Obwohl RFC 5424 verlangt, dass alle Syslog-Implementierungen einen verschlüsselten TLS-Netzwerktransport über TCP unterstützen müssen, werden die meisten Syslog-Meldungen weiterhin über die ältere UDP-Methode zugestellt. In der UDP-Version werden Nachrichten einfach in den Datenteil eines UDP-Pakets gepackt und über den UDP-Port 514 an den Server gesendet. Jede Nachricht passt in der Regel in ein einzelnes Paket. UDP ist zustands- und sitzungslos, sodass es keine Bestätigung gibt. Pakete werden in das Netzwerk gesendet. Dies hat das offensichtliche Problem, dass jede Art von Netzwerkproblem die Zustellung des Pakets verhindern kann. In diesem Fall wissen Sie möglicherweise nicht, dass das Netzwerk ausgefallen ist, weil es Ihnen nichts sagen kann. Das bedeutet auch, dass manchmal wichtige Pakete während des Transports verloren gehen oder beschädigt werden können.
Grundprinzipien
Die folgenden Prinzipien gelten für die Syslog-Kommunikation:
o Das Syslog-Protokoll bietet keine Bestätigung der Nachrichtenübermittlung. Obwohl einige Transporte Statusinformationen bereitstellen können, ist syslog konzeptionell ein reines Simplex-Kommunikationsprotokoll.
o Absender und Relais können so konfiguriert werden, dass sie dieselbe Nachricht an mehrere Collectors und Relays senden.
o Die Funktionen für Absender, Relais und Sammler können sich auf demselben System befinden.
Minimal erforderliche Transportzuordnung
Alle Implementierungen dieser Spezifikation MÜSSEN eine TLS-basierte Übertragung unterstützen, wie in [RFC5425 beschrieben.
Alle Implementierungen dieser Spezifikation SOLLTEN auch einen UDP-basierten Transport unterstützen, wie in [RFC5426 beschrieben. Es wird EMPFOHLEN, für Bereitstellungen dieser Spezifikation die TLS-basierte Übertragung zu verwenden.
Die freie Form von Syslog-Meldungen ist die größte Stärke von Syslog, aber auch das größte Problem von Syslog. Es ist sehr schwierig, ein Protokoll mit Ereignissen von Dutzenden verschiedener Systeme von verschiedenen Anbietern zu analysieren und sie gleichzeitig zu verstehen. Welche Meldungen stellen welche Funktionen dar? Und welche stellen kritische Ereignisse dar und welche stellen rein informative Botschaften dar?
Zur Behebung dieser Fragen stellt das Syslog-Protokoll (das in RFC 5424 definiert ist) diese Freiformmeldungen mit speziellen Feldern namens "Einrichtung" und "Schweregrad" bereit.
(Beachten Sie, dass RFC 5424 der Standard für Syslog ist, aber nicht alle Syslog-Implementierungen RFC 5424-konform sind. Das Syslog-Protokoll gibt es schon sehr lange, und es gibt einige vorab standardmäßige Implementierungen, die immer noch verwendet werden.)
Sicherheitsanforderungen für Syslog
Syslog-Meldungen können mehrere Hops durchlaufen, bis sie zum gewünschten Collector gelangen. Einige zwischengeschaltete Netzwerke werden vom Absender, Relay oder Empfänger möglicherweise nicht als vertrauenswürdig eingestuft, da sich das Netzwerk in einer anderen Sicherheitsdomäne oder auf einer anderen Sicherheitsstufe befindet als der Absender, das Relay oder der Collector. Ein weiteres Sicherheitsproblem besteht darin, dass sich der Absender, das Relais oder der Empfänger selbst in einem unsicheren Netzwerk befindet.
Es gibt mehrere Bedrohungen, die für die Syslog-Sicherheit bekämpft werden müssen.
Die primären Bedrohungen sind:
o Maskerade. Ein nicht autorisierter Transportabsender kann Nachrichten an einen legitimen Transportempfänger senden, oder ein nicht autorisierter Transportempfänger kann versuchen, einen legitimen Transportabsender dazu zu verleiten, Syslog-Meldungen an ihn zu senden.
o Änderung. Ein Angreifer zwischen dem Transportsender und dem Transportempfänger kann eine Syslog-Nachricht während der Übertragung ändern und die Nachricht dann an den Transportempfänger weiterleiten. Eine solche Modifikation kann dazu führen, dass der Transportempfänger die Nachricht missversteht oder sich unerwünscht verhält.
o Offenlegung. Eine nicht autorisierte Entität kann den Inhalt der Syslog-Meldungen untersuchen und unbefugten Zugriff auf die Informationen erhalten. Einige Daten in Syslog-Meldungen sind vertraulich und können für einen Angreifer nützlich sein, z. B. das Kennwort eines autorisierten Administrators oder Nutzers.
Die sekundäre Bedrohung ist
o Änderung des Nachrichtenstroms. Ein Angreifer kann eine oder mehrere Syslog-Meldungen aus einer Reihe von Meldungen löschen, eine Meldung wiedergeben oder die Übermittlungsreihenfolge ändern. Das Syslog-Protokoll selbst basiert nicht auf der Meldungsreihenfolge. Ein Ereignis in einer Syslog-Meldung kann jedoch semantisch mit Ereignissen in anderen Meldungen zusammenhängen, sodass die Reihenfolge der Meldungen wichtig sein kann, um eine Abfolge von Ereignissen zu verstehen.
Die folgenden Bedrohungen werden für Syslog als weniger wichtig erachtet und in diesem Dokument nicht behandelt:
o Denial-of-Service
o Traffic-Analyse
Verwenden von TLS zum Sichern von Syslog
TLS kann als sichere Übertragungsmethode verwendet werden, um allen oben beschriebenen primären Bedrohungen für Syslog entgegenzuwirken.
o Vertraulichkeit, um der Offenlegung des Nachrichteninhalts entgegenzuwirken.
o Integritätsprüfung, um Änderungen an einer Nachricht auf Hop-by-Hop-Basis entgegenzuwirken.
o Server- oder gegenseitige Authentifizierung, um der Maskerade entgegenzuwirken.
Hinweis: Diese sichere Übertragung (d. h. TLS) sichert nur den Syslog-Transport Hop-by-Hop und ist nicht vom Inhalt von Syslog-Meldungen betroffen. Insbesondere ist die authentifizierte Identität des Transportabsenders (z. B. Antragstellername im Zertifikat) nicht notwendigerweise mit dem Feld HOSTNAME der Syslog-Meldung verknüpft. Wenn eine Authentifizierung des Ursprungs der Syslog-Meldung erforderlich ist, kann [SYS-SIGN] verwendet werden.
Cause
Die obige Abbildung zeigt den Bildschirm in Unisphere for PowerMax zur Konfiguration von Secure Syslog.