11. Sicherheitsüberlegungen

11.1. Empfohlene Praktiken

Dieser Abschnitt beschreibt Praktiken, die zum sicheren und effektiven Betrieb der in diesem Memo definierten Mechanismen beitragen.

• Eine SNMP-Engine muss SNMP-Antwortnachrichten verwerfen, die keiner aktuell ausstehenden Anforderungsnachricht entsprechen. Es liegt in der Verantwortung des Message Processing-Moduls, sich darum zu kümmern. Beispielsweise kann dafür eine msgID verwendet werden.

  Eine SNMP Command Generator-Anwendung muss jede Response Class PDU verwerfen, für die es keine aktuell ausstehende Confirmed Class PDU gibt; beispielsweise kann bei SNMPv2 [RFC3416] PDUs die request-id-Komponente in der PDU verwendet werden, um Antworten mit ausstehenden Anforderungen zu korrelieren.

  Obwohl es für eine SNMP-Engine und eine SNMP Command Generator-Anwendung typisch wäre, dies routinemäßig zu tun, ist es bei Verwendung dieser Sicherheitsprotokolle aufgrund der Möglichkeit der Nachrichtenduplizierung (böswillig oder anderweitig) von Bedeutung.

• Wenn eine SNMP-Engine eine msgID zur Korrelation von Antwortnachrichten mit ausstehenden Anforderungsnachrichten verwendet, muss sie in allen solchen Anforderungsnachrichten, die sie während eines Zeitfensters (150 Sekunden) sendet, unterschiedliche msgIDs verwenden.

  Eine Command Generator- oder Notification Originator-Anwendung muss in allen Request-PDUs, die sie während eines Zeitfensters (150 Sekunden) sendet, unterschiedliche request-ids verwenden.

  Dies muss getan werden, um sich vor der Möglichkeit der Nachrichtenduplizierung (böswillig oder anderweitig) zu schützen.

  Beispielsweise ist es keine gute Idee, Operationen mit einem msgID- und/oder request-id-Wert von Null zu beginnen. Sie mit einer unvorhersehbaren Zahl zu initialisieren (damit sie nach jedem Neustart nicht gleich beginnen) und dann um eins zu inkrementieren, wäre akzeptabel.

• Eine SNMP-Engine sollte die Zeitsynchronisierung unter Verwendung authentifizierter Nachrichten durchführen, um sich vor der Möglichkeit der Nachrichtenduplizierung (böswillig oder anderweitig) zu schützen.

• Beim Senden von zustandsändernden Nachrichten an eine verwaltete autoritative SNMP-Engine sollte eine Command Generator-Anwendung das Senden aufeinanderfolgender Nachrichten an diese verwaltete SNMP-Engine verzögern, bis eine positive Bestätigung für die vorherige Nachricht empfangen wurde oder die vorherige Nachricht abgelaufen ist.

  SNMP erzwingt keine Nachrichtenreihenfolge. Nachrichten können in beliebiger Reihenfolge relativ zu ihrem Erzeugungszeitpunkt empfangen werden, und jede wird in der empfangenen Reihenfolge verarbeitet. Beachten Sie, dass wenn eine authentifizierte Nachricht an eine verwaltete SNMP-Engine gesendet wird, sie unter normalen Umständen für einen Zeitraum von etwa 150 Sekunden gültig ist und während dieser Zeit einem Replay unterliegt. Tatsächlich müssen eine SNMP-Engine und SNMP Command Generator-Anwendungen routinemäßig mit dem Verlust und der Neuordnung von Nachrichten umgehen, die durch Anomalien im Netzwerk entstehen.

  Das verwaltete Objekt snmpSetSerialNo [RFC3418] ist jedoch speziell für die Verwendung mit SNMP-Set-Operationen definiert, um einen Mechanismus bereitzustellen, der sicherstellt, dass die Verarbeitung von SNMP-Nachrichten in einer bestimmten Reihenfolge erfolgt.

