Apache mit Perl und AuthUserFile (.htaccess), aber wie?

Apache, Lighttpd, nginx, Cherokee
Post Reply
roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar
Contact:
 

Apache mit Perl und AuthUserFile (.htaccess), aber wie?

Post by roi »

Guten Abend,

das Thema wurde hier zwar schon ein paarmal besprochen, aber ich versuche es trotzdem nochmal, das aufzuwaermen und hoffe trotzalledem auf Anteilnahme von Euch. ;-)

Bin mit meiner Apache-Config (es laufen fuer verschiedene Benutzer VHosts, die nicht aufeinander oder sonstwo ausserhalb des Webspaces zugreifen sollen) inzwischen recht zufrieden was Sicherheit anbelangt. PHP loese ich momentan mit den safe_mode etc. Geschichten, was zwar nicht ganz optimal ist wie man hier in verschiedenen Threads lesen kann, aber damit mach ich erst weiter, wenn ich gravierendere Probleme geloest habe, die ich hier schildern will.

Ich setze suEXEC ein, hier habe ich mich am DebianHowto orientiert. Rewrite ueber .htaccess scheint auch gut zu funktionieren, dh Rewrites auf ausserhalb des eigenen Webdirs funktionieren nicht. Allerdings habe ich das Problem, dass sich z.B. AuthUserFile recht seltsam verhaelt. Gebe ich das File so an "AuthUserFile /var/www/webdir/.htpasswd" dann wird das File auch gefunden. Gebe ich es so an "AuthUserFile .htpasswd" dann sucht er das File laut Logfile in /etc/apache. Laut Apache-Docs ist das wohl auch richtig so, aber wie kann ich das korrigieren? Kenne das von frueher als einfacher Benutzer gar nicht, dass man da absolute Pfade angeben muss. Was mich allerdings viel mehr stoert: Gebe ich einen absoluten Pfad an, ist es egal, wo ich den Apachen das File suchen lasse. Er oeffnet es naemlich von ueberall, egal ob es in /etc/, /usr/ oder in einem anderen Webspace liegt. 8O

Auch aeusserst stoerend finde ich das Verhalten von Perl. Mit suEXEC habe ich es zwar in den Griff bekommen, dass u.g. Script nicht mehr auf Inhalte anderer Webspaces zugreifen kann, aber z.B. /etc/passwd wird immer noch brav angezeigt. :evil:

Gut, mit mod_security kann ich das Problem wohl umschiffen indem man den Apachen chrootet (20 minuetige Beschaeftigung mit dem Tool haben dazu gefuehrt, dass sich der Apache mehrfach verabschiedete), aber die super Loesung scheint es ja nicht zu sein. Ansonsten kam hier im Forum noch die Idee, irgendwie / mit chmod zu bearbeiten und man hat das Problem so irgendwie geloest, was mir allerdings noch nicht so ganz klar ist. Sehe glaube ich den Wald vor lauter Baeumen nicht...

Wie macht Ihr denn das?

Vielen Dank und viele Gruesse,
Martin

Code: Select all

#!/usr/bin/perl -T
$htmlfile = "/etc/motd";

print "Content-type: text/htmlnn";

open(FILE,"$htmlfile");
while(<FILE>) {
   print $_;
   }
   exit;
roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar
Contact:
 

Re: Apache mit Perl und AuthUserFile (.htaccess), aber wie?

Post by roi »

Kann mir wirklich niemand einen kleinen Tipp geben?

Bin in dem Thema immer noch nicht weiter. Gut, die Moeglichkeit chroot ueber mod_security ziehe ich nicht mehr in Erwaegung, da ist mir der Stress, was dann nachher alles nicht mehr laeuft und neu eingerichtet werden uss, einfach zu gross.

PHP schuetze ich inzwischen nicht mehr ausschliesslich ueber den safe_mode sondern lasse es mit suPHP laufen. Aber das hat ja nix mit meinen oben geschilderten Problemen zu tun.

Kann mir einfach ned vorstellen, dass Ihr alle die Probleme auch habt. ;-)
Roger Wilco
Posts: 5923
Joined: 2004-05-23 12:53
 

