Ankündigung

Einklappen
Keine Ankündigung bisher.

Glassfish log Files für Entwickler zugänglich machen

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Damit wir alle was davon haben und insbesondere der TE.
    mich wundert, dass du beispielweise shellshock, trotz meiner häufigen posts zu dem thema nicht als ernsthaft problematisch ansiehst.
    ich gebe zusätzlich zu bedenken, dass nicht nur bekannte bugs sorgen bereiten können, sondern auch normales turnen auf den maschinen.

    erfordert kein einziges zusätzliches Softwarepaket
    ich will mal hoffen, dass auf der angesprochenen dose auch syslog läuft
    Man richtet auf dem Glassfish Server einen unpriviligierten Benutzer ein, der das Glassfish Logfile lesen darf
    schön, bitte erkläre mir doch in konkreto was die user dort dürfen. ich glaube nicht, dass du mit einem zuigang der dir cat file erlaubt sinnvoll debiggen kannst. eine krücke wie
    Code:
    while(true); do cat file | ssh user@my_own_maschine "my_own_logfile_interpreter"; done
    halte ich für nicht sinnvoll.

    um es abzuschliesssen, du machst es so, ich nicht.
    wie es auch immer gemacht wird, es trifft jemand die entscheidung und der/die muss damit leben.
    für mich ists genung hier.

    Kommentar


    • #17
      mich wundert, dass du beispielweise shellshock...
      Sicherheitslücken können überall aufklaffen, oder würdest Du wirklich ernsthaft behaupten, daß z.B. remote syslog, Graylog oder irgendwelche offenen Logfile-Ports absolut sicher seien? Vielleicht sollte man dabei zusätzlich auch noch in Betracht ziehen, daß die Keys nur für bestimmte Personen/Entwickler, für einen unpriviligierten Account und auch noch auf einem Testserver eingerichtet werden.

      schön, bitte erkläre mir doch in konkreto was die user dort dürfen. ich glaube nicht, dass du mit einem zuigang der dir cat file erlaubt sinnvoll debiggen kannst.
      "cat" "tail" und "tail -f" sollten für 99% der Fälle ausreichen. Auf Client-/Entwicklerseite sollten damit kaum Wünsche offen bleiben. Bei cat bleibt natürlich der Nachteil (insbesondere bei großen Logfiles), daß eine Filterung erst nach der vollständigen Übertragung des kompletten Logfiles erfolgen kann

      # Client/Entwickler
      Code:
      ssh logreader@glassfish "cat" | grep "was auch immer Du suchst"
      ssh logreader@glassfish "tail" | grep "nur was aktuelles"
      ssh logreader@glassfish "tail -f" | grep "folgt in Echtzeit dem Logfile"

      # Server

      /home/logreader/.ssh/authorized_keys
      Code:
      # Entwickler 1
      no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="~/sshCmd.sh" ssh-rsa ....
      # Entwickler 2
      no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="~/sshCmd.sh" ssh-rsa ....
      # Entwickler 3
      no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="~/sshCmd.sh" ssh-rsa ....
      #usw.


      ~/sshCmd.sh
      Code:
      #!/bin/bash
      LOGFILE="/var/log/glassfish.log"
      
      case "$SSH_ORIGINAL_COMMAND" in
          "cat")
              cat "$LOGFILE"
              ;;
          "tail")
              tail "$LOGFILE"
              ;;
          "tail -f")
              tail -f "$LOGFILE"
              ;;    
          *)
              echo "Invalid ssh command!"
              exit 1
              ;;
      esac
      VG
      Jack
      -

      Kommentar


      • #18
        oh mann oh mann, ich gebe es auf:
        , daß z.B. remote syslog (..) oder irgendwelche offenen Logfile-Ports (..) sicher seien?
        what the hell: wieso sollt bei remote syslog ein port offen sein?
        allein schon die idee ssh auf eine uid zu reduzieren, man.

        Sicherheitslücken können überall aufklaffen
        achne.

        es ist dir durchaus positiv anzurechnen dass du da config files geposted hast. der ein oder andere wird sich drüber freuen.

        -> out.






        Kommentar


        • #19
          what the hell: wieso sollt bei remote syslog ein port offen sein?
          Werden bei remote syslog die Logdaten etwa auf einer Schubkarre transportiert?

          Übrigens, "irgendwelche offenen Logfile-Ports" bezog sich auf Deinen Vorschlag die logs "auf irgendeinem Port rauszuhauen" und nicht auf remote syslog.

          allein schon die idee ssh auf eine uid zu reduzieren, man.
          SSH auf eine uid? Wie geht dass denn? Oder meinst Du daß man sich mit mehreren Keys in einem Account einloggen kann? Nun genau dafür ist authorized_keys ja da.
          Und falls Du Dich brennend dafür interessierst wann mit welchem Key auf den Account zugegriffen wurde, dann kannst Du auch den LogLevel erhöhen. Aber wenn auch das nicht ausreicht, dann bleibt natürlich immer noch die Option für jeden Entwickler einen eigenen Account anzulegen. Dann kannst alle Entwickler einzeln ins Monitoring aufnehmen und beobachten wie Sie alle mit tail und cat arbeiten

          VG
          Jack
          -

          Kommentar


          • #20
            Oder meinst Du daß man sich mit mehreren Keys in einem Account einloggen kann? Nun genau dafür ist authorized_keys ja da.
            //OT: und jetzt outet er sich auch noch als stallman fan.
            btt: üblicherweise nutzt man mehrer keys um sich von mehreren konten auf mehrern dosen einloggen zu können, allerdings als - physikalisch - eine person.

            ok, bei remote syslog ist ein port offen, sonst könnte man ja kein logs annehemen.
            wenn dich daten über netz raushaue, habe ich keine offenen ports.

            Und falls Du Dich brennend dafür interessierst (..)
            in konkreto nicht. es hat sich aber bezahlt gemacht die spiel und testfreude unter aufsicht zu halten.

            Kommentar


            • #21
              Hallo Jack, Hallo moma,

              ich muss Jack recht geben der Einfachste weg wäre SSH für die Developer. Problem dabei ist das die bequem sind und ich es nicht darf. Damit ist eure Diskussion zwar interessant aber für mich ehrlich gesagt leider nicht hilfreich.

              Ich habe mich jetzt mal durch eine Anleitung aus dem netz gearbeitet und einige Ergebnisse damit erzielen können.

              https://www.digitalocean.com/communi...gs-on-centos-6
              https://www.digitalocean.com/communi...-4-on-centos-7

              Die Grundstruktur ist Logstash als zentralen Logserver, Kibana also zusammenzufassende Oberfläche mit Elasticsearch dahinter und einen NGINX als Revers Proxy [Habe ich noch nie benutzt bin einfach dem Tutorial gefolgt] Da ich die neusten versionen genommen habe bin ich die Schritte aus dem CentOS 6 Tut durch gegangen und habe die Konfiguration aus dem CentOs 7 Tutorials übernommen.

              Die Services laufen alle Logstash Server, NGINX, Elasticsearch und Kibana. Nun bekomme ich auf der Kibana Oberfläche welche ich auf den logstash Server konfigurieren will jedoch eine Fehlermeldung.

              error.JPG

              Ich kann also Quasie den letzten schritt mit der Zuweisung nicht machen und weiß nicht so wirklich nach was ich und vor allem wo ich suchen soll

              Kommentar


              • #22
                //OT:
                ich kann auf deinem bild nichts erkennen, was hast denn für ne auflösung?
                --nebenbei:
                syslogng kann auch direct to elasticsearch loggen mit plugin:
                https://github.com/balabit/syslog-ng-incubator

                Kommentar


                • #23
                  Ich denke bevor Du zig Server oder irgendwelche Beta-Software installierst, wäre es sinvoll zuerst die Anforderungen an das System genau zu definieren (ungefähre Anzahl der Entwickler, Arbeitsworkflow etc.).
                  Was wird also ganz genau benötigt?

                  Bedenke auch, daß jedes System langfristig gewartet und gepflegt werden muss. Updates/Upgrades/EOL, Migrationen auf neue Produktversionen all das summiert sich im Laufe der Zeit und kann einen Haufen Arbeit und damit zusätzliche Kosten verursachen. Versuche es daher schlank zu halten, daß ist auf Dauer oft nicht nur billiger, sondern auch unter Berücksichtigung der Sicherheitsaspekte sinnvoll.

                  VG
                  Jack
                  -

                  Kommentar


                  • #24
                    Puh, Graylog2 ist ja schon gefallen. Warum das nicht? Geht auch "relativ" einfach mit der Installation: Dockerimage
                    Standards - Best Practices - AwesomePHP - Guideline für WebApps

                    Kommentar


                    • #25
                      Danke erstmal für eure hohe Anteil nahem an dem Thema das Problem besteht immer noch aber nach dem ich mich ein wenig was zu grayLog angesehen habe werde ich das jetzt probieren und wenn es funktioniert meinen Chef davon über zeugen.

                      Bei dem anderen Setup habe ich jetzt ein SSL Zertifikats Problem. Der Forwarder von LogStash meldet immer

                      "Connecting to [xxx.xxx.xxx.xxx]xxx (xxx.xxx.xxx.xxx) Failed to tls handshake with xxx.xxx.xxx.xxx EOF"

                      also denek ich mal das mit dem Zertifikat etwas nicht stimmt.

                      Wie bekomme ich mehr raus? Also was genau dort nicht stimmt bzw. wie lege ich das SSL Richtig an was sollte ich prüfen und so weiter. Bin für eure Ratschläge im voraus schon sehr dankbar.

                      Kommentar


                      • #26
                        "Connecting to [xxx.xxx.xxx.xxx]xxx (xxx.xxx.xxx.xxx) Failed to tls handshake with xxx.xxx.xxx.xxx EOF"
                        ich hab noch nicht mit graylog gearbeitet, und die fehlermedung relativ nichtsagend, d.h. sie kann auch bei port und ip problemen auftreten, tat es jedenfalls früher bei openvpn.
                        ich gehe davon aus, dass du dich mit 5x509 und pki relativ gut auskennst? sonst kan ich dir leider nicht helfen.


                        //OT:

                        Ich denke bevor Du zig Server oder irgendwelche Beta-Software installierst, wäre es sinvoll zuerst die Anforderungen an das System genau zu definieren (ungefähre Anzahl der Entwickler, Arbeitsworkflow etc.).
                        jo jack88

                        ich hätte schon gedacht du versucht das zu finden:
                        http://www.rsyslog.com/doc/v8-stable...ticsearch.html

                        sonst? betasoftware --> ohne beta lief vor wenigen jahren noch die wenigsten linux distries "state oof the art"; als langrähriger linuxer schockt mich das nicht.
                        zig server? klar einen logserver.

                        Kommentar


                        • #27
                          sonst? betasoftware --> ohne beta lief vor wenigen jahren noch die wenigsten linux distries "state oof the art"; als langrähriger linuxer schockt mich das nicht.
                          zig server? klar einen logserver.
                          Letzendlich kann ja jeder selbst entscheiden und machen wie er es für richtig hält.

                          Wie bekomme ich mehr raus?
                          Google einfach mal nach "tls debugging" und setze den "verbosity level" nach Möglichkeit immer etwas höher -vv -vvv.

                          VG
                          Jack
                          -

                          Kommentar


                          • #28
                            Danke das mit dem TSL debugging werde ich defintiv mal durch ziehen.

                            Ich habe mich dann heute mal an grayLog versucht auf anraten von einigen Leuten hier und muss gestehen auch hier gibt es Probleme. Ist jemand dabei der sich mit graylog aus kennt oder macht es eurer Meinung nach mehr Sinn in diesem thread nur das Thema Logstash, Elasticsearch und Kibana zu behandel und für GrayLog einen Neuen auf zusetzen?

                            Kommentar


                            • #29
                              Was für Probleme hast du denn mit graylog?
                              Standards - Best Practices - AwesomePHP - Guideline für WebApps

                              Kommentar


                              • #30
                                Thema geschloßen Problem behoben.

                                Ich habe mich jetzt zu dem Setup Logstash, Kibana NGINX als reversproxy und Elasticsearch durch geschlagen.

                                Der Fehler wieso keine Logs ankamen lag zu einem im Zertifikat, zum anderen war in der Konfiguration des Forwarders ein Lehrzeichen und somit wurde die IP Adresse des Logstash Servers nicht als IP sondern als Domain interpretiert und das ging natürlich schief.

                                Ich danke euch für eure Hilfe und Unterstützung

                                Kommentar

                                Lädt...
                                X