Plesk: Domain-Alias angelegt, damit komme ich aber auf Haupt-Domain

[Gast King555]

Ich verwende Plesk 11 auf meinem Debian6-Rootserver und habe meine IP-Adressen dort eingerichtet. Eine davon ist auf "Shared" (statt "Dedicated") und soll mehrere Websites bereitstellen. Das klappt auch.

Aber: Ich habe bei einigen Domains in Plesk Domain-Aliase angelegt. Das sind Domains, die auf eine andere Domain verweisen sollen, ohne dass man explizit eine Weiterleitung oder gar einen Webspace einrichtet.

Auf meinem alten Rootserver hat das wunderbar geklappt, allerdings waren da alle IPs Dedicated.

Auf dem neuen, mit der Shared-IP, lande ich bei Eingabe eines Domain-Alias immer auf meiner Haupt-Domain (die als Standard-Site für die IP eingerichtet ist).

Warum lande ich nicht auf der Domain, für die der Alias eingerichtet wurde? Die DNS-Records von der Domain und deren Alias verweisen beide auf die selbe IP (die Shared-IP), genau wie die Haupt-Domain.

[flashpixx]

Auf meinem alten Rootserver hat das wunderbar geklappt, allerdings waren da alle IPs Dedicated.

und was soll das jetzt heißen

Auf dem neuen, mit der Shared-IP, lande ich bei Eingabe eines Domain-Alias immer auf meiner Haupt-Domain (die als Standard-Site für die IP eingerichtet ist).

Die DNS-Records von der Domain und deren Alias verweisen beide auf die selbe IP (die Shared-IP), genau wie die Haupt-Domain.

Du gibst die Antwort selbst.

[Gast King555]

und was soll das jetzt heißen

Also zunächst mal habe ich jetzt rausgefunden, dass es in Plesk für meine Zwecke völlig egal ist, ob die IPs als Shared oder als Dedicated eingetragen werden. Also vergesst diese Info wieder.

Das hat nur was damit zu tun, ob andere Kunden auf dem gleichen Server (ich bin da aber allein) auch Zugriff auf die IP haben (beim Anlegen von neuen Sites).

Beim alten Server hatte ich allerdings eine IP pro Website, das wird wohl der Hauptunterschied sein, warum früher alles ging.

Du gibst die Antwort selbst.

Verstehe ich nicht. Ich habe in Plesk acht Websites (sogenannte Abonnements) angelegt. Diese Abos haben jeweils eine Haupt-Domain (z. B. domain1.de, domain2.de). Alle Domains haben die selbe IP, sowohl im DNS-Record, als auch in Plesk.

Aber (selbstverständlich) kann ich trotzdem durch Eingabe von domain1.de auf Website #1 kommen und durch Eingabe von domain2.de auf Website #2. Bei Webspace-Providern liegen u. U. hunderte von Domains auf einer einzigen IP.

Was ist jetzt also konkret bei mir das Problem? Liegt es an Plesk? Oder am Server? Oder muss der DNS-Record noch irgendwie modifiziert werden?

[flashpixx]

Ich empfehle Dir ganz dringend Dich mit Serveradministration zu beschäftigen, denn die Fragen, die Du stellst, zeigen, dass Du nicht verstehst, wie Dein Server arbeitet. Da Du aber rechtlich für diesen Server verantwortlich bist, solltest Du eben auch das Fachwissen haben diesen zu verwalten.

Plesk ist nur eine GUI zur Administration und die Zuordnung von resultierender Webseite bei einer Domaineingabe ist Sache des Webservers, d.h. der Webserver entscheidet welche Inhalte er bei welcher Domain ausliefern muss. Ich habe z.B. eine IP und hoste 6 Domains (inkl. Mail) mit unterschiedlichen Inhalten. Die Technologie nennt sich "virtual host" (z.B. beim Apache) und sie muss entsprechend konfiguriert sein.

Ich rate generell dazu, solche Tools wie Plesk o.ä. gar nicht zu verwenden, vor allem wenn man nicht weiß was sie machen. Konfiguriere das System richtig, dann wird es auch das machen, was Du möchtest.