• Die Häufigkeit, mit der die Geheimnisse eines User-based Security Model-Benutzers geändert werden sollten, hängt indirekt mit der Häufigkeit ihrer Verwendung zusammen.

  Der Schutz der Geheimnisse vor Offenlegung ist entscheidend für die Gesamtsicherheit der Protokolle. Die häufige Verwendung eines Geheimnisses bietet eine kontinuierliche Datenquelle, die für einen Kryptoanalytiker nützlich sein kann, um bekannte oder wahrgenommene Schwächen in einem Algorithmus auszunutzen. Häufige Änderungen des Geheimnisses vermeiden diese Verwundbarkeit.

  Das Ändern eines Geheimnisses nach jeder Verwendung wird allgemein als sicherste Praxis angesehen, aber damit kann ein erheblicher Overhead verbunden sein.

  Beachten Sie auch, dass in einer lokalen Umgebung die Gefahr der Offenlegung möglicherweise weniger bedeutend ist, und daher das Ändern von Geheimnissen möglicherweise seltener erfolgt. Wenn jedoch öffentliche Datennetze als Kommunikationswege verwendet werden, ist mehr Vorsicht geboten.

11.2 Definieren von Benutzern

Die in diesem Dokument definierten Mechanismen verwenden den Begriff der Benutzer, in deren Namen Nachrichten gesendet werden. Wie "Benutzer" definiert werden, unterliegt der Sicherheitsrichtlinie der Netzwerkverwaltung. Beispielsweise könnten Benutzer Einzelpersonen sein (z.B. "joe" oder "jane"), oder eine bestimmte Rolle (z.B. "operator" oder "administrator"), oder eine Kombination (z.B. "joe-operator", "jane-operator" oder "joe-admin"). Darüber hinaus kann ein Benutzer eine logische Entität sein, wie z.B. eine SNMP-Anwendung oder eine Gruppe von SNMP-Anwendungen, die im Namen einer Einzelperson oder Rolle oder einer Gruppe von Einzelpersonen oder einer Gruppe von Rollen, einschließlich Kombinationen, handelt.

Anhang A beschreibt einen Algorithmus zum Zuordnen eines Benutzer-"Passworts" zu einem 16/20-Oktett-Wert zur Verwendung als Authentifizierungsschlüssel oder Datenschutzschlüssel (oder beides) eines Benutzers. Beachten Sie jedoch, dass die Verwendung desselben Passworts (und daher desselben Schlüssels) sowohl für Authentifizierung als auch Datenschutz eine sehr schlechte Sicherheitspraxis ist und dringend abgeraten werden sollte. Passwörter werden oft von Menschen generiert, erinnert und eingegeben. Von Menschen generierte Passwörter können weniger als die 16/20 Oktette sein, die von den Authentifizierungs- und Datenschutzprotokollen benötigt werden, und Brute-Force-Angriffe können bei einem relativ kurzen ASCII-Zeichensatz ziemlich einfach sein. Daher führt der Algorithmus in Anhang A eine Transformation des Passworts durch. Wenn der Algorithmus in Anhang A verwendet wird, müssen SNMP-Implementierungen (und SNMP-Konfigurationsanwendungen) sicherstellen, dass Passwörter mindestens 8 Zeichen lang sind. Bitte beachten Sie, dass längere Passwörter mit sich wiederholenden Zeichenfolgen genau denselben Schlüssel ergeben können. Beispielsweise ergibt ein Passwort 'bertbert' genau denselben Schlüssel wie das Passwort 'bertbertbert'.

