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

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

  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. Zum Login

Stellenmarkt
  1. BWI GmbH, Meckenheim
  2. DATAGROUP Köln GmbH, Düsseldorf
  3. BWI GmbH, Bonn
  4. Stiftung Hannoversche Kinderheilanstalt, Hannover

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 72,99€ (Release am 19. September)
  2. 289€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Timex Data Link im Retro-Test: Bill Gates' Astronauten-Smartwatch
Timex Data Link im Retro-Test
Bill Gates' Astronauten-Smartwatch

Mit der Data Link haben Timex und Microsoft bereits vor 25 Jahren die erste richtige Smartwatch vorgestellt. Sie hat es sogar bis in den Weltraum geschafft. Das Highlight ist die drahtlose Datenübertragung per flackerndem Röhrenmonitor - was wir natürlich ausprobieren mussten.
Ein Test von Tobias Költzsch

  1. Smart Watch Swatch fordert wegen kopierter Zifferblätter von Samsung Geld
  2. Wearable EU warnt vor deutscher Kinder-Smartwatch
  3. Sportuhr Fossil stellt Smartwatch mit Snapdragon 3100 vor

Projektmanagement: An der falschen Stelle automatisiert
Projektmanagement
An der falschen Stelle automatisiert

Kommunikationstools und künstliche Intelligenz sollen dabei helfen, dass IT-Projekte besser und schneller fertig werden. Demnächst sollen sie sogar Posten wie den des Projektmanagers überflüssig machen. Doch das wird voraussichtlich nicht passieren.
Ein Erfahrungsbericht von Marvin Engel


    Ocean Discovery X Prize: Autonome Fraunhofer-Roboter erforschen die Tiefsee
    Ocean Discovery X Prize
    Autonome Fraunhofer-Roboter erforschen die Tiefsee

    Öffentliche Vergaberichtlinien und agile Arbeitsweise: Die Teilnahme am Ocean Discovery X Prize war nicht einfach für die Forscher des Fraunhofer Instituts IOSB. Deren autonome Tauchroboter zur Tiefseekartierung schafften es unter die besten fünf weltweit.
    Ein Bericht von Werner Pluta

    1. JAB Code Bunter Barcode gegen Fälschungen

    1. Schnittstellen-Standard: Displayport 2.0 schafft 8K bei 60 Hz mit HDR10
      Schnittstellen-Standard
      Displayport 2.0 schafft 8K bei 60 Hz mit HDR10

      Gut drei Jahre nach Displayport 1.4 erscheint Displayport 2.0: Der Standard liefert bis zu 16K bei 60 Hz samt High Dynamic Range, ohne Kompression immer noch 8K60 mit HDR. Wie schon USB 4 setzt auch Displayport 2.0 auf Thunderbolt 3 als Interface, USB-C als Stecker ist optional.

    2. Dresden: HP und Zoll beschlagnahmen gefälschte Toner-Kartuschen
      Dresden
      HP und Zoll beschlagnahmen gefälschte Toner-Kartuschen

      Rund 4.000 nachgemachte Toner-Kartuschen von HP hat der Zoll in Dresden sichergestellt. Dazu hatte HP Informationen geliefert. HP macht einen Großteil seiner Gewinne mit Verbrauchsmaterialien.

    3. DSGVO-Anpassung: Koalition will mehr als 150 Gesetze ändern
      DSGVO-Anpassung
      Koalition will mehr als 150 Gesetze ändern

      Noch vor der Sommerpause will die Koalition viele Datenschutzvorgaben an die DSGVO anpassen. Bei umstrittenen Themen soll es vorerst jedoch keine Klarstellung geben. Kritik gibt es zu einer Änderung bei betrieblichen Datenschutzexperten.


    1. 16:45

    2. 16:31

    3. 15:40

    4. 15:27

    5. 14:40

    6. 14:25

    7. 13:48

    8. 13:39