Re: Apache mit Perl und AuthUserFile (.htaccess), aber wie?

Post by Roger Wilco »

Roi wrote:Laut Apache-Docs ist das wohl auch richtig so, aber wie kann ich das korrigieren?
Gar nicht. Die .ht*-Dateien müssen für den Apache lesbar sein und das Wurzel-Verzeichnis (ServerRoot) kannst du nur 1x pro Apache-Instanz setzen.
Roi wrote:Auch aeusserst stoerend finde ich das Verhalten von Perl. Mit suEXEC habe ich es zwar in den Griff bekommen, dass u.g. Script nicht mehr auf Inhalte anderer Webspaces zugreifen kann, aber z.B. /etc/passwd wird immer noch brav angezeigt. :evil:
Was stört dich daran, dass man /etc/passwd lesen kann? Im Ã?brigen muss das so sein, weil SuExec sonst nicht funktioniert (die UID muss zu einem Benutzernamen "aufgelöst" werden können und andersrum). Wenn du das ändern willst, musst du jeden Benutzer in ein eigenes chroot-Jail packen. Mit allen daraus resultierenden Konsequenzen.
Roi wrote:Ansonsten kam hier im Forum noch die Idee, irgendwie / mit chmod zu bearbeiten und man hat das Problem so irgendwie geloest
Nein. Das oben beschriebene "Problem" kannst du damit nicht lösen. Natürlich sollten die Berechtigungen der Dateien in /etc aber sinnvoll gesetzt sein, d. h. so restriktiv wie möglich. /etc/passwd und /etc/group müssen aber für alle lesbar sein.
roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar
Contact:
 

Re: Apache mit Perl und AuthUserFile (.htaccess), aber wie?

Post by roi »

Roi wrote:Laut Apache-Docs ist das wohl auch richtig so, aber wie kann ich das korrigieren?
Roger Wilco wrote:Gar nicht. Die .ht*-Dateien müssen für den Apache lesbar sein und das Wurzel-Verzeichnis (ServerRoot) kannst du nur 1x pro Apache-Instanz setzen.
Dachte, ich haette frueher, als ich noch Anwender war, das so machen koennen, also die .htpasswd ohne absolutes Verzeichnis anzugeben.

Finde dieses Verhalten halt stoerend, dass man theoretisch jede Datei als Passwort-Datei einbinden. Witzigerweise auch Dateien aus anderen VHosts.
Roi wrote:Auch aeusserst stoerend finde ich das Verhalten von Perl. Mit suEXEC habe ich es zwar in den Griff bekommen, dass u.g. Script nicht mehr auf Inhalte anderer Webspaces zugreifen kann, aber z.B. /etc/passwd wird immer noch brav angezeigt. :evil:
Roger Wilco wrote:Was stört dich daran, dass man /etc/passwd lesen kann? Im Ã?brigen muss das so sein, weil SuExec sonst nicht funktioniert (die UID muss zu einem Benutzernamen "aufgelöst" werden können und andersrum). Wenn du das ändern willst, musst du jeden Benutzer in ein eigenes chroot-Jail packen. Mit allen daraus resultierenden Konsequenzen.
Auf chroot hab ich keine Lust, das erscheint mir ein Hoellenaufwand und danach dann wahrscheinlich immer noch mit Problemen gespickt.
Roi wrote:Ansonsten kam hier im Forum noch die Idee, irgendwie / mit chmod zu bearbeiten und man hat das Problem so irgendwie geloest
Roger Wilco wrote:Nein. Das oben beschriebene "Problem" kannst du damit nicht lösen. Natürlich sollten die Berechtigungen der Dateien in /etc aber sinnvoll gesetzt sein, d. h. so restriktiv wie möglich. /etc/passwd und /etc/group müssen aber für alle lesbar sein.
Dh ich muss hergehen und jede einzelne Datei anfassen und entsprechend so berechtigen, dass die VHost-User nicht zugreifen duerfen, richtig? Das erscheint mir ein Hoellenaufwand. Hab eben schon ueberlegt, ob ich das mit den POSIX ACLs machen soll. Also einfach gar nix aendern sondern nur ueber die POSIX ACLs sagen, dass eine bestimmte Gruppe nicht zugreifen darf. Auf was muss denn der suEXEC-User zugreifen duerfen ausser sein Webverzeichnis?
Roger Wilco
Posts: 5923
Joined: 2004-05-23 12:53
 