Da der Algorithmus in Anhang A solche Passwörter (fast) direkt verwendet, ist es sehr wichtig, dass sie nicht leicht zu erraten sind. Es wird vorgeschlagen, dass sie aus gemischten Groß- und Kleinbuchstaben, alphanumerischen und Satzzeichen bestehen, die keine Wörter oder Phrasen bilden, die in einem Wörterbuch zu finden sein könnten. Längere Passwörter verbessern die Sicherheit des Systems. Benutzer möchten möglicherweise mehrere Wörter eingeben, um ihre Passwortzeichenfolge länger zu machen und gleichzeitig sicherzustellen, dass sie einprägsam ist.

Da es für menschliche Benutzer nicht machbar ist, unterschiedliche Passwörter für jede SNMP-Engine zu pflegen, aber Sicherheitsanforderungen dringend davon abraten, denselben Schlüssel für mehr als eine SNMP-Engine zu haben, verwendet das User-based Security Model einen in [Localized-key] vorgeschlagenen Kompromiss. Es leitet die Benutzerschlüssel für die SNMP-Engines vom Benutzerpasswort auf eine Weise ab, dass es praktisch unmöglich ist, entweder das Benutzerpasswort oder den Benutzerschlüssel für eine andere SNMP-Engine aus einer beliebigen Kombination von Benutzerschlüsseln auf SNMP-Engines zu bestimmen.

Beachten Sie jedoch, dass wenn das Passwort des Benutzers offengelegt wird, die Schlüssellokalisierung nicht hilft und die Netzwerksicherheit in diesem Fall gefährdet sein kann. Daher darf das Passwort eines Benutzers oder ein nicht lokalisierter Schlüssel nicht auf einem verwalteten Gerät/Knoten gespeichert werden. Stattdessen soll der lokalisierte Schlüssel gespeichert werden (wenn überhaupt), damit, falls ein Gerät kompromittiert wird, keine anderen verwalteten oder verwaltenden Geräte kompromittiert werden.

11.3. Konformität

Um als "Sichere SNMP-Implementierung" basierend auf dem User-based Security Model bezeichnet zu werden, muss eine SNMP-Implementierung:

• ein oder mehrere Authentifizierungsprotokolle implementieren. Die in diesem Memo definierten HMAC-MD5-96- und HMAC-SHA-96-Authentifizierungsprotokolle sind Beispiele für solche Protokolle.

• soweit wie möglich den Zugriff auf die Geheimnisse jedes Benutzers, über den sie Informationen in einem Local Configuration Datastore (LCD) pflegt, unter allen Umständen außer bei Bedarf zum Generieren und/oder Validieren von SNMP-Nachrichten in Bezug auf diesen Benutzer verbieten.

• den Schlüssellokalisierungsmechanismus implementieren.

• die SNMP-USER-BASED-SM-MIB implementieren.

Darüber hinaus sollte eine autoritative SNMP-Engine eine Erstkonfiguration gemäß Anhang A.1 bereitstellen.

Die Implementierung eines Datenschutzprotokolls (das in diesem Memo definierte DES Symmetric Encryption Protocol ist ein solches Protokoll) ist optional.

11.4. Verwendung von Reports

Die Verwendung unsicherer Reports (d.h. das Senden mit einem securityLevel von noAuthNoPriv) setzt eine nicht-autoritative SNMP-Engine potenziell einer Form von Angriffen aus. Einige Leute betrachten diese als Denial-of-Service-Angriffe, andere nicht. Eine Installation sollte das damit verbundene Risiko bewerten, bevor unsichere Report-PDUs eingesetzt werden.

11.5 Zugriff auf die SNMP-USER-BASED-SM-MIB

Die Objekte in dieser MIB können in vielen Umgebungen als sensibel betrachtet werden. Insbesondere enthalten die Objekte in der usmUserTable Informationen über Benutzer und ihre Authentifizierungs- und Datenschutzprotokolle. Es ist wichtig, den Zugriff (sowohl Lese- als auch Schreibzugriff) auf diese MIB-Objekte durch Verwendung geeignet konfigurierter Access Control-Modelle (z.B. das View-based Access Control Model wie in [RFC3415] spezifiziert) streng zu kontrollieren.