Beiträge von tab

Ich schätze mal diese Idee sollte funktionieren.

Zitat von peng

• Ein Hilfsskript bauen (welches ich über den Browser aufrufe) das wiederum mein Skript aufruft. Dann bin ich ja nämlich im richtigen Pfad
  

Ist doch eh das gleiche Verzeichnis, solange das Skript in der Konsole die Pfade relativ zu /projekt_xy anlegt kann doch der Webprozess über /var/www/vhosts/hosting123.abc123.netcup.net/projekt_xy darauf zugreifen?!? Ansonsten hilft eventuell die realpath() Funktion. Welches Problem entsteht denn konkret?

Vielleicht kann man das gesetzte WCP-Passwort ja durch den Support entfernen lassen. Oder startet ein Bürgerbegehren . Mehr fällt mir dazu auch nicht ein. Ansonsten ist die Antwort ja bereits gegegeben. 2FA für den direkten WCP -Zugang gibt es momentan nicht.

Zitat von aRaphael

Ich weiss nicht, ob sich open_basedir überhaupt mit symlinks austricksen lässt:

"When a script tries to access the filesystem, for example using include, or fopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to access it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink."

Quelle: https://www.php.net/manual/en/ini.core.php#ini.open-basedir

Nein, es lässt sich nicht durch Symlinks austricksen. Aber das Besondere hier ist ja, dass open_basedir das komplette Webhosting freigibt. Damit können prinzipiell Dateien aus dem gesamten Webspace gezielt mit Hilfe von Symlinks vom Apache ausgeliefert werden. Im Gegensatz zum Webserver ist PHP von vornherein nur durch open_basedir und Unix-Dateirechte begrenzt, braucht also eigentlich keine Symlinks um Zugriff zu Dateien außerhalb der document root zu bekommen. Es geht hier also eigentlich nur darum, das gewünschte reale Verzeichnis durch den Symlink unter einem anderen Pfad zugreifbar zu machen. Also auf ein Verzeichnis zuzugreifen, das nicht zum aktuellen Projekt gehört, indem im aktuellen Projekt ein Symlink auf das Verzeichnis erzeugt wird. Der Webserver selbst kann mit oder ohne Symlink auf keins der beiden Verzeichnisse (wenn man also den Symlink durch ein gleichnamiges Verzeichnis ersetzen würde) zugreifen, weil beide außerhalb der document root liegen.

Ich bin kein PHP-Programmierer und lese auch nur das PHP Manual. Ob da bei Funktionen wie scandir() grundsätzlich überhaupt das Verzeichnis durch einen Symlink ersetzt werden kann, das weiss ich nicht - zumindest nicht ohne es auszuprobieren. FollowSymlinks oder SymlinkIfOwnerMatch sind Einstellungen für den Webserver, ob die überhaupt einen Einfluss auf das Verhalten von PHP haben weiss ich nicht, schätze aber eher, dass das auf PHP-Ebene entweder immer oder gar ncht funktioniert, unabhängig von diesen Einstellungen. Es mag aber auch auf die Spezifikation und Implementierung der konkreten PHP-Funktion, hier scandir(), ankommen. Keine Ahnung, bisher reine Spekulation meinerseits.

Edit: Ich sehe, es klappt jetzt wohl mit dem relativen Symlink.

Und wenn du den '/' am Anfang weglässt? Ansonsten wird das Ziel ja ein absoluter Pfad, der so natürlich nicht innerhalb von irgendwas liegen kann.

Und wie führst du die index.php aus? Aufruf über den Browser?

Ist FollowSymLinks oder SymlinkIfOwnerMatch auch gesetzt (.htaccess, falls Apache überhaupt verwendet wird)

Möglicherweise wird von deinem Apache ein falsches/abgelaufenes Zertifikat ausgeliefert, wenn es nach Erneuerung deines LE-Zertifikats immer noch nicht funktioniert wäre es wohl ein Fall für den Support. Wüsste jetzt nicht was du selbst da noch dran machen könntest.

Zitat von KB19

Mama, der böse tab hat mich ausgesperrt, weil ich mich bei meiner eigenen IP-Adresse bei der ersten SSH-Verbindung vertippt habe!

*holtsicheineneueipundh4ckt*

Der kann hacken mit allen IPs die er kriegen kann, da muss er schon erst mal den public key und die Passphrase meines zum Login benutzten stinknormalen Users knacken. Danach kann er erst mal eine Weile in der Konsole am über 20-stelligen Root-Passwort rumhacken. Naja, zumindest wenn er glaubt ich merke es nicht. Die Frustration will ich ihm halt ersparen.

Ihr seid ja zimperlich . Solche IPs sperre ich komplett auf Lebenszeit (meines Servers) direkt in der Firewall. Wer versucht meinen Server zu hacken muss mir auch keine Mails schreiben und keine Websites sehen. Oft sind es eh irgendwelche russischen oder chinesischen IPs, auf die ich gut und gern verzichten kann.

Fail2ban schützt in dem Fall nur den ssh Port. Allerdings sollten ja sowieso nur Ports offen sein, die auch gebraucht werden.

Bei Netcup denke ich eher nicht, Anexia bietet aber weltweite Services an, insbesondere auch Cloud-Server. Wenn man sich die Liste der Rechenzentren anschaut, dann ist "weltweit" auch nicht übertrieben.

