SNMP Überwachung
Hallo Freunde,
wir setzen zur Zeit die Überwachungssoftware Proactivewatch vom Hersteller Rapidfiretools ein. Jetzt war ich gerade dabei, die SNMP-Überwachung einzurichten. Ich habe soweit alle OIDs und deren Vergleichswert von unseren Servern. Habe dies auch so eingetragen im Proactivewatch zum Testen. Siehe . Natürlich habe ich auch die Server soweit eingerichtet, dass ich die Überwachung aktiviert habe. Siehe und . Leider funktioniert dies nach wie vor nicht. Beim ziehen einer Platte übergibt er keine RAID Fehlermeldung. Wisst ihr, ob ich was vergessen habe einzustellen?
Es handelt sich um einen HP Proliant Server mit Windows 2008 R2 als Betriebssystem. Ich weiß dass die Überwachung funktioniert, da unser altes System (GFI Max) noch die Hardwaretestüberprüfung erstellen kann (Siehe ). Über jede mögliche Hilfe bin ich äußerst dankbar!!
Vielen Dank.
Mit freundlichen Grüßen
Neuling
wir setzen zur Zeit die Überwachungssoftware Proactivewatch vom Hersteller Rapidfiretools ein. Jetzt war ich gerade dabei, die SNMP-Überwachung einzurichten. Ich habe soweit alle OIDs und deren Vergleichswert von unseren Servern. Habe dies auch so eingetragen im Proactivewatch zum Testen. Siehe . Natürlich habe ich auch die Server soweit eingerichtet, dass ich die Überwachung aktiviert habe. Siehe und . Leider funktioniert dies nach wie vor nicht. Beim ziehen einer Platte übergibt er keine RAID Fehlermeldung. Wisst ihr, ob ich was vergessen habe einzustellen?
Es handelt sich um einen HP Proliant Server mit Windows 2008 R2 als Betriebssystem. Ich weiß dass die Überwachung funktioniert, da unser altes System (GFI Max) noch die Hardwaretestüberprüfung erstellen kann (Siehe ). Über jede mögliche Hilfe bin ich äußerst dankbar!!
Vielen Dank.
Mit freundlichen Grüßen
Neuling
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 228660
Url: https://administrator.de/contentid/228660
Ausgedruckt am: 26.11.2024 um 11:11 Uhr
6 Kommentare
Neuester Kommentar
Siehe Screenshot 1... Siehe Screenshot 2 und 3
Wo sollen die denn bitte sein ???...Die kann man aber nicht sehen im obigen Thread ?!Tip: Thread auf "Bearbeiten" klicken, Hochladen mit der Bilder Upload Funktion und Bilder URL mit cut and paste in den Text klicken.... (FaQs lesen hilft !)
Hast du mit den Net-SNMP Tools http://www.net-snmp.org oder dem Paessler SNMP Browser http://www.de.paessler.com/tools/snmptester einmal manuell diese OIDs abgefragt um zu sehen ob diese Änderungen überhaupt im SNMP Daemon registriert werden ??
"Mit freundlichen Grüßen"
Nein, das ist kein Test sondern lediglich die Pauschalaussage das SNMP geht...mehr aber auch nicht. Du hast auch keinerlei Customization gemacht was aus Sicherheitssicht sträflich und fahrlässig ist ! Was die Screenshots lediglich zeigen ist das der Dienst gestartet ist..mehr nicht.
Wenn SNMP sets und gets z.B. aus anderen Netzwerken kommen bleiben sie in der Firewall hängen usw. SNMP Traps sendet er nur an sich selber was auch unüblich ist.
Das ist so als wenn du behaupten würdest ein Webserver funktioniert nur weil du ihn anpingen kannst, das ist also Unsinn...weist du aber sicher selber !
Frage also mit snmpwalk oder -get genau die relevante OID mit den oben genannten SNMP Tools ab dann weisst du ganz genau ob da ein gültiger Inhalt drin ist und ob diese OID überhaupt benutzt wird !!
Nochwas...:
Den Community String "public" zu verwenden ist bei SNMP eingentlich tödlich, denn das ist der Default den jeder eingestellt hat. Damit kann dann jeder Dummie mit jedem beliebigen SNMP Browser diese Daten abfragen.
Kein verantwortungsvoller Netzwerker macht sowas nur blutige Laien !! Die Strings "public" und "private" da konfiguriert zu lassen ist sträflicher Sicherheitsleichtsinn, speziell was den RW String "private" anbetrifft ! Damit exponierst du den Server für SNMP Angriffe.
Auch wenn das RO Daten sind verschleiert man diese doch bei v1 oder v2 wenigstens mit einem nicht so leicht erratbaren Community String (bei RW so oder so zwingend) oder wenn man es wirklich richtig macht benutzt man SNMPv3 dafür was verschlüsselt ist !
Wenn SNMP sets und gets z.B. aus anderen Netzwerken kommen bleiben sie in der Firewall hängen usw. SNMP Traps sendet er nur an sich selber was auch unüblich ist.
Das ist so als wenn du behaupten würdest ein Webserver funktioniert nur weil du ihn anpingen kannst, das ist also Unsinn...weist du aber sicher selber !
Frage also mit snmpwalk oder -get genau die relevante OID mit den oben genannten SNMP Tools ab dann weisst du ganz genau ob da ein gültiger Inhalt drin ist und ob diese OID überhaupt benutzt wird !!
Nochwas...:
Den Community String "public" zu verwenden ist bei SNMP eingentlich tödlich, denn das ist der Default den jeder eingestellt hat. Damit kann dann jeder Dummie mit jedem beliebigen SNMP Browser diese Daten abfragen.
Kein verantwortungsvoller Netzwerker macht sowas nur blutige Laien !! Die Strings "public" und "private" da konfiguriert zu lassen ist sträflicher Sicherheitsleichtsinn, speziell was den RW String "private" anbetrifft ! Damit exponierst du den Server für SNMP Angriffe.
Auch wenn das RO Daten sind verschleiert man diese doch bei v1 oder v2 wenigstens mit einem nicht so leicht erratbaren Community String (bei RW so oder so zwingend) oder wenn man es wirklich richtig macht benutzt man SNMPv3 dafür was verschlüsselt ist !
@aqui, solang nicht SNMP v3 verwendet wird ist es Schnurtze-Piepe-Egal welche Community verwendet wird, da die Community aus den übertragenen Paketen auslesbar ist.
Die einzige Möglichkeit SNMP v1 und v2(c) abzusichern ist imo über die Begrenzung der Kommunikation auf EngineIDs und direkten IPs, und selbst dass ist nicht wirklich sicher, da sich auch die EngineIDs ebenfalls aus den Paketen auslesen lassen. Und IPs... naja
Aber sonst kann ich dir voll und ganz zustimmen. SNMP v3 all-the-way.
Grüße,
Philip
Die einzige Möglichkeit SNMP v1 und v2(c) abzusichern ist imo über die Begrenzung der Kommunikation auf EngineIDs und direkten IPs, und selbst dass ist nicht wirklich sicher, da sich auch die EngineIDs ebenfalls aus den Paketen auslesen lassen. Und IPs... naja
Aber sonst kann ich dir voll und ganz zustimmen. SNMP v3 all-the-way.
Grüße,
Philip