Re: Apache mit Perl und AuthUserFile (.htaccess), aber wie?

Post by Roger Wilco »

Roi wrote:Finde dieses Verhalten halt stoerend, dass man theoretisch jede Datei als Passwort-Datei einbinden. Witzigerweise auch Dateien aus anderen VHosts.
Ja. Ist halt so. Du könntest natürlich für jeden Benutzer einen eigenen kleinen httpd laufen lassen und die dann mit einem Reverse-Proxy nach außen verfügbar machen. Dann können die Berechtigungen entsprechend restriktiv gesetzt werden.
Roi wrote:Dh ich muss hergehen und jede einzelne Datei anfassen und entsprechend so berechtigen, dass die VHost-User nicht zugreifen duerfen, richtig?
Nein, nicht jede Datei. Es gibt neben /etc/passwd und /etc/group durchaus noch andere Dateien, auf welche die Benutzer zugreifen können sollten, z. B. /etc/localtime.
Roi wrote:Das erschein mir ein Hoellenaufwand.
Du musst dich immer zwischen Sicherheit und Bequemlichkeit entscheiden bzw. ein (für dich) gesundes Gleichgewicht finden.
Roi wrote:Hab eben schon ueberlegt, ob ich das mit den POSIX ACLs machen soll. Also einfach gar nix aendern sondern nur ueber die POSIX ACLs sagen, dass eine bestimmte Gruppe nicht zugreifen darf. Auf was muss denn der suEXEC-User zugreifen duerfen ausser sein Webverzeichnis?
Ja, die POSIX ACL wären eine Möglichkeit, die allerdings auch a) einen erhöhten Konfigurationsaufwand nach sich zieht und b) stark auf die Performanz des Systems drückt. Die Benutzer, für die du SuExec einrichtest, müssen auf die Skripte, den Skriptinterpreter und alle dynamisch gelinkten Bibliotheken zugreifen können, die der Skriptinterpreter benötigt.
rootsvr
Posts: 538
Joined: 2005-09-02 11:12
Contact:
 

Re: Apache mit Perl und AuthUserFile (.htaccess), aber wie?

Post by rootsvr »

Eine ähnliche Frage hab ich auch.. Danke suExec/OpenbaseDir/Doc_root kann man ja zumindest PHP einsperren, geht das für andere CGIs auch? wenn ja wie?
roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar
Contact:
 

Re: Apache mit Perl und AuthUserFile (.htaccess), aber wie?

Post by roi »

rootsvr wrote:Eine ähnliche Frage hab ich auch.. Danke suExec/OpenbaseDir/Doc_root kann man ja zumindest PHP einsperren, geht das für andere CGIs auch? wenn ja wie?
Du meinst suPHP plus die safe_mode etc Einschraenkungen ueber die php.ini, oder?

