Apache 1.3 und Schutz vor CGIs

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

Apache 1.3 und Schutz vor CGIs

Post by roi »

Guten Abend,

verzweifelt bin ich und auch die vielerwaehnte Suche hier im Forum und bei Google habe ich schon bemueht. Auch die Dokumente auf http://httpd.apache.org halfen nicht weiter.

Um folgendes geht es. Ich habe einen Apache 1.3 unter Debian 3 laufen. Auf diesem Apache laufen diverse VHosts. Nun haette ich gerne, dass VHost-User auch mit Perl-Scripten keinen Unfug anstellen koennen. PHP habe ich per safe_mode entsprechend in die Schranken weisen koennen. Fuer Perl soll sich suEXEC ja gut eignen, nur habe ich entweder kein Verstaendnis fuer die Materie oder meine Installation ist nicht fuer eine solche Loesung geeignet. Irgendwie wird immer geschrieben, dass suEXEC mit Userberechtigungen arbeitet. Auch soll es auf irgend eine Art und Weise schauen, wo in welchen Verzeichnissen das Script unterwegs ist, aber so recht schlau werde ich aus den Beschreibungen nicht.

Folgende Konstellation: Meine VHosts liegen unter
/var/www/www.domain1.tld/
/var/www/www.domain2.tld/
und so weiter. Die cgi-bin Verzeichnisse liegen unter
/var/www/www.domain1.tld/cgi-bin/
/var/www/www.domain2.tld/cgi-bin/
und so weiter. Alle Files in /var/www/, egal zu welchem VHost sie gehoeren, gehoeren www-data:www-data. Der Apache laeuft auch unter www-data:www-data. Upload der Files mit den o.g. Berechtigungen funktioniert per virtuellen Usern ueber ProFTPd-MySQL.

Nun haette ich einfach gerne eine Moeglichkeit, Scripten aus dem Verzeichnis cgi-bin eines jeden VHosts zu verbieten, ausserhalb des VHost-Rootverzeichnisses irgendetwas zu tun. Das ist momentan problemlos moeglich, folgendes Script spuckt ohne zu murren die /etc/motd aus:

Code: Select all

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

print "Content-type: text/htmlnn";

open(FILE,"$htmlfile");
while(<FILE>) {
   print $_;
   }
   exit;
Hier noch meine Apache-Config was die Einstellungen eines VHosts anbelangt:

Code: Select all

<Directory /var/www/http/www.domain.tld/cgi-bin/>
    AllowOverride None
    Options ExecCGI
    Order allow,deny
    Allow from all
</Directory>

<VirtualHost www.domain.tld>
    ServerAdmin webmaster@domain.tld
    DocumentRoot /var/www/http/www.domain.tld
    ScriptAlias  /cgi-bin/  /var/www/http/www.domain.tld/cgi-bin/
    ServerName www.domain.tld
    ServerAlias domain.tld
    ErrorLog /var/log/apache/www.domain.tld/error.log
    CustomLog /var/log/apache/www.domain.tld/access.log combined
    Alias /custom-apache-error-messages/ /var/www/error/
    php_admin_flag engine on
    php_admin_value open_basedir /var/www/http/www.domain.tld/
    php_admin_value upload_tmp_dir /var/www/http/www.domain.tld/tmp/
    php_admin_value session.save_path /var/www/http/www.domain.tld/tmp/
    php_admin_value include_path /var/www/http/www.domain.tld/
    php_admin_flag safe_mode on
    php_admin_value sendmail_from webmaster@domain.tld
    php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f webmaster@domain.tld"
</VirtualHost>
(Fuer andere Verbesserungsvorschlaege abseits des eigentlichen Themas bin ich natuerlich offen, nur her damit!)

Kann mir jemand weiterhelfen?

Vielen Dank,
Roi
athlux
Posts: 61
Joined: 2004-08-20 13:53
 

Re: Apache 1.3 und Schutz vor CGIs

Post by athlux »

Debian ist eigentlich schon auf suexec vorbereitet.

Bei der Installation des Apache sollte debconf dich eigentlich gefragt haben ob Du suexec nicht gleich aktivieren möchtest. Nachträglich tut es auch noch dpkg-reconfigure apache.

Man kann auch unter /usr/lib/apache einen symlink mit namen suexec anlegen und zu suexec.disabled linken. Das ist nämlich die binary.

Wenn alles geklappt hat sollte in der error.log vom Apache stehen

Code: Select all

[notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache/suexec)
Dieser Link sollte eigentlich die wichtigen Fragen noch beantworten.
roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar
Contact:
 

Re: Apache 1.3 und Schutz vor CGIs

Post by roi »

Hi Athlux,

suEXEC konnte ich wie Du beschrieben hast auch aktivieren. Das habe ich auch schon geschafft, bevor ich hier gepostet habe. Im error.log steht auch alles so drinnen wie es sein sollte. Leider fehlt das eigentliche Logfile von suEXEC, warum auch immer.

Die DebianHowTo-Seite beantwortet mir eigentlich gar keine Fragen. Wie gesagt, entweder sehe ich den Wald vor lauter Baeumen nicht oder es eignet sich fuer meine Installation nicht. Was bringt mir denn eine Einstellung von User und Gruppe? Alle VHosts bzw die Dateien innerhalb der VHosts bei mir laufen mit www-data:www-data.

*komplettes Brett vor'm Kopf*

Viele Gruesse,
Roi
wgot
Posts: 1675
Joined: 2003-07-06 02:03
 

Re: Apache 1.3 und Schutz vor CGIs

Post by wgot »

Hallo,
Roi wrote:Alle VHosts bzw die Dateien innerhalb der VHosts bei mir laufen mit www-data:www-data.
das paßt nicht zum Konzept von suexec. Die Verzeichnisse und Dateien jeden Nutzers sollten einen eigenen user haben, und die User zusammen für sich alleine eine Gruppe oder sogar jeder User eine eigene Gruppe. Suexec paßt dann auf daß jeder nur das ausführen kann was ihm gehört und nur in seinem eigenen Verzeichnis.

Wenn Dateien nicht von Usern eingesehen werden sollen setze die Zugriffsrechte entsprechend.

Gruß, Wolfgang
roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar
Contact:
 

Re: Apache 1.3 und Schutz vor CGIs

Post by roi »

Dh suEXEC ist nichts fuer mich, zumindest nicht in meiner Konfiguration? Richtig?

Habe ich in meiner Konfiguration andere Probleme? Momentan mache ich es so, dass Perl-Scripte nicht hochgeladen werden sondern eben zuerst geprueft werden (Perl und CGIs sind eh auf dem Rueckzug, so etwas wird kaum noch verwendet, zumindest kommen selten Anfragen). Ansonsten habe ich keine Schwachstelle gefunden.

Bis auf die eine Ausnahme mit dem Sicherheitsproblem bei Perl/CGI finde das Konzept, das ich fahre, an sich sehr gut. Keine echten User auf dem System, alles laeuft ueber virtuelle User. Und es macht mir auch nach langem Nachdenken einen sehr sicheren Eindruck.
Post Reply