[Gast King555]

War ja irgendwie klar, dass mal wieder so eine Antwort kommt...

Ich muss echt sagen, dass ich jedes Mal äußert verärgert bin, dass man, anstatt die Hilfe einfach zu unterlassen, wenn man nicht helfen möchte, jedes Mal mit der "du hast keine Ahnung, also lass es"-Schelte kommen muss.

Ich bin einer von vermutlich Millionen Plesk-Nutzern. Die Software kostet tausende von Euros. Ich kann mir nicht vorstellen, dass die der größte Müll sein soll, wie du sicher sagen wolltest.

Und wieso bitte schön erzählst du mir was von "ich bin rechtlich verantwortlich", wenn ich von der Einrichtung von Domain-Aliasen rede? Ist das in irgendeiner Form sicherheitsrelevant? Mitnichten!

EDIT: Und mir sind "virtual hosts" natürlich ein Begriff. Aber warum umständlich in irgendwelchen Config-Dateien rumpfuschen, wenn ich's mit ein paar Mausklicks erledigt habe?

Und ich wette, dass mein Server um einiges sicherer eingerichtet ist, als der von Leuten, die Antworten wie deine geben.

Bearbeitet 20. März 2013 von King555

[Gast King555]

Problem gelöst! Und es war so einfach...

Ich musste in Plesk beim Domain-Alias lediglich die Option "Webdienst" aktivieren. Ich hatte das früher nicht gemacht und es ging trotzdem, weil ich da pro Website eine eigene IP hatte.

[Crash2001]

War ja irgendwie klar, dass mal wieder so eine Antwort kommt...

Ich muss echt sagen, dass ich jedes Mal äußert verärgert bin, dass man, anstatt die Hilfe einfach zu unterlassen, wenn man nicht helfen möchte, jedes Mal mit der "du hast keine Ahnung, also lass es"-Schelte kommen muss.

Das war keine "du hast keine Ahnung also lass es "-Schelte, sondern er hat nur gesagt, du solltest dich genauer informieren über die Dienste, die du anbieten möchtest und wie diese konfiguriert werden.

Ich bin einer von vermutlich Millionen Plesk-Nutzern. Die Software kostet tausende von Euros. Ich kann mir nicht vorstellen, dass die der größte Müll sein soll, wie du sicher sagen wolltest.

Für die GRUNDkonfiguration eines Servers ist die vollkommen in Ordnung, aber dennoch muss man manche Sachen manchmal einfach noch manuell konfigurieren, da sie in der Software nciht vorgesehen sind. Und virtuelle hosts im Apache anzulegen ist nun wirklich kein Zauberwerk. Wenn du also einen webserver unter Apache betreibst, solltest du auch in der Lage sein, zu verstehen, was er macht und wieso.

Klar kann man sich da einarbeiten, aber die meisten User, die die Konfiguration nur über Plesk, Webmin oder Konsorten versuchen einzustellen, haben keinerlei Ahnung, was eigentlich dahinter steckt und zudem keinerlei Interesse, das herauszufinden. Sie denken, damit könne man alles machen was sie brauchen. Kann man aber leider nicht.

Und wieso bitte schön erzählst du mir was von "ich bin rechtlich verantwortlich", wenn ich von der Einrichtung von Domain-Aliasen rede? Ist das in irgendeiner Form sicherheitsrelevant? Mitnichten!

Wenn du den Root-Server adiministrierst bist du höchstwahrscheinlich auch dafür verantwortlich und somit hast du auch rechtliche Verpflichtungen, die du damit eingehst. Sollte es dein eigener sein noch viel mehr, als wenn es für jemand anderen ist. Denn sollte der Server z.B. gehackt werden (Datenverlust, als Spambot missbraucht, für D(D)OS-Attacken missbraucht oder sonstiges) dann kann das sehr unangenehm werden.

Und ich wette, dass mein Server um einiges sicherer eingerichtet ist, als der von Leuten, die Antworten wie deine geben.

