Ankündigung

Einklappen
Keine Ankündigung bisher.

Virtual Server: Installation von ISPConfig

Einklappen

Neue Werbung 2019

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

  • Virtual Server: Installation von ISPConfig

    Hi!

    Ich habe mir einen virtuellen Server mit dem Betriebssystem Debian Etch angemietet, und muß nun zusehen, wie ich damit klar komme. Ich muß vorab sagen, daß ich noch nie so etwas gemacht habe und 100% unerfahren bin. Jungens (und Mädels), ich brauche Eure Hilfe! Es sind verschiedene Fragen zu klären.

    Bitte nennt immer das entsprechende Problem beim Antworten (1..6).

    1. Problem

    Ich habe die Anleitung unter "http://www.tim-bormann.de/debian-lenny-server-vserver/" befolgt, doch nach Erstellen der Konfigurationsdatei mittels "mcedit /etc/apache2/sites-available/MeineDomainDE" bekomme ich beim Ausführen von "/etc/init.d/apache2 reload" den folgenden Fehler: "Reloading web server config..8108", was bedeutet: "Line break does not start a new line".

    Ich vermute den Fehler in jener Konfigurationsdatei, aber eine erneute Kontrolle jener Datei läßt mich keinen Fehler erkennen.

    2. Problem

    Ich habe bereits eine existierende Website zur neuen Firma mit dem angemieteten virtuellem Host umgezogen, doch so einfach, wie ich es mir naiverweise vorgestellt hatte, ist dies nicht. Denn noch immer sehe ich die alten Domaindateien (die alte Website), obwohl ich eigentlich unter 1. die Domain neu erstellen wollte. Dies hängt vieleicht mit dem Fehler "8108" zusammen, vermute ich.

    Wie erstelle ich denn nun eigentlich Domains auf so einem virtuellen Server? Imemr mittels mcedit und Restart des Apache2-Servers?

    3. Problem

    Und wie erstelle ich dann für WinSCP oder WS_FTP-Pro die FTP-Zugangskonten, um meinen Kunden FTP-Zugänge zu genau diesen Verzeichnissen (und nicht darüber) zu ermöglichen? Den FTP-Server hatte ich auch schon installiert, erfolgreich sogar.

    4. Problem

    Ich will mir eine schöne, einfache Benutzeroberfläche erstellen. leider ist Plesk unheimlich teuer oder ich bin unheimlich geizig, jedenfalls will ich keine 799 US$ ausgeben dafür, auch wenn es sehr gut arbeitet (hatte es schon mal benutzt). Ich dachte also an ISPConfig. In welches Server-Verzeichnis muß ich die .tar.gz-Archive hineinbewegen, um sie zu installieren? Und wie installiere ich sie? "Apt-get install" geht ja anscheinend nicht in diesem Fall, zumindest nicht solange die installationsdateien nicht dort sind, wo sie eventuell erwartet werden.

    5. Frage

    Welche anderen Konfigurationsoberflächen kennt Ihr, welche sind möglichst identisch zu Parallels Plesk?

    6. Frage

    Welche Sicherheitsmaßnahmen könnt Ihr mir empfehlen und beschreiben, um den Server sehr sicher zu machen, auf der ROOT-Ebene und allen anderen?
    sigpic
    Vielen Dank für Eure Zeit, Absicht, Mühe und für Eure Ideen. Grüße,
    Sven


  • #2
    Hallo,

    generell möchte ich davon abraten, einen Server zu betreuen, wenn man nicht die entsprechende Erfahrung dazu besitzt. Das kann sowohl für einen selbst als auch für andere fatale Folgen haben.

    Weiter im Text:

    Problem 1: Es ist egal, mit welchem Editor du die Konfigurationsdateien bearbeitest, es sollte aber ein Texteditor sein, keine Automatiklösung. Ich würde vim bevorzugen. (erfordert etwas Einarbeitung, ist aber unheimlich mächtig). Zu deinem Fehler können wir wenig sagen, wenn du uns die Konfigurationsdateien nicht zeigst.

    Problem 2: Lese dir am besten an, wie du virtuelle namensbasierte Hosts erstellst, das ist nicht so schwer. Bei mehreren IP-Adressen kannst den Apache sogar an jeder einzeln horchen lassen.

    Problem 3: Mit einem FTP-Server wie ProFTPd oder PureFTPd. Bitte aber unbedingt auf die Konfiguration achten, es wäre nicht gut, wenn du dich z.B. mit jedem Systemuser einloggen könntest. Besser ist es, virtuelle User anzulegen.
    Wer benutzt aber eigentlich noch WS_FTP? Wozu gibt es FileZilla?

    Problem 4: cPanel ist noch teurer. Zu ISPConfig wende dich am besten an den Hersteller. Plesk ist übrigens keine Serverkonfigurationsoberfläche in dem Sinne, sondern eine Serverkundenverwaltung.

    Problem 5: wenn du wirklich eine reine Administrationsoberfläche brauchst, schau dir mal Webmin an, das solltest du auch übers Repository installieren können.
    Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

    Kommentar


    • #3
      Da muss ich meinen Vorredner Recht geben. Bin auch vor einigen Jahren ziemlich "eingefahren" mit einem eigenen Server
      Wie immer an dieser Stelle => Der eigene Server | ragtek

      Daher mein Rat: Virtuellen Server Zuhause aufsetzen und erstmal üben ODER einen managed Server besorgen.
      Wem das nicht reicht kann sich natürlich auch an jemanden wenden, der das für einen erledigt (wobei ich hier wirklich nur zu seriösen Firmen raten kann)

      Punkt 6:
      Mir fallen hier folgende Punkte ein, wobei hier jeder "Admin" seine Vorlieben hat...

      * ssh login über public key anstatt user & pw
      * Direktlogin von root verbieten
      * ssh Port ändern
      * userprivilegeseperation aktivieren

      Kommentar


      • #4
        Besonders zu betonen ist der letzte Absatz deines Artikels: es kann nicht nur ein umheimlich teurer Spaß sein, weil man sich dauernd das System neu aufsetzen lassen muss, es kann auch unheimlich teuer werden, weil der Server ohne Kenntnis des Betreibers (das bist du) plötzlich Spam versendet, Bruteforce- oder Dos-Attacken fährt. Sollte eines davon erfolgreich sein, kannst du dich auf nicht ganz günstige anwältliche Post freuen. Ich selbst hatte auch schon einmal den Spaß, dass der Server plötzlich „gebrütet“ hat. Zum Glück hatte der Betroffene aber den ISP angeschrieben, sodass das Problem noch rechtzeitig behoben werden konnte, bevor wirklich Schaden entsteht. Das muss aber nicht immer so sein. Seitdem habe ich auch viel über Serverwartung gelernt und nutze mittlerweile selbst ein Gentoo-Linux, dessen Innereien ich mittlerweile besser kenne als die der Windowse, das ich die Jahre zuvor genutzt habe.
        Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

        Kommentar


        • #5
          Hmmm..... Umso mehr benötige ich Eure Anleitungen, denke ich. Denn genau diese Sachen will ich auf meinem Server verhindern.

          Zuallererst natürlich Zugangsverbot für "Mr. Root" und das Erstellen eines neuen Zugangkontos. Etc.. Ich hatte bereits eine Online-Doku gelesen, aber die war sehr ungenügend in Hinblick auf Sicherheitsbedürfnisse. Lieber ziehe ich Anleitungen hier vor.
          sigpic
          Vielen Dank für Eure Zeit, Absicht, Mühe und für Eure Ideen. Grüße,
          Sven

          Kommentar


          • #6
            Hmmm..... Umso mehr benötige ich Eure Anleitungen, denke ich.
            Ehrlich Sven - wohin soll so ein Thread führen?! Wenn Dir partout die Einsicht fehlt, bist Du sicher in einem Board für Administratoren besser aufgehoben.
            --

            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


            --

            Kommentar


            • #7
              Also ich habe mir vor einiger Zeit: Webserver - einrichten und administrieren zugelegt.
              Ist leider nicht die Eierlegende Wollmilchsau die ich mir erhofft habe, aber ist ansonsten ganz ok.

              Anleitungen sind IMHO Schmafu (für die nicht Österreicher: Unsinn/BLödsinn)
              Da geht man dann Zeile für Zeile durch und bleibt bei Zeile 30 von 200 stecken, weil sich das System nicht so verhält wie es im HowTo steht)

              Kommentar


              • #8
                Und dem root den Zugang zu verwehren ist ebenso unsinnig. Der Zugang sollte durch starke Kennwörter oder vernünftige Zertifikate gut abgesichert werden, aber wie willst du den Server warten, wenn root keinen Zugang hat? Nur Benutzer der Gruppe root können Systemdienste starten und beenden, Systemdateien editieren usw.
                Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

                Kommentar


                • #9
                  Nun, ich poste hier, weil der Name des Unterforums her doch auch "Server" beinhaltet, Nikosch. Laß' uns doch erst mal sehen, wie weit mir die anderen Mitglieder hier helfen können. Wenn Geduld und Zeit nicht mehr ausreichen, werde ich woanders fragen. Aber das PHP Friends Forum ist normalerweise die erste Wahl für mich, um Expertise zu bekommen. Ich werde Deinen Rat aber beherzigen, wenn hier niemand sich mit Servern auskennt oder die Zeit hat. Immerhin sind hier ja schon einige Antworten erschienen, die mich sehr gut sehen lassen, daß auch hier sehr wohl das Wissen existiert, ich brauche also nicht unbedingt auf andere Foren auszuweichen...

                  Also, meine Fragen 1..6 bleiben weiterhin offen für Euch alle.

                  RagTek, ja, die Anleitung welche ich benutzt hatte, beinhaltete auch einige Punkte, die ich so nicht übernehmen konnte mit meinem vServer. Du hast Recht. Vor allem will ich ROOT sperren und Sicherheit einbauen. Hilfe ist also ganz stark erwünscht!
                  sigpic
                  Vielen Dank für Eure Zeit, Absicht, Mühe und für Eure Ideen. Grüße,
                  Sven

                  Kommentar


                  • #10
                    Was heißt hier, „dass sich niemand mit Servern auskennt.“
                    Das ist faktisch falsch. Wir geben dir hier schlicht den Ratschlag, dass du mit denem Erfahrungsstand keinen Server im Alleingang managen solltest. Außerdem habe ich deine Fragen schon soweit es mit deinen spärlichen Beschreibungen möglich ist, beantwortet, aber anscheinend hast du das vollkommen überlesen und noch überhaupt nicht darauf reagiert.
                    Dieser Satz
                    Vor allem will ich ROOT sperren und Sicherheit einbauen.
                    bestätigt meine These übrigens, dass du meine beiden Postings nicht gelesen hast.
                    Zitat von Manko10 Beitrag anzeigen
                    Und dem root den Zugang zu verwehren ist ebenso unsinnig. Der Zugang sollte durch starke Kennwörter oder vernünftige Zertifikate gut abgesichert werden, aber wie willst du den Server warten, wenn root keinen Zugang hat? Nur Benutzer der Gruppe root können Systemdienste starten und beenden, Systemdateien editieren usw.
                    Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

                    Kommentar


                    • #11
                      Und dem root den Zugang zu verwehren ist ebenso unsinnig.
                      sudo bzw. su


                      EDIT:
                      Hilfe ist also ganz stark erwünscht!
                      Das, was Du hier willst, ist doch sinnlos. Die Sicherheit kannst Du Dir nicht mit ein paar "Anleitungen" erkaufen. Wenn Du es nicht mal von selbst schaffst, den Root-User für ssh (nehme ich an) zu sperren, dann ist das - zumindest im Moment - das absolut falsche und gefährliche für Dich.

                      Kommentar


                      • #12
                        sudo ja, su nein. Mit su nimmt man die Identität eines anderen Nutzers an, um administrative Aufgaben durchzuführen, also die des roots. Das ist ein anderes Prinzip als sudo.
                        Dennoch halte ich es für unsinnig, den root zu sperren. Es ist sinnvoll, in der Regel einen anderen Benutzer zu nutzen, aber eine Login-Sperre für root halte ich für nicht sinnvoll.
                        Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

                        Kommentar


                        • #13
                          Zitat von Manko10 Beitrag anzeigen
                          Und dem root den Zugang zu verwehren ist ebenso unsinnig. Der Zugang sollte durch starke Kennwörter oder vernünftige Zertifikate gut abgesichert werden, aber wie willst du den Server warten, wenn root keinen Zugang hat? Nur Benutzer der Gruppe root können Systemdienste starten und beenden, Systemdateien editieren usw.
                          Ähm, man kann dem Roor den Zugang verwehren und sich zB nur mit Manko10 und dem dazugehörigen Key einloggen.

                          Für 0815 arbeiten würde ich auch den Manko10 verwenden und für den Rest gibt es sudo bzw su.

                          My 0.02$

                          Kommentar


                          • #14
                            Ja, das ist richtig und wie ich schon schrieb, ist es sinnvoll nicht mit dem root unterwegs zu sein. Ihn mit einer generellen Login-Sperre zu versehen, halte ich aber dennoch nicht (zumindest nicht in allen Situationen) für sinnvoll. Hat man Zugriff über das interne Netzwerk, sollte man ihn nach außen sperren, das ist klar. Hat man jedoch nur externen SSH-Zugriff, halte ich es für sinnvoller, den Login auf Keys zu beschränken anstatt ihn ganz zu unterbinden. Das mögen diverse Serveradministratoren anders sehen, aber meiner Meinung nach bringt ein generelles Login-Verbot nichts. Man stelle sich nur das Szenario vor, dass man den root per SSH sperrt und sich in Sicherheit wähnt, weil man nur einen anderen Account in Verbindung mit sudo nutzt. Wird jedoch dieser Account geknackt, stehen dennoch alle (und ich sage: alle) Türen offen. Ein schlichtes
                            Code:
                            $ sudo passwd root
                            $ su
                            und schon lässt sich wirklich jeder Unfug auf dem System anstellen. Deshalb halte ich ein Sperren des root-Logins für ein Placebo. Sinnvoller ist es, Key-Auth zu nutzen und SSH auf einen anderen Port zu legen.
                            Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

                            Kommentar


                            • #15
                              Ihn mit einer generellen Login-Sperre zu versehen
                              Ich meinte das nur auf ssh bezogen.

                              Kommentar

                              Lädt...
                              X