Wohin im Dateisystem mit Webanwendungen

[BlackJack]

Mal eine vielleicht blöde Frage: Wo speichert ihr eure Webanwendungen? Und warum gerade dort?

Ich wollte den mittlerweile gewachsenen Zoo auf verschiedenen Servern mal an einen ”Standard”-Ort verschieben. Bisher liegen die Anwendungen in Heimatverzeichnissen, in ``/opt/``, in Unterverzeichnissen von ``/var/``, und so weiter.

[mutetella]

@BlackJack
Ohne mir darüber jemals selbst Gedanken gemacht zu haben: Auf meinem WebFaction Host liegen die Anwendungen unter ``.../webapps``, also z. B. ``.../webapps/trac``.

mutetella

[BlackJack]

@mutetella: Ähm ja und wofür steht nun ``...``? Das ist ja eigentlich meine Frage.

[mutetella]

Ähm ja und wofür steht nun ``...``?

Ok, war ja klar...
``webapps`` liegt im Homeverzeichnis des webfaction-Accounts.

mutetella

[Sirius3]

Ich habe einen www-User, der alle Daten in seinem Home-Verzeichnis hat.

[jerch]

/srv/<Protokoll- bzw. Serverdienstname>/sub.domain....

Das /srv/ hab ich mir irgendwann mal bei SuSE abgeschaut und nie wirklich hinterfragt - nu isses Gewohnheit ....

[Brawn]

Hallo,

Bei mir ist es unter /var/www/<projekt.subdomain> (Debian geschädigt).

Meiner Meinung nach ist es fast egal wo du es reintust (/srv, /opt /var/www,...), hauptsache es funktioniert (auch nach einem Upgrade) und du fährst bei deinen Servern eine Linie (falls du mal nicht da bist und ein anderer deine Arbeit tun soll (Dokumentation)).

@jerch:
Komischerweise die Leute was ich kenne, haben auch mit Suse angefangen.

[BlackJack]

@Brawn: Naja so egal ist es nicht und ``/var/www/…`` ist wohl *der* Ort wo man es *ganz bestimmt nicht* ablegen sollte, denn das ist traditionell das `DocumentRoot` vom Webserver.

Klar kann man Programm und nicht-öffentliche Daten auch dort per Webserverkonfiguration schützen, aber man muss das halt aktiv tun und darf das nie vergessen und wenn irgendwas an der Webserverkonfiguration kaputt geht, kann trotzdem potentiell alle Welt Programm/Quelltext/Templates/Konfiguration (mit Zugangsdaten zur DB, …) auslesen. Böse Falle.

[Brawn]

Klar kann man Programm und nicht-öffentliche Daten auch dort per Webserverkonfiguration schützen, aber man muss das halt aktiv tun und darf das nie vergessen und wenn irgendwas an der Webserverkonfiguration kaputt geht, kann trotzdem potentiell alle Welt Programm/Quelltext/Templates/Konfiguration (mit Zugangsdaten zur DB, …) auslesen. Böse Falle.

Man sollte so oder so den Webserver einschränken und die Zugriffe auf ohne index.html oder ähnliches sperren.
Und ausserdem greift das Programm als Dienst bsp.: www-data drauf zu, somit bringt es auch wenig die Configs wo anders hinzulegen.
Ich sehe da eher ein Risiko, wenn jemand dem Webserver aus dem Webverzeichnis in ein anderes Verzeichnis im System zugreifen lässt (nur da man meint, dass der Ordner safe unter /etc sicher sei).

PS.: Könnte es sein, dass wir an uns vorbeireden? :K

EDIT: Natürlich unter /etc und in die Systemordnern sollte man keine Webfreigabe machen.

[BlackJack]

@Brawn: Diese Einschränkungen auf Verzeichnisse muss man aktiv einrichten, und wenn man irgendwas an der Konfiguration versemmelt oder sich auch den verschiedensten anderen Gründen mal etwas ändert, kann es halt doch immer mal wieder passieren das der Webserver Sachen aus DocumentRoot ausliefert die man mal versucht hat zu schützen. Und das ist nicht nur theoretisch, denn eine Suchmaschine nach typischen Texten auf von Webservern generierten Verzeichnisauflistungen fördert immer mal wieder Ergebnisse zu Tage von Verzeichnissen bei denen der oder die Verantwortliche(n) sicher nicht wollten das die jeder einfach so herunterladen kann. So eine Suchanfrage gehört zu Evil Scriptkiddie 101

Wenn man die Webanwendung und die Daten nicht unter DocumentRoot speichert, dann kann das halt gar nicht erst passieren, egal wie kaputt die Webserverkonfiguration ist.

Und selbst wenn man das Auflisten verhindert, kann ein Angreifer ja immer noch gezielt versuchen Dateien abzurufen. Viele Webanwendungen, insbesondere wenn sie ein Rahmenwerk verwenden, haben ja ein ähnliches Namensschema für ein paar strategisch wichtige Quelltextdateien. So etwas wie `urls.py`, `models.py`, oder `config.py` kann man als Angreifer immer mal ausprobieren. Und in so einer `config.py` stehen dann nicht selten die Zugangsdaten zur Datenbank drin, und auch gerne mal Zugangsdaten zu einem Mailserver und ähnlich sensibles Zeug.

Warum Du den Benutzer unter dem das läuft ins Spiel bringst, ist mir nicht ganz klar. Der spielt bei dem Problem gar keine Rolle.

[DasIch]

Bei mir liegts in /var/www/<app>/ hab allerdings auch keinen DocumentRoot auf /var/www gesetzt und selbst wenn die Konfiguration kaputt ist, /var/www ist nicht der nginx default deswegen mache ich mir um irgendein ominöses kaputt gehen der Konfiguration jetzt weniger sorgen.

Ansonsten ist der Ansatz für jede Anwendung einen User zu haben und die Anwendung dann ins home Verzeichnis zu packen wohl auch recht populär.

[Leonidas]

Ansonsten ist der Ansatz für jede Anwendung einen User zu haben und die Anwendung dann ins home Verzeichnis zu packen wohl auch recht populär.

So mache ich das auch, jeder User hat dazu noch sein eigenes VirtualEnv und eigenen PostgreSQL-User. Dazu noch ein wenig Config in /etc für mod_wsgi und das wars.