Monitoring mit SSL

This forum was archived to /woltlab and is now in read-only mode.
  • Hallo zusammen,


    Ich stehe gerade vor der Frage, ob es denn möglich ist die ganzen checks die man übergibt meist mit nsclient oder per wmi mit ssl abzusichern?


    Ich habe leider echt kein blassen schimmer wo ich anfangen soll, da irgendwie nichts für noobs im Netz verständlich dokumentiert ist.

    Was genau wäre dabei zu beachten? Was brauche ich dafür? und wie bewerkstellige ich das ganze mit einer Grundinstallation?


    Ich gebe zu mir fehlt dafür auch ein bisschen das KnowHow dafür aber im Zusammenhang mit Monitoring habe ich nichts akzeptables gefunden und wäre froh wenn jemand hier entsprechende HowTo's hat oder auch selber es erklären könnte.


    Dabei ist es natürlich auch gut zu wissen was gegenseitig (Windows <-> Linux; Client <-> Server) zu beachten ist.


    Ich habe das tolle HowTo von Mickem (https://medin.name/blog/2012/1…ate-based-authentication/) schon gelesen, aber leider kein Wort verstanden.

    Auch im Issue auf seinem git repo konnte ich mir keinen Reim machen.

  • Ich gebe zu mir fehlt dafür auch ein bisschen das KnowHow dafür aber im Zusammenhang mit Monitoring habe ich nichts akzeptables gefunden

    Die Grundidee - eine Vertrauensbeziehung zwischen zwei Rechnern herzustellen - ist unabhängig vom Monitoring. Das gilt auch für die Funktion des Rechners, denn ob Client/Server oder zwei Peers, ändert nichts daran.


    Ich habe das tolle HowTo von Mickem (https://medin.name/blog/2012/1…ate-based-authentication/) schon gelesen, aber leider kein Wort verstanden.

    Im Moment gehe ich davon aus, daß das nicht am englischen Text, sondern am Inhalt liegt. Insofern wäre es hilfreich zu wissen, was unklar ist.

  • Ja, das es davon nicht abhängt das ist mir bewusst. Aber in erster Linie geht es eher genau darum. Aktuell läuft alles intern daher war das bisher kein großes Thema. In naher Zukunft werden aber Linux Webserver hinzukommen, die extern bei einem Hoster liegen.


    Diese wollen wir dementsprechend nicht ohne ssl ins monitoring aufnehmen. Und wenn wir schon dabei sind, wäre es sinnvoll gleich alles so umzustellen, dass es safe ist. Aber wie gesagt fehlt mir dazu irgendwo der Ansatz. Ich weiß nicht wo ich anfangen soll und habe diesbezüglich nichts gefunden. Meinetwegen habe ich auch nicht nach dem richtigen Begriffen gesucht und darum habe ich die Anfrage gestellt.


    Versteh mich nicht falsch ich will nicht einfach nur blind ein Tutorial runtertippen, aber es hilft ungemein manchmal. (Und ja, es lag nicht an der Sprache ^^)

  • Verständlich, ich weiß ja schon was SSL ist und was dahintersteckt, ganz blöd bin ich ja auch nicht ;)

    Es geht mehr um das WIE ich es bewerkstellige. Was muss ich tun um die Kommunikation von nrpe zB zwischen meinem Icinga und einem Client (OS egal) zu verschlüsseln. Wie ich ein SSL Zertifikat auf dem Apache einbinde ist auch nicht das Problem (und auch nicht die Frage gewesen), hatte ich auf Web2 auch gemacht. Dann aber wieder gelassen wegen den Iframes von Graphite *seufz*.

  • Was muss ich tun um die Kommunikation von nrpe zB zwischen meinem Icinga und einem Client (OS egal) zu verschlüsseln.

    Code
    1. Usage: check_nrpe -H <host> [-n] [-u] [-p <port>] [-t <timeout>] [-c <command>] [-a <arglist...>]
    2. Options:
    3. -n = Do no use SSL

    Diese Option NICHT benutzen?

  • Richtig, funktioniert aber nicht ohne vorher Arbeit geleistet zu haben.

    Es ist ja nicht so, das ich nicht schon ein bisschen rumprobiert und recherchiert habe, nur irgendwie auf keinen gemeinsamen Nenner kommen konnte.


    Bestes Beispiel ist folgende Meldung: Could not complete SSL Handshake.

    Und was wird zu 90% als Lösung geboten? Richtig: -n


    Verstehst du was ich meine?

  • Bestes Beispiel ist folgende Meldung: Could not complete SSL Handshake.

    Und was wird zu 90% als Lösung geboten? Richtig: -n


    Verstehst du was ich meine?

    Ich vermute, daß bei fehlerhaftem SSL-Connect geraten wird, mit Hilfe der Option "-n" auf die Nutzung von SSL zu verzichten. Meinst du das?

    Richtig, funktioniert aber nicht ohne vorher Arbeit geleistet zu haben.

    Wie darf ich das verstehen? Sollen die beteiligten Rechner selbst ermitteln, ob eine Kommunikation per SSL stattfinden soll?

  • Genau, aber ich formuliere es mal ein wenig anders.

    Eine völlig neue Installation einer Linux Distribution und einer Erstinstallation von Icinga. Nach Einrichtung wird dann der erste Host hinzugefügt.

    NSClient wird installiert und jetzt macht man zB auf der Konsole den ./check_nrpe -H 10.0.0.1 und bekommt den SSL Fehler.


    Was muss ich also tun um die Vertrauensstellung zwischen den beiden einzurichten? Ich werde Zertifikate erstellen müssen, klar. Aber wo kommen diese hin und welche Schritte in der Konfiguration sind sowohl beim Icinga als auch auf dem Client notwendig, damit ich eine anständige Kommunikation hinbekomme.


    Wo und wie sage ich dem Icinga dem nrpe oder auch dem nsclient dann wie sie die Zertifikate bekommen. Ich rede hier nicht von öffentlichen Zertifikaten wie man es bei webseiten hat, bitte nicht falsch verstehen. Ich weiß auch nicht wie ich mich da deutlicher ausdrücken soll, aber ich hoffe es wird so langsam verständlich.

  • Ich weiß die Mühe zu schätzen, aber ich bezweifel irgendwie das ich so zum Ergebnis komme.

    Keys anlegen, auf anderen Rechnern importieren, einmal SSH-Verbindung testen, Checks anpassen.

    Das ist halt Aufwand, den du treiben mußt, um SSL-Verbindungen zu haben,

  • Wie gesagt, mir ist bewusst welchen Aufwand ich habe um SSL zum Laufen zu bringen, trotzdem habe ich immer noch nicht verstanden wie ich den Geräten das klar mache. Selbst wenn ich jetzt tausend Zertifkate erstellt habe weiß ich immer noch nicht wie ich dem Icinga sage, dass mein Windows Host vertrauenswürdig ist oder wie er den Handshake erfolgreich durchführen kann und umgekehrt.

  • Selbst wenn ich jetzt tausend Zertifkate erstellt habe weiß ich immer noch nicht wie ich dem Icinga sage, dass mein Windows Host vertrauenswürdig ist oder wie er den Handshake erfolgreich durchführen kann und umgekehrt.

    "Keys anlegen, auf anderen Rechnern importieren, einmal SSH-Verbindung testen"


    In vielen Fällen passiert der Verbindungsaufbau vom Monitoring-Server aus, also muß auf dem Zielrechner der Public Key des Monitoring-Servers installiert werden. Anschließend passiert der Test mit dem Benutzer, unter dem der Monitoring-Prozeß läuft, gegen den Benutzer des Ziel-Hosts (ssh Benutzer-Ziel-Host@Ziel-Host), um den Ziel-Host in known_hosts auf dem Monitoring-Server einzutragen.

    Beim Plugin-Aufruf weiß der Monitoring-Rechner aufgrund des Eintrags in known_hosts, daß der Zielrechner angesprochen werden darf. Der Ziel-Host kann anhand des Public Keys prüfen, ob der Monitoring-Server mit dem richtigen Schlüssel anfragt.