Simple Network Management Protocol: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „'''topic''' kurze Beschreibung == Beschreibung == == Installation == == Anwendungen == === Fehlerbehebung === == Syntax == === Optionen === === Parameter === === Umgebungsvariablen === === Exit-Status === == Konfiguration == === Dateien === == Sicherheit == == Dokumentation == === RFC === === Man-Pages === === Info-Pages === == Siehe auch == == Links == === Projekt-Homepage === === Weblinks === === Einzelnachweise === <references /> == Testfragen == <div…“ |
|||
| (29 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
''' | '''Simple Network Management Protocol''' (SNMP) - [[Netzwerkprotokoll]] um [[Netzwerkelement]]e zentral überwachen und steuern | ||
== Beschreibung == | == Beschreibung == | ||
{| class="wikitable float" | |||
{| class="wikitable float | |||
|- | |- | ||
! bgcolor="#C0C0FF" colspan="2" font="size:larger" | SNMP (Simple Network Management Protocol) | ! bgcolor="#C0C0FF" colspan="2" font="size:larger" | SNMP (Simple Network Management Protocol) | ||
|- | |- | ||
| '''Familie:''' | | '''Familie:''' | ||
| [[ | | [[Internetprotokolle]] | ||
|- | |- | ||
| '''Einsatzgebiet:''' | | '''Einsatzgebiet:''' | ||
| Zeile 68: | Zeile 25: | ||
| RFC 1157 (SNMP, 1990)<br />RFC 3410 ''ff'' (SNMPv3, 2002)<br />''(siehe Text)'' | | RFC 1157 (SNMP, 1990)<br />RFC 3410 ''ff'' (SNMPv3, 2002)<br />''(siehe Text)'' | ||
|} | |} | ||
[[Datei:SNMP-Managementkonsole.PNG|mini|420px|Überwachung der Netzwerk/Hardwaren von der Managementkonsole aus]] | |||
* Überwachung von | |||
* Fernsteuerung und Fernkonfiguration von | ; Einfaches Netzwerkverwaltungsprotokoll | ||
* ist ein [[Netzwerkprotokoll]], das von der [[Internet Engineering Task Force|IETF]] entwickelt wurde, um [[Netzwerkelement]]e (z. B. [[Router]], [[Host (Informationstechnik)|Server]], [[Switch (Computertechnik)|Switches]], Drucker, Computer usw.) von einer zentralen Station aus überwachen und steuern zu können. | |||
* Das Protokoll regelt dabei die Kommunikation zwischen den überwachten Geräten und der Überwachungsstation. | |||
* SNMP beschreibt den Aufbau der [[Datenpaket]]e, die gesendet werden können und den Kommunikationsablauf. | |||
* Es wurde dabei so ausgelegt, dass jedes netzwerkfähige Gerät mit in die Überwachung aufgenommen werden kann. | |||
* Zu den Aufgaben des [[Netzwerkmanagement]]s, die mit SNMP möglich sind, zählen: | |||
* Überwachung von Netzwerk/Hardwaren, | |||
* Fernsteuerung und Fernkonfiguration von Netzwerk/Hardwaren, | |||
* Fehlererkennung und Fehlerbenachrichtigung. | * Fehlererkennung und Fehlerbenachrichtigung. | ||
| Zeile 80: | Zeile 43: | ||
[[Datei:SNMP v1.01.png|mini|Wie SNMP funktioniert.]] | [[Datei:SNMP v1.01.png|mini|Wie SNMP funktioniert.]] | ||
Zur Überwachung werden sogenannte [[Software-Agent|Agenten]] eingesetzt. Dabei handelt es sich um Programme, die direkt auf den überwachten Geräten laufen, oder um Hardware, welche die gleichen Aufgaben erfüllt.<ref>http://www.dpstele.com/white-papers/snmp-tutorial/snmp_glossary.php</ref> Diese Programme/Geräte sind in der Lage, den Zustand des Netzwerkgerätes zu erfassen und auch selbst Einstellungen vorzunehmen oder Aktionen auszulösen. Mit Hilfe von SNMP ist es möglich, dass die zentrale [[Managementstation]] mit den Agenten über ein Netzwerk kommunizieren kann. Dazu gibt es sieben verschiedene Datenpakete, die gesendet werden können: | Zur Überwachung werden sogenannte [[Software-Agent|Agenten]] eingesetzt. | ||
* Dabei handelt es sich um Programme, die direkt auf den überwachten Geräten laufen, oder um Hardware, welche die gleichen Aufgaben erfüllt.<ref>http://www.dpstele.com/white-papers/snmp-tutorial/snmp_glossary.php</ref> Diese Programme/Geräte sind in der Lage, den Zustand des Netzwerkgerätes zu erfassen und auch selbst Einstellungen vorzunehmen oder Aktionen auszulösen. | |||
* Mit Hilfe von SNMP ist es möglich, dass die zentrale [[Managementstation]] mit den Agenten über ein Netzwerk kommunizieren kann. | |||
* Dazu gibt es sieben verschiedene Datenpakete, die gesendet werden können: | |||
; GET-REQUEST | ; GET-REQUEST | ||
: zum Anfordern eines Management-Datensatzes. | : zum Anfordern eines Management-Datensatzes. | ||
| Zeile 88: | Zeile 54: | ||
: um eine angegebene Anzahl an Datensätzen auf einmal abzurufen, ähnelt mehreren GETNEXT-REQUEST. | : um eine angegebene Anzahl an Datensätzen auf einmal abzurufen, ähnelt mehreren GETNEXT-REQUEST. | ||
; SET-REQUEST | ; SET-REQUEST | ||
: um einen oder mehrere Datensätze eines Netzelementes zu verändern. Manchmal verlangt ein Netzelement die gleichzeitige Änderung mehrerer Datensätze, um die Konsistenz zu überprüfen. Beispielsweise erfordert die Konfiguration einer IP-Adresse die gleichzeitige Angabe der Netzwerkmaske. | : um einen oder mehrere Datensätze eines Netzelementes zu verändern. | ||
* Manchmal verlangt ein Netzelement die gleichzeitige Änderung mehrerer Datensätze, um die Konsistenz zu überprüfen. | |||
* Beispielsweise erfordert die Konfiguration einer IP-Adresse die gleichzeitige Angabe der Netzwerkmaske. | |||
; GET-RESPONSE | ; GET-RESPONSE | ||
: Antwort auf eines der vorherigen Pakete. | : Antwort auf eines der vorherigen Pakete. | ||
; TRAP | ; TRAP | ||
: unaufgeforderte Nachricht von einem Agenten an den Manager, dass ein Ereignis eingetreten ist. Programme wie [[Wireshark]], die zum Dekodieren von Protokollen wie SNMP benutzt werden, nennen dieses Datenpaket auch '''REPORT'''. Ein '''TRAP''' kann auch geschickt werden, wenn die in einem '''SET-REQUEST'''-Paket beschriebene(n) Datensatzänderung(en) nicht durchgeführt werden konnte(n), und nicht nur, um eine Fehlfunktion (z. B. einen Defekt eines Moduls eines Netzelements) zu melden. | : unaufgeforderte Nachricht von einem Agenten an den Manager, dass ein Ereignis eingetreten ist. | ||
* Programme wie [[Wireshark]], die zum Dekodieren von Protokollen wie SNMP benutzt werden, nennen dieses Datenpaket auch '''REPORT'''. | |||
* Ein '''TRAP''' kann auch geschickt werden, wenn die in einem '''SET-REQUEST'''-Paket beschriebene(n) Datensatzänderung(en) nicht durchgeführt werden konnte(n), und nicht nur, um eine Fehlfunktion (z. B. einen Defekt eines Moduls eines Netzelements) zu melden. | |||
; INFORM-REQUEST | ; INFORM-REQUEST | ||
: aufgebaut wie ein Trap, nur dass dieser vom Empfänger quittiert wird. | : aufgebaut wie ein Trap, nur dass dieser vom Empfänger quittiert wird. | ||
Die drei '''GET'''-Pakete ('''GET''', '''GETNEXT''', '''GETBULK''') können vom Manager zu einem Agenten gesendet werden, um Daten über die jeweilige Station anzufordern. Dieser antwortet mit einem '''RESPONSE'''-Paket, das entweder die angeforderten Daten oder eine Fehlermeldung enthält. | Die drei '''GET'''-Pakete ('''GET''', '''GETNEXT''', '''GETBULK''') können vom Manager zu einem Agenten gesendet werden, um Daten über die jeweilige Station anzufordern. | ||
* Dieser antwortet mit einem '''RESPONSE'''-Paket, das entweder die angeforderten Daten oder eine Fehlermeldung enthält. | |||
Mit dem '''SET-REQUEST'''-Paket kann ein Manager Werte beim Agenten verändern. Damit ist es möglich, Einstellungen vorzunehmen oder Aktionen auszulösen. Der Agent bestätigt die Übernahme der Werte ebenfalls mit einem '''GET-RESPONSE'''-Paket. | Mit dem '''SET-REQUEST'''-Paket kann ein Manager Werte beim Agenten verändern. | ||
* Damit ist es möglich, Einstellungen vorzunehmen oder Aktionen auszulösen. | |||
* Der Agent bestätigt die Übernahme der Werte ebenfalls mit einem '''GET-RESPONSE'''-Paket. | |||
Wenn der Agent bei der Überwachung des Systems einen Fehler erkennt, kann er diesen mit Hilfe eines '''TRAP'''-Paketes unaufgefordert an die Management-Station melden. Diese Pakete werden nicht vom Manager bestätigt. Der Agent kann daher nicht feststellen, ob das gesendete '''TRAP'''-Paket beim Manager angekommen ist. | Wenn der Agent bei der Überwachung des Systems einen Fehler erkennt, kann er diesen mit Hilfe eines '''TRAP'''-Paketes unaufgefordert an die Management-Station melden. | ||
* Diese Pakete werden nicht vom Manager bestätigt. | |||
* Der Agent kann daher nicht feststellen, ob das gesendete '''TRAP'''-Paket beim Manager angekommen ist. | |||
Damit die Netzwerkbelastung gering bleibt, wird zum Versenden der Nachrichten das verbindungslose Protokoll [[User Datagram Protocol|UDP]] verwendet. Der Agent und der Manager kommunizieren (Requests/Responses) auf dem [[Port (Protokoll)|Port]] 161, während der Port 162 zum Empfangen der '''TRAP'''-Meldungen vorgeschrieben ist. | Damit die Netzwerkbelastung gering bleibt, wird zum Versenden der Nachrichten das verbindungslose Protokoll [[User Datagram Protocol|UDP]] verwendet. | ||
* Der Agent und der Manager kommunizieren (Requests/Responses) auf dem [[Port (Protokoll)|Port]] 161, während der Port 162 zum Empfangen der '''TRAP'''-Meldungen vorgeschrieben ist. | |||
== Management Information Base == | == Management Information Base == | ||
[[Management Information Base]] | |||
Zum Rahmenwerk des SNMP-basierten Management gehört nicht nur das Protokoll, sondern auch die Repräsentation der Datenbasis, die im Netzwerkgerät vorhanden ist und die man als „Management Information Base“ oder abgekürzt als „MIB“ bezeichnet. | Zum Rahmenwerk des SNMP-basierten Management gehört nicht nur das Protokoll, sondern auch die Repräsentation der Datenbasis, die im Netzwerkgerät vorhanden ist und die man als „Management Information Base“ oder abgekürzt als „MIB“ bezeichnet. | ||
| Zeile 116: | Zeile 92: | ||
* RFC 1157 – A Simple Network Management Protocol (Ersetzte die RFC 1067 und die RFC 1098) | * RFC 1157 – A Simple Network Management Protocol (Ersetzte die RFC 1067 und die RFC 1098) | ||
Das Hauptproblem der ersten Version ist die unzureichende Sicherheit bei der Übertragung. Eines der Probleme ist die unverschlüsselte Übertragung des Passwortes, dadurch kann es leicht abgehört und durch unberechtigte Parteien verwendet werden. | Das Hauptproblem der ersten Version ist die unzureichende Sicherheit bei der Übertragung. | ||
* Eines der Probleme ist die unverschlüsselte Übertragung des Passwortes, dadurch kann es leicht abgehört und durch unberechtigte Parteien verwendet werden. | |||
=== Secure SNMP === | === Secure SNMP === | ||
| Zeile 128: | Zeile 105: | ||
=== Party-Based SNMP Version 2 (SNMPv2p) === | === Party-Based SNMP Version 2 (SNMPv2p) === | ||
1993 wurde SNMPv2p von der [[Internet Engineering Task Force|IETF]] veröffentlicht. Es verbesserte SNMPv1 in puncto Sicherheit und Vertraulichkeit, durch die | 1993 wurde SNMPv2p von der [[Internet Engineering Task Force|IETF]] veröffentlicht. | ||
* Es verbesserte SNMPv1 in puncto Sicherheit und Vertraulichkeit, durch die Kryptografie des Community-String und führte eine Kommunikation zwischen verschiedenen Managern ein. | |||
* Durch den neuen GetBulk-Befehl wurde das Abfragen von Tabellen erheblich erleichtert. | |||
* RFC 1441 – Introduction to version 2 of the Internet-standard Network Management Framework | * RFC 1441 – Introduction to version 2 of the Internet-standard Network Management Framework | ||
| Zeile 146: | Zeile 125: | ||
=== Community-Based SNMP Version 2 (SNMPv2c) === | === Community-Based SNMP Version 2 (SNMPv2c) === | ||
SNMPv2c ist bezüglich Sicherheit auf dem Stand von SNMPv1. Es ist lediglich erweitert um ein paar zusätzliche Funktionen, die es bereits bei SNMPv2p gab: | SNMPv2c ist bezüglich Sicherheit auf dem Stand von SNMPv1. | ||
* Es ist lediglich erweitert um ein paar zusätzliche Funktionen, die es bereits bei SNMPv2p gab: | |||
* Tabellen müssen nicht mehr mit dem GetNext-Befehl durchlaufen werden, sondern können mit dem GetBulk-Befehl auf einmal geholt werden. | * Tabellen müssen nicht mehr mit dem GetNext-Befehl durchlaufen werden, sondern können mit dem GetBulk-Befehl auf einmal geholt werden. | ||
* Kommunikation zwischen verschiedenen Managern. | * Kommunikation zwischen verschiedenen Managern. | ||
Diese Version hat sich durchgesetzt und breite Akzeptanz erfahren. Wenn heutzutage von SNMPv2 gesprochen wird, ist meistens diese Version gemeint. | Diese Version hat sich durchgesetzt und breite Akzeptanz erfahren. | ||
* Wenn heutzutage von SNMPv2 gesprochen wird, ist meistens diese Version gemeint. | |||
* RFC 1901 – Introduction to Community-based SNMPv2 | * RFC 1901 – Introduction to Community-based SNMPv2 | ||
| Zeile 157: | Zeile 138: | ||
=== Version 3 === | === Version 3 === | ||
SNMP-Versionen 1 und 2c bieten fast keine Sicherheitsmechanismen. Daher stammt auch die scherzhafte Deutung der Abkürzung SNMP als „Security is not my problem“ (Sicherheit ist nicht mein Problem). In der aktuellen Version 3 wurden die Sicherheitsmechanismen deutlich ausgebaut. Die damit einhergehende gestiegene Komplexität (z. B. [[Schlüssel ( | SNMP-Versionen 1 und 2c bieten fast keine Sicherheitsmechanismen. | ||
* Daher stammt auch die scherzhafte Deutung der Abkürzung SNMP als „Security is not my problem“ (Sicherheit ist nicht mein Problem). | |||
* In der aktuellen Version 3 wurden die Sicherheitsmechanismen deutlich ausgebaut. | |||
* Die damit einhergehende gestiegene Komplexität (z. B. [[Schlüssel (Kryptografie)|Schlüsselverwaltung]]) hat aber dazu geführt, dass SNMPv3 noch nicht so weit verbreitet ist wie SNMPv2. | |||
SNMP in der neuesten Version 3 wird durch eine Reihe neuer RFCs definiert (die Spezifizierung erfolgte im Dezember 2002): | SNMP in der neuesten Version 3 wird durch eine Reihe neuer RFCs definiert (die Spezifizierung erfolgte im Dezember 2002): | ||
* RFC 3410 – Introduction and Applicability Statements for Internet-Standard Management Framework | * RFC 3410 – Introduction and Applicability Statements for Internet-Standard Management Framework | ||
* RFC 3411 – An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks | * RFC 3411 – An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks | ||
| Zeile 172: | Zeile 155: | ||
== Paketaufbau (SNMPv1) == | == Paketaufbau (SNMPv1) == | ||
Die Beschreibung der SNMP-Pakete erfolgt durch [[ASN.1]], die Kodierung für den Transport über das Netzwerk mittels [[Basic Encoding Rules]] (BER). Die meisten SNMP-Pakete sind identisch aufgebaut. Lediglich bei Trap-Meldungen werden im [[Protocol Data Unit|PDU]]-Header teilweise andere Informationen versendet. | Die Beschreibung der SNMP-Pakete erfolgt durch [[ASN.1]], die Kodierung für den Transport über das Netzwerk mittels [[Basic Encoding Rules]] (BER). | ||
* Die meisten SNMP-Pakete sind identisch aufgebaut. | |||
* Lediglich bei Trap-Meldungen werden im [[Protocol Data Unit|PDU]]-Header teilweise andere Informationen versendet. | |||
{| | {|class="wikitable" | ||
|+ Aufbau eines SNMP-Paketes, für Nicht-Trap-Meldungen | |+ Aufbau eines SNMP-Paketes, für Nicht-Trap-Meldungen | ||
|- | |- | ||
| Zeile 186: | Zeile 171: | ||
=== SNMP-Paket Header === | === SNMP-Paket Header === | ||
Im Header wird die Versionsnummer (SNMPv1, SNMPv2 oder SNMPv3) und der Community Name übertragen. | Im Header wird die Versionsnummer (SNMPv1, SNMPv2 oder SNMPv3) und der Community Name übertragen. | ||
Durch das Zuweisen von Communities werden Zugriffsrechte vergeben. In den meisten Fällen wird für lesenden Zugriff (read-only) standardmäßig der Community Name "public", für Schreib-/Lesezugriff (read-write) "private" verwendet. | * Durch das Zuweisen von Communities werden Zugriffsrechte vergeben. | ||
Da diese beiden Community Names als Standardeinstellung bekannt sind, sollten diese geändert werden. Allerdings erhöht dies die Sicherheit nicht zwangsläufig, da die Community Namen als Klartext über das Netzwerk übertragen werden. | * In den meisten Fällen wird für lesenden Zugriff (read-only) standardmäßig der Community Name "public", für Schreib-/Lesezugriff (read-write) "private" verwendet. | ||
Da diese beiden Community Names als Standardeinstellung bekannt sind, sollten diese geändert werden. | |||
* Allerdings erhöht dies die Sicherheit nicht zwangsläufig, da die Community Namen als Klartext über das Netzwerk übertragen werden. | |||
=== PDU-Header (Nicht-Trap-Pakete) === | === PDU-Header (Nicht-Trap-Pakete) === | ||
Im ersten Teil des PDU-Headers wird die Art des SNMP-Paketes und die Größe der PDU übertragen. Der Aufbau des zweiten Teils hängt von der Art des SNMP-Paketes ab. | Im ersten Teil des PDU-Headers wird die Art des SNMP-Paketes und die Größe der PDU übertragen. | ||
* Der Aufbau des zweiten Teils hängt von der Art des SNMP-Paketes ab. | |||
Damit Antwortpakete den vorherigen Anfragen zugeordnet werden können, gibt es die Request ID, welche bei Anfrage und Antwort identisch sind. Damit ist es möglich, mehrere Anfragen zu verschicken und die Antworten wieder richtig zuzuordnen. | Damit Antwortpakete den vorherigen Anfragen zugeordnet werden können, gibt es die Request ID, welche bei Anfrage und Antwort identisch sind. | ||
* Damit ist es möglich, mehrere Anfragen zu verschicken und die Antworten wieder richtig zuzuordnen. | |||
Der Fehlerstatus und -index wird dazu verwendet, bei Antwortpaketen mitzuteilen, warum eine Anfrage nicht bearbeitet werden konnte. Solange kein Fehler auftritt, sind die beiden Felder mit dem Wert Null belegt. Im Fehlerfall gibt der Fehlerindex an, beim wievielten Datensatz der Fehler auftrat. Mit dem Fehlerstatus wird der Grund des Fehlers angegeben. Der Fehlerstatus kann bei SNMPv1 einen von 6 möglichen Werten haben: | Der Fehlerstatus und -index wird dazu verwendet, bei Antwortpaketen mitzuteilen, warum eine Anfrage nicht bearbeitet werden konnte. | ||
* Solange kein Fehler auftritt, sind die beiden Felder mit dem Wert Null belegt. | |||
* Im Fehlerfall gibt der Fehlerindex an, beim wievielten Datensatz der Fehler auftrat. | |||
* Mit dem Fehlerstatus wird der Grund des Fehlers angegeben. | |||
Der Fehlerstatus kann bei SNMPv1 einen von 6 möglichen Werten haben: | |||
* kein Fehler | * kein Fehler | ||
* Paket ist zu groß zum Versenden | * Paket ist zu groß zum Versenden | ||
| Zeile 203: | Zeile 197: | ||
=== PDU-Header (Trap-Pakete) === | === PDU-Header (Trap-Pakete) === | ||
Die ersten beiden Felder des PDU-Headers sind bei Traps identisch mit denen anderer SNMP-Pakete. Das Feld Pakettyp gibt an, dass es sich um einen Trap handelt. Im zweiten Teil werden andere Werte übertragen, die nur bei Traps benötigt werden. | Die ersten beiden Felder des PDU-Headers sind bei Traps identisch mit denen anderer SNMP-Pakete. | ||
* Das Feld Pakettyp gibt an, dass es sich um einen Trap handelt. | |||
* Im zweiten Teil werden andere Werte übertragen, die nur bei Traps benötigt werden. | |||
{| | {| class="wikitable" | ||
|+ Aufbau des PDU-Headers eines SNMP-Trap-Paketes (SNMPv1) | |+ Aufbau des PDU-Headers eines SNMP-Trap-Paketes (SNMPv1) | ||
|- | |- | ||
| Zeile 213: | Zeile 209: | ||
|} | |} | ||
Zum Erkennen, von wem die Nachricht kommt, wird die IP-Adresse des Absenders und dessen herstellerspezifische OID (1.3.6.1.4.1.*) mitgesendet. Die OID gibt an, um was für ein Gerät es sich handelt. Das ist wichtig zu wissen, wenn es sich um einen firmenspezifischen Trap handelt, der nur für diesen Gerätetyp gilt. | Zum Erkennen, von wem die Nachricht kommt, wird die IP-Adresse des Absenders und dessen herstellerspezifische OID (1.3.6.1.4.1.*) mitgesendet. | ||
* Die OID gibt an, um was für ein Gerät es sich handelt. | |||
* Das ist wichtig zu wissen, wenn es sich um einen firmenspezifischen Trap handelt, der nur für diesen Gerätetyp gilt. | |||
Danach folgt die allgemeine TrapID. | |||
* Es gibt sieben mögliche allgemeine TrapIDs<ref>[//tools.ietf.org/html/rfc2089 RFC2089]. Mapping SNMPv2 onto SNMPv1</ref>: | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! Bezeichnung | ! Bezeichnung !! Wert in der Trap-PDU | ||
|- | |- | ||
| Kaltstart (coldStart) || 0 | | Kaltstart (coldStart) || 0 | ||
| Zeile 237: | Zeile 237: | ||
Wird im Feld "TrapID" "firmenspezifisch (enterpriseSpecific)" angegeben, so wird die ID der firmenspezifischen Trap im nachfolgenden Feld übertragen. | Wird im Feld "TrapID" "firmenspezifisch (enterpriseSpecific)" angegeben, so wird die ID der firmenspezifischen Trap im nachfolgenden Feld übertragen. | ||
Da es möglich ist, dass Trap-Pakete nicht in der Reihenfolge eintreffen, wie sie versendet wurden, gibt es zusätzlich noch eine Zeitangabe, die auf Hundertstelsekunden genau angibt, wie lang der SNMP-Agent gelaufen ist, bis das Trap-Ereignis auftrat. Dadurch ist es möglich die Trap-Ereignisse in die zeitlich richtige Reihenfolge zu bringen. | Da es möglich ist, dass Trap-Pakete nicht in der Reihenfolge eintreffen, wie sie versendet wurden, gibt es zusätzlich noch eine Zeitangabe, die auf Hundertstelsekunden genau angibt, wie lang der SNMP-Agent gelaufen ist, bis das Trap-Ereignis auftrat. | ||
* Dadurch ist es möglich die Trap-Ereignisse in die zeitlich richtige Reihenfolge zu bringen. | |||
=== PDU-Body === | === PDU-Body === | ||
Im PDU-Body werden die eigentlichen Werte übertragen. Jeder Wert wird in einer sogenannten Variable Binding übertragen | Im PDU-Body werden die eigentlichen Werte übertragen. Jeder Wert wird in einer sogenannten Variable Binding übertragen. | ||
{| | |||
{| class="wikitable" | |||
|+ Variable Bindings | |+ Variable Bindings | ||
|- | |- | ||
| Zeile 252: | Zeile 254: | ||
Zu einer Variable Binding gehören deren OID und der Wert selber. | Zu einer Variable Binding gehören deren OID und der Wert selber. | ||
Es gibt keine Vorgabe, wie viele Variable Bindings im PDU-Body mitgeschickt werden dürfen. Es ist also möglich, mehrere Werte mit einem Get-Befehl abzufragen. Wenn aber das Antwortpaket dabei zu groß wird, kann es passieren, dass die entsprechende Fehlermeldung im Antwortpaket zurückgeschickt wird. | Es gibt keine Vorgabe, wie viele Variable Bindings im PDU-Body mitgeschickt werden dürfen. | ||
* Es ist also möglich, mehrere Werte mit einem Get-Befehl abzufragen. | |||
* Wenn aber das Antwortpaket dabei zu groß wird, kann es passieren, dass die entsprechende Fehlermeldung im Antwortpaket zurückgeschickt wird. | |||
Bei Traps ist es auch möglich, dass keine Variable Bindings mitgeschickt werden. In dem Fall wird die TrapID als ausreichende Information angesehen. | Bei Traps ist es auch möglich, dass keine Variable Bindings mitgeschickt werden. | ||
* In dem Fall wird die TrapID als ausreichende Information angesehen. | |||
Im SNMP-Paket ist keine Angabe vorgesehen, welche die Anzahl an mitgeschickten Variable Bindings angibt. Das lässt sich nur über die Größenangabe des PDU-Bodys und der Größenangabe der einzelnen Variable Bindings herausfinden. | Im SNMP-Paket ist keine Angabe vorgesehen, welche die Anzahl an mitgeschickten Variable Bindings angibt. | ||
* Das lässt sich nur über die Größenangabe des PDU-Bodys und der Größenangabe der einzelnen Variable Bindings herausfinden. | |||
== Sicherheitsprobleme == | == Sicherheitsprobleme == | ||
Ein Nachteil von SNMP Version 1 bis 2c ist die fehlende Sicherheit. Diese Versionen von SNMP unterstützen keine Anmeldung mit Kennwort und Benutzernamen, es werden sogenannte Communities verwendet. Diese haben jedoch den Nachteil, dass jeder User im Netzwerk mit einem passenden Programm Systeminformationen auslesen und sogar Werte verändern kann. | Ein Nachteil von SNMP Version 1 bis 2c ist die fehlende Sicherheit. | ||
* Diese Versionen von SNMP unterstützen keine Anmeldung mit Kennwort und Benutzernamen, es werden sogenannte Communities verwendet. | |||
* Diese haben jedoch den Nachteil, dass jeder User im Netzwerk mit einem passenden Programm Systeminformationen auslesen und sogar Werte verändern kann. | |||
Communities sind einfache Namen, wie zum Beispiel „PUBLIC“ (darf nur lesen) oder „PRIVATE“ (darf auch schreiben), die mit der Anfrage zusammen vom SNMP-Service übermittelt werden. Sie sind nichts anderes als ein vorher vereinbarter Schlüssel ([[Pre-shared key]]s). | Communities sind einfache Namen, wie zum Beispiel „PUBLIC“ (darf nur lesen) oder „PRIVATE“ (darf auch schreiben), die mit der Anfrage zusammen vom SNMP-Service übermittelt werden. | ||
Man kann natürlich auch sehr lange und komplizierte Community-Namen verwenden. Das ist allerdings von begrenztem Nutzen, da SNMP-Pakete nicht verschlüsselt sind und deshalb sehr einfach von einem Angreifer „gesnifft“ (abgehört) werden können. | * Sie sind nichts anderes als ein vorher vereinbarter Schlüssel ([[Pre-shared key]]s). | ||
Man kann natürlich auch sehr lange und komplizierte Community-Namen verwenden. | |||
* Das ist allerdings von begrenztem Nutzen, da SNMP-Pakete nicht verschlüsselt sind und deshalb sehr einfach von einem Angreifer „gesnifft“ (abgehört) werden können. | |||
'''Allowed Host: ''' | '''Allowed Host: ''' | ||
Es gibt jedoch die Möglichkeit, die IP-Adressen der Systeme einzuschränken, die mit einem überwachten SNMP-System Kontakt aufnehmen dürfen. Das ist ein relativ einfacher Schutz, der sich jedoch möglicherweise mit [[ARP-Spoofing]] und [[IP-Spoofing]] aushebeln lässt. | Es gibt jedoch die Möglichkeit, die IP-Adressen der Systeme einzuschränken, die mit einem überwachten SNMP-System Kontakt aufnehmen dürfen. | ||
* Das ist ein relativ einfacher Schutz, der sich jedoch möglicherweise mit [[ARP-Spoofing]] und [[IP-Spoofing]] aushebeln lässt. | |||
'''Management-Schutz: ''' | '''Management-Schutz: ''' | ||
Seit Anfang der 1990er Jahre ist es üblich, dass man für die Überwachung der Systeme ein eigenes Netzwerk erstellt, um den Nutzdaten-Verkehr vom Management-Verkehr zu trennen. Dies wird Out-of-Band genannt. Verkehr, der über das herkömmliche Datennetz fließt, wird als Inband-Kommunikation bezeichnet. | Seit Anfang der 1990er Jahre ist es üblich, dass man für die Überwachung der Systeme ein eigenes Netzwerk erstellt, um den Nutzdaten-Verkehr vom Management-Verkehr zu trennen. | ||
* Dies wird Out-of-Band genannt. | |||
* Verkehr, der über das herkömmliche Datennetz fließt, wird als Inband-Kommunikation bezeichnet. | |||
'''Read Only: ''' | '''Read Only: ''' | ||
Es besteht auch die Möglichkeit, auf gewisse Systeme ein „Read Only“ zu vergeben. Somit kann jedes Überwachungsgerät nur lesen. Das wird häufig bei Routern verwendet | Es besteht auch die Möglichkeit, auf gewisse Systeme ein „Read Only“ zu vergeben. | ||
* Somit kann jedes Überwachungsgerät nur lesen. | |||
* Das wird häufig bei Routern verwendet. | |||
SNMP Version 3 bietet unter anderem Kryptografie und eine bessere [[Authentifizierung]], was zurzeit aber wegen der höheren Komplexität oft nicht genutzt wird. | |||
<noinclude> | |||
== Siehe auch == | == Siehe auch == | ||
{{Special:PrefixIndex/SNMP}} | |||
---- | |||
* [[Agent Extensibility Protocol]] (AgentX) | * [[Agent Extensibility Protocol]] (AgentX) | ||
== | === Dokumentation === | ||
==== RFC ==== | |||
== | === Links === | ||
==== Weblinks ==== | |||
# http://www.oid-info.com | |||
# http://www.snmp.com/FAQs/snmp-faq-part1.txt | |||
# http://www.snmp.com/FAQs/snmp-faq-part2.txt | |||
[[Kategorie: | </noinclude> | ||
[[Kategorie:SNMP]] | |||
Aktuelle Version vom 15. Februar 2024, 12:16 Uhr
Simple Network Management Protocol (SNMP) - Netzwerkprotokoll um Netzwerkelemente zentral überwachen und steuern
Beschreibung
| SNMP (Simple Network Management Protocol) | |
|---|---|
| Familie: | Internetprotokolle |
| Einsatzgebiet: | Netzwerkverwaltung |
| Neueste Version: | SNMPv3 |
| Ports: | 161/UDP 162/UDP (Trap) |
| Standards: | RFC 1157 (SNMP, 1990) RFC 3410 ff (SNMPv3, 2002) (siehe Text) |
- Einfaches Netzwerkverwaltungsprotokoll
- ist ein Netzwerkprotokoll, das von der IETF entwickelt wurde, um Netzwerkelemente (z. B. Router, Server, Switches, Drucker, Computer usw.) von einer zentralen Station aus überwachen und steuern zu können.
- Das Protokoll regelt dabei die Kommunikation zwischen den überwachten Geräten und der Überwachungsstation.
- SNMP beschreibt den Aufbau der Datenpakete, die gesendet werden können und den Kommunikationsablauf.
- Es wurde dabei so ausgelegt, dass jedes netzwerkfähige Gerät mit in die Überwachung aufgenommen werden kann.
- Zu den Aufgaben des Netzwerkmanagements, die mit SNMP möglich sind, zählen:
- Überwachung von Netzwerk/Hardwaren,
- Fernsteuerung und Fernkonfiguration von Netzwerk/Hardwaren,
- Fehlererkennung und Fehlerbenachrichtigung.
Durch seine Einfachheit, Modularität und Vielseitigkeit hat sich SNMP zum Standard entwickelt, der sowohl von den meisten Managementprogrammen als auch von Endgeräten unterstützt wird.
Funktionsweise
Zur Überwachung werden sogenannte Agenten eingesetzt.
- Dabei handelt es sich um Programme, die direkt auf den überwachten Geräten laufen, oder um Hardware, welche die gleichen Aufgaben erfüllt.[1] Diese Programme/Geräte sind in der Lage, den Zustand des Netzwerkgerätes zu erfassen und auch selbst Einstellungen vorzunehmen oder Aktionen auszulösen.
- Mit Hilfe von SNMP ist es möglich, dass die zentrale Managementstation mit den Agenten über ein Netzwerk kommunizieren kann.
- Dazu gibt es sieben verschiedene Datenpakete, die gesendet werden können:
- GET-REQUEST
- zum Anfordern eines Management-Datensatzes.
- GETNEXT-REQUEST
- um den nachfolgenden Datensatz abzurufen (um Tabellen zu durchlaufen).
- GETBULK (ab SNMPv2)
- um eine angegebene Anzahl an Datensätzen auf einmal abzurufen, ähnelt mehreren GETNEXT-REQUEST.
- SET-REQUEST
- um einen oder mehrere Datensätze eines Netzelementes zu verändern.
- Manchmal verlangt ein Netzelement die gleichzeitige Änderung mehrerer Datensätze, um die Konsistenz zu überprüfen.
- Beispielsweise erfordert die Konfiguration einer IP-Adresse die gleichzeitige Angabe der Netzwerkmaske.
- GET-RESPONSE
- Antwort auf eines der vorherigen Pakete.
- TRAP
- unaufgeforderte Nachricht von einem Agenten an den Manager, dass ein Ereignis eingetreten ist.
- Programme wie Wireshark, die zum Dekodieren von Protokollen wie SNMP benutzt werden, nennen dieses Datenpaket auch REPORT.
- Ein TRAP kann auch geschickt werden, wenn die in einem SET-REQUEST-Paket beschriebene(n) Datensatzänderung(en) nicht durchgeführt werden konnte(n), und nicht nur, um eine Fehlfunktion (z. B. einen Defekt eines Moduls eines Netzelements) zu melden.
- INFORM-REQUEST
- aufgebaut wie ein Trap, nur dass dieser vom Empfänger quittiert wird.
Die drei GET-Pakete (GET, GETNEXT, GETBULK) können vom Manager zu einem Agenten gesendet werden, um Daten über die jeweilige Station anzufordern.
- Dieser antwortet mit einem RESPONSE-Paket, das entweder die angeforderten Daten oder eine Fehlermeldung enthält.
Mit dem SET-REQUEST-Paket kann ein Manager Werte beim Agenten verändern.
- Damit ist es möglich, Einstellungen vorzunehmen oder Aktionen auszulösen.
- Der Agent bestätigt die Übernahme der Werte ebenfalls mit einem GET-RESPONSE-Paket.
Wenn der Agent bei der Überwachung des Systems einen Fehler erkennt, kann er diesen mit Hilfe eines TRAP-Paketes unaufgefordert an die Management-Station melden.
- Diese Pakete werden nicht vom Manager bestätigt.
- Der Agent kann daher nicht feststellen, ob das gesendete TRAP-Paket beim Manager angekommen ist.
Damit die Netzwerkbelastung gering bleibt, wird zum Versenden der Nachrichten das verbindungslose Protokoll UDP verwendet.
- Der Agent und der Manager kommunizieren (Requests/Responses) auf dem Port 161, während der Port 162 zum Empfangen der TRAP-Meldungen vorgeschrieben ist.
Management Information Base
Zum Rahmenwerk des SNMP-basierten Management gehört nicht nur das Protokoll, sondern auch die Repräsentation der Datenbasis, die im Netzwerkgerät vorhanden ist und die man als „Management Information Base“ oder abgekürzt als „MIB“ bezeichnet.
Versionen
Version 1
Die erste Version von SNMP wurde 1988 in den folgenden RFCs definiert:
- RFC 1155 – Structure and Identification of Management Information for TCP/IP-based internets (Ersetzte die RFC 1065)
- RFC 1156 – Management Information Base for Network Management of TCP/IP-based internets (Ersetzte die RFC 1066)
- RFC 1157 – A Simple Network Management Protocol (Ersetzte die RFC 1067 und die RFC 1098)
Das Hauptproblem der ersten Version ist die unzureichende Sicherheit bei der Übertragung.
- Eines der Probleme ist die unverschlüsselte Übertragung des Passwortes, dadurch kann es leicht abgehört und durch unberechtigte Parteien verwendet werden.
Secure SNMP
Das gestiegene Bedürfnis nach Sicherheit führte dazu, dass 1992 drei RFCs über SNMPsec (Secure SNMP) veröffentlicht wurden.
- RFC 1351 – SNMP Administrative Model
- RFC 1352 – SNMP Security Protocols
- RFC 1353 – Definitions of Managed Objects for Administration of SNMP Parties
Diese Version wurde nie eingeführt, sondern durch SNMPv2 ersetzt.
Party-Based SNMP Version 2 (SNMPv2p)
1993 wurde SNMPv2p von der IETF veröffentlicht.
- Es verbesserte SNMPv1 in puncto Sicherheit und Vertraulichkeit, durch die Kryptografie des Community-String und führte eine Kommunikation zwischen verschiedenen Managern ein.
- Durch den neuen GetBulk-Befehl wurde das Abfragen von Tabellen erheblich erleichtert.
- RFC 1441 – Introduction to version 2 of the Internet-standard Network Management Framework
- RFC 1445 – Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)
- RFC 1446 – Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)
- RFC 1447 – Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)
Diese Version wird heute nicht mehr verwendet.
User-Based SNMP Version 2 (SNMPv2u)
Bei SNMPv2u versucht man durch Benutzernamen die Sicherheit zu erhöhen.
- RFC 1909 – An Administrative Infrastructure for SNMPv2
- RFC 1910 – User-based Security Model for SNMPv2
Diese Version wird heute nicht mehr verwendet.
Community-Based SNMP Version 2 (SNMPv2c)
SNMPv2c ist bezüglich Sicherheit auf dem Stand von SNMPv1.
- Es ist lediglich erweitert um ein paar zusätzliche Funktionen, die es bereits bei SNMPv2p gab:
- Tabellen müssen nicht mehr mit dem GetNext-Befehl durchlaufen werden, sondern können mit dem GetBulk-Befehl auf einmal geholt werden.
- Kommunikation zwischen verschiedenen Managern.
Diese Version hat sich durchgesetzt und breite Akzeptanz erfahren.
- Wenn heutzutage von SNMPv2 gesprochen wird, ist meistens diese Version gemeint.
- RFC 1901 – Introduction to Community-based SNMPv2
- RFC 1905 – Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) (Ersetzte die RFC 1448)
- RFC 1906 – Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) (Ersetzte die RFC 1449)
Version 3
SNMP-Versionen 1 und 2c bieten fast keine Sicherheitsmechanismen.
- Daher stammt auch die scherzhafte Deutung der Abkürzung SNMP als „Security is not my problem“ (Sicherheit ist nicht mein Problem).
- In der aktuellen Version 3 wurden die Sicherheitsmechanismen deutlich ausgebaut.
- Die damit einhergehende gestiegene Komplexität (z. B. Schlüsselverwaltung) hat aber dazu geführt, dass SNMPv3 noch nicht so weit verbreitet ist wie SNMPv2.
SNMP in der neuesten Version 3 wird durch eine Reihe neuer RFCs definiert (die Spezifizierung erfolgte im Dezember 2002):
- RFC 3410 – Introduction and Applicability Statements for Internet-Standard Management Framework
- RFC 3411 – An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
- RFC 3412 – Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
- RFC 3413 – Simple Network Management Protocol (SNMP) Applications
- RFC 3414 – User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
- RFC 3415 – View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
- RFC 3416 – Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
- RFC 3417 – Transport Mappings for the Simple Network Management Protocol (SNMP)
- RFC 3418 – Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
Paketaufbau (SNMPv1)
Die Beschreibung der SNMP-Pakete erfolgt durch ASN.1, die Kodierung für den Transport über das Netzwerk mittels Basic Encoding Rules (BER).
- Die meisten SNMP-Pakete sind identisch aufgebaut.
- Lediglich bei Trap-Meldungen werden im PDU-Header teilweise andere Informationen versendet.
| SNMP-Paket-Header | PDU-Header | PDU-Body | |||||||
|---|---|---|---|---|---|---|---|---|---|
| Versionsnummer | Community-Name | Pakettyp (Get, GetNext …) | RequestID | Fehlerstatus | Fehler-Index | Variable Bindung 1 | Variable Bindung 2 | … | Variable Bindung n |
Der Paketaufbau eines SNMPv1-Pakets enthält keine Größenangabe, da jedes Feld mit Hilfe von ASN.1 in das Type-Length-Value-Format gebracht wird.
SNMP-Paket Header
Im Header wird die Versionsnummer (SNMPv1, SNMPv2 oder SNMPv3) und der Community Name übertragen.
- Durch das Zuweisen von Communities werden Zugriffsrechte vergeben.
- In den meisten Fällen wird für lesenden Zugriff (read-only) standardmäßig der Community Name "public", für Schreib-/Lesezugriff (read-write) "private" verwendet.
Da diese beiden Community Names als Standardeinstellung bekannt sind, sollten diese geändert werden.
- Allerdings erhöht dies die Sicherheit nicht zwangsläufig, da die Community Namen als Klartext über das Netzwerk übertragen werden.
PDU-Header (Nicht-Trap-Pakete)
Im ersten Teil des PDU-Headers wird die Art des SNMP-Paketes und die Größe der PDU übertragen.
- Der Aufbau des zweiten Teils hängt von der Art des SNMP-Paketes ab.
Damit Antwortpakete den vorherigen Anfragen zugeordnet werden können, gibt es die Request ID, welche bei Anfrage und Antwort identisch sind.
- Damit ist es möglich, mehrere Anfragen zu verschicken und die Antworten wieder richtig zuzuordnen.
Der Fehlerstatus und -index wird dazu verwendet, bei Antwortpaketen mitzuteilen, warum eine Anfrage nicht bearbeitet werden konnte.
- Solange kein Fehler auftritt, sind die beiden Felder mit dem Wert Null belegt.
- Im Fehlerfall gibt der Fehlerindex an, beim wievielten Datensatz der Fehler auftrat.
- Mit dem Fehlerstatus wird der Grund des Fehlers angegeben.
Der Fehlerstatus kann bei SNMPv1 einen von 6 möglichen Werten haben:
- kein Fehler
- Paket ist zu groß zum Versenden
- die OID wird nicht unterstützt
- falscher Datentyp oder Wert (nur als Antwort auf Set-Pakete möglich)
- nur Lesezugriff (nur als Antwort auf Set-Pakete möglich)
- unbekannter Generierungsfehler
PDU-Header (Trap-Pakete)
Die ersten beiden Felder des PDU-Headers sind bei Traps identisch mit denen anderer SNMP-Pakete.
- Das Feld Pakettyp gibt an, dass es sich um einen Trap handelt.
- Im zweiten Teil werden andere Werte übertragen, die nur bei Traps benötigt werden.
| PDU-Header | |||||
|---|---|---|---|---|---|
| Pakettyp (Trap) | OID des Gerätes, das den Trap generiert hat | IP-Adresse des Absenders | allgemeine TrapID | firmenspezifische TrapID | Zeitpunkt des Auftretens des Trap-Ereignisses |
Zum Erkennen, von wem die Nachricht kommt, wird die IP-Adresse des Absenders und dessen herstellerspezifische OID (1.3.6.1.4.1.*) mitgesendet.
- Die OID gibt an, um was für ein Gerät es sich handelt.
- Das ist wichtig zu wissen, wenn es sich um einen firmenspezifischen Trap handelt, der nur für diesen Gerätetyp gilt.
Danach folgt die allgemeine TrapID.
- Es gibt sieben mögliche allgemeine TrapIDs[2]:
| Bezeichnung | Wert in der Trap-PDU |
|---|---|
| Kaltstart (coldStart) | 0 |
| Warmstart (warmStart) | 1 |
| Link Down (linkDown) | 2 |
| Link Up (linkUp) | 3 |
| Authentifizierungsfehler (authenticationFailure) | 4 |
| EGP-Nachbar verloren (egpNeighborLoss) | 5 |
| firmenspezifisch (enterpriseSpecific) | 6 |
Wird im Feld "TrapID" "firmenspezifisch (enterpriseSpecific)" angegeben, so wird die ID der firmenspezifischen Trap im nachfolgenden Feld übertragen.
Da es möglich ist, dass Trap-Pakete nicht in der Reihenfolge eintreffen, wie sie versendet wurden, gibt es zusätzlich noch eine Zeitangabe, die auf Hundertstelsekunden genau angibt, wie lang der SNMP-Agent gelaufen ist, bis das Trap-Ereignis auftrat.
- Dadurch ist es möglich die Trap-Ereignisse in die zeitlich richtige Reihenfolge zu bringen.
PDU-Body
Im PDU-Body werden die eigentlichen Werte übertragen. Jeder Wert wird in einer sogenannten Variable Binding übertragen.
| OID | Variable Binding |
| Wert |
Zu einer Variable Binding gehören deren OID und der Wert selber.
Es gibt keine Vorgabe, wie viele Variable Bindings im PDU-Body mitgeschickt werden dürfen.
- Es ist also möglich, mehrere Werte mit einem Get-Befehl abzufragen.
- Wenn aber das Antwortpaket dabei zu groß wird, kann es passieren, dass die entsprechende Fehlermeldung im Antwortpaket zurückgeschickt wird.
Bei Traps ist es auch möglich, dass keine Variable Bindings mitgeschickt werden.
- In dem Fall wird die TrapID als ausreichende Information angesehen.
Im SNMP-Paket ist keine Angabe vorgesehen, welche die Anzahl an mitgeschickten Variable Bindings angibt.
- Das lässt sich nur über die Größenangabe des PDU-Bodys und der Größenangabe der einzelnen Variable Bindings herausfinden.
Sicherheitsprobleme
Ein Nachteil von SNMP Version 1 bis 2c ist die fehlende Sicherheit.
- Diese Versionen von SNMP unterstützen keine Anmeldung mit Kennwort und Benutzernamen, es werden sogenannte Communities verwendet.
- Diese haben jedoch den Nachteil, dass jeder User im Netzwerk mit einem passenden Programm Systeminformationen auslesen und sogar Werte verändern kann.
Communities sind einfache Namen, wie zum Beispiel „PUBLIC“ (darf nur lesen) oder „PRIVATE“ (darf auch schreiben), die mit der Anfrage zusammen vom SNMP-Service übermittelt werden.
- Sie sind nichts anderes als ein vorher vereinbarter Schlüssel (Pre-shared keys).
Man kann natürlich auch sehr lange und komplizierte Community-Namen verwenden.
- Das ist allerdings von begrenztem Nutzen, da SNMP-Pakete nicht verschlüsselt sind und deshalb sehr einfach von einem Angreifer „gesnifft“ (abgehört) werden können.
Allowed Host: Es gibt jedoch die Möglichkeit, die IP-Adressen der Systeme einzuschränken, die mit einem überwachten SNMP-System Kontakt aufnehmen dürfen.
- Das ist ein relativ einfacher Schutz, der sich jedoch möglicherweise mit ARP-Spoofing und IP-Spoofing aushebeln lässt.
Management-Schutz: Seit Anfang der 1990er Jahre ist es üblich, dass man für die Überwachung der Systeme ein eigenes Netzwerk erstellt, um den Nutzdaten-Verkehr vom Management-Verkehr zu trennen.
- Dies wird Out-of-Band genannt.
- Verkehr, der über das herkömmliche Datennetz fließt, wird als Inband-Kommunikation bezeichnet.
Read Only: Es besteht auch die Möglichkeit, auf gewisse Systeme ein „Read Only“ zu vergeben.
- Somit kann jedes Überwachungsgerät nur lesen.
- Das wird häufig bei Routern verwendet.
SNMP Version 3 bietet unter anderem Kryptografie und eine bessere Authentifizierung, was zurzeit aber wegen der höheren Komplexität oft nicht genutzt wird.
Siehe auch
- Agent Extensibility Protocol (AgentX)
Dokumentation
RFC
Links
Weblinks
- http://www.oid-info.com
- http://www.snmp.com/FAQs/snmp-faq-part1.txt
- http://www.snmp.com/FAQs/snmp-faq-part2.txt
- ↑ http://www.dpstele.com/white-papers/snmp-tutorial/snmp_glossary.php
- ↑ RFC2089. Mapping SNMPv2 onto SNMPv1