it-swarm.com.de

Änderungen an der Apache/Linux-Konfiguration betreffen das automatische Upgrade

Ich habe einigeBeiträge gelesen, die diesen Punkt zu berühren scheinen ( oder vielleicht adressieren, aber es geht mir über den Kopf). Unix ist bei weitem nicht meine Stärke.

Ich habe einen Fedora-Server geerbt, der etwas holprig ist, wenn es um automatische Upgrades geht.

Zwei Dinge sind mir aufgefallen: 1. Es fordert mich zur Eingabe von FTP-Benutzernamen und Passwort auf. Ich möchte dies vermeiden, OHNE die Anmeldeinformationen fest zu codieren (aus einer Reihe von Gründen). 2. Das neueste 3.3.1-Update schlägt aus Berechtigungsgründen fehl (frühere Upgrades sind nicht fehlgeschlagen). Die Problemumgehung ist Sudo chmod -R g + w ./* im Hauptverzeichnis von wp, aber ich habe es jedes Mal satt, das zu tun.

Fazit: Dinge funktionieren, aber es ist mehr Arbeit als ich möchte.

Im Moment scheint alles unter dem 'Apache'-Benutzer zu laufen, der ein Mitglied meiner' Entwickler'-Gruppe ist, die für die verschiedenen FTP-Benutzer dieselbe Gruppe ist und Änderungen/Bearbeitungen an Dateien/Ordnern vornimmt. Für alle neuen Dateien/Ordner, die von diesen Benutzern erstellt werden, ist der Gruppenschreibmodus jedoch nicht festgelegt, sodass ich ihn manuell ausführen muss ...

Irgendwelche Gedanken? Ich werde ein bisschen Schritt für Schritt brauchen, da ich ein Unix-Idiot bin.

Vielen Dank!

T

3
Tom Auger

Die einfachste Antwort lautet:

Solange Sie sich auf einem RedHat/CentOS/Fedora-Standardserver befinden, stellen Sie sicher, dass alles in Ihrem WordPress-Verzeichnis zu Apache: apache gehört. Dadurch wird die Aufforderung zur Eingabe von FTP-Anmeldeinformationen verhindert.

Dies hat den Vorteil, dass Apache in fast ALLEN Situationen/bin/false oder/sbin/nologin als Shell eingerichtet hat. Dies verhindert, dass jemand den Apache-Benutzer ausnutzt, um Shell-Zugriff auf Ihre Box zu erhalten.

Ich denke, dass Sie wahrscheinlich von Verzeichnissen gestolpert werden, die Berechtigungen von Benutzern mit gültigen Shells erben, deren umasks lustig eingestellt sind. Versuchen Sie, alles auf Apache zu übertragen: Apache, und führen Sie einige Testupdates durch, um festzustellen, ob 99% der Probleme, auf die Sie stoßen, dadurch nicht behoben werden.

1
ZaMoose

Die Antwort darauf ist ziemlich kompliziert.

Auf einem gemeinsam genutzten Server (auf dem mehrere Websites ausgeführt werden) bietet die Verwendung eines setuid-Prozesses für PHP (mit welchen Mitteln auch immer) zusätzliche Sicherheit für Benutzer. Wenn zwei Personen Zugriff auf einen Server haben und ihre Skripte als solche anstatt als einzelner "Apache" -Benutzer ausgeführt werden, erhält jemand, der über das Web in eine Site einbricht, nur die Privilegien dieses Benutzers, nicht die Privilegien von "Apache". die größer sein wird (Apache kann zum Beispiel die Webdateien aller sehen, um sie auszuführen, aber "otto" kann die Dateien von "bob" nicht sehen).

In diesem Fall wird WordPress als "otto" und nicht als "Apache" ausgeführt. Da es als "otto" ausgeführt wird und die WP -Dateien im Besitz von "otto" sind, kann es die Dateien nur direkt schreiben und benötigt keine FTP-Anmeldeinformationen.

Sehen Sie, es geht nur um Eigentum. Wenn die Dateien demselben Benutzer gehören, unter dem WP tatsächlich ausgeführt wird, wird die direkte Methode verwendet. Ist dies nicht der Fall, muss auf die FTP-Methode (oder eine andere Methode) zurückgegriffen werden, da sich der Dateibesitz während eines Upgrades nicht ändert. Wenn es versuchte, sie direkt als Apache-Benutzer zu schreiben, würde "Apache" die resultierenden Dateien besitzen. Dies könnte ein Sicherheitsrisiko auf einem dedizierten Server darstellen.

Für einen dedizierten Server ist es am sichersten, die Dateien eines Nicht-Apache-Benutzers zu haben, während PHP unter 'Apache' ausgeführt wird. Vielleicht ist es in einer solchen Situation sogar vorzuziehen und sicherer, einen speziellen Benutzer nur für den Besitz dieser Dateien einzurichten. Dann könnten die zu aktualisierenden Anmeldeinformationen in die wp-config-Datei gestellt werden, und selbst wenn sie auf irgendeine Weise gestohlen würden, würden sie keine Bedrohung darstellen, da diese Anmeldeinformationen an Stellen gesperrt werden könnten, an denen sie praktisch keinen Zugriff auf etwas anderes als das _ hatten.WP Dateien selbst. Wenn dann jemand einbricht, bricht er entweder als "Apache" (mit eingeschränkten Rechten) ein oder kann Code als benutzerdefinierter WP-Benutzer (mit eingeschränkten Rechten) ausführen.

Die Idee ist, die Fähigkeiten eines Benutzers zu begrenzen, der eine Lücke im System findet. Wenn jemand eine Schwachstelle findet, wird er durch die Berechtigungen des Benutzers weiter eingeschränkt, als der Prozess ausgeführt wird, mit dem er durchbrochen hat.

1
Otto

Die kurze Antwort ist, suPHP auf Ihrem Server zu aktivieren, damit WordPress als eigener Benutzer und nicht als Apache ausgeführt werden kann.

Otto erklärt hier mehr .

1
Chip Bennett