Wieviele Email-Adressen aus wievielen Domains sollen denn da gesammelt werden? Einiges kann man ja mit Mailaliasen machen. Und wieviele Mails sollen da täglich rausgehen? Im Prinzip funktioniert das auch mit Webspace (Webhosting). Aber je nachdem wie kritisch die Sache ist, würde ich das nicht unbedingt empfehlen. Erstens gibt es ein Maillimit was mir persönlich dicke reichen würde, einigen Kunden aber definitiv nicht. Zweitens verirren sich die netcup-Mailserver auch öfter mal auf irgendwelche Blacklisten, was dann der zuverlässigen Zustellung der versendeten Emails nicht besonders förderlich ist.

Je nachdem was da nun noch als Info kommt würde ich hinzufügen, dass unter anderem auch solche Aktionen den Mailservern Reputation kostet. Ich denke auch nicht, dass es funktionieren wird, mit Absenderadressen zu senden, die zu Domains gehören, für die netcups Mailserver nicht zuständig sind. Oder mit Absenderadressen, die nicht als Mailadresse oder Mailalias bei netcup explizit angelegt sind.

Die einem anderen Webhosting zugeordnete Hauptdomain wirst du nicht in einem zweiten Webhosting extern zugeordnet bekommen. Wenn ich mich recht erinnere, klappt es auch nicht mit einer Subdomain davon. Die Domain ist nun mal nach netcup Definition eine zusätzliche Domain und nicht extern. Mit einer wirklich externen, nicht bei netcup registrierten Domain klappt so etwas besser. Aber auch da wirst du nicht die Hauptdomain in zwei unterschiedlichen netcup Webhostings einbinden können, allenfalls dann unterschiedliche Subdomains.

Ist ja bald Black Friday

Wenn das eine Software ist, die auch auf der Mehrzahl der Webhostings auf dem Markt laufen soll und nicht nur auf Servern, dann melde das Problem bei Entwicklern der Software. Vielleicht ist da was bei der Erstellung der neuesten Version verrutscht. Der angemeckerte Pfad ist jedenfalls bei beiden Varianten der open_basedir Einstellung nicht freigegeben. Das wundert mich auch nicht weiter. Die zweite, "größere" Variante umfasst ja schon alle deine Verzeichnisse plus einige mehr, wie z.B. das temporäre Verzeichnis und das Verzeichnis in dem die Sessions gespeichet werden. Das wird wahrscheinlich nur auf Webhostings funktionieren, bei denen open_basedir komplett deaktiviert ist oder eben auf Servern, wo man das selbst beliebig einstellen kann.

Hast du das Wordpress-Toolkit benutzt hast oder manuell installiert? Du musst in jedem Fall die einzelnen Wordpress-Seiten in jeweils einem eigenen document root installiere, also AAA.de und BBB.de müssen unterschiedliche document roots haben und nicht etwa beide /httpdocs als document root.

Es kommt darauf an, welcher Aufwand betrieben wird um an die Kundendaten zu kommen. Grundsätzlich wird derjemige, der physikalischen Zugriff auf den Server hat, immer Möglichkeiten haben an Daten zu kommen, die nicht bereits verschlüsselt hochgeladen werden. Und wenn die Staatsanwaltschaft mit einem richterlichen Beschluss kommt, dann wird der Hoster selbstverständlich alle Möglichkeiten nutzen müssen die es braucht, um an die Kundendaten zu kommen. Das kann bis zur Benutzung von Debuggern gehen. Wenn man das verhindern will, dann müssen die Daten bereits verschlüsselt auf den (v)Server übertragen werden und im Bedarfsfall auch verschlüsselt wieder heruntergeladen werden. Einen grundsätzlichen Unterschied zwischen echten und virtuellen Servern sehe ich da nicht. Der eine Hoster ist vielleicht etwas williger die Kundendaten preiszugeben als der andere. Aber am Ende des Tages kann sich kein Hoster einem richterlichen Beschluss widersetzen. Dann ist der Server halt beschlagnahmt.

Edit: Natürlich ohne dass der Kunde etwas davon erfährt, dass, wenn er sich mit seinem Server verbindet, am anderen Ende die Staatsanwaltschaft sitzt.

Im normalen Betrieb wird natürlich kein Hoster so einen Aufwand treiben an Kundendaten zu kommen ohne einen sehr triftigen Grund dafür zu haben.

Also meines Erachtens

zu 1) ganz sicher

zu 2) grundsätzlich auf alles

zu 3) ja

zu 4) keine grundsätzlichen, der Aufwand mag sich etwas unterscheiden.

"Ein Script" ist halt auch nicht sonderlich informativ, das kann ja alles mögliche sein. Wenn man den Datenbankserver nirgends eingegeben hat bzw nirgends eingeben kann vor oder während der Installation, wird sich das Script naturgemäß schwertun sich mit ihm zu verbinden.

Also was du sicher brauchen wirst, ist eine open_basedir Einstellung, die auch das Verzeichnis oberhalb von public für PHP freigibt, also die mit {WEBSPACEROOT} anfängt. Direkter Download der PHP-Datei ist allerdings einigermassen komisch.