Da würde ich aber dagegen wetten. Wie schon geschrieben - nur mit Plesk / webmin kann man einfach nciht alles machen. Bestimmte Absicherungen kann man damit z.B. auch nicht automatisiert machen.

Lass mich raten - hier mal ein paar Sachen, die du vermutlich genau so eingerichtet hast, bzw. die so stimmen.

• du erlaubst den Login vom user "root" direkt per SSH anstatt Sachen über sudo zu machen
  
• SSH lauscht auf den Standardport 22
  
• Zugang ist per User/Passwort möglich statt per Zertifikat
  
• Der Apache wurde nicht noch manuell abgesichert
  
• es laufen Dienste, die du gar nicht nutzt
  
• diverse Software wird mit Adminrechten ausgeführt und du hast keine Ahnung welche
  
• Du hast einen FTP-Server auf dem root Server laufen statt eines SFTP-Server
  
• du hast keine Ahnung, was in deiner httpd.conf oder apache2.conf so alles drin steht
  
• vom Webserver werden jede Menge Module geladen, die du gar nicht benötigst, die jedoch jeweils zusätzliche Angriffspunkte bieten
  
• du hältst die entsprechenden Pakete nicht immer up to date (Updates und Bugfixes) oder nutzt auch mal nicht als "stable" markierte Versionen.
  
• Du schaust dir die Logfiles nicht regelmässig an, um Angriffe erkennen zu können
  
• Du hast dir noch keine großartigen Gedanken über Zugriffsrechte auf dem Server selber gemacht
  
• dein Apache gibt sich zu erkennen, welche Version er genau ist
  
• das Modul "autoindex" ist bei dir geladen
  
• ...

Na, mit wie vielen meiner Vermutungen habe ich recht?

[Gast King555]

sondern er hat nur gesagt, du solltest dich genauer informieren über die Dienste, die du anbieten möchtest und wie diese konfiguriert werden.

Und woher wollt ihr wissen, dass ich mich nicht darüber informiert habe? Meine Frage bezog sich ausschließlich auf Plesk und auf eine bestimmte Funktion, die im Handbuch nicht 100%ig erklärt ist.

Und virtuelle hosts im Apache anzulegen ist nun wirklich kein Zauberwerk

Ich möchte aber Plesk verwenden und kann nicht parallel dazu manuelle Konfigurationen machen, das leuchtet ja sicher ein. Das kommt sich in die Quere bzw. das manuelle Zeugs wird einfach überschrieben.

Wenn du den Root-Server adiministrierst bist du höchstwahrscheinlich auch dafür verantwortlich und somit hast du auch rechtliche Verpflichtungen

Ja, das ist mir doch alles völlig klar. Aber wieso kommt dieser Hinweis, wenn ich eine Frage zu Plesk habe? Zudem betreibe ich seit nun genau drei Jahren meinen eigenen dedizierten Rootserver und in dieser Zeit gab es von meinem Server aus nicht eine einzige Spammail oder Attacke jeglicher Art, gehackt wurde da auch nichts.

du erlaubst den Login vom user "root" direkt per SSH anstatt Sachen über sudo zu machen

Ja, aber ich garantiere dir, dass niemand auch nur in die Nähe meines SSH-Zugangs kommt. Somit sehe ich da keine Probleme. Bisher konnte mir noch niemand erklären, wo denn der Nachteil des root-Zugangs liegt, wenn niemand überhaupt den SSH-Login zu Gesicht bekommt.

SSH lauscht auf den Standardport 22

Nein.

Der Apache wurde nicht noch manuell abgesichert

Doch.

es laufen Dienste, die du gar nicht nutzt

Nein.

vom Webserver werden jede Menge Module geladen, die du gar nicht benötigst, die jedoch jeweils zusätzliche Angriffspunkte bieten

Nein.

du hältst die entsprechenden Pakete nicht immer up to date (Updates und Bugfixes)

Doch.

oder nutzt auch mal nicht als "stable" markierte Versionen.

Nein.

Du schaust dir die Logfiles nicht regelmässig an, um Angriffe erkennen zu können

Doch.

Du hast dir noch keine großartigen Gedanken über Zugriffsrechte auf dem Server selber gemacht

Kommt drauf an, was du meinst.

dein Apache gibt sich zu erkennen, welche Version er genau ist

Nein.

das Modul "autoindex" ist bei dir geladen

Nein.

Wie du siehst, bin ich nicht ganz so blöd, wie ihr offensichtlich denkt. Aber gerne wird ja jeder, der eine beliebige Frage zu Servern stellt, gleich als totaler Anfänger und Sicherheitsrisiko für das gesamte Internet abgestempelt. So ist es in jedem Forum. Daher wundere ich mich, dass man überhaupt so ein Unterforum anbietet, denn offenbar darf es ja nur Profis in dem Bereich geben, die niemals irgendwelche Fragen stellen.

Und nochmal: Mein Server war in den drei Jahren so gut abgesichert, dass nichts passiert ist - und ihr könnt mir glauben, es gab Angriffe ohne Ende auf den Server.

[flashpixx]

Ja, aber ich garantiere dir, dass niemand auch nur in die Nähe meines SSH-Zugangs kommt. Somit sehe ich da keine Probleme. Bisher konnte mir noch niemand erklären, wo denn der Nachteil des root-Zugangs liegt, wenn niemand überhaupt den SSH-Login zu Gesicht bekommt.

Portscan auf Deinen Server und ich habe den Port auf dem SSH Dämon läuft und dann geh ich mit ner Rainbow Table / Bruteforce / Dictionary an das Ausprobieren Deines root-Passwortes dran, dauert zwar etwas, aber durchaus machbar. Wenn ich ein Botnetz zur Verfügung habe, dann kann man den Zugriff auch nicht auf eine einzelne IP beschränken also sperren. Ist dann letztendlich nur eine Frage der Zeit bis ich das Passwort habe und da ich ja dann root bin, kann ich alles machen, was ich mag

[Gast King555]

Und welche IP benutzt du? Die sollte man vorher kennen, bevor man einen Portscan macht. Die wirst du nicht herausfinden.

[flashpixx]

Wenn ich Deine Domain kenne, brauch ich keine IP, denn der A Record löst ja direkt passend auf

[Gast King555]

lol, ich wusste ganz exakt, dass diese Antwort kommt.

Nein, selbst wenn du die IPs aller meiner Domains hast (was ja kein Problem ist) - du kennst dann nicht die IP, auf welcher der SSH-Daemon horcht.

[flashpixx]

Nein, selbst wenn du die IPs aller meiner Domains hast (was ja kein Problem ist) - du kennst dann nicht die IP, auf welcher der SSH-Daemon horcht.

Wieso, wenn ich alle IP's habe und Du ja sagst, dass auf irgendeiner ein SSH Dämon auf irgendeinem Port läuft, dann kann ich diesen per Portscan finden (davon ausgehend, der Dienst ist erreichbar), allenfalls probiere ich auf jeder IP & jedem Port einen SSH Connect aus. Da die Menge der Möglichkeiten endlich ist, finde ich den Dienst: Anzahl IPs * 65535 = Anzahl der Möglichkeiten

[Gast King555]

Nein, du verstehst nicht. Mein SSH-Damon horcht auf einer IP, die keiner meiner Sites zugewiesen ist. Wie willst du die rausfinden? Klar, der Provider hat vermutlich "nur" ein paar Millionen IPs, aber wie lange willst du die alle scannen? Noch dazu müsstest du bei jeder der paar Millionen IPs alle Ports durchgehen.

Da bist du schneller im Rechenzentrum eingebrochen und nimmst einfach die Festplatte mit.

[flashpixx]

Nein, du verstehst nicht. Mein SSH-Damon horcht auf einer IP, die keiner meiner Sites zugewiesen ist.

Was haben Sites mit IP's zu tun. Ich kann jede IP und deren Domains (vice versa) auflösen Domain Name Lookup, Domain Whois | DomainTools

existiert eine IP ohne Domainzuordnung, ist es schwieriger, aber dennoch nicht unmöglich.

Du machst letztendlich Security through obscurity und die Aussage von Shannon ist definitiv das, was hier relevant ist; d.h. Dein Ansatz verstecken zu wollen, wo Dein Dienst läuft ist irrelevant

[Gast King555]

Häh? Ich verstehe echt nicht, wie man die IP rausfinden kann. Wie soll das möglich sein? Ich halte das für absolut unmöglich.

Erklär mir doch bitte, wie du (theoretisch) die IP rausfinden würdest? Außer mich zu besuchen und mich zur Rausgabe zu zwingen.

Bearbeitet 21. März 2013 von King555

[Gast King555]

Sollte als Edit drangehangen werden, aber das ist hier ja nur 15 Minuten lang möglich:

Abgesehen von dieser Unmöglichkeit denke ich, dass "Security through obscurity" es nun wirklich nicht trifft. Immerhin ist das bei Weitem nicht die einzige Sicherheitsmaßnahme. Selbst wenn, auch wenn ich es nach wie vor für absolut unmöglich halte, du Kenntnis von der IP erlangen würdest, gäbe es noch den anderen Port, eine Firewall-Regel zu Verlangsamung von Portscans, 24h-Autobann bei 2-facher Falscheingabe des Passworts und zu guter Letzt natürlich das Passwort selbst!

Wer da durch kommt, bekommt von mir sogar noch einen Orden (und die Strafanzeige, natürlich)!

[flashpixx]

Häh? Ich verstehe echt nicht, wie man die IP rausfinden kann. Wie soll das möglich sein? Ich halte das für absolut unmöglich.

Ich infiziere Deinen Rechner oder Router und logge Passwort bzw. IPs zu denen Du Dich verbindest. Da Dein Server Teil eines (Sub)Netzes ist, Deine Domains auch, muss daraus folgen, dass alle IPs Deines Rechner zu dem Netz gehören, da sonst das Routing nicht möglich wäre. An das Netz Deines Hoster kommt man über die Domains, d.h. ein entsprechender Portscan über das (Sub)Netz auf verschiedenen Ports über ein Botnetz sollte den SSH Dämon finden. Da die IPs sicherlich nicht heuristisch verteilt sind, wäre es naheliegend erst einmal die IPs zu probieren, die relativ dicht beieinander liegen.

Ein Portscan für eine IP dauert geschätzt eine Stunde, d.h. bei einem 24er Netz somit 255 Stunden, bei einem Rechner, da ich über ein Botnetz das ganze verteilt rechnen lassen kann, sollte es tendenziell etwas schneller gehen, sofern Dein Server nicht unter der Last aufgibt.

Kenntnis von der IP erlangen würdest, gäbe es noch den anderen Port, eine Firewall-Regel zu Verlangsamung von Portscans, 24h-Autobann bei 2-facher Falscheingabe des Passworts und zu guter Letzt natürlich das Passwort selbst!

Wenn man Zugriff auf ein Botnetz hat, kann ich von vielen Rechnern einen Scan bzw. einen Versuch der Passworteingabe probieren, da nützt Dein 24h Ban überhaupt nichts, weil die Connects von verschiedenen IPs aus unterschiedlichen Netzen über die Welt kommen. Selbst wenn ich kein Botnetz habe, dann kann ich TOR nutzen, damit kannst Du mich nicht zurück verfolgen und sperrst allerhöchstens die Exit-Nodes, da es aber sehr viele Exit-Nodes in unterschiedlichen Ländern gibt, nutzt Dir der Ban auch nichts.

[Gast King555]

OK, jetzt übertreibst du aber maßlos. Klar, irgendwo ist ja Schluss mit der Sicherheit. Ich komme auch an alle deine Passwörter, indem ich deine Tür zu Hause eintrete und deinen PC klaue. Genau so klingt dein theoretisches Vorhaben.

Außerdem ging es doch um den root-Zugang. Und wenn du durch eine Infizierung Zugriff auf meinen PC hättest, was würde da ein Zugriff über einen Nicht-Root bringen? Gar nichts. Was würde da überhaupt irgendwas bringen?

Aber um auf Details deines Vorhabens einzugehen: Die IP ist weit entfernt von den anderen IPs, also mit Raten ist da nichts. Du müsstest definitiv alle IPs meines Providers abgrasen - und es sind verschiedene Netze. Tor-Exit-Nodes sind übrigens gesperrt. Ob's alle sind, weiß ich nicht, aber vermutlich die meisten.

Bearbeitet 21. März 2013 von King555

[Crash2001]

OK, du hast also den Server soweit abgesichert, wie du sagst.

Das Problem mit Oberflächen wie Plesk ist einfach, dass viele Leute diese bedienen können, auch wenn sie keine Ahnung haben, was es im Hintergrund eigentlich macht. Genau das sollte man aber wissen, wenn man die Oberfläche nutzen möchte, denn wenn etwas nicht so funktioniert, wie von dir erwartet, dann soltte man auch dazu in der Lage sein, das ganze manuell zu beheben.

Plesk ist nur ein Tool, das die Verwaltung erleichtert. Ein Ersatz für das ansonsten benötigte Wissen mit dem Betriebssystem sollte es aber halt nicht sein.

Zudem ist es eine zusätzliche Sicherheitslücke, denn es braucht nur jemand deine Plesk-Zugangsdaten in die Hände bekommen und schon hat er quasi Vollzugriff auf dein System und kann alles umstellen, löschen, kopieren, umbiegen wie er will. Das ist die Krux bei solchen Management-Tools. Zudem gab es bereits diverse Sicherheitslücken bei dem Tool und ich gehe einfach davon aus, dass hier auch noch weitere Sicherheitslücken existieren.

Je weniger Angriffsfläche (Möglichkeiten auf den Server zu kommen) man hat, um so unwahrscheinlicher ist es, dass er gehackt wird.

Man kann übrigens durchaus, auch wenn man Plesk nutzt, die Config des Apache manuell anpassen, ohne dass es jede manuelle Änderung wieder überschreibt. Man muss es halt nur an anderer Stelle machen und die Integration in Plesk berücksichtigen.

Da du aber ja schreibst, dass dir Plesk immer alle manuellen Änderungen am Apache überschreibt, frage ich mich doch, wie du es denn dann hinbekommen hast, dass du den Apache abgesichert und nicht benötigte Module im Apache entladen hast. Laut deiner eigenen Aussage wird dir doch die Config immer wieder überschrieben... :confused:

[Gast King555]

denn es braucht nur jemand deine Plesk-Zugangsdaten in die Hände bekommen und schon hat er quasi Vollzugriff auf dein System

Auch mein Plesk horcht auf einer unbekannten IP und unbekanntem Port mit einem sicheren Passwort. Es ist also genau so einfach in mein Plesk zu kommen, wie in meinen SSH-Zugang.

wie du es denn dann hinbekommen hast, dass du den Apache abgesichert und nicht benötigte Module im Apache entladen hast

Ich weiß ja nicht, wie gut du Plesk kennst, aber man kann in der aktuellen Version (und auch schon in füheren) viele Dinge bzgl. des Apache konfigurieren, u. a. auch festlegen, welche Module geladen werden und welche nicht.

[Crash2001]

Über Plesk kann man halt nicht alle Optionen konfigurieren, auch wenn man schon recht viel damit machen kann.

Linux ist einfach ein System, bei dem man auch mal was in die Tiefe gehen muss, wenn man Dinge absichern will, und wo nicht unbedingt ein Plesk (oder eine andere webbasierte Oberfläche) immer das Allheilmittel ist.

Immerhin ist dein Root Server aber schon besser abgesichert als sehr viele andere Root-Server, die von Privatpersonen betrieben werden, solange kein Bock in irgendeiner deiner Configs ist.