CGIs scheint man gar nicht einsperren zu koennen, zumindest glaube ich das aus den o.g. Posts von Roger Wilco entnommen zu haben. Hier scheint nur eine Ueberpruefung und eventuelle Anpassung der Verzeichnis-/Dateirechte moeglich zu sein. Oder hab ich nicht richtig gelesen?
Roi wrote:Finde dieses Verhalten halt stoerend, dass man theoretisch jede Datei als Passwort-Datei einbinden. Witzigerweise auch Dateien aus anderen VHosts.
Roger Wilco wrote:Ja. Ist halt so. Du könntest natürlich für jeden Benutzer einen eigenen kleinen httpd laufen lassen und die dann mit einem Reverse-Proxy nach außen verfügbar machen. Dann können die Berechtigungen entsprechend restriktiv gesetzt werden.
Oh ne lass mal stecken. :-) Das klingt aehnlich aufwaendig wie die chroot Geschichte. Wie machst Du das denn? So wie ich, nur dass Du Dich um die Ueberpruefung der Verzeichnis-/Dateirechte schon ausgiebig gekuemmert hast? Wie machen es die anderen Leute hier im Rootforum? Wie machen es die grossen Provider?
Roi wrote:Dh ich muss hergehen und jede einzelne Datei anfassen und entsprechend so berechtigen, dass die VHost-User nicht zugreifen duerfen, richtig?
Roger Wilco wrote:Nein, nicht jede Datei. Es gibt neben /etc/passwd und /etc/group durchaus noch andere Dateien, auf welche die Benutzer zugreifen können sollten, z. B. /etc/localtime.
Ja das meinte ich auch so. Also jede Datei/Verzeichnis, auf das der Webuser keinen Zugriff benoetigt, muss ich anpassen damit er nicht mehr drauf darf/kann.
Roi wrote:Das erschein mir ein Hoellenaufwand.
Roger Wilco wrote:Du musst dich immer zwischen Sicherheit und Bequemlichkeit entscheiden bzw. ein (für dich) gesundes Gleichgewicht finden.
Hab es oben ja schon anklingen lassen: Wie hast Du das Thema umgesetzt?
Roi wrote:Hab eben schon ueberlegt, ob ich das mit den POSIX ACLs machen soll. Also einfach gar nix aendern sondern nur ueber die POSIX ACLs sagen, dass eine bestimmte Gruppe nicht zugreifen darf. Auf was muss denn der suEXEC-User zugreifen duerfen ausser sein Webverzeichnis?
Roger Wilco wrote:Ja, die POSIX ACL wären eine Möglichkeit, die allerdings auch a) einen erhöhten Konfigurationsaufwand nach sich zieht und b) stark auf die Performanz des Systems drückt.
Oha. Drueckt das so stark auf die Performance? Hast Du spontan ungefaehre Zahlen parat? Auch wenn es nur ueber den Kernel aktiviert und das Volume so gemountet ist oder nur, wenn es tatsaechlich aktive ACLs gibt?
Roger Wilco wrote:Die Benutzer, für die du SuExec einrichtest, müssen auf die Skripte, den Skriptinterpreter und alle dynamisch gelinkten Bibliotheken zugreifen können, die der Skriptinterpreter benötigt.
Das ist ja ne Menge Kram, an sich ja logisch. Puh das alles richtig zu erwischen... Hm... Dazu kommt dann beispielsweise noch, dass man natuerlich nicht einfach /var/ sperren kann weil die Webuser sonst auch nicht mehr in ihre Webroots kommen, hier drunter muss man dann jedes Verzeichnis einzeln angehen.
Roger Wilco
Posts: 5923
Joined: 2004-05-23 12:53
 

Re: Apache mit Perl und AuthUserFile (.htaccess), aber wie?

Post by Roger Wilco »

Roi wrote:CGIs scheint man gar nicht einsperren zu koennen, zumindest glaube ich das aus den o.g. Posts von Roger Wilco entnommen zu haben.
Da haben wir uns glaube ich falsch verstanden. Du kannst z. B. bei PHP auch wenn es als CGI/FastCGI läuft, die open_basedir Restrictions und safe_mode benutzen. Bei anderen Skriptinterpretern gibt es ähnliche Mechanismen.
Roi wrote:Wie machst Du das denn?
Bei mir läuft für jeden Benutzer eine Instanz von lighttpd unter der jeweiligen UID. Je nach "Vertrauensstufe" in einem chroot-Jail. Mit Skripten kann man das Bauen der chroot-Jails recht gut automatisieren, so dass du nur einmalig einen Aufwand hast, ein funktionierendes Minisystem darin zu bauen. Mit Portage (Gentoo) kann man die Pakete auch in ein anderes Root-Verzeichnis installieren, so dass die Installation der Programme im chroot-Jail recht leicht von der Hand geht.
Roi wrote:Oha. Drueckt das so stark auf die Performance? Hast Du spontan ungefaehre Zahlen parat? Auch wenn es nur ueber den Kernel aktiviert und das Volume so gemountet ist oder nur, wenn es tatsaechlich aktive ACLs gibt?
Naja, "stark" liegt wohl im Auge des Betrachters. Auf die schnelle habe ich nur den Benchmark von einem SuSE-Mitarbeiter gefunden.
Post Reply