1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Monitoring: Zabbix 2.0…

Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

Über PC-Games lässt sich am besten ohne nerviges Gedöns oder Flamewar labern! Dafür gibt's den Freiraum!
  1. Thema

Neues Thema Ansicht wechseln


  1. Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: bitshift 23.05.12 - 14:29

    Hi,

    Leider scheint auch bei Zabbix das Problem zu bestehen, dass die Kommunikation zwischen Client und Server nicht verschlüsselt ist: https://support.zabbix.com/browse/ZBXNEXT-17

    Das trifft irgendwie auf alle gängigen Monitoring-Lösungen zu. Oder, sofern kein Client eingesetzt wird, werden IMHO teils dicke Löcher in das System gebohrt, damit Kommandos vom Monitoring zur sammeln der Daten z.B. per SSH ausgeführt werden können... scheint z.B. im Nagios-Umfeld gängig zu sein.

    Lange Rede kurzer Sinn: ich bin auf der Suche nach einer Monitoring-Lösung, mit der ich Server in verschiedenen Rechenzentren möglichst über das Internet monitoren kann, ohne nachts ungut zu schlafen. Die Client-Server-Architektur von Zabbix ist sehr angenehm und die Datensammlung des Zabbix-Clients läuft recht ressourcenschonend. Aber die unverschlüsselte Kommunikation ist für mich ein no-go.

    Hat mir vllt. jemand einen Tipp für eine Lösung? Am besten:
    - Kein SSH-Zugang auf die zu monitorenden Clients benötigt
    - Ein wie auch immer gearteter, zu installierender Agent auf den zu monitorenden Clients ist kein Problem, solange er keinen Netzwerkdienst auf eben jenem auf macht.
    - Falls möglich: OpenSource. Darf auch was kosten, aber die Quellen sollten offen liegen.

    Gruß
    bitshift
    - Sichere Kommunikation der Monitoring-Daten auch über das Internet.

    Gruß
    bitshift

  2. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: Helm 23.05.12 - 15:10

    Hallo,

    mich würde interessieren, weshalb du keinen SSH-Zugang benötigen möchtest?
    Das ist doch ein sehr sicheres Zugangsverfahren, welches sich sogar so verdongeln lässt, dass der Benutzer nur einen einzigen Befehl ausführen darf und nicht einmal eine Loginshell bekommt.

    Ich empfehle generell check_mk, bzw eine Lösung auf Basis von OMD (www.omdistro.org). Allerdings ist dies natürlich eine nagiosnahe Lösung.

    Mich würden aber wirklich fundierte Einwände gegen den Einsatz von SSH interessieren.

    mfg
    Helm

  3. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: Chardonnay 23.05.12 - 17:07

    @Helm

    Jede Abfrage per Nagios-Plugin über eine seperate SSH-Verbindung durchzuführen ist unsinn.
    Größere Netzwerke lassen sich nur über einen effizenten Nagios-Client durchführen.
    Sonst dauern die Test ewig!

    PS: Nagios Client-Server Verbindungen sind i.d.R. per OpenSSH verschlüsselt!

  4. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: bitshift 23.05.12 - 17:29

    Es geht nicht um den SSH-Zugang als solchen. SSH-Zugriff für z.B. Administratoren mit ordentlichen Key-Managment plus - bei sicherheitskritischen Systemen zusätzlich mittels Hardware-Token - passt.

    Worauf ich hinaus will ist: das Monitoring muss Daten vom Client sammeln. Zum einen kann ein Monitoring-System öffentliche Daten beziehen (also "ist das System Online? Wie schnell antwortet es?" etc.), zum anderen braucht man aber auch Daten, die man nur auf dem System selbst erfassen kann.

    Bei Geräten muss eben SNMP herhalten (auch wenn das oft ein wahres Sicherheitsdesaster ist, vgl. https://secure.wikimedia.org/wikipedia/de/wiki/SNMP#Sicherheitsprobleme ). Bei Servern läuft es normal anders. Entweder werden Daten über Scripte oder z.B. eine Art Agent gesammelt.

    Der Zabbix-Client macht das recht intelilgent und leichtgewichtig. Es ist für BSD/Linux/Windows verfügbar und sammelt viele Daten die man so haben möchte, ohne eigene Scripte oder ähnliches schreiben zu müssen, und kann diese dann an den Zabbix-Server übermitteln. Installieren, fertig. Das Monitoring ist so sehr schnell und ressourcenschonend umsetzbar. Nur leider ist diese Datenübermittlung zum Server selbst nicht verschlüsselt und die Übertragung so ggf. auch leicht manipulierbar. Dennoch ist das recht sauber, da der Zabbix-Client nicht einfach Shell-Befehle oder ähnliches auf den Systemen ausführt. D.h. wenn der Monitoring-Server gehackt wird, hat der Eindringling nicht über das Monitoring vollen Zugriff auf die Nodes.

    Genau das ist das Problem, dass ich mit Nagios habe, sofern ich bei meinen Recherchen alles richtig verstanden habe. Es ist durchaus gängig, Nagios-Plugins auf den Clients per SSH aufzurufen und dort mit administrativen Rechten zum Datensammeln auszuführen. Was ich bisher so gesehen habe frisst nicht nur CPU ohne Ende (im vergleich zu z.B. Zabbix), sonder ist eben auch ein Sicherheitsproblem. Wird der Nagios-Server gehcakt hat man durch die Nagios-SSH-Zugänge eine Remote-Shell auf allen Clients mit Addons, die ggf. mit root-Rechten laufen und manipuliert werden können.
    Es gibt noch den Nagios Remote Plugin Executor, der das ganze dann auch ohne Remote-Shell abhandeln kann (und auch Ressourcenschonender ist). Ist aber sehr viel frickeliger als Zabbix (=ein Agent vs. zig Nagios Plugins oft zweifelhafter Qualität) und man hat danna uch wieder das "wird nicht verschlüsselt übertragen"-Problem, weil wiederum kein SSH-Tunnel genutzt wird.

    Da ich mir kaum vorstellen kann, dass nicht nur ich Probleme damit habe das:

    a) auf jedem Client ein SSH-Zugang fürs Monitoring existiert der Plugins mit root-Rechten ausführt und somit das gesamte Netzwerk von der Sicherheit des zentralen Monitoring-Servers abhängt

    b) Man alternativ nur sämtliche Monitoring-Daten unverschlüsselt durch das Netz jagen kann

    dachte ich, ich frage mal nach. Ich bin wie gesagt noch recht neu in der Thematik. Vllt. übersehe ich ja auch etwas ganz offensichtliches. Wäre eine Client-Server-Authentifizierung + verschlüsselte Übertragung implementiert, käme Zabbix meinen Idealvorstellungen recht nahe. Auf die verschlüsselte Verbindung könnte man u.U. sogar verzichten, wenn die Authentifizierung sicherstellt, dass nur bekannte Clients Daten übertragen können und Manipulation erschwert wird. Für Tipps wäre ich wirklich dankbar. Ansonsten wird es wohl auf viel Frickel mit Nagios + Nagios Remote Plugin Executor auf den Clients rauslaufen, sofern ich nichts offensichtliches übersehe.



    2 mal bearbeitet, zuletzt am 23.05.12 17:33 durch bitshift.

  5. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: Chardonnay 23.05.12 - 17:57

    "Bei Geräten muss eben SNMP herhalten (auch wenn das oft ein wahres Sicherheitsdesaster ist, vgl. https://secure.wikimedia.org/wikipedia/de/wiki/SNMP#Sicherheitsprobleme ). Bei Servern läuft es normal anders. Entweder werden Daten über Scripte oder z.B. eine Art Agent gesammelt. "

    Wer hat dir denn das erzählt ?
    Mit SNMP kannst Du oft auch viele Programme monitoren!
    Die Progs müssen halt das SNMP Protokoll unterstützen.
    Und über SNMP geht das Monitoring wesentlich schneller als über olle Shell/Perl/Python/Ruby Skripte!
    Es gibt extra dafür ein SNMP Modul (in C geschrieben) das Optimal für SNMP ABfragen zu verwenden ist.

    Der Nagios NRPE Daemon baut eine verschlüsselte Verbindung zum Nagios-Server auf und zeichnet auch Performance/Fehler-Daten auf, falls der Server nicht online ist oder das Netz gestört.
    Jedes Mal eine Abfrage per SSH zu starten ist absolut unprofessionell und extrem fehleranfällig!

  6. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: bitshift 23.05.12 - 18:44

    Chardonnay schrieb:
    --------------------------------------------------------------------------------
    > "Bei Geräten muss eben SNMP herhalten (auch wenn das oft ein wahres
    > Sicherheitsdesaster ist, vgl. secure.wikimedia.org#Sicherheitsprobleme ).
    > Bei Servern läuft es normal anders. Entweder werden Daten über Scripte oder
    > z.B. eine Art Agent gesammelt. "
    >
    > Wer hat dir denn das erzählt ?
    > Mit SNMP kannst Du oft auch viele Programme monitoren!
    > Die Progs müssen halt das SNMP Protokoll unterstützen.

    kommt wie gesagt ganz und gar auf das Programm an. Worauf ich mit dem Satz hinaus wollte ist, dass man an SNMP im LAN(!) nicht vorbeikommen, da man schlecht einen Router oder andere Geräte ohne SNMP abfragen kann. Es ist und bleibt aber eine Krücke, dass viel SNMPv1 und 2 unterwegs ist (vgl. https://secure.wikimedia.org/wikipedia/de/wiki/SNMP#Sicherheitsprobleme):
    "Ein schwacher Aspekt von SNMP Version 1 bis 2c ist die 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.

    SNMP Version 3 bietet unter anderem Verschlüsselung und bessere Authentifizierung; das wird aber zur Zeit wegen der höheren Komplexität oft nicht genutzt."

    Und SNMP über Internet? Sicher nicht :-)

    > Und über SNMP geht das Monitoring wesentlich schneller als über olle
    > Shell/Perl/Python/Ruby Skripte!

    Schon klar, aber wie gesagt vom Programm abhängig. Zabbix nutzt ja auch keine ollen Scripte, sondern einen ausgereift wirkenden, in C geschriebenen Agent.

    > Es gibt extra dafür ein SNMP Modul (in C geschrieben) das Optimal für SNMP
    > ABfragen zu verwenden ist.
    >
    > Der Nagios NRPE Daemon baut eine verschlüsselte Verbindung zum
    > Nagios-Server auf und zeichnet auch Performance/Fehler-Daten auf, falls der
    > Server nicht online ist oder das Netz gestört.
    > Jedes Mal eine Abfrage per SSH zu starten ist absolut unprofessionell und
    > extrem fehleranfällig!

    Danke für einen Input :-). Ich denke, ich werde mir jetzt mal Nagios + NRPE Daemon sowie Zabbix genauer anschauen.

  7. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: Helm 23.05.12 - 19:59

    bitshift schrieb:
    --------------------------------------------------------------------------------
    > Genau das ist das Problem, dass ich mit Nagios habe, sofern ich bei meinen
    > Recherchen alles richtig verstanden habe. Es ist durchaus gängig,
    > Nagios-Plugins auf den Clients per SSH aufzurufen und dort mit
    > administrativen Rechten zum Datensammeln auszuführen. Was ich bisher so
    > gesehen habe frisst nicht nur CPU ohne Ende (im vergleich zu z.B. Zabbix),
    > sonder ist eben auch ein Sicherheitsproblem. Wird der Nagios-Server gehcakt
    > hat man durch die Nagios-SSH-Zugänge eine Remote-Shell auf allen Clients
    > mit Addons, die ggf. mit root-Rechten laufen und manipuliert werden
    > können.
    Schau dir einmal check_mk an:
    http://mathias-kettner.de/check_mk.html
    Es ist ein Nagiosplugin (von der reinen Architektur), welches Nagios aber die komplette Arbeit im Prinzip abnimmt.
    Du kannst es so absichern, dass der check_mk_key nur den check_mk_agent auf dem zu monitorenden Server ausführt und das reicht auch für das komplette Monitoring jedes Servers, da du den Agent um lokale Scripts erweitern kannst.
    Die Absicherung geht wie in folgender Anleitung:
    http://mathias-kettner.de/checkmk_datasource_programs.html
    Besonders wichtig:
    http://mathias-kettner.de/checkmk_datasource_programs.html#H1:Restricting%20SSH%20and%20making%20it%20safe

    Ich arbeite nicht für den Hersteller oder so, bin nur begeisterter Anwender.
    Weiterhin hat das Tool den großen Vorteil, dass man viele Checks nicht mehr konfigurieren muss, da Sie bereits in check_mk enthalten sind (Standardchecks wie ping, filesysteme, cpu-Auslastung, etc.)

    Ich hoffe das hilft dir weiter, generell kann diese Vorgehensweise natürlich für jede Monitoringlösung benutzt werden, welche nur einen Agent callen muss.

    @Chardonnay: Das ist der Witz an check_mk, es wird nur eine Anfrage an den Agent gestellt und dieser Antwort mit allen Daten des Clients, welche vorhanden sind, keine Einzelanfragen pro Servicecheck mehr-> Wesentlich bessere Performance.

    Zabbix kannte ich bisher noch nicht, werde es mir einmal ansehen.

  8. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: oSu. 23.05.12 - 21:08

    bitshift schrieb:
    --------------------------------------------------------------------------------

    > Genau das ist das Problem, dass ich mit Nagios habe, sofern ich bei meinen
    > Recherchen alles richtig verstanden habe. Es ist durchaus gängig,
    > Nagios-Plugins auf den Clients per SSH aufzurufen und dort mit
    > administrativen Rechten zum Datensammeln auszuführen.

    Ich denke da hast Du etwas falsch verstanden.
    Im Normalfall wird kein SSH für das Nagios Monitoring eingesetzt.

    > Was ich bisher so
    > gesehen habe frisst nicht nur CPU ohne Ende (im vergleich zu z.B. Zabbix),
    > sonder ist eben auch ein Sicherheitsproblem. Wird der Nagios-Server gehcakt
    > hat man durch die Nagios-SSH-Zugänge eine Remote-Shell auf allen Clients
    > mit Addons, die ggf. mit root-Rechten laufen und manipuliert werden
    > können.

    Genau aus den von Dir genannten Gründen sollte SSH auch nur eingesetzt werden, wenn es gar nicht anders geht.

    > Es gibt noch den Nagios Remote Plugin Executor, der das ganze dann auch
    > ohne Remote-Shell abhandeln kann (und auch Ressourcenschonender ist).

    So ist es.

    > Ist aber sehr viel frickeliger als Zabbix (=ein Agent vs. zig Nagios Plugins
    > oft zweifelhafter Qualität) und man hat danna uch wieder das "wird nicht
    > verschlüsselt übertragen"-Problem, weil wiederum kein SSH-Tunnel genutzt
    > wird.

    Da bist Du falsch informiert, die Kommunikation zwischen dem Nagios Server und dem NRPE erfolgt über eine SSL gesicherte Verbindung.

    > Für Tipps wäre ich wirklich dankbar. Ansonsten
    > wird es wohl auf viel Frickel mit Nagios + Nagios Remote Plugin Executor
    > auf den Clients rauslaufen, sofern ich nichts offensichtliches übersehe.

    Wenn man das Prinzip einmal verstanden hat, ist die Frickelei relativ schnell erledigt.
    Außerdem ist der Einsatz von Nagios + NRPE bzw. NSCA, im Falle eines Hacks des Nagios Servers, deutlich sicherer als die SSH Variante.
    Die von Dir befürchtete schlechte Qualität der Nagios Plugins kann ich zumindest für die Standard Plugins nicht bestätigen.

    Außerdem erwartet Dich eine sehr hilfsbereite Nagios Community.
    Wenn Du noch Fragen hast, poste sie einfach hier und es wird Dir schnell geholfen.
    http://www.monitoring-portal.org

    Weitehin gibt es einen Fork von Nagios der wesentlich aktiver weiterentwickelt wird und eine zeitgemäße Web-GUI besitzt.
    Nähere Infos findes Du auf https://www.icinga.org/
    Und hier gibt es eine Online Demo http://web.demo.icinga.org/icinga-web/



    2 mal bearbeitet, zuletzt am 23.05.12 21:20 durch oSu..

  9. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: Helm 23.05.12 - 21:40

    Ich weiß nicht was hier alle gegen SSH haben, eventuell stimmen eure Vorbehalte, wenn man Nagios pur oder mit altertümlichen Plugins einsetzt, die Performance von check_mk ist jedenfalls extrem gut und um etliche Faktoren schneller, da der Core von Nagios praktisch nicht mehr genutzt wird.
    Wir setzen das System erfolgreich mit SSH ein und ich kann auch kein Sicherheitsloch erkennen, wenn der user nur einen einzigen Befehl ausführen kann und eben keine Loginshell bekommt.

    mfg
    Helm

  10. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: Colttt 24.05.12 - 12:03

    Hihi,

    es gibt einen Patch in zabbix der die verbindung verschlüsselt, ist aber nicht offiziell und noch in der Beta-phase, aber es gibt einige die es schon nutzen, ansonsten warte einfach noch, das wird definitiv noch in zabbix kommen, also die verschlüsselung.

    Ansonsten würde ich es so machen: zabbix server -- zabbix proxy -- zabbix-agents.. der proxy sammelt die daten und schickt sie zum zabbix server, der port wird via ssh zum server geleitet und das it die einfachste und aktuell eleganteste art das zu machen vor allem dann wenn man mehrere standorte monitoren will..

  11. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: bitshift 25.05.12 - 15:41

    gut zu wissen... hast du mir vllt. einen Link zu dem crypto-Zabbix-Patch?

    @Helm: danke für die ganzen Tipps. :-)

  12. Re: Alternativen? Client-Sever-Kommunikation inzwischen verschlüsselt?

    Autor: Colttt 26.05.12 - 01:48

    hier hast du das was du suchst:
    http://zabbix.org/wiki/Active_agent_authentication

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Bundeskriminalamt, Wiesbaden
  2. via 3C - Career Consulting Company GmbH, München, Stuttgart, Berlin, Hamburg, Köln (Home-Office)
  3. Bundesamt für Sicherheit in der Informationstechnik, Bonn
  4. Pro Projekte-GmbH & Co. KG, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 1.555,00€ (Bestpreis!)
  2. 49,90€ (Bestpreis!)
  3. (u. a. Galaxy Tab S6 Lite für 299,99€, Nintendo Ring Fit Adventure für 79,99€, Samsung Galaxy...
  4. (u. a. 24-Stunden-Deals, Sandisk Ultra 3D 2 TB SATA-SSD für 159,00€, LG OLED TV für 1.839...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme