Ankündigung

Einklappen
Keine Ankündigung bisher.

Mehrere Benutzer und private Verzeichnisse mit Apache

Einklappen

Neue Werbung 2019

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

  • fantast
    hat ein Thema erstellt Mehrere Benutzer und private Verzeichnisse mit Apache.

    Mehrere Benutzer und private Verzeichnisse mit Apache

    Folgendes Szenario. Ich habe einen Server, dieser wiederum ein Verzeichnis, nennen wir es /srv/www. In diesem Verzeichnis liegen die Webauftritte mehrerer Personen /srv/www/kunde1, /srv/www/kunde2.
    Der Apache muss mindestens Leserechte auf die Verzeichnisse haben. Wie kann ich nun verhindern, dass Kunde1 mit einem Script per Apache das Verzeichnis von Kunde2 ausliest ?
    Oder noch konkreter: Kunde2 hat in /srv/www die Zugangsdaten fuer seine Datenbank liegen. Ausserhalb des DocRoots. Der Apache muss trotzdem drauf zugreifen duerfen. Wie verhindere ich, dass Kunde1 sie auch auslesen kann (via Apache) ?
    Mir faellt nix passendes ein...

    edit: einige Ergaenzungen noch: fuer jeden Kunden ist ein VirtualServer eingerichtet, der auf das Verzeichnis des jeweiligen Kunden zeigt. Mit PHP ist es dennoch moeglich auch oberhalb des DocRoots Dateien zu lesen.
    Ich habe mir grade das Apache-Manual angeschaut, mpm_perchild ist noch nicht aktiv, so wie ich das sehe, und mod_suexec kommt daher nicht in Betracht, da ich PHP als Modul, nicht als CGI-Programm benutze...

  • Gast-Avatar
    Ein Gast antwortete
    Zitat von fantast
    confixx hingegen habe ich nie gemocht und gleich wieder runtergeschimissen.
    wie laeuft denn das bei confixx mit den domains ?
    Bei mir erstellt Confixx den Systemuser <pop3user>oponly,
    trägt die Domain (falls neu) in /etc/postfix/confixx_localDomains ein und die Email incl. localen User in /etc/postfix/confixx_virtualUsers.

    Danach kommt dann das übliche postmap...

    Einen Kommentar schreiben:


  • fantast
    antwortet
    hehe, irgendwie muss ich mich doch beschaeftigen *gg

    sendmail.cf hat sich irgendjemand mal ausgedacht, als er ein wenig zu viel lsd genommen hat, das syntax-highlightin im vim is schick. der rest is furchtbar. da lass ich auch die finger von so gut es geht. aliases ist ja etwas einfacher zu bedienen.
    selbstverstaendlich ist mein server kein open relay. verschicken darf da nur, wer darf. und ja, ich verwende zwar webmin, aber nur da, wo ich die kommandos auch alle nachvollziehen bzw. per hand durchfuehren koennte. man will ja lernen. confixx hingegen habe ich nie gemocht und gleich wieder runtergeschimissen.
    wie laeuft denn das bei confixx mit den domains ?

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    @fantast
    >okeh das is soweit alles verdaut. naechste frage

    Ich ahnte sowas schon...

    MTA:
    >is zwar derselbe rechner, aber das sollte ja auch moeglich sein.
    >sendmail laeuft bei mir.

    Ich bin kein Freund von Sendmail. Wenn Du Dir schon mal sendmail.cf angeguckt hast, kannst Du das nachempfinden.

    >is /etc/aliases mein freund ? oder geht das einfacher ?

    Die korrekte Konfiguration eines MTA so, daß er nicht als 'open relay' für die "Freunde aus der SPAM-Fraktion" ausgenutzt werden kann, ist ein sehr weites Feld. Wenn Du kein Confixx nutzen willst, dann bleibt Dir als echte Alternative nur noch Postfix mit MySQL Unterstützung und viel zusätzliche manuelle Arbeit übrig.

    Bevor Du fragst: auch wenn Du webmin einsetzt, mußt Du über die erforderlichen Kenntnisse verfügen. Webmin ist kein Ersatz für eine ISP Software sondern eher ein Werkzeug für den Root, wenn der zu faul ist, in der Shell meterlange Kommandos abzusetzen.

    Einen Kommentar schreiben:


  • fantast
    antwortet
    okeh das is soweit alles verdaut. naechste frage
    wie kann ich verhindern, dass user a dem domain1 gehoert emails auf domain2 empfangen kann. also es soll nur moeglich sein mails an a@domain1.tld zu verschicken. a@domain2.tld soll nen user not found bringen. is zwar derselbe rechner, aber das sollte ja auch moeglich sein. sendmail laeuft bei mir. is /etc/aliases mein freund ? oder geht das einfacher ?

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    Zitat von axo
    Zitat von fantast
    wie macht das denn zb confixx.
    gar nicht oder nicht ordentlich. deswegen sollte man niemals confixx verwenden -
    Das ist falsch. Man soll nur die Software verwenden, die man auch administrieren kann. Man muß wissen, was man tut und worauf man zu achten hat, wenn man einen Account anlegt.
    jeder, der den trick kennt, holt sich mit confixx root-rechte über den server.
    Quark. Man kann, wenn der safe_mode ausgeschaltet ist, mittels der Systemfunktionen nach den Confixx Configfiles suchen und sich diese anzeigen lassen. Im Ergebnis erhält man das Adminpaßwort für die Datenbank. Den Rest beschreibe ich hier nicht...
    http://www.debianhowto.de/howtos/de/webconfig/ eine kurze anleitung - scheint ganz ok zu sein.
    Dort steht:
    Zitat von debianhowto
    4.2.4. PHP Skripte abschotten
    Es gibt mehrere Möglichkeiten, auch PHP-Skripte soweit einzuengen, dass sie sich nur innerhalb eines bestimmten Verzeichnis austoben dürfen. Eine Möglichkeit wäre, PHP nicht als Modul im Apache laufen zu lassen, sondern PHP als CGI-Binary aufzurufen, das ja wiederum unter dem jeweils passenden User ausgeführt wird. Eine weitere wäre (suPHP).
    Korrekt.
    Allerdings gibt es auch geeignete Möglichkeiten, PHP als normales Apachemodul (mod_php4) anzubieten und gleichzeitig die nötige Sicherheit herzustellen. Diese beschreibe ich im Folgenden.

    Das PHP-Modul kann dazu veranlasst werden, sich nur in einem Bereich zu bewegen, d.h. nur dort Dateien einzubinden (include) oder Dateioperationen durchzuführen. Ebenso kann ein Verzeichnis definiert werden, in das temporäre (Upload-)Dateien geschrieben werden, sodass die nicht ins /tmp des Systems gelangen. Dazu einfach folgende dre Zeilen wieder in jedem VHost angepasst (User- und Domainname) hinzufügen:

    Code:
    php_admin_value open_basedir /var/www/user1/user1-1.tld/
    php_admin_value upload_tmp_dir /var/www/user1/user1-1.tld/temp
    php_admin_value session.save_path /var/www/user1/user1-1.tld/temp/
    Ab hier wirds ungenau:
    Noch mehr Sicherheit kann mit dem safe_mode erreicht werden, der genauso für jeden VHosts extra an (=sicher) oder ausgeschaltet werden kann. Dazu folgende Direktive noch einfügen:

    Code:
     php_admin_value safe_mode on
    Und genau das ist falsch, weil man nur dann Sicherheit erreicht, wenn man keine Systemfunktionen zuläßt. Die einzige sinnvolle Möglichkeit ist die, den safe_mode einzuschalten.

    Wer den safe_mode ausschalten muss (einige Skripte erfordern dies leider), kann in der Systemweiten PHP-Konfigurationsdatei /etc/php4/apache/php.ini kritische Funktionen verbieten. Das kann momentan allerdings nur in dieser Datei geschehen, nicht pro VHost einzeln. Dazu einfach die Funktionen durch Kommas getrennt hinter der Direktive disable_functions aufzählen. Mindestens folgende:
    Code:
    disable_functions = system,exec,passthru,popen,escapeshellcmd,shell_exec
    Und das ist eine trügerische Sicherheit.

    Probleme mit Confix 3.01
    Wer exec deaktiviert bekommt Probleme, sofern er die (unnoetige) Resellerverwaltung Confixx 3.01 nutzt.
    Und das ist Quark, weil die Resellerverwaltung nicht unnötig ist.

    Hier eine Liste der "bösen Funktionen", die man nach Prüfung mehr oder weniger global verbieten muß, wenn man den safe_mode ausknipst:
    system():
    Die Funktion system() ähnelt der C Version der Funktion sehr, indem es einen übergebenen Befehl ausführt und dessen Ausgabe anzeigt. Wir als zweiter Parameter der Funktion eine Variable übergeben, so wird der Rückgabestatus des Befehls in diese geschrieben.

    exec():
    exec() führt ein gegebenen Befehl aus, ohne eine Ausgabe zu erzeugen.

    passthru():
    Die Funktion passthru() ähnelt der Funktion exec(), da sie ebenfalls einen Befehl ausführt. Ist der Parameter return_var angegeben, wird der Rückgabestatus des UNIX-Befehls hier abgelegt.

    popen():
    Öffnet eine Verbindung zu einem Prozess, der durch die Anweisung command ausgeführt wurde.

    escapeshellcmd():
    escapeshellcmd() maskiert alle möglichen Zeichen in einer Zeichenkette, die dazu benutzt werden könnten, um einen Shellbefehl zur Durchführung von willkürlichen Befehlen zu veranlassen.

    shell_exec():
    Diese Funktion ist identisch mit dem 'backtick operator'.

    proc_open():
    proc_open() is similar to popen() but provides a much greater degree of control over the program execution. cmd is the command to be executed by the shell.

    highlight_file():
    Die Funktion highlight_file() erzeugt die Ausgabe des Codes der Datei filename mit hervorgehobener Syntax. Dabei werden die Farben des in PHP eingebauten Syntax-Highlighter benutzt.

    disk_free_space():
    Diese Funktion gibt den freien Speicherplatz eines Verzeichnisses in Byte zurück.

    diskfreespace():
    Von diesem Alias wird abgeraten, benutzen Sie stattdessen disk_free_space().

    popen():
    Öffnet eine Verbindung zu einem Prozess, der durch die Anweisung command ausgeführt wurde.

    fsockopen():
    Öffnet eine Socket-Verbindung zum Internet (AF_INET, unter Verwendung von TCP oder UDP) oder unter Unix (AF_UNIX).

    pfsockpen():
    Diese Funktion beinhaltet das gleiche wie fsockopen() mit dem Unterschied, dass die Verbindung nicht beendet wird, sobald das Script beendet wird. Sie ist die permanente-Version von fsockopen().

    show_source():
    Diese Funktion ist ein Alias der Funktion highlight_file().

    php_uname():
    php_uname() returns a string with a description of the operating system PHP is built on.

    ini_get():
    Returns the value of the configuration option on success.

    ini_get_all():
    Returns all the registered configuration options as an associative array. If optional extension parameter is set, returns only options specific for that extension.

    ini_alter():
    This function is an alias of ini_set().

    ini_restore():
    Restores a given configuration option to its original value.

    ini_set():
    Sets the value of the given configuration option. Returns the old value on success, FALSE on failure.

    getrusage():
    Zeigt den aktuellen Ressourcenverbrauch an. Dies ist eine Schnittstlle zu getrusage(2). Stellt ein assoziatives Array mit den Daten zur Verfügung, die der Systemaufruf ausgibt. Wenn who 1 ist, wird getusage mit RUSAGE_CHILDREN aufgerufen.

    mysql_list_dbs():
    mysql_list_dbs() liefert eine Ergebnis-Kennung, die alle Datenbanken auf dem Datenbankserver enthält.

    get_current_user():
    Zeigt den Namen des Besitzers des aktuellen PHP-Scripts an.

    set_time_limit():
    Legt die Zeit in Sekunden fest, die ein Script laufen darf.

    getmyuid():
    Zeigt die User-ID des aktuellen Scripts oder FALSE bei einem Fehler.

    getmypid():
    Zeigt die aktuelle ID des PHP-Prozesses oder FALSE bei einem Fehler.

    Achtung: Wenn PHP als Server-Modul läuft, ist es nicht garantiert, dass Scripts unter verschiedenen PIDs laufen.

    dl():
    Lädt die mittels dem Parameter library angegebene PHP-Erweiterung.

    leak():
    void leak(int num_bytes=3)
    Cause an intentional memory leak, for testing/debugging purposes.

    listen():
    this function lacks a proto definition

    chown():
    Ändert den Eigentümer der Datei filename in Benutzer user.

    chmod():
    Diese Funktion ändert die Zugriffsrechte der Datei spezifiziert in filename in die Zugriffsrechte um, die in mode spezifiziert sind.

    chgrp():
    Weist der Datei filename die Benutzergruppe group zu (spezifiziert durch Name oder Nummer).

    realpath():
    realpath() expandiert alle symbolischen Links, und beseitigt Verweise zu '/./', '/../' und extra '/' Zeichen im Input path, und gibt den absoluten Pfadnamen kanonisch zurück. Der Pfad im Ergebnis enthält keine Komponenten eines symbolischen Links mehr, wie '/./' or '/../'.

    link():
    link() erzeugt einen absoluten Link mit dem Ziel target.

    Siehe auch symlink() um symbolische Links zu erstellen und readlink() zusammen mit linkinfo().

    Einen Kommentar schreiben:


  • axo
    antwortet
    Zitat von fantast
    wie macht das denn zb confixx.
    gar nicht oder nicht ordentlich. deswegen sollte man niemals confixx verwenden - jeder, der den trick kennt, holt sich mit confixx root-rechte über den server.

    http://www.debianhowto.de/howtos/de/webconfig/ eine kurze anleitung - scheint ganz ok zu sein.

    Einen Kommentar schreiben:


  • fantast
    antwortet
    yep, hab ich mir auch so gedacht...

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    Zitat von fantast
    zum thema: dann werd ich mich wohl mal mit dem safe_mode auseinandersetzen, fand mod_php immer ganz nett
    Den safe_mode sollte nur für die Tüten anknipsen, denen der Server nicht gehört. Die dürfen, im Gegensatz zum Admin, nicht mit cat die Configfiles mit den Zugangsdaten lesen können.

    Einen Kommentar schreiben:


  • fantast
    antwortet
    ich habs deaktiviert, versuch es gar nich erst *gg kann sone admin programme nich ab.
    zum thema: dann werd ich mich wohl mal mit dem safe_mode auseinandersetzen, fand mod_php immer ganz nett

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    Zitat von fantast
    wie macht das denn zb confixx.
    Prinzipiell so ähnlich, wie ich geschrieben hatte.

    php is hier allerdings als apache-modul hinterlegt. safe_mode is aus. wies mit open_basedir aussieht weiss ich net.
    safe_mode muß für die Virtualhosts angeschaltet werden, auf die solche User Zugriff haben, denen Du den Server nicht schenken willst.

    Einen Server mit Confixx 1.6 konnten wir innerhalb von 3 Minuten knacken, weil der safe_mode ausgeschaltet war.
    gibts da noch ne andere moeglichkeit als die von meikel vorgeschlagene ?
    PHP als CGI compilieren und konfigurieren. Dann startet der Apache das PHP mit den im Virtualhost angegebenen Usernamen. Allerdings macht dann Confixx nicht mehr mit, weil es nur mit der Modul Version läuft.

    Einen Kommentar schreiben:


  • fantast
    antwortet
    wie macht das denn zb confixx. das is auf dem s4y-vserver vorinstalliert und behauptet verschiedene benutzer machen zu koennen. php is hier allerdings als apache-modul hinterlegt. safe_mode is aus. wies mit open_basedir aussieht weiss ich net. gibts da noch ne andere moeglichkeit als die von meikel vorgeschlagene ?

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    bin zwar kein grosser fan von dem safe-mode
    Der safe_mode ist erforderlich, damit keine System Befehle ausgeführt werden dürfen.
    ZB. sowas:
    Code:
    echo shell_exec('/bin/cat /srv/www/pfad/zu/geheime_datei');
    Da schlägt die open_basedir Beschränkung leider nicht zu.

    Einen Kommentar schreiben:


  • fantast
    antwortet
    aah, das is dochmal brauchbar. okeh werd ich mal reinschaun, besten dank. bin zwar kein grosser fan von dem safe-mode, tendiere da auch eher zur cgi-loesung aber schaun mer mal...

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    Re: Mehrere Benutzer und private Verzeichnisse mit Apache

    Zitat von fantast
    Mir faellt nix passendes ein...
    safe_mode = on
    in jeden Virtualhost für jeden Kunden ein separates open_basedir definieren.

    Damit Sessions und HTTP Upload möglich sind, müssen die Variablen upload_tmp_dir und session.save_path auf ein Verzeichnis unterhalb von open_basedir zeigen

    Einen Kommentar schreiben:

Lädt...
X